[ODE] Re: Heightfield / Collision.

[skjold@cistron.nl]

> That assumes that you only want smooth, rolling hills, but that isn't
> necesarily the case, at least not for everyone. Cliffs, craters,
> non-organic terrain (perhaps as extreme as Marble Madness with deliberate
> faceting) etc. should all be possible. The terrain may also be
deformable,
> and I don't think you'd want to recompute splines etc (although maybe you
> could). Basically we're shooting for a fairly general and flexible
> heightfield solution.

Interpolation only gets a heightfield smooth and rolling if either the heighfield was already smooth and rolling, or you're dealing with a low-resolution heightmap. But yes, generally, heightmaps are used for smooth rolling terrain. If it's Marble Madness you aim for, I think you won't end up as generic and flexible as you'd like. About recomputing splines: If that's an obstacle for any application, then I'm sure it's not related to the presence or absense of triangle-based heightfield CD.



> Also, don't forget that your collision heightmap may be far more detailed
> than what you draw - the collision data represents the full resolution
> source, your drawn data may be level-of-detailed etc. And with hardware
> vertex acceleration now wide spread, pumping large amounts of triangles is
> not only viable, but actually good for vertex throughput (modern cards
hate
> having to draw small vertex counts per rendering call).

What's this about LOD and vertex-throughput on today's graphics cards, I thought we were discussing collision detection solutions.



> Finally the triangles are of
> course required for rendering, so it makes sense to share the full
> resolution data with the collision and drawing.

My point is that, in essense, triangles have nothing to do with terrain/heightfields, except that triangles happen to be one of various ways of *rendering* terrain - which IMHO has nothing to do with colliding against terrain. Just as an extreme example, who is to say I'm not rendering my terrain using voxels? All of a sudden those triangles make no sense anymore then, do they?

And that is exactly why I tend to oppose the notion, that collision detection solutions should primarily be based on rendering issues. I thought I just read a post from gl saying that the aim was a flexible, generic solution. If that solution is targeted at colliding with tri-meshes, then I'm barking up the wrong tree with my comments here. But if the solution is targeted at colliding with heightfields then I'd submit that using triangles is not the way to go about it.



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

I don't see how parking garages and tunnels have anything to do with heightfields. The main point of a heightfield is that they don't have multiple levels. Why not try incorporating a BSP-tree collider while you're at it? Excuse me for being so blunt, but I'm starting to wonder what the aim is here. I thought ODE was a physics simulation library aiming for realtime performance, stability and reasonable accuracy. But now it looks like it's being molded into a gaming engine.


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

This is totally irrelevant to the discussion.

Greets,
Mark