[ODE] New ODE Collision detection

[Erwin de Vries]

> A few more design thoughts...
>
> * sub-spaces or putting objects in multiple spaces -- If it was possible
to add objects to more than one space, you could do collision queries other
than 1vsN and NvsN.  That flexibility might be useful when you want to only
collide against a subset of the space.  For example, a camera system may
want to collide some rays with occlusion walls but the occlusion walls may
also need to be in the game-level space to bounce against.

Hmm. What about this? Place the occlusion walls in a seperate group, and
collide the rays against that group. Also place your group in your regular
space, so your normal collision detection also collides with them.

Implementing the object in multiple spaces idea can be done, but it would
mean all space related data must disappear from the geom. This can be done
(in fact i have just done it to test), but it means you have to be more
careful while coding. For example, now you are in charge of removing a geom
from a space. This is all enforced by asserts, but it still may be a pain to
implement. You also have the chance that you collide a geom against itself,
which is also asserted. It would also mean that in hierarchical spaces the
dCollideGeom() function cant take advantage of the fact that you know a geom
is in a space, simply because you dont know.

> * layers (hierarchical spaces) -- If a geom group doesn't support a nested
hash space, how about a new thing called a 'layer' which allows hierarchical
AABB testing.

Could you explain this a bit more detailed?

> * cloning -- if the tri-list geoms could support rot/pos transformations
then we could have several tri-lists pointing to the same vertex
information.

You can also do this by passing the same vertex and index pointers to
multiple trilists. The trees are rebuilded though, so this needs to be fixed
indeed. I will consider it for the next release.

> * Support for heightfields would be nice.  Really it's just another way of
describing a tri-list.

It would be interesting, but i wont do it anytime soon.

> * lightweight bodies-- for simulating large numbers of objects with simple
physics such as hail, lottery balls, bullets, etc.  i really miss not having
that for the 100 or so items in my world that i can pick up.

A lightweight body is a body that doesnt support joints, right? I think it
is in Russ' todo list to optimize jointless bodies someday.

> * auto-static geoms - if velocities (angular/linear) go zero, and position
doesn't change for one frame, then assume the geom cannot collide with other
static geoms.  of course, you'll need to clear the auto-static flag when you
set position or get a collision

This is also in Russ' todo. But it is hard to get right i belive.

> * pre-converted collision data -- Creating a hash space and associated
opcode tree structures may take significant amounts of time for a large
world with many 10s of thousands of triangles.  Any chance of pre-building
that off-line and passing a memory block pointer to the collision system?
I'm trying to make my load time as quick as possible.

The hashspace is currently rebuilt every step, so that cannot be pre-cached.
If you have static data you need a BVtree as space. In my collision
detection i've added a quadtree space, but i dont think i will release that
unless people really want it. I've abstracted the spaces so you can add new
implementations easier, just like for the geomclasses. As for the opcode
tree. It can probably be done, but i doubt you'll win much. The
tree-building process is already pretty fast.

> A few bugs (or perhaps user errors on my part)...
>
> 1) - when a sphere collides with two planes coming together at right
angles, the sphere seems to get "stuck" for a moment.  you can see this in
the freefall demo.  it also happens with two tri-lists coming together at
right angles.
> 2) - if a tri-list has a sharp edge, or point, such as a mountain peak, a
sphere will fall through sometimes.
> 3) - if a tri-list has a small gap or hole in it, a large sphere will
still pass through the hole sometimes.  (same as #2?)
> 4) - on a smoothly curved triangulated area, when a sphere rolls from one
tri-list to another it sometimes stops whereas if the tri-lists are
combined, the sphere will roll smoothly.
> 5) - on a smoothly curved triangulated area, when a sphere rolls over a
point where several triangles come together, the sphere will sometimes dip
into and penetrate the tri-list.
>
> i hope to construct simple test examples showing these bugs in the near
future and then hopefully we can solve these problems or at least understand
and document them.

Are you using the new tricollider i posted to this list last week or so?

Erwin