[ODE] ODE in Myst V: A Postmortem

[Shaul Kedem]

Wow. This is awsome. I played URU and loved it (well, the physical
puzzles were a bit dodgy.. but then again, they were the first ever).

It's great seeing ODE in such a high profile game. 

Anyway Colin, if you may; is there going to be a linux version?

Thanks,
Shaul

On 6/22/05, Colin Bonstead <colin at cyan.com> wrote:
> 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
> 
> 
> 
> 
> 
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>