[ODE] Contacts filtering/merging

Aras Pranckevicius nearaz at interamotion.com
Mon May 17 21:00:55 MST 2004


Hi,

I recently read a paper in GPG4 by Pierre and Adam on contacts management 
(filtering, merging etc.).

Then I remembered the old "fear the wireframe" problem that occured to me 
when trying to make sphere-wheeled cars that drive on tri-mesh roads. The 
problem is that at triangle edges, the penetration depth computation is 
inaccurate, causing the car to "respond" to triangle boundaries.

Simple example: take two adjacent coplanar triangles. When a wheel (sphere) 
is colliding with one, everything's ok. When it's colliding with both of 
them, the contact code gets penetration distances to triangle edges 
(naturally) and averages them at the end. Now, averaged distance to edges is 
_less_ than a real distance to the mesh plane!

It seems that "no excessive contacts generation" solution for trimeshes in 
GPG4 would help in dealing with this (and generally improve performance as 
well). It would tag the edges between coplanar triangles as such, and just 
compute distance to the surface plane in above scenario...

It would require basically this:
* adjacency info (like 12 bytes per triangle), probably good to have for 
colliders in general,
* bit flags (1 byte per triangle), indicating which vertices/edges of the 
triangle are "insignificant" ones (coplanar with adjacent tris, etc.).
* some (I guess isolated) changes to triangle-sphere and triangle-box contact 
generation (I saw those functions are even in a separate file).

Now, extra 13 bytes per tri may be ok or it might be not (PS2 anyone? :))...


Aras Pranckevicius aka NeARAZ
http://www.gim.ktu.lt/nesnausk/nearaz/



More information about the ODE mailing list