[ODE] CFM and timesteps

[gl]

> Why? I see no problems with my simulation. I've inserted a maximum
> timestep, in case something freezes for a while, which multitasking
> operating systems sometimes do, to keep ODE from crashing or doing
> strange things, I guess that could happen if timesteps suddenly get too
> big.

Well, two reasons (in my case).  a) using variable timesteps, as noted in
the docs, produces different results; 2 x 0.1s timesteps != 1 x 0.2s
timestep.  This also means that if you want the simulation to be completely
deterministic (eg. for replaying events exactly, with just starting
positions/velocities as input), again you'll need a fixed timestep.

b) In some circumstances (a client/server multiplayer game for example), the
server would run at a fixed timestep and then synchronize its clients off
the results.

> Have you thought of how complicated fixed timesteps would be, and how

Not at all, see my code.

> inefficient it is to run the physics engine for several times per frame?

See above.

> Why should this cause any problems? I've noticed you (all of you)
> stressing this, but why? Except for CFM and ERP, if ODE is properly
> written physics-wise (and it certainly is as far as I can see), and
> except for the possibility of colliding objects travelling through
> eachother, there really shouldn't be any problems. Besides, the time
> steps will never be bigger than 1/10 sec anyway.

I'm no maths whizz, but as I understand it, the integrator in effect uses
linear segments to simulate trajectories - different timesteps, different
results.  Also intersection behaves very differently with different
timesteps.  Example - try spawning a sphere just below a plane at different
timesteps - the speed it gets kicked out varies heavily with different
timesteps.  I'm sure someone else can give a more eloquent answer...
--
gl