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

Martijn Buijs buijs512 at planet.nl
Tue Oct 3 06:18:59 MST 2006


Matthew Reid wrote:
> Hi.
> 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).

There is now a new collider called dHeightfield, and replaces dTerrainY. It is pretty much as 
efficient as it can get for heightmaps. Though it is based on dTerrainY, likely not much faster.
Are you sure the performance drop is caused by the terrain lookup, and not the vehicles themselves? 
  What happens if you replace the terrain with a plane?

> 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. How is large scale terrain collision and ray 
> checking handled in commercial games such as battlefield 1942?

I know that BF1942 uses heightmaps, and probably does simple 2d top down lookups (at least for the 
wheels of vehicles), much like dHeightfield.

 > Is there some
> technique whereby the trimesh could be split up into a AABB tree...similar 
> to BSP collision?

I doubt it would be faster, heightmap lookups are almost instant, unlike tree structure. BSP trees 
are probably not what you want (unless you need overhangs and tunnels), and it would not speed 
things up at all (actually BSP trees are notorious for being really inefficient for terrains, or at 
least in the Quake-based engines).

For my own game (doesn't use ODE) export the terrain is exported as a quad tree subdivided mesh 
(terrain is created/edited as mesh rather than heightmap). These clusters of faces are 
convenient/efficient to render and allow features like holes. Height lookups are done by traversing 
the quad tree and brute force testing against each triangle in the leaf node (2d top-down, a bit 
faster than 3d but doesn't allow overhangs). My implementation isn't faster than heightmaps, the 
reason I chose it is that it is more efficient for rendering, and doesn't require complex LOD schemes.

Hope that helps. :)

Martijn


More information about the ODE mailing list