[ODE] Finally Trimesh-Trimesh collision works!!
f.brebion at vrcontext.com
Thu Oct 26 12:22:12 MST 2006
Francisco Leon wrote:
>Good news: Finally ODE Trimesh-Trimesh Collision works
>Really works. No fakes!!
>Trimesh-trimesh collision system was refactored,
>replacing OPCODE with GIMPACT.
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
More information about the ODE