[ODE] Benchmarking GIMPACT vs OPCODE

Francisco Leon projectileman at yahoo.com
Fri Oct 27 08:29:53 MST 2006

To my fellow OPCODE lovers....
  I've published the oldy  "ODE trimesh collision" OPCODE version . So you can do all necessary tests and judge which library is your favorite. (Like the supernova contest !!) :D 
  Download the updated gammaleon demos with the old 'physicscollision.exe' OPCODE versión: https://sourceforge.net/project/showfiles.php?group_id=176513&package_id=208771&release_id=458186
  And download the older version of my modification of the ODE library working with OPCODE : https://sourceforge.net/project/showfiles.php?group_id=176513&package_id=209429&release_id=458885
  Good luck.

Pierre Terdiman <pierre.terdiman at novodex.com> wrote:
  > 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

ODE mailing list
ODE at q12.org

Do you Yahoo!?
 Everyone is raving about the  all-new Yahoo! Mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://q12.org/pipermail/ode/attachments/20061027/4380bfa2/attachment.htm

More information about the ODE mailing list