Geometry Clipmaps

| No Comments | No TrackBacks
I've been working on recreating the research of Losasso, Asirvatham, and Hoppe on GPU-based Geometry Clipmaps. One of their articles on the subject appears in GPU Gems 2. Geometry Clipmaps are a simple approach to rendering large terrains. The basic idea is you create fixed donut rings of varying LOD and then displace these rings using a heightmap in the GPU's vertex shader. Offloading the displacement into the GPU is a significant performance improvement as it avoids continuous recreation of vertex and index buffers.

This week I implemented two ideas that I thought would be improvements to the Geometry Clipmap algorithm presented in GPU Gems 2. The first I call the "view dependent" approach. In Asirvatham's paper the clipmaps are oriented along the x,z plane and move only when the camera exceeds some threshold. Every frame, the positions of the clipmaps must be recomputed by the CPU and then passed to the GPU. The "view dependent" approach attempts to skip this step by fixing the clipmap meshes in view space.

Imagine the intersection of the view frustum with the plane of the clip maps. It forms a large trapezoid that extends out to infinity. The view dependent approach fills this trapezoid with triangles that become denser closer to the camera and more spaced out as you move away from the camera. On the GPU, view space is transformed back into world space and then the world space coordinates are used to sample the height map. The advantage of this approach would be the vertex and index buffers would be 100% fixed and no transformations would ever need to take place on the CPU.

I implemented the view dependent approach and ran into some interesting problems that make it apparent why Asirvatham et al choose to orient the clipmaps in the x,z plane. When the view frustum is oriented at an even 0, 90, 180, 270 degree angle everything looks perfect, but as you rotate the camera in between these angles you get a stair-stepping effect in the terrain. This is because the points sampled on the heightmap are no longer "even" sample points, and you get an effect similar to drawing a line without anti-aliasing.

To combat this problem I tried solving it the same way you would if you were doing anti-aliasing: super-sampling. Instead of sampling at the point given by the transformation, I sampled 4 points around that point and averaged the results. This did indeed smooth the stair-stepping effect, but just like even anti-aliasing in a ray tracer, you're just offloading the problem further back into the scene--the stair-stepping was still there, it just wasn't as apparent.

Another way to combat the stair-stepping effect that I want to try would be to sample only the floor of the transformed points and move the transformed geometry in the x,z plane to an even interval. This might get funky, but I'd like to try it.

The second optimization I tried with geometry clipmaps was a simpler clipmap. In Asirvatham's paper he uses a very unusual clipmap pattern so that transitions from one LOD to the next are always half the detail, and so each LOD ring has the same width. There's no other way to get half detail and fixed width without using an unusual spiraling pattern. (Look at the paper, you'll see what I mean). A simpler approach I thought would be to have transitions go to one third the detail and three times the width, kind of like an expanding checkerboard. Picture a Pascal's triangle of Purina dog chow logos. This optimization worked pretty well. I believe I'm using significantly less geometry than Asirvatham's approach. It doesn't look quite as good, but it's definitely functional.

Because the LOD tapers off much faster with this approach heightmap aliasing effects become apparent much faster, and it made me aware of a serious deficiency with geometry clipmaps that you don't have with other terrain rendering algorithms. If you have a mountain off in the background, and that mountain has two peaks, it might look like just one wide peak depending upon how it's sampled. Irregular mesh approaches don't have this problem as they perform mesh optimization based on changes in slope. Geometry clipmaps just sample willy-nilly regardless of the consequences. A geometry clipmap approach that takes into account the silhouette differences of the resulting terrain might yield better results.

Once I get this project wrapped up I'll post screen shots.

No TrackBacks

TrackBack URL:

Leave a comment



Monthly Archives


About this Entry

This page contains a single entry by Robert W. Rose published on June 3, 2005 1:01 PM.

On the Intel-Apple talks was the previous entry in this blog.

Terrain rendering using geometry clipmaps is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.