[ODE] ODE in Myst V: A Postmortem

[Colin Bonstead]

Sorry, I wasn't really clear here.  I do run ODE at a fixed 100 Hz, but 
if more than 100 ms passes in a frame I'll clamp the amount I'm going to 
step total that frame to 100 ms.  So the ODE clock and game clock will 
move out of sync at that point.  As far as ODE knows though, every step 
is 10 ms.

At first I did try using a variable step, since that was supported in 
Havok.  It worked great until you had a long frame followed by a short 
frame, at which time contact joints would launch objects out of the 
world.

-----Original Message-----
From: Adam D. Moss <adam at gimp.org>
Sent: Wed, 22 Jun 2005 18:22:24 +0100
To: ode <ODE at q12.org>
Subject: Re: [ODE] ODE in Myst V: A Postmortem

Colin Bonstead wrote:
> The main problem I ran into was with the instability of the ODE 
joints.
> I run our simulation at a fixed 100 Hz, and clamp the per-frame delta 
to
> a max of 100 ms (so we don't kill the framerate even more by doing too
> many steps during a slow frame).  That works great on fast machines, 
but
> on slow ones (ie dropping below 10 fps at times) the joints tend to 
get
> unreliable.

If I understand you correctly, this isn't the recommended way
to timestep.  You're running a variable 0ms<timestep<=100ms, right?

There are three issues with this.  The first is that an ultra-small
timestep causes numerical instability, though there might not be
fast enough machines around to see this much.  Secondly, a 100ms
timestep is (as you've discovered) often too big for catching
collisions while they're shallow and subtly-correctable.  Thirdly
and most importantly, ODE is not happy with variable timestepping.

The third issue has an easy hack which mostly defangs it: add a
smoothing filter which doesn't let ODE's view of the timestep vary
by more than (for example) 3% from frame to frame.

The real solution here is to use a fixed timestep as far as
ODE is concerned: accumulate time deltas each frame, then
perform as many collision+simulation steps as can wholly be
satisfied by the accumulator (which may be none, when the framerate
is rather faster than the simulation update frequency).  Keep any
residue for next time.  (This may be a FAQ, or at least in the
Wiki somewhere.)

That's a little more involved if you want to do it really properly,
because a 11Hz simulation with a 60Hz camera moving through it
looks pretty jarring, so you'd need extrapolation.  But if you can
afford a fixed 60-100Hz simulation then (IME) you can get away
without.

Regards,
--adam
--
Adam D. Moss   -   adam at gimp.org