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

[gl]

> 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.

Same here, I need at least 16bit values, and probably floats.

> 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).

I think in keeping with the spirit of ODE, we shouldn't use C++ (though I'm
a big fan).  It might be an idea to have different heightfield types, eg,
dGeomHeightfield8,
dGeomHeightfield16 & dGeomHeightfieldF.

> Whenever we do
> calculations on the height values, we had to cast them into dReals or
> whatever.

It's an option, but it would require people modifying ODE source code, which
I think we should avoid.

> 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.

I actually do that with my terrain now, ie. I work off a large bitmap in
memory, but it's split into tiles that point at subrects.  Should certainly
be in there as an option.

> 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.

Ah, right.  Again, I guess we should make on-the-fly optional, and allow for
interleaved normals.

> 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.

Again, we could have an option for normal decompression (eg. creating z from
x & y) for user-supplied normals.

> 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.

Hopefully we can come up with something general that still works optimally
for all of us... thanks for the code Fabian, I'll probably check it out over
the weekend.
--
gl