[ODE] Terrain<->Box collision without tri-collider

[Fabian Herb]

(I didn't notice that I haven't send this to the list at all. So here it is)

Hello all,

I sent my code to Stephan and gl, if someone else is interested, I 
can send also send it to the list (3.7K gzip, not much, I know ;-).

>I think for a heightfield contribution to be useful, it should be able to
cope with any sized grid input.
>
>The next question is what format we should pass in.  I can see two
>scenarios - either sharing height-only data, and computing triangles and
>normals from that on-the-fly.  This might be less than optimal?

I'm currently doing a re-implementaion of my terrain engine to use 
binary triangle trees (see 
http://gamasutra.com/features/20000403/turner_01.htm , and turn off 
javascript). Mr. Turner suggests using 8-bit height samples and 8-bit 
indexed normals for minimum memory requirements. I think I'm going to 
use 16-bit height samples instead, as I want to be able to blast some 
craters into my terrain, and 256 possible height values would not 
suffice, if I have big mountains.
We could either implement this as a transparent typedef, so that 
everyone can change that type to whatever he/she needs, or as a C++ 
template class (which is C++ only, of course). Whenever we do 
calculations on the height values, we had to cast them into dReals or 
whatever.
I think when creating the heightfield geometry, we should just store 
a pointer, width and height values, so that a terrain geometry object 
shares data with the graphics engine (everybody needs graphics). If 
we additionally store an array row size value, we could even point to 
parts of larger heightfield arrays (e.g. bitmaps), as it's always 
advisable to split the terrain into many collision geometry objects, 
so that it takes advantages of the bounding box optimizations of ODE.

>The 2nd I guess would be using heights (float?) and pre-computed normals.  I
>think we need both averaged vertex normals and face normals?

I think calculating the normals on-the-fly shouldn't take too much 
computing time. If we would store all needed normals, we had to store 
edge normals also. I'm going to store vertex normals as indexed 
normals (1-byte index) for my graphics). But I wouldn't use them in a 
general collision detection, as requirements would differ.

>
>Anybody else interested in this, please chime in with your requirements.  We
>may aswell make this as general (and yet optimal) as possible, if we're
>going to contribute it back to ODE...

These were my requirements. I'm looking forward to see your comments. 
Of course I would accept a more general implementaion (if possible) 
and make necessary changes for my own use.

Best Regards
	Fabian Herb