[ODE] Contacts and multiple updates per frame

[Bob Dowland]

If your sim is particularly sensitive you should be updating contacts between sub"step"s. I can't see how the other alternatives help in any general way - of course tweaking things for a particular sim is often going to yield local "improvements" but that's another issue.

I think the *proper* thing to be doing here is some form of tracking of system config - a la "sweep and prune" so you can "afford" a full cd refresh between each frame and/or substep. OPCODE has an implementation I think..(?) and well, Google of course..

:)

Bob.



> -----Original Message-----
> From: mucki [mailto:michael.lacher at hlw.co.at]
> Sent: 11 November 2004 08:51
> To: ode at q12.org
> Subject: [ODE] Contacts and multiple updates per frame
> 
> 
> Hi!
> 
> I am writing this in responso to the thread about "Making simulation 
> speed independant from computer speed".
> 
> Both Megan Fox and Jon Watte replied that the best solution 
> for a stable 
> simulation is to use multiple dWordStep() calls with a fixed 
> update time.
> 
> I have tried this too, and had good experience in my simulations, 
> however I repeatedly ran into problems with contact joints. 
> The problem 
> seems to be that ODE behaves badly (sometimes) when a contact 
> joint is 
> kept for more than one update (probably because thebodies are already 
> seperated again in the later updates ?).
> 
> The most accurate solution would of course be:
> 
> timeAccum += elapsedTimeSinceLastFrame
> while (timeAccum > STEP_SIZE)
> {
>    collideWorld();
>    dWorldStep(STEP_SIZE)
>    dJointGroupEmpty(contactgroup);
>    timeAccum -= STEP_SIZE
> }
> 
> however, this brings down the speed to a crawl, as collision 
> takes a lot 
> of time.
> 
> I also tried a cleaning the contacts after the first step like this:
> 
> timeAccum += elapsedTimeSinceLastFrame
> collideWorld();
> while (timeAccum > STEP_SIZE)
> {
>    dWorldStep(STEP_SIZE)
>    dJointGroupEmpty(contactgroup);
>    timeAccum -= STEP_SIZE
> }
> 
> but this also seems to have problems in some cases.
> 
> Of course i also tried the version where the contacts are 
> kept for the 
> whole batch of updates, but it has the above mentioned 
> problems. Maybe 
> someone with inepth knowledge of how exactly contact joints 
> are handled 
> by ODE, and how they interact with the simulation can explain what is 
> going on and why, and which of the two faster methods is the 
> better one 
> to use (the slower, accurate one beeing out of question for 
> performance 
> reasons).
> 
> regards,
> mucki
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>