[ODE] New ODE Collision detection

[David McClurg]

A few more design thoughts...

* sub-spaces or putting objects in multiple spaces -- If it was possible to add objects to more than one space, you could do collision queries other than 1vsN and NvsN.  That flexibility might be useful when you want to only collide against a subset of the space.  For example, a camera system may want to collide some rays with occlusion walls but the occlusion walls may also need to be in the game-level space to bounce against.

* layers (hierarchical spaces) -- If a geom group doesn't support a nested hash space, how about a new thing called a 'layer' which allows hierarchical AABB testing.

* cloning -- if the tri-list geoms could support rot/pos transformations then we could have several tri-lists pointing to the same vertex information.

* Support for heightfields would be nice.  Really it's just another way of describing a tri-list.

* lightweight bodies-- for simulating large numbers of objects with simple physics such as hail, lottery balls, bullets, etc.  i really miss not having that for the 100 or so items in my world that i can pick up.

* auto-static geoms - if velocities (angular/linear) go zero, and position doesn't change for one frame, then assume the geom cannot collide with other static geoms.  of course, you'll need to clear the auto-static flag when you set position or get a collision

* pre-converted collision data -- Creating a hash space and associated opcode tree structures may take significant amounts of time for a large world with many 10s of thousands of triangles.  Any chance of pre-building that off-line and passing a memory block pointer to the collision system?  I'm trying to make my load time as quick as possible.

A few bugs (or perhaps user errors on my part)...

1) - when a sphere collides with two planes coming together at right angles, the sphere seems to get "stuck" for a moment.  you can see this in the freefall demo.  it also happens with two tri-lists coming together at right angles.
2) - if a tri-list has a sharp edge, or point, such as a mountain peak, a sphere will fall through sometimes.
3) - if a tri-list has a small gap or hole in it, a large sphere will still pass through the hole sometimes.  (same as #2?)
4) - on a smoothly curved triangulated area, when a sphere rolls from one tri-list to another it sometimes stops whereas if the tri-lists are combined, the sphere will roll smoothly.
5) - on a smoothly curved triangulated area, when a sphere rolls over a point where several triangles come together, the sphere will sometimes dip into and penetrate the tri-list.

i hope to construct simple test examples showing these bugs in the near future and then hopefully we can solve these problems or at least understand and document them.

Ta