[ODE] Large terrains

[John Miles]

Yes, I have (1024x1024-cell terrains).  It's a mixed bag.

It takes a VERY long time (20 seconds or so on a 3-GHz P4) to submit a mesh
that large to ODE as a TriMesh geom.   Expect to lose about 100 megabytes of
RAM in the bargain.  The good news, though, is that there's no significant
CPU penalty when you actually use the resulting mesh, relative to a flat
single-quad mesh covering the same territory.  OPCODE's performance in this
regard is impeccable.

The first practical approach I tried was to break the mesh into 1024
separate TriMesh geoms of 32x32 (1024) cells each.  Flat regions (the
majority in my case) were represented as a single quad; non-flat regions
were tessellated into 1024 quads (= 2048 triangles).  Keeping all 1024 geoms
in the level's collision set cost about 15 milliseconds per frame on the
above machine, even with most of them disabled.  (I don't understand why,
but that's what my notes say, so I'm assuming the observation was correct).
At any rate, I solved that problem by adding and removing the geoms from the
world collision set on an as-needed basis, rather than simply enabling and
disabling them.  That technique works fine.

I wasn't 100% happy with that approach because it still took a couple of
seconds to create the TriMesh geoms at map-load time, especially if very
many of them were non-flat.  So I modified the block-caching scheme to
create and destroy the geoms themselves on demand, caching them on an LRU
basis.  That took care of the startup-time issue, but now there is a very
perceptible hitch in movement when the system has to create new geoms as the
player walks across the landscape.

I will probably stick with the latter scheme, modifying it to avoid
destroying geoms once they're created.  That will require me to put the
flatness optimization back in, which I removed when I added the LRU cache.
All in all, it's a fairly-ugly kludge to attack what should be a
relatively-simple problem.

I also tried Benoit Chaperot's dCreateTerrainY() contribution from CVS, but
its collision characteristics appear to be substantially inferior to TriMesh
terrain.  The contact parameters seem to vary widely depending on the angle
of the terrain being collided with, which is a Bad Thing given my
kinematically-driven player movement.  It was way too easy to walk through
cliff faces and the like.  I also had problems without objects that behaved
fine with the TriMesh implementation bouncing around wildly with
dCreateTerrainY().  It might work better for you than it did for me, though,
and it wasn't hard to get it up and running.  I'd suggest giving it a try
before resorting to any of the hacks I've mentioned above.

-- jm

> -----Original Message-----
> From: ode-bounces at q12.org [mailto:ode-bounces at q12.org]On Behalf Of Bill
> Lebreton Merrill
> Sent: Sunday, May 23, 2004 6:16 PM
> To: ode at q12.org
> Subject: [ODE] Large terrains
>
>
>
> Has anyone gotten around to implementing large terrains with the tri mesh?
> =]
>
> Any ideas on optimizing terrain collision in ODE w/ LARGE meshes?
>
> Thanks!
>
>