[ODE] ODE in Myst V: A Postmortem
Adam D. Moss
adam at gimp.org
Wed Jun 22 18:22:24 MST 2005
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
More information about the ODE
mailing list