Flexible Generation and Lightweight View-Dependent Rendering of Terrain

Transcription

1 Flexible Generation and Lightweight View-Dependent Rendering of Terrain Blake Pelton Darren C. Atkinson Computer Engineering Department Santa Clara University 500 El Camino Real Stanta Clara CA Abstract The generation and real-time rendering of terrain are related problems that occur in the development of virtual reality and gaming applications. These applications must be able to create and render realistic terrains at interactive rates. In many applications it is desirable to generate unique terrains instead of reusing static geometry time and again. Finally, all applications that render large terrains must cope with selecting the correct subset or approximation of the terrain geometry to render during each frame. In this paper we describe a terrain generation and rendering system. Multiresolution shaders are used to procedurally generate terrains. An innovative subset selection algorithm is used to render terrains with very minimal CPU usage. CR Categories: I.3.7 [Computer Graphics]: Three-Dimensional Graphics and Realism Fractals; I.4.10 [Image Processing]: Image Representation Hierarchical I.3.8 [Computer Graphics]: Applications ; Keywords: Computer Games, Rendering, Surface Simplification, Fractals, Terrain. 1 Introduction Many interactive visualization applications, such as video games, are required to display realistic terrains. To accomplish this, these applications typically load a rectangular height field during initialization and render a triangulation of this height field during runtime. Both of these steps contain challenging problems. The loading step defines what the terrain will look like. A simple way to accomplish this step is to load a pre-made height field from disk. This approach is easy to program and guarantees predictable results but requires the potentially large data set to be stored on a disk and allows no variety of the terrains. Another way to generate terrains is to let the computer generate them procedurally. This method requires minimal disk space and allows a near infinite number of terrains to be created. Rendering realistic terrains at interactive rates requires a carefully crafted algorithm that balances the competing requirements of bpelton@scu.edu atkinson@engr.scu.edu realism and frame rates. A realistic rendering of terrain requires the terrain to be represented by a near optimal set of triangles while an efficient rendering of terrain requires few triangles. A brute force rendering method renders an entire terrain at the highest level of detail regardless of viewing parameters. This method works well for small terrains but does not scale well because large terrains could require millions of triangles to describe. Graphics hardware cannot maintain interactive frame rates with such large triangle loads. To deal with this problem, hierarchical methods were developed (see [Hoppe 1998], [Lindstrom and Pascucci 2001], [Duchaineau et al. 1997], and [Pajarola 1998]). These algorithms select a subset or approximation of the terrain to be rendered based on viewing conditions. This alleviates the load placed on the graphics processor by not rendering off-screen or insignificant triangles. While these systems scale well, they require the CPU to frequently traverse a hierarchical structure to determine which triangles are off-screen or insignificant. This adds a CPU overhead that may be too high for applications like video games that need to use the CPU for other purposes like collision detection, pathing, and physics. In this paper we present TerraLib, a terrain generation and rendering system designed for use by interactive graphics applications on personal computers. The first part of this paper describes the terrain generation component of this system that uses shaders written in a high level language to create multiresolution descriptions of height fields. This allows applications to create a wide range of realistic height fields. The second part of this paper describes the terrain rendering component that uses the graphics processor to perform scalable terrain subset selection which approximates the results of hierarchical methods with minimal CPU usage. 2 Related Work 2.1 Terrain Generation A popular model used for terrain synthesis is called fractional Brownian motion or fbm. As described in [Fournier and Carpenter 1982], fbm is a self-similar stochastic model that has been used countless times in computer graphics. As described in [Fournier and Carpenter 1982], a popular method for generating fbm structures is to start with a base primitive, such as a triangle, and subdivide that primitive into smaller primitives. Alternatively, one can sum a set of scaled random noises at various frequencies (see figure 1). While the fbm model has been very effective in procedurally generating height fields, fbm algorithms do not have a wide range of output possibilities. In other words one fbm height field looks very similar to another. The key idea that TerraLib takes from the fbm model is that self-similar terrain can be generated through multiresolution processes. In addition to generating height fields from a model, height fields can also be created to have the same look and feel as existing height fields. To do this we draw on ideas from image synthesis research.

