[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