I: [Plib-users] triangles from branches

[Paolo L. <p.l...@ci...>]

> -----Messaggio originale-----
> Da: pli...@li...
> [mailto:pli...@li...] Per conto di
> Paolo Sacconier
> Inviato: luned=EC 25 ottobre 2004 16.23
> A: pli...@li...
> Oggetto: [Plib-users] triangles from branches
>=20
>=20
> Hi,
> I'm new to this mailing list. I'm trying to use plib together with ode
> (www.ode.org) dynamics engine, did anyone have some=20
> experience with it?

Yes, I did it in the last six months. I'd like to make it public after a
generalization and cleaning of the code.

> My main problem is that I need to access the triangle data for a given
> object (ie a branch entity, which contains data loaded from a=20
> model in=20
> .ac format) to create the geometric rapresentation for the ode's=20
> collision detection system. Is there a simple way to reach these=20
> informations using plib api? I couldn't figure out from the docs.

I attached some code but was blocked by the list - just tell me where to
send it.
At the end of the file there's the actual 'entry point', i.e. given a
node name load all the subtree leafs' geometry into corresponding ode
trimeshes. There's a number of utilities you could find useful for your
ambitious task. Among leaf data the only to actually duplicate is
indices (shorts in SSG, ints in ODE) - the rest is a pointer to SSG
vertices/normals structures.

It creates a geomtransform and the related geom with the transformation
along the path from the root to the node. Keep in mind that a ODE body
requires absolute positioning, while the set of transformation+geometry
in SSG put your object already in its absolute position. When you'll get
either the body position, or the geom one, you cannot put it into the
SSG transform node directly. I suggest to 'subtract' the body position
(and orientation of course) from the transformation+geometry bundle, so
that the geom pos-orient just represent the offset from the body. This
is not done in the code for clarity, and it's not so easy to accomplish.

Don't expect reliable collisions between trimeshes, at least for
dynamics. Keep the gravity low, and use a very small step. Use the
Quickstep instead of the WorldStep since with many contacts the last
quickly become unusable and sonn get stack overflow.

Furthermore don't underevaluate a hidden aspect: lasttransformation are
*important* for ODE trimeshes. I included my
update_trimesh_lasttransformation, which should be first called with a
dSpaceID and a null body. Then it will recursively apply the proper
action on the trimesh data for each space's trimesh. It is not called in
any place into the code excerpt, and you should call it after the
simulation step.

Please feel free to contact me personally for further hints, there are
lot of them.

> TIA.
> --
> Paolo Sacconier

Good luck -

Paolo Leoncini (p.leoncini a_t cira.it)