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

[Fabian Herb]

Hello,

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

I think we should use a single type that we use in our collider code, 
and that can be changed in the header file (using typedef).

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

I mean we should only do typecasts in our code, so that we won't get 
any surprising results when we try to divide an integer (if the user 
chose that).

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

Perhaps another useful option would be using only every second (or 
fourth?) heightfield value, so that people can have high-detail 
graphics and faster collision detections (with compromised accuracy 
of course).

>  Ah, right.  Again, I guess we should make on-the-fly optional, and allow
>  for interleaved normals
...
>Again, we could have an option for normal decompression (eg. creating z from
>x & y) for user-supplied normals.

That's quite complicated, since everyone can have her/his own format 
of indexed normals and/or accessor functions.

That's already a lot of options. We should do multiple interfaces (to 
the same code) for quick and full-featured setup of the geometry 
object.

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

No problem. Take your time.
	Fabian