[ODE] Contact cache optimization

John Miles jmiles at pop.net
Sat Jul 24 19:42:07 MST 2004


In any simulation with numerous objects resting against each other, it seems
that quite a few contact joints are created over and over each frame with
relatively-small penetration depths.  I've observed this in both
test_boxstack and my own application by looking at contact_array[0].depth in
the ODECollide() callback, where contact_array has been sorted in order of
decreasing depth.

These collisions are reported for geoms with both disabled and enabled
bodies, but presumably because of their small magnitude, they don't cause
disabled bodies to become enabled, and even if the bodies *are* enabled, no
separation forces are applied by ODE.  As a result, the same collisions with
the same depths are reported to ODECollide() every single frame.

This phenomenon would be expected when nonzero CFM factors and/or
dWorldSetContactSurfaceLayer() parameters are used, but it also happens when
these factors are all set to 0.0.

I'm not sure how far the ODE solvers get before rejecting these contacts,
but it's possible that this is a fairly-major optimization opportunity for
applications with lots of objects at rest.  I noticed it when adding a
contact cache to my game code to control how often collisions between given
object pairs are reported to the game's higher-level scripts.  In testing,
the cache was experiencing continuous thrashing even after all of the active
game objects had settled down into their autodisabled state.  I added a
simple test to ignore any collisions that were already cached with identical
object pairs and primary contact depths, and that eliminated the
contact-cache thrashing nicely without appearing to cause any unwanted
effects.

Novodex appears to maintain a similar contact cache internally.  It's able
to inform the application when two objects collide with each other for the
first time (as well as when they no longer touch each other, although the
latter functionality is poorly-documented.)  The application can veto
further collision processing for a given pair, and presumably,
redundant-contact generation of the nature described above is easily
avoided.

Has anyone investigated adding caching and constant-contact filtering to
ODE?

-- jm



More information about the ODE mailing list