[ODE] Static environment vs static joints.

[Mohsin Hasan]

If all the static objects remain static throughout the execution of a level,
I would suggest using a trimesh to represent them. It's collision is quite
optimized compared to you having geoms throughout the level to represent the
walls.

 

Mohsin

 

  _____  

From: ode-bounces at q12.org [mailto:ode-bounces at q12.org] On Behalf Of Josh
Singer
Sent: Friday, May 26, 2006 9:12 AM
To: ode at q12.org
Subject: [ODE] Static environment vs static joints.

 

Hi folks, 

I have a world containing many moderately complex objects that I intend to
be fixed to the static environment. Think of them as walls in a 2d maze.
Bouncing around between these walls are my non-static objects, which are
even more complex, but less numerous. 

For reasons of simplicity I initially modelled the wall objects using their
own individual bodies, and used static joints to fix them to the static
environment. From the documentation on static joints (and from common sense)
I knew this was a wasteful and inefficient approach. And, when they are
bumped hard, the walls do move very slightly, which I do not want. 

So, as a clean up task I thought it would be best to model these wall
objects as geoms fixed to the static environment, as the ODE documentation
suggests. That is, I do not set a body ID on them. The new implementation
appears to be fine in the sense that the collisions and dynamics appear to
be correct. 

The only problem is, due to this change, the performance of the simulation
has got quite a bit *worse*, whereas I expected it to get better. I am
guessing that the hit is on the collision detection side rather than the
dynamics side, since there are now far fewer bodies. I am using
QuadTreeSpace for my collision space. 

Does anyone have any idea why my performance has suffered due to this clean
up?

josh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://q12.org/pipermail/ode/attachments/20060526/8e5e1394/attachment.htm