[ODE] Re: Heightfield / Collision.

[gl]

(I had this lovely long reply crafted, and then my email prog crashes on
me... nice ; ).

> I would hereby like to sincerely appologize for using this list as an
emotional outlet, taking it so personally and, not in the least, for
snapping at some of you - none of whom ever having given any cause
whatsoever to such treatment.

OK, no worries - we all have our off days (trust me ; ).  Thanks for
re-evaluating.

To keep this short (my first reply was getting long), here's what I came up
with:

You're interested in using ODE for it's mathematical accuracy, and see the
output as an approximation only.  That's a perfectly reasonable approach.

I on the other hand am writing a game, where the visual output must closely
match the collision response.  You do not want to see nearby players or
vehicles float above or sink into the terrain noticably.  If you have a
low-res map, things must follow the output triangles or the whole thing
falls apart.

I'd argue that in it's current state, ODE is a 'looks right' not 'is right'
solution (the friction approximations, the intergrator etc).  It's therefore
safe to say that many, if not most people interested in heightfields _at the
moment_ are going to fall into the latter category.  As such, a
triangle-based collider will be useful for many people.

However, using the callbacks others have discussed here (and which I'm
planning on using in my draft), you don't have to be working off triangles
internally.  The collider will merely ask for either heights (or probably
better triangles, as it removes all the layout issues) covering a specific
area (ie. the AABB of the object in question projected onto the terrain).
You can then supply real heights/triangles at real spacing if you wish, or
you can specify an ultra-fine virtual spacing and simply generate the
requested heights/triangles any way you like (interpolation, working off
curves etc).

If you make this virtual spacing fine enough, the triangles the collider
then uses will be visually virtually unfacetted (at the expense of a little
performance).

So, the (internal) triangle approach actually can cover all scenarios,
allows maximum flexibilty, and is optimal for most cases.  It may not be
100% ideal for the purist approach, but it will get most people up and
running, and there's always room for a 2nd implementation if people need it.

Is everyone agreed on this?

As for specific problems with normals and collision response, I can see
there might be something there (see my other mail) - but for now I'd like to
get on with getting spheres working.  Then we can all see what the issues
are for ourselves.
--
gl