[ODE] Stepsizes and framerates

Chris Klein cdkode at ennui.dnsalias.net
Fri Dec 13 11:11:01 2002


On Fri, 13 Dec 2002, Nate W wrote:

> On Fri, 13 Dec 2002, Anders Olofsson wrote:
>
> > Need some advice on stepsizes.. I'm timing how long time a loop is
> > (rendering+simulation) and then sending that time as stepsize to
> > dWorldStep().. This is done to keep the simulation running at correct
> > speed. When the framerate goes down, objects needs to move faster and
> > so on..
>
> That's pretty much the method I'm using, but the elapsed time is clamped
> between 1 and 15 milliseconds.  A minimum of 1 prevents divide-by-zero
> errors, and a maximum of 15 prevents the instabilities that come with long
> step sizes.  One problem with this approach is that the simulation slows
> down when the true elapsed time exceeds 15ms.  With LOTS of joints (e.g. a
> centipede) the simulations gets very slow.  But for my purposes,
> slow-and-stable is preferable to real-time-but-unstable.

For both of you, I'd recommend decoupling your simulation and render
loops.  I think other people here have pointed out the benefits of having
a fixed (and small) timestep for simulation accuracy.  A fixed timestep
will also result in getting the same behaviour from your system from
different platforms.

Plus, there's nothing that says you actually have to run one render step
per simulation step.

A couple of approaches are - 1.  if you can get an event signal every x ms
(libsdl provided this for me rather nicely when I was using it), do a
simulation step of length x. Spend the rest of your time rendering.

2. Keep your timesteps of length x ms, and every time you're going to run
your world, run N timesteps of length x so that x * N ~= elapsed time.
Then render once.  (this is what I use now.)

(In fact at the moment I'm getting about 30-50 fps rendering, but doing
several simulation steps inbetween each frame.)

The problem with both these approaches is that if you do hit situations
where it takes longer to simulate than you have time available you will
grind to a screeching halt.  But capping the number of iterations per loop
should help here anyway.

--Chris