[ODE] Heightfield / Collision.

[skjold@cistron.nl]

> OK, no worries - we all have our off days (trust me ; ). 
That's true, I suppose. Still it bothers me how much effort I had put into sneering at everyone. Anyway, I'm happy it's over and done with now, so I'll stop polluting this mailing list over it any longer, except for this one thing:

> Thanks for re-evaluating.
Thanks for the opportunity.


And to finish up the heightfield discussion:

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

There's nothing wrong with using this marvel for games at all. It's a rightfully obvious use of ODE and I see the appeal for that as much as for other uses. My own interest in ODE, even though not primarily for games (at least not currently), is based in no small part on the fact that it has plenty of speed for real-time performance. What I was looking for in ODE was the ability to provide a virtual environment for those flaky AI attempts of mine, that is realistic enough to be usable but not necessarily 100% mathematically correct. I'm aiming for simulations that are at least real-time, and possibly faster should I decide to let it run for a while and check back later what happened. So come to think of it, my priorities aren't all that different from yours. Speed is a big bullet on ODE's list of strong points, I'd hate to see that go to waste. End of speech :P


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

Right, if I remember correctly this idea of using a callback was given by Erwin around the same time as my 'fit of depression'. Nonetheless I do remember reading that and thinking it an elegant and flexible solution, and I'm very interested in seeing it work.


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

Digging it! By the way I agree with Chris Brodie, you're doing a great job. I'll try to stop being such a frustrating bore now ;)

Greets,
Mark