[ODE] ODE-GIMPACT performance and advices

[Pierre Terdiman]

> 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

Well, if you find "real" bugs in Opcode, please report them :)


> 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.

You do realize that Opcode -does- support fully deformable meshes thanks to
the "Refit" function, right... ?

Somehow people tend not to see this one :)


> Transforming trimeshes mustn't be a worry these days,
> so lazy evaluation is not a plus.

Well, opinions vary about this. This is probably true for dynamic meshes
with a small number of triangles. This is probably not true for static
levels with nowadays' triangle counts...

Anyway, as I said, for primitive-vs-static-mesh Opcode does -not- transform
a -single- triangle. If you transform all the triangles ahead of time,
weeeell, it might be an issue...


> 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.

Both the old Solid 2.0 and Opcode support deformable AABB trees (i.e.
deformable meshes like cloth), through the same "refit" operation. Opcode is
usually faster for this because the "no leaf" trees have twice as less nodes
as Solid, so the refit function is immediately twice as fast. And hybrid
trees are even better since they usually have an order of magnitude less
nodes :)

So, again, I'm really interested in speed/memory benchmarks between your
approach and Opcode's. It's kind of funny, because I also used Opcode's "box
pruning" in the past, for deformable objects (this time it was called
"Decode", for DEformable CD...). [I had an IOTD about this a while back...
let me check..... Here, the cloth stuf:
http://www.flipcode.com/cgi-bin/fcarticles.cgi?show=63381]. On the plus
side, it doesn't use a BV-tree so it's really memory-friendly (and that's a
BIG plus on next-gen consoles). On the minus side, what I got was usually
slower than Opcode's refit trees, and so I eventually dropped the whole
idea. But maybe your implementation is better!

In any case, this is "easy", the real challenge is contact generation for
concave meshes under penetration, and I think -this- is where GIMPACT comes
to the rescue..... :)

- Pierre