Re: [Algorithms] Terrain performance comparisons

[Mark D. <duc...@ll...>]

I will toss in one message to the terrain opinion fest:

  -- Jonathan's idea about coherence-exploitation leading to
     a cycle of death completely forgets the idea of
     "split-merge until time's up" that was in the original
     ROAM paper.

  -- if you want 60Hz absolutely solid, the ONLY known method
     (that scales to big terrain and has any claims of
     accuracy) is ROAM-like systems with the "time's up" option,
     as far as I know (any other contenders?).  I don't count
     "threshhold feedback" schemes -- they are not guaranteed
     solid (without, ehem, guarantees of frame coherence!).

  -- Chunking is critical to eliminating CPU work.  Latest ROAM's
     spend all their time creating fractal detail, not doing
     CLOD "thinking".

  -- Chunking can be dynamic.  The linux ROAM 2 work in progress
     produces detail on the fly, and presumably could re-produce
     it as needed if you change the terrain.  Of course tossing
     something like ocean waves into a terrain engine will be a
     little awkward...but the computation of the waves will likely
     dominate the CPU anyway (do it on the GPU???).  You still
     need chunk CLOD for a big ocean.  BTW, is "chunk CLOD"
     and oxymoron? ;-)

  -- progressive vertex arrays are way cool as replacements for
     ROAM "triangles".  I'm getting 100M tri/sec with PVAs as the
     primitives in my latest experimental ROAM-like renderer with
     sliding progression on a radeon 9700 pro.

  -- split-merge dual queues and PVAs are great for very wacky
     geometry, e.g. isosurfaces of 3D fully developed turbulent
     fluid flow.  Maybe you can toss your whole game world into
     a 3D hierarchy (think tetrahedron bintree) with PVAs per tet.
     That's where I'm headed...

Cheers,

--Mark D