Trimesh-trimesh collider (was Re[2]: [ODE] Triangle-box collider contribution)

Jeffrey Smith jeffreys at Softimage.com
Tue Apr 6 10:34:11 MST 2004


Nguyen Binh wrote:
> Regards the new trimesh-trimesh collider :
> IMHO, it's not (yet) mature to use in real life. (No offense Jeff
>  :)). 

How did you test it?  What step function/stepsize did you use?  How
many contacts did you allow the collider to create?  I've been having
very good (although certainly not perfect) performance when using
dWorldStep, a step size of about 0.5 msec and up to 128 collisions.
Stacking trimesh objects still causes problems, for reasons I haven't
been able to track down, but "simple" collisons between multiple
trimesh objects works just fine for me.

> But everyone knows tris-tris is amazingly hard so the first brick is
> very important!

Actually, given the current architecture of ODE, it's basically
impossible to do trimesh/trimesh collisions "correctly". With some big
changes to the way trimeshes are represented, I think we could do a
convex decimation/GJK approach, which is what Havok, Maya and others
use.  However, the amount of work involved in this solution is so
large that I chose a more "heuristic" (i.e. wild-ass guessing) method.

> Then, with the existence of moving trimesh, we really need a
> dMassSetTrimesh() . I had done it before so I'll look back and
> contribute it.

Currently, I just set the mass based on the bounding box of the
trimesh. A more "correct" approach would be great, but remember that
it has to handle solid vs. hollow objects as well as polygon soup
meshes (i.e. meshes with no particular notion of "inside" and
"outside."

Jeff



More information about the ODE mailing list