2 Figure 1: Fraction brownian motion expressed as a linear combination of noises of exponentially increasing frequency. Figure 2: A high-pass () and low-pass () filter bank applying a wavelet transform to decompose an image into multiresolution components. A fundamental theme in image synthesis research has been to transform an image into a multiresolution space that allows one to identify the defining features of an image. Once this transformation has been made, a stochastic algorithm can be used to generate a new image that has the same features as an input image (see [De Bonet 1997] and [Heeger and Bergen 1995]). Our system uses a high level shading language to create the multiresolution components of the synthesized height field. This system allows for fbm height fields to be created and for height fields to be synthesized with similar properties to pre-existing height fields. 2.2 Terrain Rendering Most of the previous research in terrain rendering has used hierarchical structures to reduce the vertex-processing load on the graphics hardware. Pajarola [Pajarola 1998], Lindstrom et al. [Lindstrom and Pascucci 2001], and Duchaineau et al. [Duchaineau et al. 1997] repeatedly subdivide right triangles to achieve a viewdependent mesh that optimizes an arbitrary error metric. Hoppe ([Hoppe 1998]) uses progressive meshing to simplify a terrain into a base mesh and a sequence of vertex splits that refine the mesh. At runtime he selects the particular set of vertex splits that optimize an error metric. All of the hierarchical methods do a very good job of selecting the critical parts of a terrain mesh to be rendered for a given set of viewing parameters, thus reducing the vertex-processing load on the GPU. They do so at the cost of CPU cycles however. By sacrificing the use or arbitrary error metrics our system is able to offload most of the CPU overhead associated with selecting the correct terrain approximation to render. TerraLib is motivated by the requirements of programs that need to use the CPU to do more than render terrain. 3 Terrain Generation TerraLib is a part of the computer graphics tradition that uses scriptbased shaders to generate datasets. TerraLib uses shaders written in a high level language to set the parameters of a terrain model. Because the shaders allow for random number generation, they can generate unique results upon every invocation. The key to the success of this system is an accurate terrain model. 3.1 Fractional Brownian Motion The nature of terrain, particularly its self-similarity, has been studied for some time. A time-tested model of terrain is fractional Brownian motion (fbm). This model captures the self-similarity of terrains as a summation of scaled noises at varying frequencies (see figure 1). 2-Dimensional fbm can be quickly evaluated by a computer using an equation of the form: n 1 f Bm(x,y) = rand( x i=0 2 i, y 2 i ) B i (1) where i represents the frequency of the signal, n is the base-2 logarithm of the size of a side the input image, and B i is a set of scaling factors. These scaling factors typically fall exponentially with frequency. This model does a good job of synthesizing realistic, self-similar terrains. By adjusting the scaling factors applied to the noise at each frequency, one can adjust the smoothness of the terrain (high frequency components create more rough terrain). As previously discussed, the fbm model suffers from the problem that it cannot discribe a wide range of terrains and thus all fbm terrains look alike. TerraLib generalizes the multiresolution image generation techniques of fbm to create terrains with many unique appearances. TerraLib does this by having the user write shaders that define the function inside the summation of equation (1) in a high level language. More specifically TerraLib shaders create images by defining one function for each color channel that takes as input x and y coordinates and a frequency and returns an intensity value. The luminance of the output image is used as the height values of the terrain. 3.2 Wavelets Given the fbm terrain model, it is useful to decompose an image (height field) into its multiresolution components. To do this Ter-

