Submitted by , posted on 30 May 2002
Image Description, by
These images are snapshots of a real-time level of detail planet renderer
which I wrote last year.
The complete source code is available on my web site:
Please feel free to use/abuse it for anything you want.
I did the project for fun and the technique used was invented on-the-fly.
Basically, the program starts with an icosahedral mesh represented as a tree
of triangular faces, edges and vertices. Split and merge operations are
defined which allow the creation of a quad-tree (splitting an approximately
equilateral triangle into four more). Split and merge operations are only
allowed to result in -1/0/+1 change in LOD across any edge. Lists of faces
which can currently be split or merged are maintained.
When an edge is split the central vertex is pushed outwards so that infinite
subdivision would create a sphere. Terrain is introduced as perturbations to
this edge splitting, either to the distance pushed out or to the surface
normal (which affects future splittings). These random perturbations are
generated using pseudo-random number generators seeded by the result of the
parent in the tree. Therefore, the planet is defined to infinite resolution
as an implicit surface and (at any time) only the information required to
render the planet needs to be stored.
The program uses AGP memory and includes an interesting little library which
maintains "render buffers" of triangles in the mesh. Each render buffer of
triangles has an associated texture map part of the vertex array. The render
buffers are plotted in turn, memcpy'ing the new texture map coordinates into
AGP memory each time. This can sustain huge triangle throughput for meshes
but isn't currently pushed by the LOD engine which requires the CPU to
perform complicated per-triangle calculations. Switching to a LOD engine
which handles bunches of ~100 triangles at a time would give (I estimate) a
50x increase in performance, smashing through 1Mtris/sec.