Fw: [ODE] Re: Heightfield / Collision.

[gl]

(copy to the right place):

> First off, I don't much appreciate the tone of your reply.  Whatever upset
> you, you're taking this way too personally...
>
> > 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.
>
> Why limit the implementation?  I for one want more complex terrain - my
> approach covers all those scenarios.  If you want to additionally
> interpolate, you can always add that yourself (but there are problems with
> that, see below).
>
> > 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.
>
> Now you're just being obtuse.
>
> > What's this about LOD and vertex-throughput on today's graphics cards, I
> thought we were discussing collision detection solutions.
>
> Someone was worried about triangle based collision producing a visibly
> facetted collision response.  My point was that heightmaps can, and are
very
> detailed these days, so it's not generally a problem.
>
> > 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?
>
> Voxels don't hardware accelerate well at all - that's why nobody uses them
> anymore.  They do use triangles.
>
> Also, you generally _want_ your collision response to follow your visual
> output.  Consider the case of interpolation over a large triangle in a
> low-res map - do you really want to see objects hover over its center?
For
> most cases, you do want the triangle output and collision data to match
up.
>
> > 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.
>
> What would you suggest?  How else are real-time heightfields rendered
> exactly?  And are you willing to have things floating if your internal
> representation doesn't closely match your output?  I'm not.
>
> > 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.
>
> You need to take a deep breath and consider apologizing for your little
> outburst - we're all friends here.  One the one hand you want an
> ultra-flexible heightfield collider, on the other you're having a go at
> someone who's considering the various instances a heightfield could be
used.
>
> Regular spaced heightfields are an optimisation.  As such, any clever use
of
> them is going to be efficient.  Example - you could do fully surrounding
> caves with an inverted heightfield above you.  Once they're in ODE, let's
> use them where we can - they will be faster to collide against than a
> general mesh after all.
>
> > This is totally irrelevant to the discussion.
>
> Sorry, most of your post is.  I'll make this simple for you: _I_ want a
> triangle based heightfield solution.  From the contributors I've had
contact
> with, it seems others do too.  So, that's what I'm going to be working on.
> If this doesn't fulfill your requirements, you're more than welcome to
work
> on your own implementation and contribute it back - I'm sure everyone here
> would appreciate all contributions.
>
> The alternative is that the few of us who are trying to help each other
out
> _and_ let others benefit go back to doing things for ourselves.  It might
> appease your, but others may be disappointed....
> --
> gl
>