[ODE] Re: Heightfield / Collision.

[gl]

> My thoughts were that such a test would be extremely quick for any point
> in the map, which could be calculated instantaneously (or by looking up
> the 4 nearest vertices/heights, which would be just an array lookup if
> you have equal vertex spacing), instead of with triangles, where you'd
> have to seek through a lot of triangles to find which triangle the point
> lies within, before you could interpolate it linearly to get the exact
> height of the point.

No you don't have to seek through triangles - with a regularly spaced
heightfield, determining the potential set of vertices, and triangles from
them is easy (except you have to take the triangle layout into account,
hence my other mail).  The triangles are also needed for on-the-fly normal
calculation, which is a nice option to have (although I'm factoring in
supplying precomputed normals if desired).  Finally the triangles are of
course required for rendering, so it makes sense to share the full
resolution data with the collision and drawing.

> You would run into further
> problems if let's say the terrain has more levels (a parking garage with
> several floors above eachother, for instance, how can the collision
> routine find out which floor you are "colliding" with?). But of course,
> if you need terrain/world that has a tunnel, for instance, a bridge, or
> any surface that is steeper than 90 degrees (that is, "inwards"), you'd
> need full triangle collision detection.

Exactly - and you have that option with the tri-collider.  You can also
choose to mix heightfields and true meshes where you want an overhang, say.

> Another method some games use is a heightmap which is represented by a
dynamically created mesh. This is clever because you don't need as many
polygons far away near the horizon as you do close to the camera, and
you could adjust this in real-time to make detailed terrain near you and
less details far away where they don't show anyway. I don't know how to
do this fast, though, but I've seen some games use it, and it seems to
work great.

There are different methods; some use a lot of CPU, others simply use lower
LOD versions of their tiles based on distance from the camera (with a few
tweaks to correct overlaps between dissimlar LOD level tiles) etc.  The
point is though that the collision representation is usually at full detail
regardless of what's drawn, but that's up to the app (it could switch tile
collision LODs if it wanted).
--
gl  (voting for reply-to-list - every so non-confrontationally)