Outdoor 3D Scenery Rendering a 3D world using Geometrical Mipmaps and Quadtree Culling Andreas Spante Jonas Roos
Luleå Tekniska Universitet Institution Skellefteå GSCEPT Immense 3D Scenery - Building a 3D world using Geometrical Mipmaps and Quadtree Culling by Spante, Andreas Roos, Jonas - GSCEPT GSCEPT 2005 Abstract Theoretical and practical information on how to effectively build an outside world using Geometrical Mipmaps, Heightmaps and Quadtree culling.
Table of Contents: 1 INTRODUCTION... 4 1.1 PROJECT INTRODUCTION... 4 1.2 CONTRACTOR AND PERFORMERS:... 4 1.3 QUESTION AT ISSUE:... 4 1.4 GOAL:... 4 1.5 METHODS... 4 1.6 ACKNOWLEDGEMENTS... 4 2 OVERVIEW...5 2.1 LEVEL OF DETAIL ALGORITHMS... 5 2.2 SPATIAL DATA STRUCTURES... 6 2.3 QUADTREES... 7 2.4 OCTREES... 8 3 IMPLEMENTATION... 9 3.1 TERRAIN REPRESENTATION... 9 3.2 GEOMETRICAL MIPMAPPING... 10 3.3 SOLVING GEOMETRY GAPS... 12 3.4 CHOOSING AN APPROPRIATE LEVEL OF DETAIL... 13 4 FUTURE WORK... 13 5 RESULTS... 14 6 CONCLUSION... 14 7 SUMMARY... 14 REFERENCES:... 15
1 Introduction 1.1 Project introduction The problem with an outdoor world is that one wants to show as many triangles as possible but on the other hand wants as high framerate as possible. The applications that have these problems are usually games and other graphical applications. The most common way to eliminate these problems is to use some kind of Level of detail algorithm and to use Octree or Quadtree culling. 1.2 Contractor and performers: The project was carried out by Andreas Spante and Jonas Roos studying at the GSCEPT institution at Luleå Technical University. It is part of the examination of a course in Graphical Programming. 1.3 Question at issue: We want to find out if there is a suitable method for real time rendering of terrain in AgentFX. 1.4 Goal: The goal with this project is to find out the most suitable level of detail algorithm and culling algorithm for an outdoor 3D world and implement them into a simple demo using AgentFX. 1.5 Methods Research of existing material Mathematics 1.6 Acknowledgements We acknowledge Lasse Wedin and Martin Börjeson for their work in the same area. We've had a lot of discussions regarding implementation and have talked a lot about the best solutions available for our problems.
2 Overview 2.1 Level of detail algorithms There are couple of algorithms that can be used for the level of detail problem that one has when dealing with large map data. Here we will look at some of the differnt algorithms and talk briefly about them. Geometrical ClipMap Overview: A Geometrical Clipmap is a sort of level of detail algorithm that utilizes the fast memory of the graphics card for vertex buffer storage. When the camera moves over the landscape the vertex buffers are incrementally refilled. That assures visual continuety and a stable framerate. The terain is cashed in the memory as nested regular grids around the viewer and the closer they get the finer the detail gets. They are stored at power of two resolutions.[l4] Fig 1: Illustration using a coarse geometry clipmap. [B1] ROAMing Overview: ROAMing is a level of detail algorithm where all the triangles are sorted into two binary trees that later will be manipulated. The entire terrain dataset is encapsulated in the two combined root triangles. The vertices of the root triangles are extracted from the root node in the quadtree strukture. Each triangle is assigned pointers to its neighbours and to its left and right child. When this is done the root triangles are pushed onto a FIFO queue so that one can do a bredth first traversal through the binary trees. The algorithm has five phases that are done every frame. First it uses recursive, incremental update to calculate the view frustum culling. The second step is to do a priority update for the triangles that can be split or merged in step three. Then it merges or splits the triangles that are in the two priority cueues. The last step is to update the triangles affected by the culling in step one and the split/merges from phase three.[l5] MipMapping Overview: Geometrical MipMapping is a level of detail algorithm based on the same theory as that of Texture MipMaps. It uses a terrain grid that is divided into a set number of quadratic terrain blocks. For each block, a set number of versions with different level of detail are created. Based on the distance away from the camera along with a few other conditions to avoid unwanted popping artifacts, an appropriate GeoMipMap level is chosen for each block. [L1]
2.2 Spatial Data Structures We have looked at different spatial data structures to handle the culling that needs to be taken care of in our program. Here we will discuss the pros and cons with the different techniques. Spatial Data Overview: A spatial data structure is a structure that takes care of geometry data and organizes it in an n-dimensional tree. They are usually used for culling, ray tracing and collision detection. The concept with the spatial data structure is that instead of checking all geometry one can traverse trough a tree and only check the relevant geometry. A linear search for a node would be an O(n) search and a tree search would take O(log n) searches. It is quite expensive to build a spatial data structure so they are often preprocessed. [L2] For example: If there are 64 geometry nodes and one just want to draw one of them the worst case scenario with a linear structure would take 64 searches to find the node. When using a Quadtree structure the worst case would take 12 searches. Root Node Internal Node Internal Node Internal Node Internal Node Internal NodeInternal NodeInternal NodeInternal Node Leaf Node Leaf Node Leaf Node Leaf Node Fig 2: A Quadtree Search with tree levels will in the worst case make 12 searches to find the right Node. There are a number of different spatial data structures, the most commonly used for culling in an outdoor environment are Octrees and Quadtrees. If there is more than one level in the tree a Quadtree consists of four internal nodes at the first level and an Octree consists of eight nodes.
2.3 Quadtrees A quadtree is a spatial data structure in which each internal node can consist of up to four children. It is an iteration process where each of the nodes are divided along the center of the nodes x and y axis. The iteration continues until some predefined condition is fulfilled. The last level of the tree consists of the leaf nodes which contain the actual data. The data is usually an object or a set of polygons. When using Quadtrees with view frustum culling the program checks if the internal node is inside, outside or partially inside the view frustum. If the node is entirely inside the frustum it gets attached to the rendering node. If it is entirely outside the frustum the program will discard it and not make any more calculations on that node. If the node is partially inside the view frustum it will continue to check the nodes children and see if the are inside, outside or partially inside the frustum. The iteration will continue until all the affected nodes have been discarded or attached to the rendering node. The last step is to send the rendering node down the graphical pipeline for rendering. [L2], [L3] Fig 3: A simple Picture of how a Quadtree is divided along the X and Y axis in a 2D plane. The red square is the root node, the blue square is one of four internal nodes and the green square is another internal node within the blue node. The leaf nodes are represented by the yellow squares and they contain the actual graphical data. The Quadtree is best used for a static landscape which has no flying objects since the height is cut out of the equation. So if you for example have an object 20 meters above ground and the camera is on 10 meters looking down the program will not cull away that object. This means that it will be sent down to the graphical pipeline and drawn for no use at all.
2.4 Octrees An Octree works just as a Quadtree but in 3 dimensions. So each iteration splits the cube along the x, y and z axis. The iteration will continue until the predefined condition is fulfilled. The predefined condition might be that the smallest cube should fit the entire object or that no cube should be smaller than 2x2x2 pixels. So each internal node has eight children instead of the four in Quadtree culling. The data is contained in the leaf nodes which has no children. When doing view frustum culling with Octrees it checks if a box is inside, outside or partially inside the frustum. If a box is inside the frustum it will be added to the rendering node and if it's not it will be discarded. When a box is partially inside the view frustum it will check its children to see if they are inside, outside or partially inside the frustum. The iteration will continue until all the affected boxes are checked. Lastly the rendering node is sent down the pipeline for rendering. [L2], [L3] Fig 4: A simple picture showing how an Octree is divided along the center of the nodes X, Y and Z axis. [B2] Octrees are ideal for culling in an open 3D room such as open space with planets and stars. The drawback when using Octrees for culling is that it takes more time than using a Quadtree.
3 Implementation We wanted to base our implementation on algorithms that are easy to understand and simple to implement - basic but still fast. In keeping it simple we decided to avoid any algorithms requiring GPU programming and instead try to make use of the GPU power by sending appropriately sized triangle batches to the GPU. Based on these wishes, Geometrical MipMapping felt like the most suitable choice; easier to understand than ROAMing and not requiring any GPU programming like Clipmaps. We will use quadtree culling in our program since we are not working with an immense universe and we put speed in the foremost room. 3.1 Terrain representation Our terrain is built up as a 2n x 2n grid in the xz-plane consisiting of (2n+1) x (2n+1) vertices with a fixed distance between them. Each vertex is then assigned a height (y) value from an 8-bit grayscale heightmap of the same dimensions as the terrain. This means one has 256 different shades of gray, from black to white, where each shade represents a different height. This representation is not only simple to implement but also very suitable for geometrical mipmapping. The main disadvantage is that it doesn't support overhangs, which might be an issue depending on what type of terrain you intend to make [L1]. In our case, the heightmap is loaded from a.raw-file which is the format Terragen [P1] exports to, but most image formats should work. Fig 5: An 8 x 8 grid (9 x 9 vertices) where each circle represents a vertex. The height value is fetched from an 8-bit grayscale heightmap.
3.2 Geometrical mipmapping The concept of geometrical mipmapping of terrain is very similar to that of texture mipmaps [L2]. This is basically how it applies to terrain rendering: First you divide the terrain into fixed size terrain blocks of size 2m x 2m. For our application, we use a terrain size of 1024 x 1024 built up from 256 terrain blocks where each block is of the size 64 x 64 (units). Experimentation is key when trying to figure out the optimal terrain size and block size for various applications. 16 16 4 4 Fig 6: A 16 x 16 terrain build up from 16 4 x 4 blocks. For each block, a set number of versions with different resolution are created (dependant on the block size). This is what is called geometrical mipmaps [L1]. They can be precalculated at terrain load time and stored in memory. The idea being that a terrain block far away from the camera doesn't need to be rendered at the same resolution as a nearby block, so we choose to render a lower resolution version of the block further away. The default (highest) resolution version of each block is called Level 0. When making this block a step size of 1 is used, meaning the distance between vertices (vertical and horizontal) is one unit. For this level, all values in the heightmap are utilized giving the block a very fine detail. The second highest resolution of a block is called Level 1 and so on. Every time you step down one level in resolution, you double the step size. In effect, each lower level resolution version contains only ¼ the number of triangles compared to the level above it.
Step = 1 Step = 2 Level 0 Step = 4 Level 1 Step = 8 Level 2 Level 3 Fig 7: Illustrations of the different levels of an 8 x 8 sized terrain block. The green circles show the vertices used to build up that particular level and the white circles show the vertices skipped.
3.3 Solving geometry gaps But what happens when you have two blocks with different level of detail next to each other as in the picture below? Fig 8: Adjacent blocks of different detail level. Geometry gaps will occur along the edge between the blocks (thick line) as a result of the fact that the less detailed block uses fewer vertices to build up the edge. One way to solve this is through the use of triangle fans as decribed in [L1]. We've opted for a somewhat different approach that felt easier to implement with AgentFX [P2]. First, the edges are separated from the centrum of the block. Each edge is then adjusted to fit the resolution of the adjacent block as shown in the following images: Level 1 North Edge West Edge East Edge Center South Edge Level 0 Fig 9: The yellow edges (north and west) are made to fit a lower resolution block while the blue edges (south and east) are made to fit a a block of the same resolution.
In separating the edges like this, none of the them need to take into account the detail level of the block's other edges (for example, the north edge doesn't need to know the detail level of the east and west edge). The main drawback of patching blocks together this way is that the difference in detail between two adjacent blocks may never be more than one level. However, this limit also makes it easier to precalculate the edges and store them in memory, since we only need two versions of each edge for each level except for the lowest level of detail (for which we need only one). To be able to choose the appropriate edges for a block, each block needs to keep references to its neighbors. When two adjacent blocks have different detail, it's always the block with the higher resolution that is responsible for making its edge fit to the lower resolution block. 3.4 Choosing an appropriate Level of Detail We decided to go with the easiest and most straightforward way to choose an appropriate resolution for a block, which simply is to calculate the distance away from the camera and set the detail accordingly. If a block is far away from the camera a lower resolution version will be used. 3.5 Texturing and Shading For texturing, we use a single large texture that is stretched over the entire map. The AFX Texture Manager class is utilized to load the texture into memory. Based on the height map, we then calculate a normal for each vertex to give the terrain a nicely shaded look when lighting is applied. A single white point light is used to light the scene. 4 Future work Improvements that can be made to the application: Take into account the height difference between different levels of detail when deciding which version of the block to be used, instead of just distance away from the camera, to reduce popping artifacts. MultiTexturing
5 Results Results from testing on a Pentium 4 2.66GHz with a Radeon 9800 Pro and 512 MB RAM. Block size: 65 x 65 vertices Map size: 1025 x 1025 vertices LOD enabled Culling enabled Average FPS 50 25 15 6 6 Conclusion It is possible to create an Outdoor 3D scenery in AgentFX using Geometrical MipMapping and Quadtree culling. The results showed us that the algorithms we used were a good choice and provided satisfactory framerates. 7 Summary To improve computer rendering speed of large terrains, one has to use some kind of Level of Detail algorithm. This paper describes the theory behind one such algorithm called geometrical mipmapping To improve the culling in OpenGL it is a good idea to use some kind of Spatial Data structure. The most efficient one for culling in an outdoor 3D environment without loose flying objects is Quadtree Culling. Quadtrees uses an iteration process that checks if a quadrant is inside, outside or partially inside the View frustum. The nodes that are inside the frustum will be set as children to a draw node which will get passed down the graphical pipeline to be rendered.
References: [B1] Geometrical Clipmap http://graphics.stanford.edu/~losasso/publications/geomclipmap/geomclipmap.pdf [B2] Octree Image http://nilo.stolte.free.fr/octree.html [L1] Willem H. de Boer, Fast Terrain Rendering Using Geometrical MipMapping http://www.flipcode.com/articles/article_geomipmaps.pdf [L2] Real-Time Rendering. Tomas Möller, Eric Haines. A K Peters, Ltd. ISBN 156881-182-9 [L3] Object Representation by Means of Nonminimal Division Quadtrees and Octrees http://portal.acm.org/citation.cfm?id=3975 [L4] Geometry Clipmaps: Terrain Rendering Using Nested Regular Grids http://graphics.stanford.edu/~losasso/publications/geomclipmap/geomclipmap.pdf [L5] View-dependent Real-time Terrain Rendering Using Static LOD http://www.cs.virginia.edu/~yy8a/vrtruslod.pdf [L4] GPGPU:General General-Purpose Purpose Computation on GPUs http://download.nvidia.com/developer/presentations/2005/i3d/i3d_05_gpgpu.pdf [P1] Terragen, Planetside Software http://www.planetside.co.uk/terragen [P2] AgentFX, Agency 9 AB http://www.agency9.se