[ODE] dHeightfield collider

[Geoff Carlton]

Hi,
One case to consider is where the terrain data is stored in a non-float 
format in the application.  For example, some games use a compressed 
representation with a uint16 or even uint8 per vertex (with a suitable 
offset and scale given per "region").  A general ODE heightfield would 
allow the app to use its own custom format, avoiding data duplication 
inside the geom object.

I would consider a general solution is a terrain geom where we can 
define two query operations:
    bool GetDepth(const dVector3& pos, float& resultDepth, dVector3& 
resultNormal);
    void GetHeightfieldUp(dVector3& resultNormal);

The second callback is in case we need to get the basic "up" invariant 
of the heightfield (e.g. +Y, or +Z).  If no collision code needed this, 
then we could eliminate that function altogether, which would make the 
solution much cleaner, as well as more powerful.  That way a 
parametrically defined heightfield could be any shape, such as a 
spherical one.

The standard "out of the box" heightfields are those that define the 
functionality by using embedding floating point data.  They use two 
elements of the input "pos" to compute nearest points, interpolate the 
height, and compare to the third element of "pos".  In C++ terms I would 
say the Y and Z heightfield have an inheritance relationship to the base 
heightfield class, overriding the GetDepth() function.  In ODE terms I 
expect it would be implemented as a single heightfield geom with several 
modes: "+X", "+Y", "+Z", "user-callback".  The first modes all use 
embedded data set into the geom, whereas the last allows the app code to 
use its own representation.  The more complex interpolation methods Jon 
mentions would also be possible using the callback.

Geoff


Jon Watte (ODE) wrote:
> First, you should be able to re-use your code using regular geom 
> transformation, assuming you can transform the colliding primitive into 
> terrain space. Disallow trimesh/terrain and terrain/terrain collisions...
>
> Second, make sure you support variable terrain interpolation methods. 
> While linear triangles between each sample is common, more advanced 
> systems do things like cubic interpolation (sampling 16 heightfield 
> samples), and subdivide a few vertices between each sample. This tends 
> to look much better than angular linear terrain, unless you actually 
> want an angular look.
>
> Cheers,
>
> 			/ h+
>
>
> Martijn Buijs wrote:
>   
>> I'm working on a general purpose heightfield collider, based on the "Terrain & Cone" contrib. It
>> removes the terrain dimension limitations (supports non-square fields & grid spacing, NPOT dims) and
>> allows deformable terrains (it should work great for animated water surfaces as well -- the reason I
>> named it "dHeightfield" rather than "dTerrain"). A bunch of fixes are included (AABB patch, callback
>> patch), and the geom creation interface has been changed to mimic the trimesh collider.
>>
>> However, I'm not sure how I can make it to work with Z-up systems (I re-used dTerrainY code) without
>> duplicating code, and in an elegant, efficient fashion. Any suggestions?
>>
>> If it proves stable (which so far it has) I think this collider would make a nice addition for the
>> next stable release. I'll do some more testing, write a readme etc. and try to post the code after
>> the weekend. :)
>>     
>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>
>
>