[ODE] which method is best for large scale terrains?

[David Walters]

> I need a way to do fast collision detection on large terrain (2048x2048
> quads or more). I've tried the terrainY contribution, but performance with
> this is very poor. A single ray check across the terrain can potentially
> lead to millions of calls to the getHeight() callback, and even for a single
> vehicle with about 200 calls, my game performance takes a huge hit (25%
> performance drop).

Have you tried the internal dHeightfield primitive from v 0.7 ?, it
should work better than the legacy terrainY contribution as it can use
instanced or local height data rather than a callback. (If you find
that this is still too slow and you can improve upon the performance,
please consider submitting a patch!)

As a _possible_ extra performance improvement I would suggest
experimenting with chopping the terrain up into sections so that the
Space can do AABB checks to reject collisions with sections that have,
for example, a lower dynamic height range - you may get a small
benefit for flying objects that way.

Anyway, I'm not sure that splitting would be faster than a single huge
terrain from a collision point of view though it depends on your scene
- but if you're using a really large terrain you might also be needing
to stream the data in as you move around so chopping would be a
necessity.


> What's the most efficient method for doing collision checks on large
> terrains? I've thought of using trimesh, but from previous experience with
> another physics engine, loading and checking against a multi-million polygon
> trimesh is out of the question.

This would additionally be a sub-optimal solution because as triangles
in a trimesh are infinitely thin, you will be more susceptible to
tunneling errors, i.e. objects getting 'stuck' in the terrain. The
dHeightfield primitive defines a solid convex volume with an
adjustable 'basement cap' that should allow you to make it thick
enough to prevent any tunneling.

Dave