[ODE] Finally Trimesh-Trimesh collision works!!

[Flavien Brebion]

Francisco Leon wrote:

>Good news: Finally ODE Trimesh-Trimesh Collision works
>correctly.
>
>Really works. No fakes!!
>
>Trimesh-trimesh collision system was refactored,
>replacing OPCODE with GIMPACT.
>
>see: http://gimpact.sourceforge.net
>  
>
After checking the API in more details, it looks pretty good, and i'm 
noticing an improvement of x4 / x5 in performance in your gammaleon demo 
compared to opcode ( Pentium D 830 3 Ghz ), while spawning a few 
hundreds of various primitives ( a few cubes, a few spheres, and lots of 
tri-meshes ). It slows down a bit when the objects are spawned quickly, 
but it stabilizes and maintains a very good framerate ( 200-ish ) when 
all the objects are at rest; in the same config, opcode gets no more 
than 40-50 fps.

I'm still hesitant about GImpact though. It seems to handle pretty well 
the case large amount of simple tri-meshes, but does not seem so 
optimized for a low amount of very complex tri-meshes.

As i understand it, dynamic tri-meshes ( those who have a transformation 
matrix ) requires to update the *whole* vertex array of the tri-mesh 
each time the transformation matrix changes ? So, moving a single 
tri-mesh of 10K vertices at 60 fps requires 600K vertex transforms per 
second ? Also, the per-triangle AABBs have to be updated, is that 
correct ? Note that i haven't measured this performance, maybe it's not 
so bad, but those were my first thoughts when i digged into the API.

What are the other limitations of the library ? Does it work with ODE 
compiled in double-floating point mode ? Or in 64 bits ?

I noticed some strange defines / settings in the API, one specifies the 
maximum bounding box of the scene to be +-1638.0f, what happens if a 
scene is larger ?

Otherwise, it looks very good and seems more robust than Opcode's 
trimesh code.

F. Brebion