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

[Nguyen Binh]

 Jeff!

JS> Right. Like I've mentioned in my previous mails to the list, you have
JS> to use smaller steps, and more contacts, that test_moving_trimesh.cpp
JS> currently uses.  When I have some free time, I'd like to change the
JS> test suite to better handle trimesh/trimesh collision.  (Or maybe you
JS> can...)

    OK, I'll play with it...

JS> I have used hundreds of different meshes, with sizes from tens of
JS> faces to tens of thousands.  The step sizes I used vary, depending on
JS> the complexity of the scene, from 8 msec to 0.05 msec (plus, I use an
JS> adaptive substepping method which can change the stepsize as needed).
JS> I allow up to 128 contacts per collision, but usually get far fewer
JS> (10-40 roughly), which I then combine before feeding them to
JS> dJointCreateContact.  These may sound like extravagant demands but
JS> remember: interactive games generally do not need exact
JS> trimesh/trimesh collisions, and when they do they can almost always
JS> get by with very low-res meshes.  In the application in which I'm
JS> using ODE, computation time is not really an issue but good, exact
JS> collisions are.

    That sounds good! I hope the problem can be cured by smaller
    stepsize. For adaptive timestep, I had tried this before but I
    don't see any good impact so I left it. But maybe the results are
    my test scene was too simple for using adaptive approach

JS> One of the primary problems with a GJK-based method (besides being
JS> hard to implement) is that it requires you to carve up your trimeshes
JS> into a collection of convex solids.  This can only be done
JS> analytically for closed meshes; for open meshes (or general
JS> non-manifold meshes), you'd have to use some heuristic for the
JS> "carving" process. All of this is expensive and can result in large
JS> numbers of convex solids.  Consider the pathological (but common) case
JS> of a thin-walled bowl.

    Yes, but everyone use this and I guess it's the only good way to deal
    with trimesh now.  I've never think of decomposition open mesh
    into list of convex.

    Before, Aras had tried to implement convex geom in ODE but I've
    never seen the result so far.


-- 
Best regards,

---------------------------------------------------------------------
   Nguyen Binh
   Software Engineer
   Glass Egg Digital Media
   
   E.Town Building  
   7th Floor, 364 CongHoa Street
   Tan Binh District,
   HoChiMinh City,
   VietNam,

   Phone : +84 8 8109018
   Fax   : +84 8 8109013

     www.glassegg.com
---------------------------------------------------------------------