[ODE] Trimesh-Trimesh and Triangle Normals

Patrick Enoch Hendrix_ at gmx.net
Sun Jul 3 20:08:08 MST 2005


The collider forgets to reverse the generated contact normal when the  
"collision order" of the objects change:
The code works correct for "A collides B". When this order is changed  
to "B collides A" (e.g. when the triangle
of B encloses the triangle of A) the contact normal must be reversed  
as well (because it will point from B to A, but the
main collision call expects values for "A collides B"). The contact  
point must be adjusted, too. (by depth*normal).

Furthermore, almost all checks dealing with the relative velocity  
yield wrong results. They should be disabled.

When having fixed the above things, you still have a lot of "fall  
throughs" which result in duplication of the nearest
contact point. Especially when the relative velocity is very small,  
and there are perpendicular triangles
(like cube on plane).

Problem is as follows:
Imagine a large cube A with 1x1x1 divisions, and a small-triangled  
flat surface B. When the cube penetrates the mesh
the big downward face will be behind a lot of little triangles, but  
cause no collision with these. Even worse, the penetrating face
will not collide at all with the mesh. Only the perpendicular faces  
collide with the mesh. In this case you have
to decide: go with shallowest penetration (mesh triangles are very  
small thus causing a very small penetration)
or with largest penetration (correct choice in this case).
Dealing with relative velocity wont help here, because the cube might  
be sliding on the surface.

Patrick


On 3. Jul 2005, at 19:25 Uhr, Peter Kyme wrote:

> After struggling to figure out why I was getting such poor results  
> with the trimesh-trimesh collider (despite the fact it seems to  
> work quite well in Softimage XSI), I've finally found what appears  
> to be the problem (for me anyway).
>
> By adding one line that reverses the normals obtained for triangles  
> on the 2nd trimesh, almost all of the problems I was seeing went  
> away. This makes sense, since before this I would get contact  
> normals facing in the wrong direction whenever a triangle normal  
> from the 2nd geometry was used.
>
> Can somebody (Jeff Smith?) explain why I needed to do this? Is it a  
> symptom of another problem in the way I'm using the trimesh-trimesh  
> collider?
>
> The above also fixed the problems with the test_moving_trimesh demo  
> as well for me (once the dGeomTriMeshDataSet call had been added).
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>
>



More information about the ODE mailing list