[ODE] New ODE Collision detection

[David McClurg]

great stuff. exactly what i'm looking for. just a few comments/questions.

what is the motivation for locking a space?  i'm thinking it would be handy because i could...

- do ray checks and get the results immediately
- avoid static vs static geom collisions.

is that what you're after? anything else?

AFAICT, big things (AABBs too big for hash table) *REALLY* slow down collisions. if that's true, then breaking apart a tri-list into smaller tri-lists is crucial.  Perhaps it would be possible to create a geom group, with its own internal hash space, and put the smaller tri-lists there.  That way, the application still gets a single geom pointer back.  Does this interest you?

A minor thing that might be handy is if the tri-list accepted a "stride" so you could more easily share data with your graphics pipeline.

Please let me know if I can help code or test.

-----Original Message-----
From: Erwin de Vries [mailto:erwin@vo.com]
Sent: Sunday, 25 August 2002 7:08 AM
To: ode@q12.org
Subject: [ODE] New ODE Collision detection


Hi,

I'm working on a replacement for ODE's collision detection. It largely
follows the same rules, and it is obviously based on the current set of
functions, but it contains several new features and breaks the current API
in several places. The features are:

- Spaces can now be locked. See the archives for my explanation on this. You
MUST lock a space before you can use it to do collision detection.

- Spaces now have a function to compute the AABB of all containing objects.
Only works in locked state.

- Geometries can now be enumerated from a space, one by one. While
enumerating the space cant be modified.

- Geometries can now be disabled, meaning they will not do collision
detection, but its AABB will still be calculated in the spacelocks. (If you
dont want that, remove the geometry from the space)

- The space_aabb pointer in dxGeom was removed, and replaced by 6 dReals
which actually define the AABB. This allows the AABB's to be cached for
'static' geometries. The definition of a 'static' geometry is currently a
bodyless geometry or a geometry with a disabled body attached. Currently you
can call dcGeomMoved() on a geometry to tell that is has moved, but i will
probably automate this behavior in dGeomSetPosition() and dGeomSetRotation()
calls. The moving flag is to 0 in every dcSpaceLock() call. For the
geomtransform and the geomgroup special implementations have been written to
make sure this all works correctly.

- The geometry group was rewritten to internally use a user-provided dSpace
on creation. This allows the user to implement various optimisation tricks
which were previously not possible.

- Geomclasses can now specify 0 for the aabb member, so the space knows that
it doesnt have to do AABB tests for geometries of that class. The behavior
is the same as the old dInfiniteAABB().

- Closing ODE is now done as i suggested earlier. See the archives.

And maybe something more. I still have to test most of these features, but
i'm pretty confident i wont find too many serious problems. However, due to
other commitments i'm not sure when i'm going to release it yet.

If anyone has more suggestions i'd gladly hear about them.

Erwin