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

[Patrick Enoch]

Unless you are generating some non-standard normals for the mesh, its  
probably safer to
let ODE generate them for now.

Each triangle of the soup has its own orientation (front/back)  
determined by its normal.

When passing vertices and normals to ODE watch out you use the  
correct buildXXX function. There will be
no error checking and you just get weird results. This is related to  
double and float builds of ODE and
also passing the correct "triangle-stripe".

normals must be passed as a double/float[3][x] array. have a look at  
the collision function for that. also
have a look there for ODE generation of normals there.

Patrick

On 17. May 2005, at 4:06 Uhr, Alex Green wrote:

> 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
>>>
>>>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>
>