[ODE] Re: dTerrainAndCone contribution ready for prime time?

[Matthew D. Hancher]

Flavien Brebion <f.brebion at vrcontext.com> wrote:
> I don't know, to me it would make more sense to support (assuming
> it's not supported yet - i haven't looked at the dTerrain code for
> a while) translations/rotations to the terrain. That way you could
> just set up the correct transformation matrix to rotate the terrain
> to the correct base, than to have to handle multiple code versions.

dTerrainY and dTerrainZ already support translation and rotation.  
The issue there is optimization.  This is most important for infinite
terrains, since in general a transformed infinite terrain cannot be
bounded by any axis-aligned bounding box.  By supporting non-placeable
infinite terrains (i.e. terrains fundamentally tied to a specific
axis) the collider is able at least to bound those terrains in that
axis, resulting in a potentially large collision-detection savings.
It would be possible to spot transforms that leave the terrain roughly
axis-aligned, but relying on recognizing a specific rotation by its
floating-point representation seems undesirable.

An alternative would be for the user to be able to specify a bounding
box to be intersected with the object's natural bounding box, possibly 
updated at each timestep.  I could imagine this proving useful for 
other sorts of collision optimization as well.

I do feel like ODE ought to come to some sort of resultion on the 
preferred-axis question as it applies to cylinders, too, though.
With the dCylinder class also poised for integration into the main 
source tree, it still uses a different axis convention than dCCylinder.  
Although this is arguably just an aesthetic question, I do think it's
one worth resolving.  Modifying dCylinder to match dCCylinder would 
be fine, too, but it sounds like there are a fair number of people 
who use ODE in environments that are Y-up and would prefer not to 
have to do the conversion to get the best possible performance.

So, in short, I don't care how things play out as long as *some* 
decision is made so we can work on polishing off dTerrain and 
dCylinder for integration into the official release.

(Full disclosure: I'm a Z-up person, myself. :)

mdh

Matt Hancher
NASA Ames Research Center
Official: mdh at email.arc.nasa.gov
Personal: mdh at media.mit.edu