[ODE] Trimesh Sphere Interactions - how to break 'test_trimesh.cpp'

[Alex Green]

Thanks Megan, my stepsize is 0.01 and this or size of forces acting are 
not the problem as dCollide always returns zero when there is a problem.
My triangles are from very small to a number of units in size and my 
object is about 2 units in size (spheres 0.4 units).
You have given me my first clue that ODE uses counter-clockwise winding. 
This explains why I need to flip my mesh upside down. I was under the 
impression ODE used 'any triangle winding' or 'just a soup of 
triangles'. Why do box's sometimes work (ie wheels fall through 
clockwise mesh but body rests on top)?
Also what is the effect of passing the normals? I pass the normals to 
buildSingle1() and I draw them for debugging, and my mesh looks like a 
nice little hedgehog with all the normals pointing upwards, but seams to 
have little effect on the behavior of the system.
I will have a play with the winding and will try some of my experiments 
on test_trimesh.cpp. Anything interesting I will post.

NORMALS: what does passing them to
dGeomTriMeshDataBuildSingle1(, , , , , , ,normalsPTR) do?

Any more detail on how ODE interprets winding order and collisions?

Thanks again -alex


Megan Fox wrote:
> I dropped my trimesh heightmap in and it worked on the first try -
> same code worked for arbitrary meshes as well, extremely solid.  I
> would be curious what you consider a small stepsize (try 0.01), and I
> would also be curious what scale your forces are and what scale your
> objects are vs the trimesh triangles.
> 
> Winding Order - affects the generation of the normals from the trimesh
> data.  So, you need the same winding order on all your triangles (I
> believe you need counter-clockwise winding order, but if that doesn't
> work, just flip the mesh or try it the other way).
> 
> Normals - I ended up letting ODE generate the normals for me.  As I
> said, they're influenced by the winding order of the polygon.  If you
> don't wind all the triangles in the same way, your normals will point
> in different directions.
> 
> 
>>From the results you're getting, it sounds as if your winding might be
> problematic, but I really can't say going from just one email posting.
> 
> -Megan Fox
> 
> On 5/16/05, Alex Green <alexg at acfr.usyd.edu.au> wrote:
> 
>>My simulation has a vehicle with spherical wheels and a trimesh terrain.
>>I have had a lot of trouble getting consistent results with the trimesh
>>sphere collisions. My stepsize is small and my erp is fine. Trimesh
>>sphere collisions only work when the trimesh data is upside down and it
>>depends on the shape of the trimesh. I have scoured the mail archives to
>>no avail. For testing I output a txt file of every triangle in the
>>trimesh data structure and they are: valid triangles, wound in the
>>clockwise fashion and the normal points correctly. No Surprises.
>>
>>Today I ran some experiments with the trimesh example code. Try this:
>>Take 'test_trimesh.cpp' turn the trimesh upside down by inserting the
>>following lines after the trimesh is created:
>>  dMatrix3 triRot;
>>  dRFromAxisAndAngle(triRot, 0, 1, 0, M_PI);
>>  dGeomSetRotation(TriMesh, triRot);
>>  dGeomSetPosition(TriMesh, 0, 0, 1.0);
>>
>>Now drop a sphere on the trimesh, it falls straight through!! Drop a box
>>it may work. To start with the following questions need to be put
>>straight for all the new users using trimesh:
>>
>>What effect does the WINDING ORDER of the triMesh have on opcode/ode
>>simulation?
>>
>>What effect does the SHAPE of the trimesh (eg. convex, concave) have on
>>the opcode/ode simulation?
>>
>>What effect does including the NORMALS actually have in
>>dGeomTriMeshDataBuildSingle1(, , , , , , ,normalsPTR)?
>>
>>What else do you need to know to get reliable trimesh/shpere collisions?
>>
>>When I sort this out I will be happy to write up a section in the WIKI
>>on trimesh use. Many thanks -alex green
>>_______________________________________________
>>ODE mailing list
>>ODE at q12.org
>>http://q12.org/mailman/listinfo/ode
>>
> 
> 
>