btDiscreteDynamicsWorld::stepSimulation

[dkfdkf]

So I'm looking at btDiscreteDynamicsWorld::stepSimulation and near the end of the function I see:

if (numSimulationSubSteps)
{

saveKinematicState(fixedTimeStep);

//clamp the number of substeps, to prevent simulation grinding spiralling down to a halt
int clampedSimulationSteps = (numSimulationSubSteps > maxSubSteps)? maxSubSteps : numSimulationSubSteps;

for (int i=0;i<clampedSimulationSteps;i++)
{
internalSingleStepSimulation(fixedTimeStep);
synchronizeMotionStates();
}

}

synchronizeMotionStates();

return numSimulationSubSteps;
}



I'm wondering ... why is there an additional synchronizeMotionStates()? if the number of steps is 0, why do we need to synchronize? if it's not 0, why do we need to synchronize twice in a row (since the previous function would be another synchronizeMotionStates())

Thanks!

[Erwin Coumans]

Passing in a btMotionState object in btRigidBody constructor, allows you to interpolate transforms in-between the simulation steps. The synchronizeMotionState will perform automatic interpolation. See CcdPhysicsDemo, uncomment the output of stepSimulation, press 'I' in the demo (to suspend) and press 'S' for single step. Watch the console output for interpolated frames or simulated (including dropped frames).

As you pointed out correctly, in case of a internal simulation step, there is a redundant synchronizeMotionState. Usually this doesn't take much time, so I haven't optimized this case away. We can add a simple check to avoid this.

Thanks for reporting,
Erwin

[dkfdkf]

Awesome thanks! My first reaction in seeing it was that this was some iterative process, and we always wanted to run one more time or something; but knowing it to be exact is even better!