3 ralib uses the wavelet transform. The Wavelet transform is a wellknown transform in digital signal processing (see [Mallat 1999]) with many applications in computer graphics (see [Stollnitz et al. 1996]). The wavelet transform takes an input signal and converts it into many signals of varying resolutions. Each output signal contains those details that are lost in the next lower resolution output signal (see figure 2; filter bank notation adapted from [Mallat 1999]). The inverse wavelet transform takes the multiresolution signals and sums them into one output signal. Thus TerraLib shaders generate image pyramids in wavelet space that are converted into images via an inverse wavelet transform. TerraLib shaders generate realistic terrain because of an important property hinted at by the success of the fbm terrain model: many terrain features (e.g., terrain roughness) can be characterized by the histograms of the wavelet transform of a height field. The TerraLib fbm shader is simply expressed as: f Bm(x,y, f req) = rand() k f req (2) where k is a constant which determines how quickly the scaling factors decrease. Additionally TerraLib shaders can apply wavelet transforms to pre-existing height fields to synthesize new height fields with similar properties to existing height fields. The key is to make sure that the levels of the output image pyramids have similar histograms to the corresponding levels of the wavelet transform of the input image. For example, given an fbm height field: fbm1, generated with a formula of the form: f Bm1(x,y, f req) = rand() B( f req) (3) where B is an unknown function (which defines the histograms of the levels of the wavelet transform of fbm1). A similar height field: fbm2, can be synthesized by sampling the wavelet transform of fbm1: W( f Bm1). f Bm2(x,y, f req) = (W( f Bm1))[rand(),rand(), f req] (4) This technique is a simplification of multiresolution texture synthesis methods (see [Heeger and Bergen 1995] and [De Bonet 1997]) which works well for height field synthesis. 4.2 View-Volume Culling / Sliding Sampling Grid To achieve view-volume culling, the TerraLib renderer enforces an important restriction: the subset of the terrain to be rendered must be a fixed size rectangle. Given this restriction, the GPU can be used to approximate view-volume culling. At load time, a 2D array of vertices V is created by sampling a height field at regular intervals. Next, a list of indices I is created which creates a triangulation of a rectangular subset of V (see figure 3). This list of indices represents a grid that samples V. By adding a constant to all the values of I, the sampling grid can slide around the terrain. In mainstream graphics libraries like Microsoft s Direct3D adding a constant to a list of indices is an operation which can be handled by the video driver and thus can potentially be done on the GPU. Figure 3: A rectangular array of vertices with a rectangular subset triangluated by a restricted quadtree sampling grid and the same vertices with a constant added to all of the indices. To render such a terrain, the CPU only needs to compute an appropriate position for the sliding sampling grid (see figure 4). This can be based on where the camera is looking, the position of the camera, or any other calculation. Because the size of the terrain and the sampling grid are known, the CPU can easily calculate the correct constant to add to all the indices. After this point all of the work is done by the GPU. 4 Terrain Rendering The goal of terrain rendering systems is to quickly select a subset or approximation of a terrain to be rendered each frame. The TerraLib terrain renderer offloads most of the triangle selection computation onto the GPU. This restricts the triangle subset selection algorithm but maximizes triangle throughput and minimizes CPU usage. 4.1 Error Metrics Hierarchical terrain renderers like those found in [Hoppe 1998], [Lindstrom and Pascucci 2001], [Duchaineau et al. 1997], and [Pajarola 1998] can use screen-space error metrics to guide terrain refinement or decimation. Three important benefits of screen-space error metrics are: Off-screen triangles are discarded (view-volume culling) The level of detail of distant terrain areas is restricted (viewdistance simplification) The level of detail of triangulation can be adapted based on the complexity of the source height field (terrain-based refinement). Although the TerraLib terrain renderer does not use screen-space error metrics, it is built around these three important benefits of screen-space error metrics. Figure 4: 2 screen shots of a scene generated by TerraLib. The camera in the first image has been moved to show how the sliding sampling grid can be moved to fit a view volume. The second image shows the same scene from the normal perspective.

4 4.3 View-Distance Simplification The triangulation that creates the list of indices can allow for viewdistance simplification to further reduce the vertex processing load on the GPU. TerraLib uses the restricted quadtree triangulation (see [Pajarola 1998] and [Lindstrom and Pascucci 2001]) to achieve crack-free view-distance simplification. The list of indices is created such that it has the highest level of detail at its center (see figure 3). By sliding the sampling grid at runtime so that it is beneath the camera, near points on the terrain are sampled at a higher frequency than far points. While this further reduces the vertex processing load on the system, it causes the temporal aliasing ( popping ) found in many level-of-detail rendering systems. An application can control the number of triangles in the sampling grid and the size of the sampling grid to trade rendering speed for visual appeal. 4.4 Terrain-Based Refinement In this system, local adaptations can be made to adjust the displayed level of detail based on the underlying complexity of the terrain. At load time, the 2D array of vertices can be adjusted. For example, TerraLib uses an iterative algorithm to adjust the vertices so that all of the highest resolution triangles have approximately the same area. Note that these adjustments slightly degrade the accuracy of determining where the sliding sampling grid is placed for a given index offset. 5 Experimental Results TerraLib was implemented in C++. In this section, we qualitatively discuss the results of results of the terrain generation component and quantitatively discuss the results of the terrain-rendering component. 5.1 Figure 5: The synthetic height field generated by the first script (left) and a rendering of that height field (right). New Medford Our second script synthesizes a height field from an existing height field. The script first applies a wavelet transform to a height map of Medford Oregon. The script generates a new multiresolution pyramid by randomly sampling the wavelet transform of the input image. Replacing the highest frequencies of the input image with fbm yielded visually pleasing results. NewMedford (x, y, freq) = if(freq < k) RealMedford(rand(), rand(), freq) fbm(x,y,freq) While the output height map did not contain the riverbeds of the original height map, the output height map did create a terrain with approximately the same roughness as the original (see figure 6). This shows that the histograms of the levels of wavelet transforms of terrain capture some, but not all, of the characteristic features of height fields. Terrain Generation We built a compiler for a language similar to C. This language is used to define a function that maps a 2-dimensional coordinate and a frequency to a color intensity. In this section we present pseudocode and the results of three example scripts in this langauge. fbm, waves, and a mountain Our first script generates completely synthetic terrain. It linearly combines fractional Browian motion, sinusoidal waves, and a peak to create a realistic landscape (see figure 5). Terrain(x, y, freq) = fbm(x, y, freq) + waves(x, y, freq) + mountain(x, y, freq) fbm(x, y, freq) = rand() * k^freq Waves(x, y, freq) = if(freq == HighestFrequency()) cos(x) * cos(y) 0.0 Mountain (x, y, freq) = if(freq == HighestFrequency()) (1.0 - DistanceBetween([x, y], [MountainX, MountainY])) 0.0 Figure 6: The input Medford height field, a synthesized height field, and a rendering of a synthesized height field generated by the second script. Blend Our final script blends a height map of Medford Oregon with Seattle Washington. The script first applies a wavelet transform to the input height fields. The script blends the high frequency information from the Medford height map with the low frequency information from the Seattle height map.

