[ODE] Static environment vs static joints.

[Jaroslav Sinecky]

I think if you can use plane + boxes for walls, it makes sense to use 
geoms scattered around instead of merging all to a trimesh. But it will 
depend on concrete case which solution will be faster or better (meaning 
better collision points for solver).

Anyway what's really strange is that performance goes down after just 
assigning null bodies to geoms. Is that the only change you made, Josh?
You should probably make sure static geoms don't collide with each other 
using category and collide bits. (Anyway this doesn't explain the 
performance drop)

Jaroslav


Mohsin Hasan wrote:
>
> 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
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>