[ODE] dTerrainAndCone contribution ready for prime time?

[John Miles]

So, it turns out that the poor results I was seeing with the dTerrainY
height-field collider contribution were caused by the same problem that was
making the new Croteam trimesh colliders look bad: insufficient contacts.
When I bumped MAX_CONTACTS up from 6 to 64, the trimesh/OBB and
trimesh/CCylinder colliders worked very well.  I just went back and retried
the dTerrainY version of my app with the same change, and it appears to work
great.

Kinetically-driven collision responses also worked fine as soon as I
modified my code to respond to the deepest contact rather than the first.

This was a real relief, because I had to find a way around the build time
and memory overhead needed to maintain a million-point TriMesh terrain, and
the block-caching schemes I was experimenting with were just too kludgy to
live.

Would it be appropriate at this point to move Benoit's dTerraindAndCone
contribution into the main library?  Several other users have indicated that
they're happy with it, and many people have emphasized the need to support
height maps as a first-class primitive.  I think Ian Overgard (below) and
myself had the only real problems with dTerrainAndCone, and I'm pretty
satisfied now.

Ian, did you ever get to the bottom of your issue?  What is your contact
limit?  Did you try requesting a large number, sorting them by depth, and
discarding the shallower ones?

It strikes me that contact depth sorting has the desirable effect of
spreading out collision response over multiple frames.  That way, you don't
bog down the solver with too many contacts per frame, and you don't ignore
important, deep contacts that happen to appear after the first few slots.

-- jm

> Gabriel Gambetta wrote:
>
> >>From: John Miles [mailto:jmiles at pop.net]
> >>The terrain part of TerrainAndCone is not very stable, in my
> >>experience.  No bugs, just poor contact-generation quality.
> >>
> >>
> >
> >How poor? I'm doing an arcadey racing game, so I don't need it to be
> >extremely precise, just enough to *look* more or less right. As long as
> >it doesn't explode and behaves more or less realistic, I could use it.
> >
> >
> The main issue I've had is that objects tend to "stick" to the terrain,
> even when it's inappropriate. For instance, I can drive a vehicle
> straight up a cliff that's at an 80 or so degree angle to the ground and
> then park. Yes, you read that right, I can park a vehicle on a cliffside
> -- no sliding at all. Or drive straight up it if I want. I suppose it's
> a bit better than the previous version where objects tended to explode
> off of cliff faces, but it's still far from being very realistic. There
> are a couple workarounds -- if I increase the mass so that the pull of
> gravity generates enough force then objects tend to slide down the
> cliffface rather than being able to scale it. It still seems rather
> "sticky" though.
>
> Of course, I might be doing something wrong myself. I noticed the
> documentation mentioned something about sorting contacts, although it
> wasn't specific enough that I was sure how I'd go about doing so; so at
> the moment I'm somewhat unsure if there's a solution that I've just been
> unable to implement.
>
> As to how well it could work for an arcadey racing game, I suppose it
> would likely work alright as long as you keep the objects masses on the
> heavy side (mass of 1 unit isn't really sufficient, I had mine set to
> around 6-8 units in order to make it workable).
>
> (I should of course make clear that this is just my own personal
> experiences with TerrainAndCone. There's always the possibility that
> I've just been using it wrong, although it seems like others have been
> having similiar problems).
>
> --Ian