Little bug in stepSimulation, or is it me?

[marcimatz]

Hello,

I noticed some inconsistency in the stepSimulation function, please let me know if I am wrong:

In my understanding, following two piece of code should yield the same result (if dt is a multiple of subDt):

Code: Select all

dynamicWorld->stepSimulation(dt,1000,subDt);

or

Code: Select all

for (int i=0;i<dt/subDt;i++)
    dynamicWorld->stepSimulation(subDt,1000,subDt)

But it doesn't. It seems that the position/orientation of kinematic objects is not interpolated internally, which means that example 1 will result in impact impulses that are too high. A simple example would be to have a kinematic box that is moved from position A to position B during dt. A smaller dynamic box is in the way and gets pushed away. In example 1 it seems as if the impact impulse on the small box is calculated from the kinematic box moving from A to B within subDt and not within dt.

I am not sure if this behaviour is intended. For now I perform the interpolation of my kinematic bodies in a loop of following style (pseudo code):

Code: Select all

for each kinematic body:
    transformationDifference=oldTransformation.getInverse()*newTransformation // calculate variation during dt
for (int i=0;i<dt/subDt;i++)
{
    for each kinematic body:
        setRigidBodyPositionAndOrientation(oldTransformation,transformationDifference,(i+1)/(dt/subDt)) // set the interpolated pos/orientation
    dynamicWorld->stepSimulation(subDt,1,subDt)
}

[ola]

Hi,

Bullet does not interpolate the movement of kinematic objects, it's all up to you to move them about. So if your framerate is lower than 60 Hz and you update your kinmatic objects outside stepSimulation, Bullet might do more than one internal substep in which your kintematic objects will remain static.

There are at least two ways of fixing this. You can either use the m_internalPreTickCallback callback function that is called in the beginning of each internal substep. Update your kinematic objects in that function.

Alternatively, you can create your own dynamics world class inheriting btDiscreteDynamicsWorld. Re-implement btDiscreteDynamicsWorld::internalSingleStepSimulation(btScalar timeStep), it can be like this:

Code: Select all

yourclass::internalSingleStepSimulation(btScalar timeStep)
{
   // update all your kinematic objects
   // HERE

   // then call Bullet's step function
   btDiscreteDynamicsWorld::internalSingleStepSimulation(timeStep);

   // And then you can do other post-process things like iterate over collisions to trigger sound effects etc.
}

I usually do this, but I guess it's mostly because this was the only way to do this before the callbacks were introduced. One advantage is that you have access to all the internals of btDiscreteDynamicsWorld if you want to do more advanced things.

I recommend taking a look at the source in btDiscreteDynamicsWorld::internalSingleStepSimulation(btScalar timeStep) to see what's really going on.

Best regards,
Ola

[marcimatz]

Thank you very much Ola,

This clarifies it. Intuitively I would have expected this interpolation to happen in the stepSimulation function since dynamic bodies are also interpolated in there, that's why I thought of it as a bug.

Thanks again

[nanocell]

Greetinz,

I have ran into this same problem with lack of kinematic interpolation. I accept that bullet does not perform the interpolation, so my question is this:
Is this behaviour actually intended or is it a bug?

The reason I would think that this is a bug is because the default behaviour of non-interpolating kinematic objects generates large (and problematic) impulses, as stated by marcimatz.

Any insight on this?

Kind regards,
Van Aarde.

[eweitnauer]

Hi.

I spend quite some time on the same issue. I also was expecting Bullet to interpolate the position of kinematic objects between last and current position in the internal steps. And didn't Erwin Coumans say just that in this thread:

1) Do you actually set the velocity at the beginning of the timestep such that you reach the desired position at the end? Otherwise you just beam objects around. This would definetely help the solver.
2) I would also try to adjust solver (Bullet) if you set a target position and you take several small substeps in a way that the current and target positions get interpolated and that you only reach the target position at the last substep.

It might be that this is actually already done in Bullet. I am just guessing here...!

Both things should be already done in Bullet, if you use the motionstate.

But maybe I misunderstood his answer. In my opinion it would be helpful to add some note about the kinematic object + interpolation behaviour to the documentation.

Kind regards,
Erik.