[ODE] ODE-GIMPACT performance and advices

[Pierre Terdiman]

> A: The main GIMPACT paradigm is to precalculate all
> results as possible. It saves a cache of the
> transformed vertices and the calculated planes from
> triangles for saving work on successive queries. It is
> specially good with static meshes that don't move very
> frequent.

Static meshes usually never move. Otherwise they are dynamic.


>Think "level editor." You do move mountains, at times.

I don't understand this, really. Who cares about physics / collisions in a
level editor? If the level designer is moving a building in a level editor,
there are usually no collisions at all.

As far as I can see there are really only two cases:
- static meshes (the level, will never ever move in the game - because it
would break the precomputed lighting solution, the AI navigation meshes,
etc, etc)
- dynamic meshes (always moving)

I don't see the point in optimizing for "pseudo static" objects, because
there are really not the common case.


> So that is my personal interpretation of
> temporal coherence. OPCODE claims to have it, but it
> isn't applicable when you have to find all contacts
> between two trimeshes,

This is true. Opcode only has a limited temporal coherence for
primitive-vs-mesh, in some cases. But over the years I found even this was
best handled outside the library.


> and OPCODE forces the app to
> calculate transformed vertices (and planes) on each
> query every time.

This is not true.

For primitive-vs-mesh, the primitive is moved to mesh space before the
actual query, and then all overlap tests happen in mesh space. So the mesh
vertices are *never* transformed.

For mesh-vs-mesh, the vertices of one mesh are moved to the space of the
other, so in the worst case it only transforms all the vertices of a single
mesh (not both). But the worst case never happens: it only transforms
necessary triangles when an overlap test is performed. If the two meshes
overlap only a little bit (or not at all), only a few triangles (or none)
are transformed.

So, transforming *all* the vertices ahead of time is not really "better", it
all depends on what happens during the actual queries. Transforming ahead of
time is "eager evaluation", transforming when needed is "lazy evaluation".
"Eager" is usually better for small meshes, "lazy" is usually better for big
ones. Pros & cons, as usual.

One other issue with transforming ahead of time is that you usually
transform vertices to world space. (So that you can reuse your cached
vertices against all possible meshes colliding with you). But this is very
bad for big worlds, suddenly the collision doesn't work properly anymore
when meshes are far away from the origin, etc => nightmare. Of course you
will never hit those problems if your boxes are limited to 1638.0f in the
first place :)


>I did indeed patch ODE/OPCODE to support 16-bit indices

Hmmm. There's a "callback mode" that one could use for 16-bit indices,
without patching anything. Oh well.


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

I assume this means "Opcode's trimesh and whaveter contact generation has
been added on top of it in ODE".....

Opcode doesn't do contact generation (narrow phase), it only does the
midphase. As far as I know there is no robustness issue there :)

I would be interested in comparing GIMPACT against Opcode alone, i.e. not
the combined Opcode + ODE contact generation thing. I'll do that at some
point, and let you guys know. It's relatively easy to go faster than Opcode
those days, since the rules for modern processors aren't really the same as
what they were on my Celeron 500 a few years back. Now, by the way, have you
ever tried to use Opcode's "hybrid" trees ? They use less memory and are
usually faster than the default ones.

About GIMPACT, I would be very very interested to see how it performs with
"real" meshes. Like, I don't know, a table against a Quake-level. That would
be sweet. I'm definitely going to try it, as soon as I get some time.

>From a quick look, it seems GIMPACT's midphase is heavily based on Opcode's
"box pruning", right? So it would mean it doesn't use a tree at all (great
for memory). It's unclear to me how well this works with oblique raycasts or
oblique OBB-vs-mesh queries, but I'll investigate... errr... "ASAP" <= might
take months :)

Anyway, kuddos so far! It certainly looks cool.

- Pierre