[ODE] Terrain colliders and/or Trimesh/OPCODE

Pierre Terdiman pierre.terdiman at novodex.com
Mon Feb 9 09:45:47 MST 2004


>- build time (my terrain is 2048x2048), each cell tesselated in 4
>triangles. As a result my terrain has a total of 16 millions tris.
>Trimesh works, but is slow to build (load times of up to many
>minutes).

Errr, you don't want to create a single Opcode tree for the whole terrain at
once, do you ?

It's probably better to cut the terrain in multiple patches/chunks and
create a different collision structure for each. The trick is that the
terrain's topology (i.e. the index buffer) is usually the same for each
chunk. So there's a very obvious thing to do here:

- create N Opcode trees for N chunks, N = max number of terrain chunks
visible/used at the same time in memory
- when a chunk gets culled, mark the Opcode tree as free
- when a new chunk gets visible, recycle the Opcode tree by using the
Refit() method.

=> no build time for new chunks, less memory used.

As usual, a dedicated terrain solution is probably better, but Opcode can
get you very far....


>- non deformable, as you mentionned

That's wrong, see previous post :)


>- but (and that's my main concern at the moment), memory usage is
>skyrocketing. I can render my terrain at up to 200 fps, but collisions
>take 550 Mb of ram... hum

You can do the kind of things I mentioned above, and also switch to "hybrid"
trees (introduced in Opcode 1.3). They use an order of magnitude less ram
than "normal" or "optimized" trees from Opcode 1.2...


Pierre Terdiman

- Novodex AG (www.novodex.com)
- Personal : www.codercorner.com




More information about the ODE mailing list