[ODE] is ODE multi-threaded?

[Jon Watte (ODE)]

Bram Stolk wrote:
> If you profile your application, and it turns out that collision 
> detection and the solver have similar runtimes, you could try 
> application-space multithreading. (2 threads).
You would have to de-couple the spaces entirely.

What this means is that you couldn't create contact joints from within 
your collision callback. Unfortunately, you would also have to do 
something about the dGeomMoved() call, which would race between the 
stepping thread and the collision thread.

What I do is put all of ODE in one thread, and then all of rendering, 
application logic, etc in one or more other threads. If your simulation 
needs more power than a full CPU core gives you, ODE might not be the 
right choice anyway. (Hint: there exist hardware accelerators)

Cheers,

          / h+


> However, you would end up with a 2-stage pipeline, where the solver 
> for frame N uses collisions from frame N-1.
> Not sure if you would encounter race-conditions though.
> You would at minimum need to use two different joint-groups for contacts.
> It would make an interesting experiment.
> Anyone here got some profile stats lying around that can be shared?
> I'm interested in the comparision between dSpaceCollide() and 
> dWorldQuickStep()