I'm updating the physics using a "time-slicer" to ensure constant stepping at different frame times:
// time accumulator
static float elapsed = 0.0f;
elapsed += timeSinceLastFrame;
// update using time slicer
while( elapsed > m_timestep )
m_world->stepDeltaTime( m_timestep );
vdb->step( m_timestep );
updateDisplay( m_world );
elapsed -= m_timestep;
This generally works quite well as illustrated in the following part of a screenshot:
As you can see one physics step is performed per frame (framerate is locked at 60 fps, m_timestep = 1.0f / 60.0f ).
But on some machines, in certain situations (probably due to process scheduling) the frametimes get very "wacky".
The first screenshot shows the beginning performance slowdown due to another process using more CPU time.
This is no big deal because the timesteps of the physics catch up and keep the "physics framerate" at its desired 60 fps.
But sometimes (e.g. on another machine) something strange happens as shown in the right image.
A periodic "peak" in the frametime appears, without the overall system load being stressed too much. These regular peaks result in "update bursts" of the physics in the above code sample, which result in really wacky physics. This means there are partially smooth movements but there are regular "jumps" in the movement of the bodies.
Is there a way to ensure the physics runs smoothly but still at a locked update rate (which is as far as I know very important for running a game over a network)?
Thanks for any help or advice!