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