[ODE] enhanced ODE collision API

[Erwin de Vries]

Feedback:

Is it a good idea to assert when calling dGeomGetBody(), dGeomGetPosition()
or dGeomGetRotation() on a non-placeable geom?

The way you handle colliding spaces is more clear to the user, and thus
preferable. I assume dSpaceCollide2() will find the (best) space itself from
the 2 geom arguments? The sample callback function in the docs also does
pairwise checks on all subspaces, right?

The enumeration function you use is better than mine. I suppose you buffer
the last used index and last used geom? If you have added the 'prev' pointer
in the spacedata of a geom, the user can also enumerate backwards.

You default the Category and Collide bits to 1 so that users that dont care
about it dont have to touch it. Wouldnt it be more logical to default to
0xffffffff then?

This is how i interpret the new way it works now:

RootSpace
  - SubSpace1
    + GeomTransform1
      o Sphere1
    + ...
  - SubSpace2
    + GeomTransform2
      o Sphere2
    + ...
  - ...

Steps:
* The user calls dSpaceCollide() on RootSpace.
* This will call the usercallback for SubSpace1 and SubSpace2.
* The usercallback will call dCollide2() on SubSpace1 and SubSpace2.
* This will call the usercallback for SubSpace1, and GeomTransform2 (or the
other way around).
* The usercallback will call dCollide2 on SubSpace1, and GeomTransform2.
* This will call the usercallback for GeomTransform1 and GeomTransform2.
* The usercallback will call dCollide() for GeomTransform1 and
GeomTransform2.
* ...

Is this correct?

>   * spaces do not need to be explicitly locked before use. rather, the
>     spaces will maintain the locked state internally and trigger an
>     error when there are any violations. the spaces will detect geoms
>     that do not move and precompute e.g. bounding boxes and internal
>     collision data structures

So outside of the 'lock' the user is still able to use the bounding boxes
computed while colliding? Excellent. How do you determine if a geom has
(not) moved? Is it possible to manually lock and unlock the spaces?

>   * there is no geom disable/enable. you can delete and add a geom to a
>     space to get the same effect.

Not entirely, but i was thinking of removing this flag as well, because it
can be faked by setting the Category and Collide bits to 0.

> please provide feedback about this new API. erwin - any comments? does
> this API work for you? is there any missing functionality?

There is no missing functionality as far as i can tell. Its a pity the geom
constructor with a body as argument is not added (It saves a malloc and a
free), but this is not that important to me. I think it is good enough to
keep me from continuing my own dc library.

> david - i think you mentioned that geoms might want to be interted into
> multiple spaces. can you give me a use case for this? - in the current
> API each geom has just one parent.

I also considered adding this, but i found it too problematic.

> after getting this API implemented i will focus on integrating erwin's
> ray and trimesh work, then adding the cylinder class. there is also a
> new quadtree space that is further down the list.

Have you added the 'prev' pointer in the spacedata of a geom? Without it you
cant store the node a geom is in. And it is also faster for the simple and
hash spaces. :-)

On a related note. Would it be possible to pass 0 in the body constructor
for the world it is in, and manually add and remove it? This would be far
more appropriate for my apps. Providing the same enumeration functions as in
a space would also be appreciated.

Cheers,
Erwin