[ODE] enhanced ODE collision API

[Russ Smith]

> 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.

> 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?

yes.

> The enumeration function you use is better than mine. I suppose you buffer
> the last used index and last used geom?

yes, that's exactly what i had in mind.

> If you have added the 'prev' pointer
> in the spacedata of a geom, the user can also enumerate backwards.

yes - i'll use a doubly circularly linked list.

> 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)?

> This is how i interpret the new way it works now:
> Is this correct?

yes.

> So outside of the 'lock' the user is still able to use the bounding boxes
> computed while colliding?

correct. your AABB caching code is preserved.

> 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.

> 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?'.

> 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.

> 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. :-)

yes.

> 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.

yes - i'll add this to the to-do list? :)

russ.

--
Russ Smith
http://www.q12.org/