[ODE] Object hierarchies

[Jon Watte (ODE)]

Jean-Sebastien Guay wrote:

> So yes, I know which objects are composed of which meshes (I make the
> distinction between objects/models and meshes, which are just the polygonal
> elements that make up the objects).

Do you know if those separate meshes attach using articulated joints 
(universal, hinge, ball-and-socket, slider, ...), or are statically 
attached to the root? Do you know if the object, itself, should be a 
simulated body, or whether it should just be statically added to the world?

> So the best thing would really be to combine trimeshes for static objects?
> That's what I thought. I didn't want to go there, because the code base is
> already pretty complex, but I guess I'll just have to do it.

You can start by not doing it, and if you find that you spend a lot of 
time in triangle mesh collisions, try combining them and measure the 
speed-up to see whether it's worth the complexity.

>>Also, for things
>>that move, you don't want to use trimesh geoms, because they aren't that
>>stable. For best stability, you want proxies (boxes, spheres, capsules)
>>for objects with bodies, and trimeshes only for things that stay fixed.

> I didn't know that. Is it mentioned somewhere in the docs? Then I'd have to once
> again go through the geometry and deduce parameters for the proxy objects
> (sphere radius, or whatever) so they envelop the real mesh as closely as
> possible right?

Yes. And I believe the docs mention that trimesh-to-trimesh collision is 
not well supported.

What most game engines do is have the artists place collision proxies in 
the mesh as separate mesh pieces. Just like you'll have separate LODs, 
you'd have a separate "LOD" for physics, consisting of boxes, spheres 
and capsules. Then they could also mark up whether things should 
articulate (and if so, with what kind of joint), or just attach to the root.

Cheers,

			/ h+