5 Blend (x, y, freq) = if(freq > k) Medford(x, y, freq) Seattle(x, y, freq) 6 The result was a terrain with varying roughness (see figure 7). With a small set of real-life input height maps, a program could generate a huge palette of height fields via blending them with randomly chosen weights. Conclusions and Future Work We have presented a multiresolution shader technique for generating terrain and a terrain rendering algorithm which minimizes CPU usage. Our terrain generation algorithm is based on the asumption that the histograms of the levels of multiresolution pyramids capture the defining characteristics of height fields. Our terrain rendering algorithm combines the triangle throughput of brute force rendering with many of the terrain subset selection benefits of hierarchical renderers. Our terrain generation algorithm failed to capture the riverbeds of the real world height field. While the multiresolution wavelet space provides a framework to decompose many terrain features, this shows that it does not capture all of the defining features of terrain. We believe that another transformation could more accurately describe the terrain features caused by erosion. A system that generates/analyzes terrain in the Fourier space could possibly capture these missing features. Our terrain rendering algorithm causes temporal aliasing when using varying level of detail triangulations. To solve this problem, some systems smoothly interpolate abrupt changes in terrain (see Hoppe s geomorphs [Hoppe 1998]). It may be possible to extend our framework to have the GPU perform this interpolation. Also, our rendering algorithm does not gracefully handle fly-throughs with widely varying altitudes because of the fixed size of the sliding sampling grid. This problem might be solved by scaling the grid if one could perform more complex operations on the triangle indices than simple addition (for example, multiplication followed by addition). We did not implement this functionality because complex index operations are not exposed by current graphics hardware. References Figure 7: The input Seattle height field, the Seattle/Medford blend height field, and a rendering of the blended height field generated by the third script. 5.2 Terrain Rendering Our terrain rendering component was built on top of Microsoft DirectX 8.1. Triangle throughput was measured on consumer level graphics accelerators. For comparison we list the triangle throughput from our test application running in a 640x480 window next to the triangle throughput found in the Microsoft DirectX 8.1 Optimized Mesh sample application which is a good measure of real life maximum triangle throughput for a consumer level video adapter (see table 1). CPU Speed (MHZ) Adaptor ATI Rage Mobility 3D Labs Oxygen GVX1 Matrox G550 NVIDIA GeForce256 NVIDIA GeForce3 TerraLib Throughput (Mtri/s) Optimized Mesh Throughput (Mtri/s) Table 1: Performance measurements of the terrain renderer. D E B ONET, J. S Multiresolution sampling procedure for analysis and synthesis of texture images. In SIGGRAPH, D UCHAINEAU, M. A., W OLINSKY, M., S IGETI, D. E., M ILLER, M. C., A LDRICH, C., AND M INEEV-W EINSTEIN, M. B ROAMing terrain: real-time optimally adapting meshes. In IEEE Visualization, F OURNIER, A LAIN, D. F., AND C ARPENTER, L Computer rendering of stochastic models. In Communications of the ACM, H EEGER, D. J., AND B ERGEN, J. R Pyramid-based texture analysis/synthesis. In SIGGRAPH, H OPPE, H. H Smooth view-dependent level-of-detail control and its application to terrain rendering. In IEEE Visualization 98, L INDSTROM, P., AND PASCUCCI, V Visualization of large terrains made easy. In IEEE Visualization 01, M ALLAT, S A Wavelet Tour of Signal Processing, 2nd edition. Academic Press, San Diego, California. PAJAROLA, R. B Large scale terrain visualization using the restricted quadtree triangulation. In IEEE Visualization 98, S TOLLNITZ, E. J., D E ROSE, T. D., AND S ALESIN, D. H Wavelets for Computer Graphics. Morgan Kaufmann Publishers.