Variable timestep with Verlet

[ikkah 122]

I''ve made few simple simulations using Verlet integration, and so far, they''ve been running with a constant timestep and locked framerate. I''ve made some lame attempts to get it look good with a variable timestep but they''ve all failed. Are there any ways to have accurate movement with a variable timestep?

[grhodes_at_work 1385]

Your best bet is to stick with a fixed physics time step, then during each frame (which might very well have a different duration/time step each time), just do as many physics steps as you need to catch up. This way, you will be able to achieve repeatable results, and you also will be in better control of numerical stability.

For example, let your physics step always be pdt = 1/50 second. As your render frames roll by, accumulate the time that has past. DO NOT do a physics step *until* the time passed, time_passed >= pdt. Then do as many physics steps as you need to drop time_passed back down to < pdt. Here''s some pseudocode:

pdt = 1/50;
time_passed = 0; // start of simulation
do render loop
{
  time_passed += frame_time;
  while (time_passed >= pdt)
  {
    do one physics step, using pdt as the time step
    time_passed -= pdt;
  }
}
 

Note that you don''t reset time_passed to 0 in that loop!

That seems simple enough. As long as you keep the physics under control so that the time to actually calc the physics is less than pdt and the average frame time, it should work well, e.g., the physics should always catch up with the frame rate while maintaining an easier-to-deal-with physics time step.

Graham Rhodes
Principal Scientist
Applied Research Associates, Inc.

[haphazardlynamed 340]

Careful with that

I tried using the very same solution with my Jakobsen/Verlet physics model

And I got a Beat Frequency between the physics timestep and the framerate
It looked really really horrible, every few frames the remaining time would accumulate till eventually you get enough to have an extra physics loop, so everything would suddenly pop forwards a little more than usual.

Beat Frequency = framestep - physicsstep
so keep them from being close together if you want to minimize this effect (i originally had mine at 16.5framestep and 16physicsstep, so i had a horrendous .5hertz popping)

alternately, you can avoid this alltogether by looping the physics up as far as possible, then looking ahead one frame and using the remainder time to linearly interpolate what the graphics should look like inbetween physics loops

i ended up deciding that I didnt really want to mess with linear interpolation (expensive) so what i did was take the remainder time after physics looping, and instead of passing it to the next frame I rounded it up or down to fit the physics interval
thus in my version, the physics engine is stable since it always uses a fixed timestep, there is no beat frequency issue, but the game as a whole can speed up or slow down (desynchronize with realtime) if your computer gets too busy
My solution is not a good way to go if you want to ever do Multiplayer, but it looks pretty smooth
however.... i belive one of the Quake games had this problem, if you set your monitor to some wierd refresh rate you could cheat and run a lot faster.....

[Guest Anonymous Poster]

For integration, using the ratio between time steps in the integration should give nice results:

float ratio=timeStep/oldTimeStep; //precalc
position += (position-oldPosition)*ratio;

Do the same for accelerations. However, unsatisfied constraints may yield strange results (varying stiffness with varying timestep).

Dennis