[ODE] Static environment vs static joints.
Josh Singer
joshua.b.singer at gmail.com
Fri May 26 11:32:50 MST 2006
Yes, the only thing I changed was using static geoms for wall objects
instead of dynamic bodies attached to the static environment with fixed
joints. The surprising thing was that the dynamic bodies approach performed
better.
I thought of introducing category and collide bits, but I think I could do
this with either approach, so it's a separate issue. I might try that with
the static geoms design and see what happens.
josh
On 5/26/06, Jaroslav Sinecky <sinecky at telefonica.net> wrote:
>
> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://q12.org/pipermail/ode/attachments/20060526/1f8b5b4c/attachment.htm
More information about the ODE
mailing list