[ODE] some quick notes on 0.6...

[Martijn Buijs]

Jon Watte (ODE) wrote:
> 
> 
> Martijn Buijs wrote:
>> I have some heightfield code (see attachment or 
>> http://home.planet.nl/~buijs512/ode/ ) that may be
>> useful. It supports both a callback AND copy/reference data mechanism, 
>> but only does Y-up terrains.
>> It is not final but I think its a good foundation to go from.
>>   
> 
> Is the terrain placeable? Does it support dGeomTransform? If so, Y-up is 
> not really a limitation -- just like ccylinders have their axis along Z.
> 
> If it's not placeable, how hard would it be to make it so? I think that 
> would be the baseline requirement of a terrain geom, because you can get 
> the other support options out of that.
> 
> Cheers,
> 
>          / h+

It is semi-placeable, it applies only translation (no rotation). It inherits most other dTerrainY 
properties that I may not be aware of.

As someone noted before me, it would probably be best to make it transformable, like other 
primitives. This would allow cliff-like features with overhangs, cave ceilings (upside down) etc. 
and IMO sounds a good solution for the whole Z-up Y-up problem. Just rotate other primitives to 
heightfield local space internally and then do the intersection tests.

As for spherical (planet-like) heightfields, you'd probably need a new collider altogether (ever 
thought of how to store the height data for those?) so the up-vector based approach and the like may 
not be as interesting (besides the fact that its a very rare situation anyway). Even so, if accuracy 
is not an issue, you can probably get away with it with 6 curved 2d heightfields (each representing 
a cube's face, facing away from the planet's center).

I'm no longer using ODE, nor do I have much knowledge of the inner workings of ODE (or complex math 
in general), so if someone else cares for an attempt that would be greatly appreciated.

Martijn