[ODE] ODE-GIMPACT performance and advices

Francisco Leon projectileman at yahoo.com
Fri Oct 27 04:01:45 MST 2006

The main problem with the old ODE-OPCODE
implementation wasn't OPCODE; it was the 'finding
triangle contacts' algorithm.

At first instance, I've discover that the clipping
polygon function was wrong, because it was clipping in
clock oriented order when in ODE we are working with
inverse clock oriented order (DX vs OpenGL systems ).
After this mistake it forces to calcule the triangle
normal at the fly, and then it tries to find the
separation normal (A quite messy code that in fact
works very bad).

At first stage I've got running the correct 'triangle
contact' algorithm  with OPCODE without problems. But
then I've discovered that OPCODE causes problems when
I trying to compile ODE on MingW, due of its low level
routines designed for MS VC++ only. After some effort
it compiles on Mingw but it carries more bugs again,
giving an strange behavior at runtime. That causes me
a lot of headeaches.:P

Then when I was planning to develop some kind of Cloth
simulations I've figure out that OPCODE is not what
I'm looking for. So GIMPACT arises as the trimesh
collision system for full dynamic trimeshes.
Transforming trimeshes mustn't be a worry these days,
so lazy evaluation is not a plus.

Rigid trimeshes can be emulated with sets of convex
polyhedrons, and then this discussion will ends.  (
Thanks Rodrigo Hernandez, keep working on your code!!

But deformable bodies have to looks like very detailed
at player's eye, so we have to do this with trimeshes
only. Here's when GIMPACT comes to the rescue.

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

More information about the ODE mailing list