plib-users

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)

Re: I: [Plib-users] triangles from branches

[Paolo S. <ax...@ti...>]

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

6 months? woah! Seems an hard task! ;)

> 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.

We managed to fix our code, but if I'll fall in trouble again now I know 
whom aks for help.
If anyone would like to see it jusk ask. Development is closed since 
it's for a university course, but the code is under the GPL.

...
> 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.

I noticed some trimeshes problems, so I ended up using planes, I was 
lucky it's convex obj...
I seem have a deep knowledge of the ode lib, are you involved in it's 
development?

> 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.

Sincerely I don't know what a lasttransformation is. ^^;

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

Probably I will!

> Good luck -

Thank you
--
Paolo Sacconier

R: 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: domenica 7 novembre 2004 14.39
> A: pli...@li...
> Oggetto: Re: I: [Plib-users] triangles from branches
> 
> 
> Paolo Leoncini wrote:
> ...
> > Yes, I did it in the last six months. I'd like to make it 
> public after 
> > a generalization and cleaning of the code.
> 
> 6 months? woah! Seems an hard task! ;)

Yes it is when you want to implement a real life case (mesh order of 1M
vertices and 10k leaf objects, dynamics world order of 10 bodies, 100
contacts) of some industrial interest.

> 
> > 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.
> 
> We managed to fix our code, but if I'll fall in trouble again 
> now I know 
> whom aks for help.
> If anyone would like to see it jusk ask. Development is closed since 
> it's for a university course, but the code is under the GPL.

There's a site where one can post pieces of source code to let other
look at it - can anyone recall the address?

> 
> ...
> > 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.
> 
> I noticed some trimeshes problems, so I ended up using planes, I was 
> lucky it's convex obj...

Look at James Dolan's patch
http://q12.org/pipermail/ode/2004-August/013632.html (not yet included
in a ODE distribution) which includes a perfectly working trimesh vs.
plane collider - it helps a lot and it's something incredibly missing in
ODE.

> I seem have a deep knowledge of the ode lib, are you involved in it's 
> development?

No, my knowledge remains at "user" level. But I really red the ODE
manual word by word. 

> > 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.
> 
> Sincerely I don't know what a lasttransformation is. ^^;

It is the mechanism to tell ODE about the "movement history" of a
trimesh (temporal coherence). Things go much better with trimesh when
you supply this information back to ODE.
This is a sample code to update the trimesh position/orientation after
the simulation step:

		const dReal *R = dBodyGetRotation( b );
		const dReal *pos = dBodyGetPosition( b );
		dTriMeshDataID TriMeshData = ...your pointer to trimesh
data;
		double bodyTransformationMatrix[16] = {
	
R[0],R[1],R[2],0,R[4],R[5],R[6],0,R[8],R[9],R[10],0,pos[0],pos[1],pos[2]
,1
		};
		dGeomTriMeshDataSet( TriMeshData,
TRIMESH_LAST_TRANSFORMATION, (void *)bodyTransformationMatrix );

> > Please feel free to contact me personally for further 
> hints, there are 
> > lot of them.
> 
> Probably I will!

You're welcome.

> > Good luck -
> 
> Thank you
> --
> Paolo Sacconier

Greetings -

Paolo Leoncini