[ODE] CFM and timesteps

[whitt013]

Forgot to change the address...
====================
I'm no expert, but I do know this:  collisions in ODE are NOT resolved until
penetration has already happened (dCollide's job is to set the penetration
_depths_ and contact positions in the contact structs).  To my understanding,
CFM and ERP work together to decide how many timesteps it takes to resolve a
constraint, including a penetration.  So if the timestep is larger, an object
can penetrate further into what it's colliding with, but still has the same
number of timesteps to get back out.  So ODE adds more force to push it
further.  So yes, CFM and ERP are timestep dependent, but only because the
collision system is.

Methods of resolving collisions the step before they happen have been
discussed on the list, but were dropped because they would basically entail
simulating the next timestep, then rewinding to the point of the first contact
and resimulating, until all contacts were resolved with depth 0.....  Pretty
expensive operation if you have a bunch of wheels (for instance) on the
ground.

Here's my suggestion: keep the same calculations you have now, but keep up
with the previous timestep as well, then do something like:
desiredTimeStep = currentTime - prevTime;
prevTimeStep = prevTimeStep + (desiredTimeStep - prevTimeStep) / 10;
dWorldStep(prevTimeStep);

That way if you were running at 50 fps and bogged down to 20 fps in one step,
one of two things would happen:  you would stay at 20 fps, and your simulation
would slide into a .05 timestep about a second later, or you would get back up
to 50 fairly quickly and the timestep would follow.  In the more common case,
your simulation speeds might vary within a 10th of a certain average, but the
values you give to dWorldStep will only vary within a 100th of that average,
keeping the steps a lot closer to constant and the simulation a lot more
stable.  The bad thing is, say you just simulated a big car crash, so your
scene dropped to 5 or 10 fps.  There's still a car out there flying towards
the pile-up, but by that time it's covering a full car length every step.
Worst case, it is within inches of running into the pile in one step, and
completely inside it the next...... and the whole pile explodes to infinity
and beyond (unless your adaptive CFM calculations have turned the pile into a
tub of jello by then).   A maximum timestep might keep scenarios that bad from
cropping up, but only localizes the effect a little more.

Just my 2 cents.
David

>===== Original Message From amundbørsand <amund@c2i.net> =====
>"gl" <gl@ntlworld.com> skreiv:
>
>> > Yes, but you're not really supposed to do that, are you? And I thought
>> > ODE finds out where the intersection/collision occurs ahead of time, and
>> > applies forces accordingly, not waiting until *after* objects have
>> > intersected, it's not using penalty methods. The way I see it your
>> > example is an error in the simulation and shouldn't happen.
>>
>> Can't answer that as I'm not clued up on that side of it yet.  I did some
>> tests with box stacking early on though, and larger timesteps resulted in
>> deeper penetration, so again you will get different results - but if you
>> don't have any of those requirements and it looks fine in your app, then
>> you're obviously OK : ).
>
>If I remember correctly, the boxstack example uses CFM, and CFM and ERP
>is stepsize dependent! =) But of course errors will sneak in more
>frequently and in a larger scale with larger time steps, and roundoffs
>and inaccuracies will be more significant and/or cause different
>solutions. But in my case it seems to work fine, which is what I hope
>for as well, because running smooth graphics at an optimal framerate is
>not easily crossed with constant time steps (unless your're running on
>75 fps refresh rate, but then you'll get such a drastic decrease if the
>computer can't keep up and drops to 35).
>
>
>_______________________________________________
>ODE mailing list
>ODE@q12.org
>http://q12.org/mailman/listinfo/ode