Game Development Reference
In-Depth Information
The second optimization involved using a “layering factor” when creating the
noise texture used for sampling the height. The original “Ridged Multifractal
Terrain Model,” in general, accumulates a number of noise octaves (layers) based
in part on the distance from the viewer. As described in the algorithm, some
processing is performed on each noise value to achieve the desired behavior within
the terrain. Using the same noise processing calculations, we embed multiple
layers of the noise within a texture. We are calling the number of added layers to
the noise texture the “layering factor.” The result of this was that we were able
to reduce the number of accumulation iterations (octaves) by the same “layering
factor,” which provided a significant reduction in the total cost of the height
calculation. One of the tradeoffs with this optimization was a reduction in the
randomness of the resulting heights, although this was hard to detect visually.
Another tradeoff was the increase in size of the noise texture in order to preserve
the necessary detail of the additional layers.
The third optimization was to embed gradient information within the noise
texture itself. Accumulated much like the height values, these gradient values
allowed us to attain the surface normal using a variable number of iterations
(octaves) without having to take additional samples to calculate a gradient. This
also reduced the sharp grid-like “knife edges” that became visually problematic
and reduced the overall believability of the terrain model. While this increased the
memory footprint of the texture through the use of the additional color channels,
the overall speed improvement was significant.
In our tests, the CPU utilization averaged approximately 1%. Frame rendering
times for our demo averaged between 20 to 25 ms, while running at a resolution
of 1 , 024
768. The demo was run on a 2.9 GHz AMD Phenom CPU with 8 GB
system memory, and a 512 MB AMD RADEON HD 6450 video card.
A breakdown of the timing for each stage of the algorithm, for a typical frame
of our demo, is as follows:
Pixel Shader
Total (ms)
Stage Shader (ms) Shader (ms) (ms)
1 0.005 0.021 0 0.026
2 0.071 0.661 0 0.732
3 0.014 0.955 19.404 20.373
From the timing results listed above, it is interesting to note that the most sig-
nificant costs involved in the use of the algorithm were not found within the
geometry shader, as expected. Both the iterative subdivision in Stage 2, as well
as the LOD algorithm used in Stage 3, added comparably marginal costs. The
pixel shader, when compositing the resulting subdivided mesh in Stage 3, domi-
nated the incurred costs of the algorithm. Furthermore, when profiling Stage 3,
Search Nedrilad ::

Custom Search