[ODE] Re: Heightfield / Collision.

[skjold@cistron.nl]

When I read back my previous post this evening, in all honesty I was myself rather surprised by the tone of what I had written only hours before. Then I saw some of the reactions it brought about, and could only agree and understand how it was interpreted.

I must admit I'm not sure what it was that made me take this so personally and lash out like that. Thinking back even further, I can safely say I got similarly involved in the Reply-To issue, although fortunately that never really escalated to this degree.

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.

It's hard for me to come up with an appropriate response in this odd situation, I suppose I'm a bit ashamed of this episode. I don't want to start about what's making me rather touchy lately, it's not really important. I just hope that, with this, I am able to convey how bad I feel about what I did.

Allow me to respond to a few things. Please don't take it as trying to shape this whole development to my own needs, I never intended to do that. But still I'd like to explain the thoughts that I had about the subject, without invalidating any counter-arguments that have been - or will be - given.


GL wrote:

> First off, I don't much appreciate the tone of your reply.  Whatever upset
> you, you're taking this way too personally...

Yes, indeed I was. I realize this only in retrospect, but I promise to make an effort to keep an open mind and not let this stuff get to me. In fact I usually strive to live up to that policy, in daily life as well as online.


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

I didn't intend to limit the implementation, although I understand that I seemed as though I wanted to bend this thing to my will. Sorry about that. Actually, interpolation doesn't fully cover what's the core of this thing I tried to point out. To get a mental picture of what I mean, imagine a sphere rolling down a hillside, and that hillside is a heightfield that uses triangle-based collision detection.

The picture I was having included the assumption that all triangles were along the same 'grain' (i.e. the diagonal separation of two triangles between each set of four neighbouring points, is always in the same direction - contrary to a diamond layout where those diagonals alternate).

The hillside would of course have slopes of varying steepness, even if only slightly, and the triangles representing that 'bumpyness' will all have elevations that are slightly biased to one side. Therefore, the image I had of it all has the sphere not rolling downwards but stuttering off to one side.

This is just one of the ways in which I thought triangles could pose a problem. I'm not basing this on anything other than my own imagination, and also my argument assumes that rolling hills are to be considered a representative scenario. But it goes without saying that I could be very wrong on both accounts :P


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

A heightmap can very well be highly detailed as you say, but a contact joint is infinitately small. So I was thinking that even when using very small triangles, it might still show that the surface normals (which are used as the repelling force vector against a penetrating hull) are hardly ever pointing where you'd expect them to, from looking at it.

It's like creating a sphere with small triangles. It might not be all that noticable when looking at one on screen, especially if properly shaded, but as soon as it starts rolling on a simple flat floor, it'll wobble and head in unexpected directions. Drop it straight down and, depending on the exact orientation of the triangle that actually collides, however small it may be, the sphere is likely to bounce off awkwardly or start spinning for no apparent reason.

Again my concerns assume that my imagination is an accurate guide, and that a smooth surface is an important criterium when it comes to heightfields.


> Voxels don't hardware accelerate well at all - that's why nobody uses them
> anymore.  They do use triangles.

I know, and like I said it was an extreme example. I'm just not in favor of taking rendering issues as being relevant for collision detection, but that's just my view from the perspective of striving for an 'ideal design', which of course only ever exist in theories. In practice, it might be a different story altogether, I don't really know.


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

Good point. Though, again from the perspective of ideal designs, that issue is about inaccuracy. All my ranting about this whole thing is not about preserving visual appeal, but preserving accuracy. That's because I am not primarily using ODE for creating games (oh I like games alright, but I just happen to have sought for a 'physics engine' like ODE for a different purpose, being to use it as an environment for my AI/ALife toy-projects).

Still, taking visual appeal and rendering methods into account, triangles are used as an approximation to what you want the user to see. Various shading and texturing techniques go a long way in refining that approximation to an extent where the final image is convincing enough. Isn't it logical when attempting to implement convincing CD, to try and refine the approximation that a raw heightfield represents?


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

Yes, I am willing to put simulation accuracy before rendering accuracy, but again that's just because I currently use ODE for a different purpose. Your use of ODE simply implies different priorities than mine, and I totally respect that. I'm sorry I've been pushy about it.


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

You're absolutely right. None of you deserved this, me snagging at you while you're all putting so much effort into contributing to something as cool as ODE. The very reason I joined this list was to learn from it and try to participate, because I really am familiar with the spirit in which it's commonly done. I am very sorry to have given that spirit such a blow! My sincere appologies.


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

I see your point.


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

No, I would be just as disappointed. I truly admire all the effort that is being put into the thousands of open source projects out there, as well as the principles behind it. This is no different for ODE and all of you guys. Joining this mailing list is just a way in which I hope to be able to participate on a scale that's managable for me, and with a project that has made me more enthousiastic than any other I've used so far.

So I want you to know, that the last thing I want is to discourage this process in any way. That is also why I appreciate being addressed about my behaviour in my last post (believe it or not). It's awkward for the moment, believe me I feel that, but at least it's out in the open and - hopefully - it can be put behind us.



Amund Børsand wrote: 

> That was something really scary to say. What do *you* think we should
> use ODE for? I never noticed a list anywhere of things you're not
> allowed to use ODE for (like Dell laptops, which are forbidden to use
> for developing weapons of mass destruction (you have to sign for that
> when you order one)).

That covers it pretty well, and you are absolutely right. I shouldn't have made any judgements about anything ODE is used for, I really didn't mean to do that.


Nate Waddoups wrote:

> Like it or not, many of the people using ODE are using for gaming.  
> There's probably going to be a fair amount of overlap between the
> functionality that different users find useful, so I don't think this is a
> bad thing at all.  If impure stuff gets added to the contrib folder, so
> what?

Another good point well taken. My previous post wasn't much deserving of a thoughtful reply like this, so I appreciate you giving it that much more.


Clint Brewer wrote:

> and either way, talking about colliding with heightmapped terrain, or 
> BSP trees  in no way takes away from those aims.
> 
> I do personally hope that ode remains targeted at it's purpose (which is 
> exactly what you state, or at least it seems to me).  I think that makes 
> the libraries easier to use for all, even people making games :)
> 
> I think we all share a desire to simulate things acurately, with 
> stability in real-time, and luckily ODE is here to help.

I agree to the max :)

Sincerely,
Mark