[ODE] enhanced ODE collision API

[Erwin de Vries]

> > Is it a good idea to assert when calling dGeomGetBody(),
dGeomGetPosition()
> > or dGeomGetRotation() on a non-placeable geom?
>
> hmmm ... non-placeable geoms may not have any relevant pos or R data at
> all. even if something is returned, e.g. zeros, i think the user
> should be notified that it's not good for anything. or perhaps the user
> should be told to check for a 0 return code? perhaps this is a way to
> detect non-placeable geoms? but in that case a dGeomIsPlaceable()
> function would be cleaner.

Agreed. But i dont think i saw it in the docs. ;-)

> > 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?
>
> i thought about this and could not decide the right answer. how about
> category=1 and collide=(~0)?

There is no correct solution.to this. People should just use it! So either 1
or ~0 for the category bits will do. I vote for ~0.

> > Excellent. How do you determine if a geom has (not) moved?
>
> a space will have a list of clean and dirty geoms. the clean geoms have
> precomputed AABBs (and perhaps precomputed other things). a geom gets
> transferred to the dirty list when:
>   * dGeomSetSomething() is called.
>   * it's attached to a non-disabled body.
> a space can only be in a clean list if it has no dirty items itself - so
> operations on clean geoms can propagate dirty-ness up to the root space.

How do you handle the case where a user creates a geom, attaches a body,
disables it, and then calls dBodySetPosition() on it each step? I actually
do this (the object gets enabled when it is touched), and it took me hours
to find why the hell my object wasnt collision-detected (and thus enabled).
Needless to say i was extremely unsatisfied when i found the bug.

> > Is it possible to manually lock and unlock the spaces?
>
> no ... can you give me a use case for when this is required?
>
> > 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.
>
> why 'not entirely?'.

Because the geom's aabb would be computed while it is inside the space, and
in the quadtree space it would be inside a node. Thus, enabling is faster
than adding.

The main reason i added this is to give the user the ability collide a geom
with a space on-demand, without performance loss. Imagine fireing a bullet
with instant impact (ray). All the objects the bullet could possibly hit are
in a seperate space. I would call dSpaceLock() on the root space, which
locks all subspaces as well. (I suppose internally this already happens?) I
would then call dSpaceCollide() on my root space. Then i call
dSpaceCollide2() with my bullet and the seperate space. The bullet now has
the same advantages as all other objects had while in dSpaceCollide().

> > I think it is good enough to keep me from continuing my own dc library.
>
> i am largely cutting and pasting from your dc library into ODE - changing
> the way some things work - but the new collision system is largely
> the result of your effort.
>
> > I also considered adding this, but i found it too problematic.
>
> as did i -
>   * memory management: when a space is deleted, which geoms are deleted?
>     should we use ref counting or garbage collection. either way
>     introduces other problems.
>   * a geom has to notify multiple parents when certain things happen,
>     e.g. when it moves. annoying for the clean-data-structure point of
>     view.

Not to mention the prev and next pointer you have to keep for each space the
geom is in, or the ability to create infinite loops by adding a space in
another space which contains the first space itself. Have fun debugging
that. :-)

Erwin