Michael Platings

The Tiled Quad Tree

A New Method for the Compression of Large Scale Terrain Data for Real Time Visualisation
A thesis submitted for the degree of

Master of Science
University of East Anglia 2003

This copy of the dissertation has been supplied on condition that anyone who consults it is understood to recognise that its copyright rests with the author and that no quotation from the dissertation nor any information derived therefrom, may be published without the authors prior, written consent.

Abstract
The Rapid World Modelling project aims to implement a system to visualise the topography of the entire world on consumer-level hardware. This presents a significant problem in terms of both storage requirements and rendering speed. This thesis presents the Tiled Quadtree, a new technique and format for the storage of digital terrain models, to work as part of an integrated system for the visualisation of global terrain datasets. We show how this format efficiently stores and compresses elevation data, in a way that allows the data to be read very rapidly from hard disk or similar storage medium, to facilitate real-time rendering. Additionally, we show how this format may be used to efficiently store spheroid models for global datasets.

Page 2

Contents

ABSTRACT.............................................................................................................................................2 TABLE OF FIGURES............................................................................................................................5 1 INTRODUCTION.................................................................................................................................8 2 RELATED WORK............................................................................................................................. 11 2.1 REGULAR GRID................................................................................................................................. 11 2.2 MULTIRESOLUTION PYRAMID...............................................................................................................11 2.3 QUADTREE........................................................................................................................................13 2.4 BINARY TREE................................................................................................................................... 18 2.5 TRIANGULATED IRREGULAR NETWORK..................................................................................................19 2.6 WAVELET.........................................................................................................................................23 3 RATIONALE FOR CHOICE OF UNDERLYING STRUCTURE............................................... 25 3.1 SUMMARY OF METHODS...................................................................................................................... 25 3.2 COMPARATIVE ANALYSIS....................................................................................................................27 4 DESIGNING THE QUADTREE.......................................................................................................29 4.1 BASIC STORAGE STRUCTURE.................................................................................................................29 4.2 DATA COMPRESSION........................................................................................................................... 32 4.3 SUBTREE REUSE................................................................................................................................. 33 4.4 TILE BASED OVERHEAD REDUCTION.......................................................................................................34 4.5 TILE ORDERING..................................................................................................................................36 4.6 SPHEROIDAL DATA............................................................................................................................ 37 5 VISUALISATION...............................................................................................................................40 5.1 QUADTREE STRUCTURE....................................................................................................................... 40 5.2 MESH CONSTRUCTION........................................................................................................................ 41 5.3 MESH RENDERING.............................................................................................................................. 45 5.4 SCREENSHOTS....................................................................................................................................46 6 RESULTS & ANALYSIS...................................................................................................................49 6.1 DATASETS........................................................................................................................................ 49 6.2 COMPRESSION RESULTS....................................................................................................................... 51 6.3 COMPARISONS WITH OTHER COMPRESSION METHODS................................................................................ 54 6.4 RUNTIME RESULTS.............................................................................................................................57

Page 3

7 CONCLUSION & FUTURE WORK................................................................................................65 7.1 FUTURE WORK................................................................................................................................. 65 8 REFERENCES....................................................................................................................................66 APPENDIX - DEFINITION OF FILE FORMAT.............................................................................73

Page 4

Table of Figures
FIGURE 1: VERTICES IN A REGULAR GRID TERRAIN MODEL........................................... 11 FIGURE 2: A MAP STORED AS A TILED PYRAMID.................................................................. 12 FIGURE 3: A SIDE ON VIEW OF A QUADTREE WITH 11 COLUMNS AT ITS BOTTOM LAYER. THE SLOP ZONES ALLOW DIMENSIONS OTHER THAN POWERS OF 2............ 14 FIGURE 4: THE WHITE AND BLACK QUADTREES. UNUSED VERTICES ARE MARKED WITH A CROSS. REPRODUCED WITH THE KIND PERMISSION OF PETER LINDSTROM......................................................................................................................................... 15 FIGURE 5: THE WHITE QUADTREE EMBEDDED IN THE CORNERS OF THE BLACK QUADTREE. REPRODUCED WITH THE KIND PERMISSION OF PETER LINDSTROM...15 FIGURE 6: VERTICES IN A QUADTREE....................................................................................... 16 FIGURE 7: OBJECT SPACE AND PROJECTED IMAGE SPACE ERROR............................... 16 FIGURE 8: A BINARY TREE WITH VERTICES AT THE CENTRE OF THE LONGEST EDGE OF EACH TRIANGLE.............................................................................................................19 FIGURE 9: A QUADTREE WITH VERTICES STORED AT THE CORNERS OF NODES..... 29 FIGURE 10: VERTICES DIVIDED INTO LAYERS....................................................................... 31 FIGURE 11: THE GROUPED VERTICES OF LAYERS 0, 1 & 2, AND ALL THREE LAYERS SUPERIMPOSED. UNGROUPED VERTICES ARE SHADED IN GREY................................... 31 FIGURE 12: A QUADTREE NODE....................................................................................................31 FIGURE 13: NODES IN A QUADTREE............................................................................................ 31 FIGURE 14: ELEVATION DATA AND ITS INTERPOLATED APPROXIMATION................ 32 FIGURE 15: VERTEX APPROXIMATIONS AND OFFSETS....................................................... 32 FIGURE 16: A 1 DIMENSIONAL ARRAY OF ELEVATION VALUES, AND THE CORRESPONDING BINARY TREE................................................................................................. 33 FIGURE 17: THE 1 DIMENSIONAL ARRAY OF ELEVATION VALUES, AND THE BINARY TREE WITH SUBTREE REUSE........................................................................................................ 33

Page 5

FIGURE 18: NODES (REPRESENTED BY SMALL SQUARES) GROUPED IN 16 * 16 NODE TILES. WHERE THERE ARE NOT SUFFICIENT NODES TO FILL A TILE (AS ON THE HIGHER LEVELS) THE TILES REMAIN PARTIALLY FULL................................................... 35 FIGURE 19: THE ELEVATION OF A POINT, AND THE OFFSET BETWEEN THE INTERPOLATED ELEVATION AND THE ACTUAL ELEVATION...........................................36 FIGURE 20: THE SUBTREE GROUPING METHOD.................................................................... 37 FIGURE 21: THE LAYER GROUPING METHOD......................................................................... 37 FIGURE 22: A GEOGRAPHIC PROJECTION OF PLANET EARTH.........................................38 FIGURE 23: A RHOMBIC TRIACONTAHEDRON........................................................................38 FIGURE 24: A FACET (CENTRE), WITH POINTERS TO ITS NEIGHBOURS, PARENT, AND CHILD NODES............................................................................................................................ 40 FIGURE 25: A SERIES OF SCREENSHOTS, IN BOTH FILLED AND WIRE-FRAME RENDERING MODES, SHOWING A FLIGHT FROM SPACE TO THE ISLAND OF HAWAII..................................................................................................................................................48 FIGURE 26: A RENDERING OF THE WEST CRATER LAKE DATASET. HEIGHTS ARE EXAGGERATED FOR CLARITY..................................................................................................... 49 FIGURE 27: A RENDERING OF THE CENTRAL PARK DATASET. HEIGHTS ARE EXAGGERATED FOR CLARITY..................................................................................................... 49 FIGURE 28: A RENDERING OF A SUBSECTION OF THE MOUNT ADAMS DATASET. HEIGHTS ARE EXAGGERATED FOR CLARITY........................................................................ 50 FIGURE 29: THE HAILEY EAST DATASET. HEIGHTS ARE EXAGGERATED FOR CLARITY............................................................................................................................................... 50 FIGURE 30: TQT COMPRESSION RATES AT DIFFERENT TILE WIDTHS. ALL TESTS WERE PERFORMED ON THE WEST CRATER LAKE DATASET........................................... 51 FIGURE 31: FILE SIZES, EXPRESSED AS A PERCENTAGE OF THE ORIGINAL BINARY FILE SIZE, COMPARED WITH ERRORS, EXPRESSED IN METRES......................................52 FIGURE 32: THE CRATER LAKE DATASET COMPRESSED TO SELECTED ERROR TOLERANCES...................................................................................................................................... 53 FIGURE 33: COMPRESSION RATES OF THE MOUNT ADAMS DATASET AT DIFFERENT HORIZONTAL GRID SPACINGS..................................................................................................... 53

Page 6

FIGURE 34: TQT COMPRESSION COMPARED WITH THAT OF THE ON DISK AND IN MEMORY METHODS OF [GERSTNER 2001].............................................................................. 55 FIGURE 35: TQT AND WAVELET COMPRESSION COMPARED............................................56 FIGURE 36: CUMULATIVE CACHE MISSES FOR DIFFERENT TILE WIDTHS, ON THE DESCEND TEST.................................................................................................................................58 FIGURE 37: CUMULATIVE CACHE MISSES FOR DIFFERENT TILE WIDTHS, ON THE ORBIT TEST.......................................................................................................................................58 FIGURE 38: CUMULATIVE LOADING TIMES FOR DIFFERENT TILE WIDTHS, ON THE DESCEND TEST.................................................................................................................................59 FIGURE 39: CUMULATIVE LOADING TIMES FOR DIFFERENT TILE WIDTHS, ON THE ORBIT TEST.......................................................................................................................................59 FIGURE 40: THE NUMBER OF INDIVIDUAL LOADING TIMES FOR DIFFERENT TILE WIDTHS, ON THE DESCEND TEST..............................................................................................61 FIGURE 41: THE NUMBER OF INDIVIDUAL LOADING TIMES FOR DIFFERENT TILE WIDTHS, ON THE ORBIT TEST.................................................................................................... 61 FIGURE 42: ACCUMULATED CACHE MISSES FOR THE FLYOVER TEST......................... 63 FIGURE 43: THE CUMULATIVE LOADING TIME FOR THE FLYOVER TEST................... 63 FIGURE 44: THE NUMBER OF PER-FRAME LOADING TIMES GREATER THAN CERTAIN THRESHOLD VALUES FOR THE FLYOVER TEST................................................. 64

Page 7

1 Introduction
Terrain visualisation is an increasingly important area of research, as its use continues to extend into new areas. As the processing power of computers continues to grow, it is possible to visualise increasingly large areas at ever higher levels of detail. The aim of the Rapid World Modelling project, begun at the University of East Anglia in 2000, is to utilise this power by visualising the entire planet Earth in 3D at interactive frame rates, on consumer-level hardware. A major focus of this project is to accurately visualise the terrain of the earth. This thesis concentrates on solving the various problems encountered in storing the data required to achieve this aim. The Shuttle Radar Topography Mission (SRTM) has successfully mapped the topography of 80% of the worlds land masses at 30 metre grid spacing. A desirable use of this data, as described by [Gore 1998], is to view it in 3D and navigate it in real-time. When visualising terrain data in three dimensions, it is possible to look across the landscape, and view massive areas of the terrain. To view such areas in high detail at a fixed resolution would require billions of polygons, which is well in excess of the capabilities of modern hardware. By rendering areas at variable resolution, using LOD (Level Of Detail) rendering techniques such as those described in [Duchaineau et al. 1997], [Lindstrom & Pascucci 2001] and [Rttger et al. 1998], it is possible to render such large datasets in real time. However, as the dataset exceeds the memory capacity it is necessary to fetch the data from external memory e.g. hard disk or similar device. As this is many times slower than main memory, the way the data is stored and retrieved can have a great impact on the speed with which the data can be rendered. An additional consideration is the size of the data. The SRTM data would require over a terabyte to store, which is well in excess of the capacity of any consumer-level storage device. Therefore it is necessary to compress the data. The main format in use today for topography storage is the United States Geological Surveys Spatial Data Transfer Standard (SDTS) [USGS 1998a]. The What is SDTS section of [USGS 1998a] gives the following overview: The Spatial Data Transfer Standard (SDTS) provides a practical and effective vehicle for the exchange of spatial data between different computing platforms. It is designed specifically as a format for the
Page 8

transfer of spatial datanot for direct use of the data. By addressing all aspects of spatial data, SDTS is comprehensive in nature effectively avoiding pitfalls of other transfer formats that have been used in the past. SDTS can store point, linear, and area features as 2D vector data, and 2D raster surfaces. The vector data is typically used to represent roads and buildings, while the raster surfaces are used to represent the topography of an area. The format encodes data as ASCII text, in a large number of separate files. The format has proved unpopular within the GIS (Geographic Information Systems) community, and has been criticised for being cumbersome [Childs 2002], incredibly complex and a giant step backwards [Townsend 2002] and a truly ugly, awful mess of a format [Discoe 2002]. There appear to be almost as many data formats as there are data providers, but there is very little variation in how they work. A typical and widely used format is the DEM (Digital Elevation Model) [USGS 1998b], which stores data using a simple raster format. The differences between the common formats are primarily in the order in which the data is stored and the types of metadata that accompany the data. The disadvantages of these formats are that they do not provide any data compression. If compression is required, it is possible to compress files using gzip or a similar utility. However, this kind of compression requires that the entire file be extracted prior to use, which is not practical when the data can be many gigabytes in size. An additional deficiency is that the compression does not take advantage of the properties of elevation data, so typically only 2:1 compression is attained. Better compression rates may be achieved by storing the data as a greyscale image in a format such as JPEG or TIFF, but these formats still require that the entire file be decompressed prior to use. The majority of LOD algorithms require information on the complexity of each part of the terrain information that cannot be calculated quickly and accurately during run-time, so must be calculated and stored during pre-processing. Existing formats give no provision for the storage of this information. We have not found a format that works in a different way to the 2D-raster approach, so a new format is required that solves the problems identified here. In this thesis we describe a system that both optimises the speed of data access from external memory, and also greatly compresses the data. In section 2 we review
Page 9

other research work done on terrain storage methods, and in section 3 we evaluate these methods for their suitability for use as part of our method. In section 4 we describe our storage method in detail. Section 5 gives an overview of the system we have implemented for visualising the terrain data. Numerical results are presented and analysed in section 6. The thesis is concluded in section 7.

Page 10

2 Related Work
There is a large body of research relating to the storage of elevation data. Here we examine techniques that are suitable for real-time rendering, and their advantages and disadvantages are outlined.

2.1 Regular Grid

This commonly used method stores height values at regularly spaced points in a twodimensional array, as shown in Figure 1. Horizontal co-ordinates are stored implicitly by a values location within the array.

Figure 1: Vertices in a regular grid terrain model.

This methods simplicity has meant that it has been adopted for all the major formats currently in use.

2.2 Multiresolution Pyramid

This method stores an area at multiple resolutions, each in a separate regular grid. The grids are conceptually arranged in separate levels, with each level being subsampled to half the resolution of the level below it, which is similar to mipmapping for texture data [Williams 1983]. The advantage of storing multiple resolutions becomes apparent when attempting to visualise large or highly detailed datasets at lower resolutions, as with an LOD algorithm. If the data is too large to be stored in memory, the data must be fetched from hard disk during run-time. The average seek time for a typical IDE harddisk is 8.5 milliseconds [Maxtor 2001]. With an efficient algorithm, several hundred separate data elements may be fetched in each frame.
Page 11

If we consider, as a conservative example, an access rate of 100 elements per frame: 8.5ms * 100 elements = 0.85 seconds. This would give a maximum frame rate of 1.18 frames per second, which is not acceptable for a real-time application. If the data is stored at multiple resolutions, the required elements can all be fetched in far fewer read operations, and the seek times will be reduced, thereby greatly decreasing the time spent fetching data. There is an extra storage cost for using this method, as in addition to the base data, the subsampled data is also stored. For a dataset of width and height 2 n , the number of samples in the base level is 2 2 n . If the data is subsampled until a 1*1 sample level is reached, there will be n + 1 levels. Each of the subsampled layers contains a quarter the number of samples of the layer below it. Therefore the total number of samples within a dataset of width and height 2n will be equal to
2 2n 4 i
i= 0 n

The summation evaluates to 1 +

1 4

1 16

1 64

1 256

+ 1 1 , which means that the 3

storage cost of the subsampled data is approximately an extra third of that of a regular grid of the same area. 2.2.1 Tiled Pyramid

Disk access times can be further reduced, by the use of tiling. The grid on each level is subdivided into many equally sized rectangular tiles, as shown in Figure 2. Each tile contains a fixed number of height values, e.g. 256 x 256 values.

Figure 2: A map stored as a tiled pyramid.

The data in each tile is stored contiguously. This is advantageous as each tile can be fetched in a single read operation, so typically the number of disk accesses is reduced, and the seek time for each access is reduced compared to fetching data line by line. For this reason, this method is used by the GeoVRML standard [Reddy & Iverson 2000].

Page 12

2.3 Quadtree
The quad tree is a data structure that is used for the recursive decomposition of twodimensional spatial data. A quad tree is composed of nodes. Each node can contain or reference some form of data, and can reference up to 4 child nodes. Each node corresponds to a certain area, and each of its child nodes corresponds to a subset of that area. The quad tree algorithm typically subdivides the area represented by a node by splitting it across two perpendicular lines, resulting in four quartiles, each of which corresponds to one of the child nodes. From this basic concept there are many adaptations and variations, of which the principal types and their applications are described in [Samet 1984]. Several methods based on the quad tree have been suggested for the storage of height data: 2.3.1 Quadtree for datasets with non-power-of-two dimensions

[Wynn et al. 1997] describes a storage scheme for terrain that allows terrains with non-power-of-two dimensions to be stored in a quadtree-like structure. Due to its regular-subdivision structure, the quadtree in its usual form can only store data that have equal dimensions of powers of two (e.g. 2, 4, 8, 16 etc.). For the storage of terrain this is disadvantageous, as terrain datasets rarely come in power-oftwo dimensions, and must therefore be resampled prior to storage. A pointerless quad tree is used, which is essentially a multiresolution pyramid, described previously in Section 2.2. The complete quad tree is stored which means that there is a simple positional relationship between a node and its child, parent and neighbour nodes. Therefore it is unnecessary to store pointers, as the position of a nodes relations can be derived trivially from its co-ordinates. To allow for terrains with dimensions other than powers of two, the concept of slop zones is introduced. A slop zone is a single extra column or row at the edge of an array at any level. These occur when the number of columns or rows on a level is odd. As the nodes in the slop zones have child nodes, the asymmetry propagates down the tree, and by adding further slop zones on lower levels the tree can be altered so that any number of rows or columns can be stored.

Page 13

Slop zones

Figure 3: A side on view of a quadtree with 11 columns at its bottom layer. The slop zones allow dimensions other than powers of 2.

Figure 3 shows a side-on view of a tree that has 11 columns. To accommodate this scheme, a node at the top or right edge of a level can have 4 child nodes (as in a conventional quad tree), or 6 child nodes, to include the slop nodes of the level below it. The node at the top right of the level can have 4, 6 or 9 child nodes. This scheme allows for terrains with non-power-of-two dimensions with the caveat that the ratio of the dimensions cannot be greater than 1:2. To solve this, instead of subdividing both rows and columns on each level, rows or columns alone can be subdivided on a level. These extensions allow the representation of a terrain with any dimensions, at a slight computational cost. The goals of this storage scheme are as follows: (1) Minimise storage. The storage method described introduces approximately the same storage overhead as a conventional multiresolution pyramid, which is not minimal, but only introduces an extra third of the storage for a standard 2D array. (2) Allow efficient access. Data may be accessed efficiently due to the lack of pointers, although when fetching sections of data from disk it is likely that a tilebased scheme would be faster. (3) Support many different visualisation techniques. The technique is highly flexible in that it can be used to store any rectangular terrain dataset, so it could potentially be used for a wide variety of visualisation applications. 2.3.2 Embedded Quadtrees

[Lindstrom & Pascucci 2001] and [Lindstrom & Pascucci 2002] describe Embedded Quadtrees. This structure is designed to minimise page faults, and have an efficient procedure for calculating the index of data elements, while also remaining relatively simple, and therefore adaptable.

Page 14

Figure 4: The white and black quadtrees. Unused vertices are marked with a cross. Reproduced with the kind permission of Peter Lindstrom.

The structure contains two complete pointerless quad trees: a white quadtree and a black quadtree, shown in Figure 4. The corner vertices are not included in either quadtree, so are stored separately. Notice that many of the vertices in the black quadtree are not used as they fall outside the area represented. This causes waste in storage resources of roughly 66% of the input data. This cost is reduced by splitting the white quadtree into 4 quadtrees, and embedding the levels of each smaller quadtree in the corners of the adjacent level of the black quadtree, as shown in Figure 5.

Figure 5: The white quadtree embedded in the corners of the black quadtree. Reproduced with the kind permission of Peter Lindstrom.

This does not eliminate unused vertices, but reduces their cost from 66% to 33% of the input data. The procedure given for calculating the index of a vertex, based on its parent vertex, requires only a multiply and two additions, and is therefore very efficient. For the number of page faults, comparisons are made with three other storage schemes, a 2D array, a tiled 2D array, and the z-ordered space filling curve scheme [Asano et al. 1997]. The embedded quadtree and z-ordering scheme caused approximately the same number of page faults, several orders of magnitude fewer than either of the other two schemes. Comparisons with multiresolution pyramids were not made, which is unfortunate, as that is one of the most widely used schemes in terrain visualisation. The reason given for the lack of this comparison is that it would be unfair due to the pyramid schemes use of multiple indices for each vertex,

Page 15

but without this comparison the use of the more complex embedded quadtree scheme cannot be justified. 2.3.3 LOD-based Clustering

[Bao & Pajarola 2002] describes a method of storage designed to minimise file access times when visualising data stored in external memory (e.g. stored on hard disk or similar medium). This paper was made publicly available several months after the implementation of my method was completed, but it is included here as it is an interesting new development. The paper describes how file access times are minimised by using clustering techniques that group data according to how they are likely to be accessed. These techniques use a pointer-based quad tree composed of nodes, each node containing three vertices, positioned at the centre, and west and north edges of the area it represents. Nodes positioned at the east or south edges of the map also contain vertices at the east or south of the area they represent. In this way, a complete map is built, without vertices being repeated, as shown in Figure 6.

Figure 6: Vertices in a quadtree.

When rendering a dataset with an LOD algorithm, whether a lower detail node is drawn instead of a higher detail node depends upon how large the projected image space approximation error would be, demonstrated in Figure 7.

Figure 7: Object space and projected image space error.

Page 16

This error is dependent upon the position and orientation of the viewer, and the nodes object space approximation error. The former varies throughout runtime, but the latter remains constant, and can therefore be used during pre-processing to predict the most likely sequence in which the nodes will be accessed. Due to triangulation dependencies between nodes, a node may also be drawn if a nearby node has a high projected image space approximation error. For these reasons, nodes with similar errors and similar location tend to be accessed at the same time, and therefore should be clustered together. This is the underlying principle of the design of the clustering techniques described in the paper. Nodes are grouped into small complete subtrees, with the error of the node at the top of the subtree being within a certain threshold of the largest error of the nodes at the bottom of the subtree. Subtrees are stored in pages. All pages contain the same number of bytes, which is a number that is equivalent to a multiple of the size of disk blocks. This makes fetching the page from hard disk more efficient. Each page contains one or more complete subtrees. Subtrees are grown (i.e. levels are added to the bottom of the tree) until the error threshold value is exceeded, or the subtree has exceeded the size of the current page. This reduces the space left unused in each page. The paper describes two techniques, basic and optimised. The optimised technique uses a slightly different strategy for arranging the data. The paper compares these with the hierarchical tiling method similar to that of [Lindstrom et al. 1997] (a similar system to the tiled pyramid described in section 2.2.1) and the embedded quadtrees of [Lindstrom & Pascucci 2001] (described in section 2.3.2). The storage requirements for each technique are compared. The dataset used would require 128Mb to be stored as a simple 2D array. For the embedded quadtree and the tiled method the requirements are approximately 1.33 Gb, the basic technique requires approximately 0.6 Gb, and the optimised requires 0.5 Gb. While the storage requirements are much less than for the embedded quadtree and the tiled method (although it should be noted that [Lindstrom & Pascucci 2001] explicitly states that storage efficiency is not an objective) they are much higher than required for a 2D array. The structures do include additional information not included in a standard 2D array, such as approximation-error data, but even when considering this, the storage requirements are comparatively very large.

Page 17

A flythrough of a sample terrain dataset is performed using each method, and the number of page faults is measured. A page fault occurs when the required data is not already cached in memory, and requires the data to be fetched from disk. A successful clustering algorithm will minimise the number of page faults. The technique described in [Lindstrom et al. 1997] performs the worst, at 57,000 page faults, [Lindstrom & Pascucci 2001] causes 23,000, the basic technique causes 14,000, and the optimised technique causes 10,000 page faults. This demonstrates that the optimised technique is very good at reducing page faults.

2.4 Binary Tree

The binary tree is similar in concept to the quad tree, except that each node has a maximum of only two child nodes. A binary tree is typically used for the decomposition of one-dimensional data, but it can also be used to recursively decompose two-dimensional data by alternating the direction of the line along which the subdivision takes place. Figure 8 shows the decomposition of an area using a binary triangle tree, the most commonly used method, with each triangle being bisected through its longest edge. 2.4.1 Gerstners Method

[Gerstner 2001] presents two methods for the compression of height data using binary triangle trees. The first uses a minimalist encoding of the binary tree to reduce its overhead. The second uses a more explicit binary tree encoding. This approximately triples storage requirements, but allows the data to be partially decompressed, and is hence suitable for real-time visualisation. Gerstner proposes that data be stored in the first form, then extracted into memory in the second form prior to rendering, but where the decompressed data is too large to fit in memory this is not possible, so only the second method is examined here. With this method, height values are stored for the centre of longest edge of each triangle, as shown in Figure 8.

Page 18

Figure 8: A binary tree with vertices at the centre of the longest edge of each triangle.

Where triangles share the same longest edge, height values will be duplicated, so to avoid the double storage of height values, the value is only stored at its first occurrence within the tree. Gerstner details an operation for finding the index of the triangle with which a triangle shares a height value: The index of the triangle is taken, and its bits are iteratively inverted in pairs, starting with the lowest bits, until a 01 or 10 code is found. The resultant value is the index. As an example, Gerstner uses the triangle 27 (binary index 11011), which shares its longest edge with triangle 20 (binary index 10100). However, in the normal course of extracting a dataset stored this way for rendering, this process is unnecessary as both triangles will be extracted simultaneously. As test data, a subsampled version of the gtopo30 dataset is used. The accuracy of gtopo30 is 30 metres at a 90% confidence interval [USGS 2002], so 30 metres is a suitable value for the accuracy of the compression. When compressed with an error of 32 metres the dataset is compressed to approximately 20% of its original size.

2.5 Triangulated Irregular Network

The basic definition of a TIN is a collection of triangles that form a continuous approximation to a surface. A TIN can be used to represent any polygonal surface, including a terrain. A basic TIN is composed of geometry and connectivity information. The geometry includes the x, y and z co-ordinates of all the vertices. It is necessary to store all three components as the fact that a TIN is irregular means that the x and y components cannot be stored implicitly, as they can with a regular grid. The connectivity information describes how the vertices are linked together to form triangles. There are a large number of methods for TIN construction, the most popular being Delaunay triangulation. [Owen 1998] provides a good overview of these, but as

Page 19

the focus of this thesis is on the representation, not the construction of datasets, we will not examine this further. 2.5.1 TIN compression

As a nave representation of a TIN, a structure such as the OpenGL indexed triangle array could be used. This stores the x, y and z components of the vertices in one array, and in a separate array, indices to the three vertices at the corners of each triangle. For a single-precision floating point representation of the vertices, each vertex is stored in 12 bytes. If 4 byte integers are used as indices to the vertices, then storing the connectivity of each triangle requires 12 bytes. For meshes with a large number of vertices and triangles, this is a significant storage burden. Deering introduced the concept of geometry compression in [Deering 1995]. The focus of the paper is on an algorithm that could be implemented in hardware, to minimise storage and bandwidth requirements. His algorithm first encodes the TIN as a generalised triangle mesh. This is essentially a standard generalised triangle strip as supported by graphics libraries such as IrisGL and XGL, with the addition of a fixed size vertex buffer. Vertices are explicitly pushed into and referenced from this buffer, rather than being automatically (and wastefully) cached. This method means that up to 94% of redundant vertices are not re-specified. The second step is to quantize the geometry to 16 bits or less. This means that the (floating point) co-ordinates of the vertices are multiplied by a constant value, and then converted to integers, the low-order bits of which are stored. This process is further optimised by encoding vertices as the offset from an adjacent vertex, which is typically a smaller displacement. Colours and normals are also encoded using a similar process. Finally, the vertices are Huffman encoded. This process compresses the data by a factor of between 6 and 10. Chow extends Deerings work in [Chow 1997]. He introduces a meshifying algorithm that generates compactly representable generalised triangle meshes. He also introduces variable quantization, which quantizes vertices at variable precision, depending on how much precision is required in that particular area. With the addition of these two optimisations, data is compressed by a factor of between 10 and 15. The methods described in [Taubin & Rossignac 1998] obtain an even greater compression ratio. A vertex spanning tree is used. This is a sequence of vertex runs which collectively include each vertex in the mesh once. The vertex runs are
Page 20

constructed so that a series of triangle strips are formed between them. This means that the vertices of each triangle strip are referenced implicitly. For each triangle strip it is only necessary to store the length of the strip, plus a series of bits indicating whether the vertex is added on the left or right of the strip. In this way the connectivity of the mesh is encoded very efficiently. The vertex runs are compressed in a similar way to that used of [Deering 1995], quantizing each component and storing delta values which are then entropy encoded using e.g. Huffman encoding. However, the deltas stored are not deltas from the previous vertex, but deltas from values generated by a prediction function, based on the values of previous vertices. This typically gives significantly smaller deltas, which can be more effectively compressed by entropy encoding. The typical compression ratio for this algorithm is stated as 50:1 compared to an ASCII VRML format, which is approximately 20:1 compared to a simple binary format. [Touma & Gotsman 1998] describes an algorithm that compresses meshes even more efficiently. From an initial single triangle, a spiral-shaped triangle strip is grown outwards over the entire mesh. The connectivity is stored as a sequence of commands. The main command adds a number of vertices to the outside of the strip, and then advances to the next vertex on the inside of the strip. Two other commands are also defined for dealing with special cases. The command sequence is entropy encoded and then run length encoded, so that it is near-optimally compressed. The geometry is stored as the sequence of vertices on the outside of the spiral, and compressed using a similar scheme to that of [Taubin & Rossignac 1998]. A function is defined for the prediction of vertex coordinates, which takes the three previous corners of the triangle strip as three corners of a parallelogram, and predicts the next vertex as the fourth corner of the parallelogram. This method was found to give more accurate predictions than when only using the previous vertices of a single vertex run. The results given show that this scheme gives an increase in compression rate over the algorithm of [Taubin & Rossignac 1998] of approximately 60%. This is the most effective geometric compression scheme developed to date.

Page 21

2.5.2

Multiresolution TINs

All TIN compression methods described so far only represent the mesh at a single resolution. For large TINs, such as those of terrains, a multiresolution representation is necessary to allow the mesh to be rendered in real-time. In this section, we present an overview of some schemes for the storage of TINs that facilitate the rendering of meshes at an adaptive level of detail. [Hoppe 1996] introduces the Progressive Mesh. This simplifies the mesh to a coarse mesh consisting of a few hundred triangles, through a series of edge collapse operations. The inverse operation of the edge collapse is the vertex split, and these splits are stored in sequence. By performing vertex split or edge collapse operations on the mesh, the number of triangles in the mesh can be progressively increased and decreased, so that a compromise is achieved between detail and rendering speed. A method is also described for geomorphs, which provide a smooth visual transition between low and high detail meshes, avoiding the popping effect as new vertices are introduced. In [Hoppe 1997], the progressive mesh is enhanced by the addition of an efficient system for view dependent refinement. Instead of representing the mesh at a single level of detail, the detail is varied over the mesh according to three view parameters - the view frustum, the surface orientation and the screen-space geometric error. Refining the mesh this way means that fewer triangles are drawn where they cannot be seen or can only be seen at low detail, thereby speeding up rendering. To allow for efficient selective refinement, the sequential system of storing vertex splits is replaced with a hierarchical system of vertex splits. Vertex splits further down the hierarchy can potentially be performed if their parent splits have already occurred. To avoid cracks occurring in the mesh, dependencies are defined between neighbouring faces in the mesh, which must be satisfied before a vertex split is performed. In [Hoppe 1998], the view dependent progressive mesh (VDPM) is specialised for terrain rendering. The first problem identified is the large memory requirements of the VDPM. As terrain data may be extremely large it is vital that memory requirements are minimised. To reduce the memory requirements, only the connectivity of the currently used parts of the mesh is stored in memory. The connectivity of other sections of the mesh is calculated as they are added to the currently active mesh. Methods are defined to reduce the requirements of the vertex
Page 22

hierarchy and refinement dependencies data, but these are still entirely stored in memory. As a solution to this, a hierarchical block-based partitioning scheme is introduced, which is similar in concept to the tiling method described in section 2.2.1. Methods for refinement and coarsening geomorphs are defined. Both of these perform linear interpolation between the end and start vertices over a constant number of frames. It is simple to implement this for the refinement geomorph, but for coarsening it presents a significant problem. A coarsening geomorph only occurs once the refinement algorithm determines that an edge collapse should occur. However, the edge cannot be collapsed until the geomorph is complete, so until then the unwanted data must be maintained. The refinement algorithm may also determine that edges further up the hierarchy should be collapsed, but this cannot be done until their child edges are collapsed. In this way the coarsening process is stalled, but unfortunately this can only be compensated for by performing coarsening geomorphs over fewer frames.

2.6 Wavelet
In simple terms, a wavelet is a finite section of a mathematical basis function; for example the section of the sine function between - and . A wavelet can be translated and scaled to represent a section of another function, or a section of data. By stitching together many differing scales and translations and scales of a wavelet, it is possible to represent an entire dataset. This becomes useful for the compression of data, as if the basis function is generally a good fit to the data then it is possible to store the wavelet representation many times more compactly than the original data. Terrains are an ideal candidate for this type of compression, as they are approximately waveform in shape. An additional benefit offered by wavelets is that of multiresolution representation of data. Terrain can be thought of as a few large waveforms, perturbed by recursively smaller waveforms. In the same way, by adding differently scaled wavelets together, larger approximating wavelets can be perturbed by progressively smaller wavelets. This means that data can be accessed at low as well as high resolutions, which is advantageous in situations where large sections of data must be loaded rapidly without requiring high accuracy.

Page 23

Unfortunately, as demonstrated by the wavelet-based ECW image compression library [Earth Resource Mapping 2002], these algorithms can be highly computationally expensive to run. This makes them less suitable for real-time visualisation. [Franklin & Said 1995] describes experiments performed using Said & Pearlmans generic wavelet based compression algorithm for the lossy compression of various terrain elevation maps. The results given show that the algorithm is capable of compressing terrain data at high accuracy by a factor of approximately 100:1 over a standard binary representation.

Page 24

3 Rationale for choice of underlying structure

In this section, we examine the relative advantages and disadvantages of each of the storage techniques we have reviewed, with a view to their suitability for use as the basis of the format that we shall develop. The data structure must facilitate the following prerequisites: 1. Efficiently store elevation data from a variety of sources of varying resolutions, projections and orientations. 2. Represent data at multiple resolutions, to facilitate LOD rendering. 3. To further facilitate LOD rendering, information on the complexity of each section of data must be efficiently stored. 4. To allow the storage of global high detail datasets, data must be compressed, using either lossy or lossless methods. 5. The compression must allow individual sections of the data to be rapidly extracted from hard disk or similar storage medium, to facilitate real-time rendering.

3.1 Summary of methods

Regular grid Advantages Disadvantages 1. Its simplicity makes it very easy to 1. It provides no compression, hence it understand. method of digital terrain storage. is unsuitable for large datasets. memory, then accessing sparse data elements (as required by most LevelOf-Detail algorithms) will be very slow due to the slow speed of permanent storage devices. Pyramid and Pointerless Quadtree Advantages Disadvantages 1. Allows data to be loaded at varying 1. Provides no compression. resolutions. 2. Can be easily integrated with 2. Data redundancy increases storage requirements by approximately a 2. It is by far the most widely used 2. If a dataset is too large to fit into

Page 25

quadtree and binary tree based terrain visualisation algorithms. Pointer Based Quadtree

third.

Advantages Disadvantages 1. Can compress data by using few 1. Storage overhead for tree structure. nodes to represent flat areas. 2. Data can be progressively loaded to match the resolution required. 3. Can store data from multiple datasets at varying grid spacing, e.g. a map of a city at 10 metre grid spacing, inset into a map of the world at 1km grid spacing. 4. Corresponds directly to the quadtree Level-of-Detail algorithm. Binary Tree Advantages Disadvantages 1. Can compress data by using few 1. Storage overhead for tree structure. nodes to represent flat areas. 2. Data can be progressively loaded to match the resolution required. 3. Can store data from multiple datasets at varying grid spacing. 4. Corresponds directly to the binary tree Level-of-Detail algorithm. TIN Advantages Disadvantages 1. Compresses flat areas by using few 1. Vertices must be stored explicitly in 3 triangles. 2. Data can be progressively loaded to match the resolution required. 3. No resolution constraints whatsoever. dimensions, 2. Triangulation giving a very can high be storage overhead. process computationally expensive. 2. Can only store square areas of width 2n + 1 where n is a positive integer. This means that it may be necessary to resample data before it can be used. 2. Can only store square areas of width 2n + 1 where n is a positive integer. This means that it may be necessary to resample data before it can be used.

Page 26

4. Corresponds directly to TIN Level-of- 3. Triangulation Detail algorithm. rendered. Wavelet 1. Likely to Advantages give extremely

can

give

sliver

triangles which look ugly when

Disadvantages high 1. Difficult to implement. 2. Compression processes expensive. and very decompression computationally

compression ratio. 2. Can be partially decompressed as required.

3.2 Comparative Analysis

For our purposes, the regular grid, pyramid and pointerless quadtree effectively fall at the first hurdle, as they all have a fixed maximum resolution. In a situation where a high resolution map is inset into a larger lower resolution map, e.g. a 10m map of a city set into a 1km map of the world, this would mean that the entire world would have to be stored at 10 metre resolution to represent the city at its full resolution. This is an unacceptable storage burden, so these three methods were not further considered. The wavelet method is very attractive as [Franklin 1995] and [Franklin & Said 1996] show that it is capable of giving a very high compression ratio. However, the computational complexity of the decompression process means that it is less suitable for a real-time algorithm than other methods. This leaves the quadtree, binary tree and TIN methods in consideration. A relative advantage of the TIN method over the regular subdivision methods is its ability to integrate data from multiple sources without requiring any resampling. Additionally, a TIN is very well suited to representing distinctive features such as mountain ridges, as such formations can be represented directly, rather than being recursively approximated. However, it was decided that these benefits were outweighed by the cost of explicitly storing all three x, y and z co-ordinates. The regular subdivision methods store horizontal co-ordinates implicitly, which makes them less costly to store. The quadtree and binary tree differ by the number of vertices that are introduced at each level of subdivision the quadtree introduces approximately twice as many vertices as the binary tree. This means that the per-vertex storage overhead of the

Page 27

quadtree structure is less than for the binary tree. For this reason, it was decided that a pointer-based quadtree would be used as the basis for the terrain storage structure. Surprisingly, at the time of the storage structures design we could find no published work on using a pointer based quadtree for the storage of digital terrain data ([Bao & Pajarola 2002] has been written since). The fact that [Wynn et al. 97] explicitly states that a pointerless quadtree is used may lead the reader to assume that a pointer-based method had already been developed for terrain storage, but this appears to be untrue. It seems that the pointer-based quadtree has thus far been overlooked, which makes it an interesting technique to explore. We postulate the following hypotheses, which make the quadtree an advantageous structure to use: It will be possible to compress the terrain data, by omitting subtrees where the subtree contains data for relatively flat areas. By loading only the sections of data that are of interest, it will be possible to view datasets that are too large to fit in a computers main memory. The fact that the quadtree is a multiresolution structure means that it will be possible to integrate data from multiple sources at different resolutions into a single dataset. As the data structure will be similar to those used in quadtree-based LOD algorithms, it will be relatively easy to visualise the data. One of the disadvantages of the quadtree is the dimensional restriction imposed on data. However, in the Rapid World Modelling project the data will come from many sources of varying detail and orientation, so resampling would be necessary for most of the data structures I have listed. Another disadvantage is the structure storage overhead. Therefore, the technique that has been developed in our work focuses on reducing, and in some cases eliminating, this overhead.

Page 28

4 Designing the Quadtree

4.1 Basic storage structure
The starting point for designing the storage structure is the context in which it will be used. In this case, it will be used by a quadtree based CLOD terrain rendering algorithm such as those described in [Lindstrom et al. 1996] and [Rttger et al. 1998]. A nave structure that could be used with these algorithms would be composed of nodes consisting of: A reference to each of the four child nodes; A vertex for each of the four corners; A number defining the object space approximation error (see Figure 7) of the node. This is used during rendering, in combination with information about the viewers position and orientation, to determine whether the node should be removed or further subdivided to give an appropriate approximation to the surface.

Figure 9: A quadtree with vertices stored at the corners of nodes.

A quadtree built up from these nodes would conceptually look as shown in Figure 9. When this tree is built up so that all levels were complete, it stores the entire terrain dataset. Therefore this can be used as a nave method for storing the terrain. An examination of this method now follows. We take as an example a dataset of dimensions 65 * 65. This would require 64 + 32 + 16 + 8 + 4 + 2 + 1 = 5461 nodes to store. The storage requirement for each node is: 4 bytes for each of the four references to a child node. A single-precision floating point representation of the x, y and z components of the vertex requires 12 bytes per vertex, for 4 vertices.

Page 29

A single-precision floating point representation of the error value requires 4 bytes. This is (4*4 + 12*4 + 4) = 68 bytes. For the entire terrain, this comes to 371,348

bytes. This does not compare well with the 8,450 bytes needed for a regular grid. The storage requirements can be dramatically reduced by taking the following simple steps: 1. The tree is built by regular subdivision, which means that, given the x and y coordinates at each of the corner vertices, it is trivial to calculate the x and y coordinates of the intermediate vertices. Therefore, it is only necessary to store a single elevation value. 2. The heights of the world are all in the range [-32768, 32767] metres, therefore the elevation value can be stored at 1 metre accuracy as a 16 bit integer. 3. The error value is the maximum height discrepancy between the actual surface and the approximation provided by the node. As heights will be in the range representable by a 16 bit integer, the error value can be stored as an unsigned 16 bit integer. 4. The error value is used as a rough guide to whether further subdivision is required when visualising the terrain, and therefore only an approximate value is required. Therefore the square root of the error value is stored, so only a single byte is necessary to store it. Once these steps are followed, each node requires (4*4 + 2*4 +1) = 25 bytes to store. This is now 136,525 bytes for the 65 * 65 dataset. This is still far greater than the requirement for a regular grid, so further analysis is needed. The nodes store vertices at their corners. Each corner is typically shared between 4 nodes, meaning that vertices are each stored 4 times. By examining the pattern in which the data is accessed, it can be seen that it is necessary to only store each vertex once. The vertices are accessed in layers, as shown in Figure 10.

Page 30

Figure 10: Vertices divided into layers.

With the exception of the top layer, if the top and right edges of each layer are ignored, the vertices can be grouped into threes, shown in Figure 11.

Figure 11: The grouped vertices of layers 0, 1 & 2, and all three layers superimposed. Ungrouped vertices are shaded in grey.

Instead of storing the vertices at the corners of the node, each node stores a group of three vertices from the layer below it. Figure 12 shows a complete diagram of a node, and Figure 13 shows the nodes in the tree structure.

Figure 12: A quadtree node.

Figure 13: Nodes in a quadtree.

It can be seen that all vertices are represented, with the exception of the corners and the top and right edges. This problem is solved by storing the corner vertices separately, and storing the top and right edges as separate binary trees. As each node stores the vertices of the layer below it, the bottom layer of the tree is no longer stored, so that the number of nodes is now 1365. Each node now takes up (4*4 + 2*3 + 1) = 23 bytes, and the total storage (excluding the top and right
Page 31

edges and the corners) for the 65*65 dataset is reduced to 31395. This is still almost 4 times that required for the regular grid.

4.2 Data compression

To compress the data, the elevation values stored in subtrees can be omitted by using linear interpolation. Where the interpolated values for a subtree are accurate to within a certain tolerance value, the subtree can be removed.

Figure 14: Elevation data and its interpolated approximation.

Figure 14 shows an instance in two dimensions where the data is within the tolerance zone of the interpolated data, so it is only necessary to store the end point data. A point is defined to be within the tolerance zone iff the absolute vertical distance between it and the interpolating surface is less than or equal to the tolerance value. This definition means that if the tolerance value is set to zero, points that lie exactly on the interpolating surface will not be unnecessarily stored. Typically this means that highly complex terrain areas, such as mountain ranges, are stored at the maximum resolution allowable by the source data, while smoother areas of terrain are stored using fewer nodes, thereby compressing the data. The degree of precision with which to store the data can be changed by modifying the tolerance value. For lossless compression the tolerance value can be set to zero.

Figure 15: Vertex approximations and offsets

Page 32

The approximating surface used for each quad is two triangles, as illustrated in Figure 15. This effectively means that the approximations to heights at the edges are calculated simply as the mean of the two adjacent corner heights. The approximation to the centre height is the mean of the bottom right and top left heights. We define the calculation for the mean as: ( (int)height_A + (int)height_B ) >> 1 A bit shift is used in place of a divide by two, as this is a less computationally expensive operation. It is important to note that when the mean is a negative noninteger the bit shift will not give the same result as a divide the bit shift always rounds down, while a divide rounds towards zero. For this reason, only the bit shift operation must be used. To further compress data, two approaches were considered, described in sections 4.3 and 4.4:

4.3 Subtree reuse

Figure 16: A 1 dimensional array of elevation values, and the corresponding binary tree.

Figure 17: The 1 dimensional array of elevation values, and the binary tree with subtree reuse.

The first approach considered was to match similar areas of terrain, and use the same groups of tree nodes to represent both. This can be demonstrated using the 1dimensional equivalent of the quad tree, the binary tree. In Figure 16, a binary tree is used to store a linear array of heights. It can be seen that the right half of the data is similar to the left half of the data. Therefore, the root node can use the left subtree for both the left and right subtrees, as shown in Figure 17. In this case, the storage requirements are almost halved. As this process can be performed as many times as there is repeated data, the compression ratio is potentially enormous. However, if the repetition in the data was not aligned with the tree structure (e.g. if the data repeated after 5 elements instead of after 4 elements), no compression could be performed, which severely limits the usefulness of this approach. In addition,

Page 33

the process of searching for similar sections of data takes O(n) time, which, when data may be many gigabytes in size, is prohibitively expensive. For these reasons, it was decided not to adopt this approach, but instead the approach that was adopted was to concentrate on reducing the overhead imposed by the quad tree structure. This is described in section 4.4:

4.4 Tile based overhead reduction

The basic storage requirements for a quad tree node are: 3 vertices (3 * 2 bytes = 6 bytes) + Complexity data (1 byte) + A pointer to each of the 4 child nodes (4 * 4 bytes = 16 bytes) = 23 bytes In the following section we demonstrate that this can potentially be reduced to just 3 bytes per node. To reduce the overhead of the quad tree structure the data is arranged so that a nodes child nodes are stored contiguously, which then means that only a reference to the first child needs to be stored. However, some child nodes may not exist (this would have previously been indicated by a null pointer). There are two possible ways to solve this: 1) Ensure that each node always has either no child nodes (indicated by a null pointer) or all 4 child nodes. However this would be potentially very wasteful if 4 nodes were always stored even when as few as 1 node is actually required. 2) Alternatively a single byte is added to the node containing 4 flag bits to indicate the presence of each child node. This is the solution we have used. In this step the storage requirements have been reduced to 23 + 1 12 = 12 bytes. Next, we introduce the concept of tiling. Each level of the tree is subdivided into smaller square sections, all with the same maximum width and height (in terms of the number of nodes). These sections are called tiles. Figure 18 shows a quad tree with its nodes grouped into tiles of 16*16 nodes width.

Page 34

Figure 18: Nodes (represented by small squares) grouped in 16 * 16 node tiles. Where there are not sufficient nodes to fill a tile (as on the higher levels) the tiles remain partially full.

We refer to this new structure as a Tiled Quadtree, abbreviated to TQT. Tiling was originally introduced to the format as a method of improving the speed with which the data could be loaded. Section 2.2.1 explains the benefits of the tiling strategy in this context. It was found that by grouping nodes into tiles like this, information that is applicable to all nodes within the tile can be stored once within the tile header, rather than once for each node. A property of a tile is that, like a quad tree node, it will have a maximum of four child tiles. Each node in the tile will have its child nodes located in one of these child tiles. The consequence of this fact is that it is unnecessary to store the 32-bit address of each nodes child, but instead the index of the child node within its tile can be stored. If all indices in a tile are less than 65536 (which will always be the case if the maximum dimensions of each tile is 256 * 256 nodes or less), each index can be stored in 2 bytes. If all indices in a tile are less than 256 (which will always be the case if the maximum dimensions of each tile is 16 * 16 nodes or less), each index can be stored in 1 byte. This reduces the storage requirements by 2 or 3 bytes per node. To indicate the length of indices a flag bit can be set in the tile header. To deduce in which tile a nodes children will be is a trivial task, as this correlates directly to in which quartile of the tile the node is located. If the node is in quartile 0, its child nodes will be in child tile 0, etc. The nodes of each quartile are stored contiguously, so to find out to which quartile a node belongs it is necessary to store in the tile header the index of the first node in each quartile. The index of the first node in quartile 0 will always be 0, so it is unnecessary to store this value. This increases the storage requirements of each tile by a maximum of 3 indices (typically 1

Page 35

or 2 bytes each). The address of each child tile is stored in the tile header, increasing the storage requirements by a maximum of 16 bytes per tile. A negative consequence of using indices to nodes is that all nodes within a tile must be of the same length in bytes, which means that it is not possible to optimise individual nodes. In the byte used to indicate the presence of a nodes child nodes, only 4 bits are used, with 4 bits remaining. It is possible to share the byte between adjacent nodes, the first node using bits 0-3, the second node using bits 4-7. This reduces the storage requirements by 0.5 bytes per node. A 16-bit (2 byte) integer is typically used to store elevation values. In many instances, all the elevation values in a tile will be in the range [-128, 127], so each value can be stored in a single byte. If this occurs, a flag bit is set in the tile header, and only the least significant byte is stored for each elevation value. To increase the likelihood of elevation values only requiring a single byte, elevation offsets are stored rather than absolute elevations, as this value will typically be smaller, demonstrated in Figure 19. Once these steps are taken, the per-node storage requirements are reduced from 12 bytes to between 9.5 and 5.5 bytes.

Figure 19: The elevation of a point, and the offset between the interpolated elevation and the actual elevation.

The final step in reducing storage requirements can be applied if all the nodes in a tile are leaf nodes (i.e. they have no child nodes). In this case, the bytes used to indicate the presence of child nodes will all have a value of 0 and the complexity data will have a value of 0, so it is only necessary to store the elevation values. Where this occurs, the tile is called a leaf tile. This reduces the storage requirements to just 3 or 6 bytes per node.

4.5 Tile ordering

An additional consideration is the order in which the tiles should be stored. This is important for the speed with which each tile is loaded, as before the hard disk can

Page 36

load the tile, it must first seek to the tiles position. By storing tiles in the order in which they are likely to be accessed, it is possible to significantly reduce seek times. The TQT structure does not impose any restriction on the ordering of tiles, so two methods were considered, the 2D equivalents of which are illustrated in Figure 20 & Figure 21. 1 2 3 4 5 7 6 8 11 10 12 14 9 13 15 8 4 9 10 2 5 11 12 6 13 14 1 3 7 15

Figure 20: The subtree grouping method.

Figure 21: The layer grouping method.

The subtree grouping method causes tree branches to be grouped together. This is advantageous when it is likely that several layers of the tree will be successively accessed, particularly near the bottom of the tree. Nearer the top of the tree this method is less efficient as each tile is more widely separated from its sibling tiles. The layer grouping method groups tiles so that they are adjacent to their sibling tiles. This is advantageous when the data is likely to be accessed over a large area on few layers. This method is disadvantageous in that it causes a large separation between parent and child tiles, particularly near the bottom of the tree. Overall the layer grouping method better fits the access pattern during LOD rendering of terrain, so that is the method used here.

4.6 Spheroidal Data

Our planet is approximately an oblate spheroid in shape [Weisstein 2002a], but the quad tree data structure can only store data in a square arrangement. This presents a significant problem if we wish to represent the entire Earth in a single model. This problem has been the subject of much study throughout recent centuries, as cartographers attempted to represent the curved surface of the Earth on a flat sheet of paper. There is no perfect solution, as all approaches inevitably introduce some distortion. Most global mapping software use a geographic projection, which maps longitude and latitude to a rectangular grid, giving a result shown in Figure 22.

Page 37

Figure 22: A geographic projection of planet Earth

For areas near the equator, this gives little distortion, but at the poles the distortion is extreme, stretching a single point to the length of the equator. In addition to the distortion, this is disadvantageous due to the large amounts of data taken up by the relatively small area of the poles. Therefore an alternative is desirable. When viewing a map in two dimensions (as with a conventional paper map) it is desirable for the entire surface to be mapped onto one continuous surface. However, if a map is to be converted back to three dimensions before viewing, this restriction no longer applies. The map can be split into many sections, which can be mapped onto the faces of a polyhedral approximation to a sphere. The question is now which polyhedron to use. The criteria for the selection of the polyhedron are: The faces must form quadrangles with edges of equal length, to be compatible with the tiled quad tree format. All quadrangles formed must be of equal shape and size to avoid disparities. The faces should form a close approximation to the surface of a sphere to minimise distortion. In effect, this means that polyhedra with a larger number of vertices are more desirable. For these criteria, the most suitable polyhedron is the rhombic triacontahedron [Weisstein 2002b], shown in Figure 23.

Figure 23: A rhombic triacontahedron.

The rhombic triacontahedron has 32 vertices, 60 edges of equal length and 30 quadrilateral faces of equal size and shape.
Page 38

To map from a spheroid to the triacontahedron, the spheroid is scaled to form a sphere. The sphere is positioned at the centre of the triacontahedron, and projected from its centre outwards onto the faces of the triacontahedron. The faces are individually skewed to form squares. These squares now form a complete twodimensional map of a spheroid, with minimal distortion. The data in each of these squares is stored in a separate quadtree. To simplify the mapping from longitude/latitude to the triacontahedron, it is recommended that the triacontahedron is orientated so that vertices connecting five quads are positioned at the north and south poles. If this orientation is used, each quad has the property that its extremities of longitude and latitude will occur at its vertices, not on an edge or within the interior of the quad. Additionally, no quad covers a region of greater than 72 longitude. As most global or large-area maps come in longitude/latitude format, this simplifies the selection and caching of data prior to its inclusion in a quad.

Page 39

5 Visualisation
In this section we describe a simple method suitable for visualising the TQT at interactive frame rates. This method is primarily based on that of [Rttger et al. 1998], but also incorporates many ideas from [Lindstrom et al. 1996], [Duchaineau et al. 1997], [Hoppe 1998], [Blow 2000] and [Lindstrom & Pascucci 2001]. Our method uses a quadtree structure to store a triangulation of the terrain. The quadtree is progressively updated according to the viewers position, and the topography of the terrain.

5.1 Quadtree structure

Figure 24: A facet (centre), with pointers to its neighbours, parent, and child nodes.

The quadtree is composed of nodes, which, to differentiate them from TQT nodes, we refer to as facets. Each facet contains pointers to each of its four neighbouring facets, and its parent and child facets, shown in Figure 24. A facet has either 0 or 4 children, which are stored in a contiguous block. This means that only a single child pointer is required, which points to the first child. Additionally, this improves memory locality. To support loading data from the TQT, the facet stores the address of the tile where its child nodes are stored, and the indices of those 4 child nodes within the tile. A facet has indices to 9 vertices - 4 corner vertices, 4 edge vertices, and 1 centre vertex.

Page 40

A vertex is composed of a position and a normal vector. Normals are calculated on-the-fly as the cross-product of the vectors between the vertexs 4 nearest neighbour vertices. Normals are updated throughout runtime to reflect updates made to the mesh. All vertices in the current triangulation are stored in a single static vertex array. This array is allocated from AGP memory1, which speeds up the transfer of vertices to the graphics card. Vertices can be added and removed from the array as required. As vertices are removed from the array, holes are created in the array. The positions of these holes are stored in a stack. When vertices are added they are positioned in the array to fill the most recently created hole, and the position of the hole is popped from the stack. If there are no holes, the vertices are appended to the back of the array. To obtain the terrain data from a TQT tile, the whole tile is loaded prior to use. As data from a single tile is likely to be accessed many times in quick succession, we can achieve a very large speedup by caching tiles. An 8-way associative cache is used to store the most recently used tiles. The cache contains a constant number of slots, each of which can contain one tile. A hash table, based on the address of each tile within the TQT file, is used to assign a tile to a slot. When a new tile is loaded, it replaces the least recently accessed of the 8 possible tiles. All nodes in a tile are all of a constant length, and we exploit this by storing the tile in memory in its compressed form. When a node is requested it can be instantly taken from the tile and extracted to its uncompressed form. This means that the cost of initially loading a tile is significantly reduced.

5.2 Mesh Construction

The scene is initially represented by a small number of facets, each covering a distinct area of the scene. In the case of a global scene, 30 facets are used, covering the world as described in section 4.6. These initial facets, which we refer to as root facets, are initialised without any parent or child facets, and are set as each others neighbour facets according to their adjacencies. Throughout runtime, the scene is further constructed and altered. To ensure that the terrain appears correctly to the viewer, as well as minimising the rendering time, each frame we adaptively refine the mesh according to the position of the viewer. At
1

This is accomplished in OpenGL using the Vertex Array Range extension for nVidia video cards, and

the Vertex Array Object extension for ATI video cards [SGI 2003]. Page 41

each frame, all the facets in the tree are recursively evaluated, and are either split to add more detail, merged to reduce detail, or left as they are, according to simple criteria. We define the split and merge operations in sections 5.2.1 and 5.2.2. Firstly, in the case of global scenes, if a facet is on a side of the spheroid that is entirely facing away from the viewer then its descendants are culled. If the facet is partially back facing then its child facets are also checked. If the facet is entirely front facing then its descendant facets will also be front facing, so the test is not performed on them. Secondly, the facets are evaluated according to their error value divided by their distance from the viewer. This value is compared with a global tolerance variable. For facets at the bottom of the tree, if the value is greater than the threshold value then the facet is split immediately. For facets one level up from the bottom of the tree, if the value is significantly below the threshold value, a pointer to the facet is added to a list of facets to be merged. To increase and decrease the overall level of detail of the terrain mesh, the tolerance variable can be increased or decreased as required. In our implementation, the tolerance was altered to maintain a constant number of triangles in the mesh, but other criteria may be used instead. It was found that despite the simplicity of the evaluation algorithm, the cost of evaluating the facets took an excessive amount of time to compute, so a method was introduced to reduce the cost of the evaluation step. When facets are evaluated, they are usually not changed. We take advantage of this fact by instead of evaluating the facets at the bottom of the tree, evaluating the facets 4 levels up from the bottom. The facets store the detail value that was calculated the last time they or their descendants were modified. If the difference between the new and the old detail value is greater than a threshold value, the facets child facets are evaluated as normal; otherwise the evaluation is skipped. 5.2.1 Split operation

Facets at the bottom of the tree may be split to add more detail to an area. When this occurs, four new facets are created, which are assigned as the facets child facets. When new facets are created, if one of their vertices does not already exist, it is loaded from the tile cache, and added to a spare slot in the vertex array.

Page 42

To avoid cracks appearing in the terrain, we apply the rule that every facet must have a neighbour on either the same level of the tree, or one level above it. This rule means that during rendering, for each edge of a facet, if the facet doesnt have a neighbour on the same level of the tree on that side, then it simply skips drawing the edge vertex of that edge, and no cracks will occur. We enforce this rule through the use of forced splits. When a facet is split, for each of its edges, if it doesnt have a neighbour on the same level of the tree on that edge, then it forces its parents neighbour on that side to be split. To reflect the refinement of the mesh, the normals of the vertices at the corners of the new nodes are recalculated using the newly created vertices. To smoothly introduce new detail into the scene, we use geomorphs [Hoppe 1998]. When a new vertex is created, it is set in the vertex array as the interpolated vertex between its two adjacent parent vertices. Delta values from the interpolated vertex to the actual vertex, and its position in the vertex array, are appended to a list of geomorphs. Each frame, a fraction of the delta value is added to the interpolated vertex, which causes the vertex to be smoothly morphed into position without any popping effect. Once a geomorph is complete, it is removed from the geomorph list. 5.2.2 Merge operation

To remove detail from an area, facets one level up from the bottom of the tree may be added to a list of facets to be merged. This is done rather than merging immediately because new neighbour dependencies may occur at a later point during the evaluation step, so delaying the merge avoids facets being merged and then split again. After the evaluation step, all facets in the merge list are checked for neighbour dependencies, and if a facet is not required then its child facets are deleted, and any associated vertices that are unused are removed. The normals of the vertices at the corners of the deleted nodes are recalculated using the vertices of nodes one step up the tree. This is done so that the normals again reflect the wider topography of the area. As identified in [Hoppe 1998], performing an inverse geomorph is not trivial. The need for a geomorph is identified at the time that a split or merge is performed.

Page 43

After a split occurs, the data is in place to perform the geomorph, but after a merge this data is removed. Therefore, the merge must be delayed until the geomorph is complete, which causes the scene update process to be delayed for several frames. An alternative approach to geomorphing is described in [Rttger et al. 1998]. At each frame the refinement evaluation process generates a floating point decision variable to determine whether each leaf node in the quad tree should be refined. This value is used to set the vertices between their interpolated and actual values. Unfortunately, as our method skips the majority of the evaluation process, we cannot use this method of geomorphing. We have observed that in general vertex removals are not as noticeable as vertex insertions. Therefore, in the interests of keeping rendering speed as high as possible, we have not implemented inverse geomorphs. 5.2.3 Texturing

The size of texture data for large terrains is typically far greater than can be fit onto a typical graphics card. Additionally, we typically wish to overlay several textures on top of each other, each of which may be in a different projection. To solve this problem, we use the quadtree structure to segment the terrain into manageable sections. Each facet can potentially have its own texture. Facets that dont have their own texture inherit their texture from their parent facets. During the evaluation step, each facet whose parent facet has its own texture is evaluated to check if it and its descendants need to be textured at a higher resolution. A facet is evaluated according to its distance from the viewer, and the angle of its surface relative to the viewer, at its closest point to the viewer. If the resulting value is high enough, a new texture at double the resolution of the parent facets texture is generated. To generate a texture for a facet, the relevant sections of the source textures are loaded at an appropriate resolution2, and are rendered onto a newly created texture that precisely covers the facet.

In our implementation, the ECW image compression/decompression library [Earth Resource Mapping

2002] is used to load texture data at varying resolutions. Page 44

5.3 Mesh rendering

The tree is drawn by recursively moving down each of the subtrees in the quadtree until leaf facets are reached. The facet is drawn using a triangle fan, starting at the centre vertex, and proceeding around the corner and edge vertices. At the edges, if the facet has a neighbouring facet on the same level on that side, the edge vertex is drawn, otherwise the edge vertex is skipped, thereby avoiding cracks appearing in the terrain. The visibility of the facets is recursively evaluated during the drawing step, to avoid drawing facets that are outside the view frustum. A sphere enclosing the facet is tested against the view frustum, which is a simple and fast operation. If the sphere is entirely outside the frustum, the facet and its descendants are not drawn. It is possible that this will cause visible facets to not be drawn if one of the facets descendants contains an elevation that extends outside the sphere, but in practice this does not occur unless the terrain is vertically scaled by a large factor. If the sphere is entirely contained by the view frustum all the facets child facets are drawn without further testing visibility, thereby saving processor time. If the sphere intersects the view frustum, the visibility test is performed on the facets child facets. This visibility culling is performed in this step, and not during the evaluation step, as it was found that if the viewer were to turn suddenly, a very large area of terrain would become visible, and the cost of suddenly loading all the necessary data was not acceptable for real time performance. By keeping data stored for the entire area around the viewer, this problem was avoided. To texture facets, their textures are set as the current texture prior to their rendering. Neighbouring differently-textured sections of terrain share vertices at their edges, but their texture co-ordinates at those vertices will be different. To solve this, rather than storing separate texture co-ordinates, the vertex positions are taken as 3D texture co-ordinates. Using a different texture matrix for each texture, these coordinates are transformed to the correct texture co-ordinates. The texture matrices for facets in global scenes are constructed using the following formula3:
0 0 0 1
3

0 0 1 0 0 0 1 1 1 0 1 1

ax a y az 1

bx by bz 1

cx cy cz 1

0 0 0 1

Courtesy of contributors to the OpenGL.org discussion forums. Page 45

a, b and c are vectors at the lower-left, lower-right, and top-right corners of the facet respectively, rescaled so that they are on the surface of the rhombic triacontahedron.

5.4 Screenshots
In this section we present a series of screenshots taken from a virtual flight from approximately 10000 km above the Earths surface, down to the island of Hawaii. The screenshots are taken in both filled and wireframe rendering modes, demonstrating the final visual result as well as the underlying tesselation. They are shown in Figure 25. The elevation data used was a high resolution map of Hawaii at 30m grid spacing (compressed to 2m vertical accuracy), inset into a map of the entire world at 1km grid spacing (compressed to 50m vertical accuracy). For the texture data, a 30m grid spacing photomap of Hawaii was used, inset into a 75 arc-second (approximately 2.5km) grid spacing satellite image composite of the rest of the Earth. The frame rate while performing this flyover averaged approximately 25 frames per second, on a PC with a 1.5 GHz Pentium 4 processor, and a GeForce 2 video card, running Windows 2000. Approximately 20,000 triangles were rendered each frame, equating to overall performance of 500,000 triangles per second. While these figures are not particularly high, they are certainly acceptable for real-time rendering.

Page 46

Page 47

Figure 25: A series of screenshots, in both filled and wire-frame rendering modes, showing a flight from space to the island of Hawaii.

Page 48

6 Results & Analysis

This section presents the results of compressing several distinct terrain datasets. To avoid resampling the data (and thereby introducing ambiguity), all tests were performed on subsets of the data, of width 2n + 1.

6.1 Datasets
This section lists and describes the datasets used in the experiments. West Crater Lake, Oregon

Figure 26: A rendering of the West Crater Lake dataset. Heights are exaggerated for clarity.

This is a digital elevation map around the west half of Crater Lake, Oregon, shown in Figure 26. The grid spacing is 20 * 27m. The height data is stored in units of decimetres. The datasets wide use as test data makes it the teapot of terrain rendering [Discoe 2002]. It is a good dataset to use for general compression experiments, as its surface is well balanced between the highly compressible flat surface of the lake, and the less compressible rocky slopes. Central Park, New York City

Figure 27: A rendering of the Central Park dataset. Heights are exaggerated for clarity.

Page 49

This is a digital elevation map at 10 metre grid spacing, around the area of Central Park, New York. The height data is stored in units of decimetres. The surface of this is fairly smooth, but with many sharp inclines at river edges and manmade alterations to the topography. Mount Adams, Washington

Figure 28: A rendering of a subsection of the Mount Adams dataset. Heights are exaggerated for clarity.

This is a very large digital elevation map at 10 metre grid spacing of the area around Mount Adams, Washington State. The height data is stored in units of decimetres. The topography of this area is extremely uneven, which means that it is likely to be less compressible. Hailey East

Figure 29: The Hailey East dataset. Heights are exaggerated for clarity.

This is a 1-degree DEM in northwest USA covering the area between 43 and 44 latitude, and 115 and 114 longitude. Its grid spacing is 3 arc seconds, which is approximately 90 metres. The height data is stored in units of metres. The terrain is mostly very uneven, making it less compressible.

Page 50

Earth This is a dataset of the entire Earth, excluding bathymetry, at a grid spacing of 30 arc seconds, which is approximately 1km near the equator. The height data is stored in units of metres. The data source is the GLOBE dataset [GLOBE 2002].

6.2 Compression results

Here we present results showing how successfully the TQT compresses data under different conditions and on different datasets. 6.2.1 Optimal tile size

The first experiment was to find the optimal tile size to gain maximum compression. The compression was tested with varying tile sizes, and the maximum error set to a constant of 1 decimetre. The results are shown in Figure 30.
42 Compression (%) 40 38 36 34 32 30 28 2 4 8 16 32 64 128 256 Tile Width (Node s )

Figure 30: TQT compression rates at different tile widths. All tests were performed on the West Crater Lake dataset.

The advantage of using small tiles is that they can take advantage of local homogeneity. This homogeneity occurs in two ways: 1) Areas of low complexity can be represented by shallow subtrees. A small tile size will mean that the nodes at the bottom of the subtree are grouped in a leaf tile, whereas if a larger tile size were used, the subtree would be grouped with deeper subtrees. 2) Elevation offset values are all stored in 1 or 2 bytes, depending on the largest elevation value within the tile. Smaller tile sizes increase the probability that the largest elevation offset value will fit in a single byte.

Page 51

Another benefit of a small tile size is that indices to nodes can be stored in single bytes. The advantage of using a large tile size is that there is a smaller ratio of tile headers to nodes. Figure 30 shows that these advantages and disadvantages typically balance out to become optimal at a tile width of 16 nodes.

6.2.2

Compression compared with maximum error

The second experiment tests the effectiveness of the compression algorithm with a varying maximum vertical error value. This experiment was performed on three separate datasets. As Figure 31 shows, Crater Lake and Central Park were compressed extremely successfully. Surprisingly, Crater Lake compressed slightly better than Central Park, suggesting that the algorithm works better with lots of general unevenness, rather than a few sharp inclines. As predicted, Mount Adams compressed less well, but still gained a good compression ratio at moderate error levels.
80 70 60 Compression (%) 50 40 30 20 10 0 0 1 2 3 Error (m ) 4 5 6 7 Crater Lake Central Park Mount Adams

Figure 31: File sizes, expressed as a percentage of the original binary file size, compared with errors, expressed in metres.

Figure 32 illustrates the visual quality of compression to selected accuracies.

Page 52

0m 0.4m

1.6m 6.4m

12.8m 25.6m Figure 32: The Crater Lake dataset compressed to selected error tolerances.

6.2.3

Compression compared with data grid spacing

Here we find how well the TQT compresses data at different horizontal grid spacing. The experiments are performed on the Mount Adams dataset as its large size means that large as well as small grid spacings can be tested. All tests were performed over the same area, but with successively doubled horizontal grid spacing. The maximum vertical error is set to one tenth of the horizontal grid spacing.
90 80 Compression (%) 70 60 50 40 30 20 0 100 200 300 400 500 600 700 Horizontal Spacing (m e tre s ), Ve rtical Error (de cim e tre s )

Figure 33: Compression rates of the Mount Adams dataset at different horizontal grid spacings.

Page 53

Figure 33 shows that the TQT compresses high resolution datasets several times more effectively than the lower resolution equivalent. It is likely that this is because terrain has proportionately smoother continuity at high resolutions than at low resolutions. 6.2.4 Worst case analysis

The compression works by reducing storage costs for, or not storing, surfaces of sufficient continuity. Therefore, the worst case occurs when the dataset has no continuity at all. This case was tested using a 513*513 dataset filled with noise generated by the C rand() function. The TQT file size for this dataset was just 10.5% greater than the file size of the original regular grid. This result shows that the TQT method is very successful at reducing the quadtree structure overhead.

6.3 Comparisons with other compression methods

In this section we compare the TQT with other terrain compression methods. 6.3.1 Binary triangle tree The in memory method of [Gerstner 2001], described in section 2.4.1, is directly comparable with the TQT, as it is designed to store height data to within a certain accuracy in a form that can be rapidly extracted for rendering. We also compare the on disk method of [Gerstner 2001] with the TQT to compare compression rates. It should be noted that the TQT and the on disk method are not equivalent, as, unlike the TQT, the on disk method must be fully extracted prior to rendering. The dataset used is the Earth dataset described in section 6.1. As described in [Gerstner 2001], the data is resampled onto two 8193*8193 grids, one for positive and one for negative longitudes. The compression results given in [Gerstner 2001] are based on the GTOPO30 [USGS 2002] dataset, which is slightly different to the GLOBE dataset used here, in that some parts of the data are from different sources, but the overall difference is negligible. It should also be noted that [Gerstner 2001] stores the data so that the errors are less than the maximum error (errors in the TQT are less than or equal to the maximum error). This means that when the maximum error is set to 0 all the vertices are stored, even if they are exactly equal to their interpolated value, effectively giving

Page 54

a worst-case result. This causes the excessively large values at 0 maximum error. The results are shown in Figure 34.

240 210 180 File Size (Mb) 150 120 90 60 30 0 0 2 4 8 16 32 64 128 256 512 1024 M axim um Error (m e tre s ) On disk In memory TQT Uniform grid

Figure 34: TQT compression compared with that of the On disk and In memory methods of [Gerstner 2001]

At higher accuracy levels the TQT compresses the data more efficiently than the on disk method, and at high to medium accuracy levels it is several times more efficient than the in memory method. This is because the TQT stores the majority of nodes in one byte when the accuracy is high, significantly reducing the cost of the additional data stored. Additionally, high accuracy means that the quadtree will be mostly full. This means that most tiles in the TQT will be leaf tiles, enabling further storage savings. At lower accuracy levels, the methods described in [Gerstner 2001] are more efficient than the TQT. This is because the TQT relies on its tiles being mostly full to get maximal efficiency, which will not be the case if its nodes are sparsely populated. An additional weakness is that vertices are stored in threes. If terrain is stored with a low error threshold then this is appropriate, as if one vertex is required it is likely that the other two will also be required. However, with a higher error threshold, it becomes more likely that of the three vertices, only one or two will be required, so the cost of storing the unnecessary vertices induces a significant storage overhead.

Page 55

6.3.2

TIN

Unfortunately, despite the abundance of material describing the compression of TINs, we are unable to compare the compression of the TQT with TIN methods. This is because the compression results given in TIN compression papers refer to the pervertex and per-triangle bit rates, but not the compression relative to the original dataset. In some cases compression ratios are given, but due to the subjective nature of the quality of the compression, precise error measures are not given. Therefore an objective comparison of TQT and TIN methods cannot be performed. 6.3.3 Wavelet

Here we compare the results given in [Franklin & Said 1996] for the compression of the Hailey East dataset using a generic wavelet compression algorithm. The root mean square errors are given in [Franklin & Said 1996], rather than a maximum error, so these are compared instead. The compression ratio is calculated as the compressed bits per pixel divided by 16 (the number of bits per pixel for a regular grid).
60

50

Compression (%)

40 TQT Wavelet

30

20

10

0 0 2 4 6 8 10 12 14 16 Root M e an Square Error (m e tre s )

Figure 35: TQT and wavelet compression compared.

The results are given in Figure 35, and show that the wavelet based compression is several times more efficient than the TQT.

Page 56

6.4 Runtime Results

In this section we examine the performance of the TQT in terms of how quickly its data can be extracted. 6.4.1 Experimental environment The tests were run on a PC with a Pentium 4 1.5 GHz processor, 512 Mb main memory, and a Maxtor Fireball Plus AS IDE hard disk, running Windows 2000. The test program was configured with a cache size of 101 tiles. For the chosen flyovers, this number of tiles is sufficiently large that tiles will not be cached more than once, regardless of the tile size. This means that only the caching of new data is tested. 6.4.2 Test method Each flyover is performed automatically, either from a pre-recorded flight sequence, or along a path defined by a few simple parameters. There is no human input during flyovers. Results are automatically written to file each frame by the program. We perform each test three times for each tile size. From the results obtained, the median values are used, to minimise errors. The operating system performs its own caching of file data, which can greatly speed up loading. To avoid this and any other residual effects, the test computer is restarted prior to each test. 6.4.3 Tile size

We first test the effect of tile size on the number of cache misses and the speed of loading. To test this, we perform two flyovers. In the first test, the viewer orbits the earth at an altitude of 200km and 23.5 latitude (this latitude was chosen as, relative to other latitudes near the equator, it covers the most land), beginning and ending at 0 longitude. In the second test we descend from an altitude of 10,000km to 10km, at 45.5 latitude, 7.5 longitude (above the Alps). For these tests we use the GLOBE dataset, sampled at its original grid spacing of 30 arc seconds, reprojected to the rhombic triacontahedron projection. 6.4.3.1 Cache misses Here we test the number of cache misses. A cache miss occurs when a node is fetched from a tile that is not currently stored in the cache, causing data to be fetched from hard disk. The results of the number of cache misses are shown in Figure 36 and Figure 37.

Page 57

10000 8000 16 6000 4000 32 64 128 256 2000 0 0 100 200 Fram e s 300 400 500

Cumulative cache misses Cumulative cache misses

Figure 36: Cumulative cache misses for different tile widths, on the descend test.

50000

40000 16 30000 32 64 20000 128 256 10000

0 0 500 1000 1500 2000 Fram e s 2500 3000 3500 4000

Figure 37: Cumulative cache misses for different tile widths, on the orbit test.

In theory, if all the data loaded from the largest tile was required then the number of cache misses for each successively smaller tile size would quadruple. The results show that this is approximately accurate for smaller tile sizes, but only for the orbit test. In the descent test and at larger tile sizes the number of cache misses only approximately doubles. The tests show that larger tile sizes cause fewer cache misses, but also suggest that for large tile sizes, a large amount of data is loaded that is not actually used.

Page 58

6.4.3.2 Accumulated loading time Here we test the accumulated amount of time spent loading data from hard disk. Section 6.4.3.1 has shown that a smaller tile size causes more tiles to be cached, which increases the hard disk seek time. With larger tiles, fewer will be cached, but more data will be loaded that is not subsequently used, increasing the load time. These two factors will even out at a certain tile size to become optimal. Figure 38 and Figure 39 show that these two factors even out to become optimal at tile widths of 128 and 256 nodes.
3 Cumulative loading time (seconds) 2.5 2 1.5 1 0.5 0 0 100 200 Fram e s 300 400 500 16 32 64 128 256

Figure 38: Cumulative loading times for different tile widths, on the descend test.

14 12 10 8 6 4 2 0 0 500 1000 1500 2000 Fram e s 2500 3000 3500 4000

Cumulative loading time (seconds)

16 32 64 128 256

Figure 39: Cumulative loading times for different tile widths, on the orbit test.

Page 59

Compared to the large disparity between the number of tiles loaded for each tile size, the difference between the load times is relatively moderate. This suggests that the tile ordering scheme is fairly successful at reducing seek times. The results show that the descent flyover causes a relatively larger number of cache misses and a longer load time compared to the orbit flyover. This suggests that the TQT performs less well when rapidly loading from many different data layers.

Page 60

6.4.3.3 Per-frame loading times Here we examine the effect of tile size on the loading times per frame. Ideally the loading times will be short and evenly distributed across the frames, rather than infrequent and long. In theory, a larger tile size will cause a larger number of long load times as although fewer tiles are loaded, in the frames that they are loaded their larger size may cause them to take longer to load. Figure 40 and Figure 41 show that in general this is not the case, although a tile width of 256 does cause a relatively large number of load times of between 64ms and 128ms for the orbit flyover.
160 140 120 Frequency 100 80 60 40 20 0 (0, 1] (1, 2] (2, 4] (4, 8] (8, 16] (16, 32] (32, 64] (64, 128] >128 16 32 64 128 256

Loading tim e s (m illis e conds )

Figure 40: The number of individual loading times for different tile widths, on the descend test.

1400 1200 1000 Frequency 800 600 400 200 0 (0, 1] (1, 2] (2, 4] (4, 8] (8, 16] (16, 32] (32, 64] (64, 128] Loading tim e s (m illis e conds ) 16 32 64 128 256

Figure 41: The number of individual loading times for different tile widths, on the orbit test.

Page 61

6.4.4

Optimal tile size

The ideal tile size is dependent upon the purpose for which the data is being stored. If a small file size is the highest priority then, as Figure 30 demonstrates, a tile width of 16 nodes is optimal. Figure 38 and Figure 39 show that tile widths of either 128 or 256 are approximately equivalently suitable if speed during rendering is the highest priority. However, Figure 40 and Figure 41 show that a tile width of 256 causes a greater number of high individual load times, making a tile width of 128 preferable. In general, the highest rate of compression that gives a subjectively satisfactory rendering speed is desirable. It was found that during a typical user flyover a tile width of 64 was satisfactorily fast and largely avoided the stuttering effect experienced with smaller tile sizes. Figure 40 and Figure 41 back this up, showing no loading times greater than 128ms. Consequently, a tile width of 64 is recommended as a general-purpose tile size, although other values between 16 and 128 may prove preferable on other hardware. 6.4.5 Flyover test

We now test the performance for a typical user-controlled flyover of the world, examining detailed areas. We use as a dataset several data sources reprojected to the rhombic triacontahedron projection and compiled into a single TQT file. The data includes: The GLOBE dataset at 30 arc second (approximately 1km) grid intervals at 50m vertical error. Washington State at 10 metre grid intervals at 2m vertical error. Hawaii and surrounding islands at approximately 18 * 16 metre grid intervals at 2m vertical error. The source data is 4.54 Gb in size, which is compressed by approximately a factor of 8, to 573 Mb. A tile width of 64 nodes is used, as a compromise between the rate of compression and the cache performance. To obtain a route for the test, we record a user flying from outer space into and around Washington State at low altitude, then over the Pacific Ocean at high altitude into and around the Hawaiian Islands at low altitude. The flyover takes approximately 3.5 minutes.

Page 62

The slowest part of the visualisation system is seeking to and reading data from the hard disk, therefore it is important that the number of hard disk accesses is minimised. For each flyover, we record the number of tiles loaded and the time taken to load the tiles.
7000 6000 Cumulative cache misses 5000 4000 3000 2000 1000 0 0 1000 2000 3000 Fram e s 4000 5000

Figure 42: Accumulated cache misses for the flyover test.

14 Cumulative loading time (seconds) 12 10 8 6 4 2 0 0 1000 2000 3000 Fram e s 4000 5000

Figure 43: The cumulative loading time for the flyover test.

Page 63

2000 1500 Frequency 1000 500 0

1896

959 771 687 556 130 >0 >1 >2.5 >5 >10 >25 28 >50

Loading tim e s (m illis e conds )

Figure 44: The number of per-frame loading times greater than certain threshold values for the flyover test.

Figure 42 shows that the accumulated number of cache misses is approximately equal to the number of frames elapsed, so there is on average approximately 1 cache miss per frame. The accumulated loading time is shown in Figure 43. The loading time is approximately 1/15th of the total rendering time. It is important that the loading times are well distributed throughout the flyover to maintain a consistent frame rate, rather than having a few longer loading times. Figure 44 shows the number of loading times above certain values. The graph shows that when loading occurs, approximately half the loading times are less than a millisecond, although a significant loading times exceed a hundredth of a second, which is enough to significantly affect the frame rate. Few loading times exceed 1/20th of a second. As an estimate of the effectiveness of the cache, we compare the accumulated number of cache hits and cache misses for each flyover. We found that the number of cache hits was over 280 times higher than the number of cache misses, which demonstrates that the caching is very effective.

Page 64

7 Conclusion & Future Work

We have presented an efficient method for storing terrain data in a quadtree structure, and have enhanced this method by the use of tiling, which greatly reduces the quadtree overhead. We have shown that the TQT compresses elevation data very successfully, particularly at high accuracy and high levels of detail. Our experimental results have shown that the TQT can be progressively loaded during real-time rendering, with minimal impact on frame rate. We have shown that in terms of compression the TQT is comparable to other terrain storage schemes with similar capabilities, and at high levels of accuracy provides a significantly higher compression ratio.

7.1 Future Work

There remains plenty of room for further improvements to the TQT structure. At present, data is compressed to minimise the number of bytes. It is likely that the compression ratio could be significantly increased (at the cost of increasing the decompression time) by compressing to individual bits using entropy coding methods such as Huffman or arithmetic coding. It was shown in section 6.3.3 that a generic wavelet based compression scheme compresses elevation data several times more effectively than the TQT. It may be worth investigating whether a combination of the two could compress data more effectively than the TQT, while allowing the data to be efficiently progressively decompressed. The clustering methods presented in [Bao & Pajarola 2002] and described in section 2.3.3 greatly enhance the cache-friendliness of elevation data, but also increases its size. It may be worth investigating whether the TQT structure could be made to increase its cache-friendliness by using these clustering methods, while retaining its compactness and ability to compress data.

Page 65

8 References
[Asano et al. 1997] Tetsuo Asano, Desh Ranjan, Thomas Roos, Emo Welzl & Peter Widmayer, "Space filling curves and their use in the design of geometric data structures," Theoretical Computer Science, vol. 181, pages 3-15, 1997. [Bao & Pajarola 2002] Xiaohong Bao & Renato Pajarola, LOD-based Clustering Techniques for Optimizing Large-scale Terrain Storage and Visualisation, UCI-ICS Technical Report No. 02-16, Department of Information & Computer Science, University of California, Irvine, June 2002 [Blow 2000] Jonathan Blow, Terrain Rendering at High Levels of Detail, Proceedings of the Game Developers' Conference 2000, San Jose, California, USA, March 2000 [Browne 2000] Shaun Browne, Charismatic Research Report An evaluation of existing terrain elevation data formats with regard to inclusion in the Charismatic terrain editor, Charismatic project internal report, UEA, November 2000 [Childs 2002] J. Childs, Digital Terrain Modelling and Mapping, 2002, http://www.terrainmap.com [Chow 1997] Mike M. Chow, Optimized Geometry Compression for Real-time Rendering, IEEE Visualization '97, pages 346-354, November 1997 [Cignoni et al. 1997] P. Cignoni, E. Puppo & R. Scopigno, Representation And Visualization of Terrain Surfaces at Variable Resolution, The Visual Computer, 13(5), pages 199-217, 1997 [Cohen-Or et al. 1999] Daniel Cohen-Or, David Levin, Offir Remez, Progressive Compression of Arbitrary Triangular Meshes, IEEE Visualization 99, October 1999
Page 66

[Danovaro et al. 2001] Emanuele Danovaro, Leila De Floriani, Paola Magillo, Enrico Puppo, Compressing Multiresolution Triangle Meshes, Advances in Spatial and Temporal Databases, Lecture Notes in Computer Science, 2121, C.S. Jensen, M. Schneider, B. Seeger, V.J. Tsotras (Eds.), Springer, Berlin, 2001, pp. 345-364. [Deering 1995] M. Deering, Geometry Compression, Computer Graphics (Proc. SIGGRAPH), pages 13 20, August 1995. [De Floriani & Puppo 1995] Leila De Floriani & Enrico Puppo, Hierarchical Triangulation for Multiresolution Surface Description, ACM Transactions On Graphics, 14(4), pages 363-411, 1995 [De Floriani et al. 1996] Leila De Floriani, Paola Marzano & Enrico Puppo, Multiresolution Models for Topographic Surface Description, The Visual Computer, 12(7), pages 317-345, August 1996 [De Floriani et al. 2000] Leila De Floriani, Paola Magillo & Enrico Puppo, Compressing Triangulated Irregular Networks, Geoinformatica 4(1), pages 67-88, 2000 [Discoe 2002] Ben Discoe, The Virtual Terrain Project, http://www.vterrain.org [Duchaineau et al. 1997] Mark A. Duchaineau, Murray Wolinsky, David E. Sigeti, Mark C. Miller, Charles Aldrich, and Mark B. Mineev-Weinstein, ROAMing terrain: Real-time optimally adapting meshes in Roni Yagel and Hans Hagen, editors, IEEE Visualization 97, pages 81-88. IEEE Computer Society Press, November 1997 [Dutton 1996] Geoffrey Dutton, Encoding and handling geospatial data with hierarchical triangular meshes in M.J. Kraak & M. Molenaar, editors, Advances in GIS Research II, pages 505-518, July 1996

Page 67

[Earth

Resource

Mapping

2002]

Earth

Resource for

Mapping

Inc.,

ECW 2.46,

Compression/Decompression http://www.ermapper.com 2002

SDK

Windows

[Evans et al. 2001] William Evans, David Kirkpatrick, Gregg Townsend, Right Triangular Irregular Networks, Algorithmica: Special Issue on Algorithms for Geographical Information, 30(2), pages 264-286, 2001 [Franklin 1995] W. R. Franklin, Compressing elevation data, Fourth International Symposium on Large Spatial Databases - SSD '95, Portland, Maine, USA, 69 August 1995. [Franklin & Said 1996] WR Franklin & Amir Said, Lossy compression of elevation data In Seventh International Symposium on Spatial Data Handling, Delft, August 1996 [Gerstner 2001] Thomas Gerstner, Multiresolution Visualization and Compression of Global Topographic Data, GeoInformatica, to appear, 2001 [GLOBE 2002] The Global Land One-km Base Elevation (GLOBE) Project http://www.ngdc.noaa.gov/seg/topo/globe.shtml [Gore 1998] Al Gore, The Digital Earth: Understanding our planet in the 21st Century, Transcript of a speech given at the California Science Center, Los Angeles, California, on January 31, 1998 [Gotsman et al. 2002] Craig Gotsman, Stefan Gumhold & Leif Kobbelt, Simplification and Compression of 3D Meshes, Tutorials on Multiresolution in Geometric Modelling, Springer, 2002 [Gumhold & Klein 1998] Stefan Gumhold & Reinhard Klein, Compression of Discrete Multiresolution Models, WSI-98-1, Wilhelm-Schickard-Institut fr Informatik, University of Tbingen, Germany, 1998

Page 68

[Hoppe 1996] Hugues Hoppe, Progressive Meshes, Computer Graphics (SIGGRAPH 96 Proceedings), pages 99-108, 1996 [Hoppe 1997] Hugues Hoppe, View-dependent refinement of progressive meshes, Computer Graphics (SIGGRAPH 97 Proceedings), pages 189-198, 1997 [Hoppe 1998] Hugues Hoppe, Smooth View-Dependent Level-of-Detail Control and its Application to Terrain Rendering, Proc. IEEE Visualisation 98, pages 35-42, 1998 [IEEE 1995] Institute of Electrical and Electronics Engineers, Inc., An Introduction to Wavelets, IEEE Computational Science and Engineering, Summer 1995, vol. 2, num. 2, 1995 [Kim et al. 1999a] Sung-Soo Kim, Yang-Soo Kim, Mi-Gyung Cho, Hwan-Gue Cho, A Geometric Compression Algorithm For Massive Terrain Data Using Delaunay Triangulation, Proceedings of WSCG '99, pages 124-131, February 1999 [Kim et al. 1999b] Yang-Soo Kim, Dong-Gyu Park, Ho-youl Jung, Hwan-Gue Cho, An Improved TIN Compression Using Delaunay Triangulation, Proc. Pacific Graphics 99, Seoul, Korea, pages 118-125, October 1999 [Klein & Gumhold 1998] Reinhard Klein, Stefan Gumhold, Data compression of multiresolution surfaces, Visualization in Scientific Computing '98, Springer, 1998 [Kronrod & Gotsman 2000] Boris Kronrod & Craig Gotsman, Optimized Triangle Mesh Compression Using Prediction Trees, Proc. 8th Pacific Graphics Conference, 2000 [Lindstrom et al. 1996] Peter Lindstrom, David Koller, William Ribarsky, Larry F. Hodges, Nick Faust & Gregory A. Turner, Real-Time, Continuous Level of

Page 69

Detail Rendering of Height Fields, Computer Graphics (SIGGRAPH '96 Proceedings), pages 109-118, Aug. 1996 [Lindstrom et al. 1997] P. Lindstrom, D. Koller, W. Ribarsky, L. Hodges, & N. Faust, An integrated global GIS and visual simulation system, GVU Technical Report 97-0, Georgia Tech Research Institute, 1997 [Lindstrom & Pascucci 2001] P. Lindstrom & V. Pascucci, Visualization of large terrains made easy, Proc. IEEE Visualization 2001, pages 363370. Computer Society Press, 2001 [Lindstrom & Pascucci 2002] P. Lindstrom & V. Pascucci, Terrain Simplification Simplified: A General Framework for View-Dependent Out-of-Core Visualization, IEEE Transactions on Visualization and Computer Graphics, 8 May 2002 [Maxtor 2001] Maxtor Corporation, Fireball Plus AS (ATA/IDE) specifications [Owen 1998] Steven J. Owen, "A Survey of Unstructured Mesh Generation Technology", Proc. 7th International Meshing Roundtable, Dearborn, MI, October 1998 [Pajarola 1998] Renato Pajarola, Large Scale Terrain Visualisation Using The Restricted Quadtree Triangulation, Proc. IEEE Visualization '98, pages 1926 & 515, 1998 [Pajarola 2002] Renato Pajarola, Overview of Quadtree-based Terrain Triangulation and Visualization, Technical Report UCI-ICS-02-01, Information & Computer Science, University of California Irvine, 2002 [Pajarola & Rossignac 2000] Renato Pajarola & Jarek Rossignac, Compressed Progressive Meshes, IEEE Transactions on Visualisation and Computer Graphics, Vol. 6, No. 1, 2000

Page 70

[Pajarola et al. 2002] Renato Pajarola, Marc Antonijuan, Roberto Lario, QuadTIN: Quadtree based Triangulated Irregular Networks, Proc. IEEE Visualization, 2002 [Reddy & Iverson 2000] Martin Reddy & Lee Iverson, GeoVRML 1.0 Recommended Practice, 19 May 2000, http://www.geovrml.org/1.0/ [Rttger et al. 1998] Stefan Rttger, Wolfgang Heidrich, Philipp Slusallek & HansPeter Seidel, Real-Time Generation of Continuous Levels of Detail for Height Fields, Proc. 6th Int. Conf. in Central Europe on Computer Graphics and Visualization, pp. 315-322, 1998 [Samet 1984] Hanan Samet, The Quadtree and Related Hierarchical Data Structures, ACM Computing Surveys 16(2), pp. 187260, June 1984 [Samet 1995] Hanan Samet, Spatial data structures, in W. Kim, Ed., Modern Database Systems: The Object Model, Interoperability, and Beyond, pages 361-385, Addison-Wesley/ACM Press, 1995 [Sedgewick 1998] Robert Sedgewick, Algorithms in C 3rd Edition, Addison Wesley, 1998 [SGI 2003] Silicon Graphics Inc., OpenGL Extension Registry,

http://oss.sgi.com/projects/ogl-sample/registry/ [Taubin & Rossignac 1998] Gabriel Taubin & Jarek Rossignac, Geometric Compression through Topological Surgery, ACM Transactions on Graphics 17(2), pages 84-115, 1998 [Touma & Gotsman 1998] Costa Touma & Craig Gotsman, Triangle Mesh Compression, Proc. Graphics Interface, pages 26-34, 1998 [Townsend 2002] Gregg Townsend, SDTS2DEM: a Translator for SDTS DEM Files, http://www.cs.arizona.edu/topovista/sdts2dem/
Page 71

[Ulrich 2000] Thatcher Ulrich, Continuous LOD Terrain Meshing Using Adaptive Quadtrees, February 2000 [USGS 1998a] U.S. Geological Survey, The Spatial Data Transfer Standard Guide for Technical Managers, ftp://sdts.er.usgs.gov/pub/sdts/articles/pdf/mgrs.pdf, 1998 [USGS 1998b] U.S. Geological Survey, Standards for Digital Elevation Models, http://rockyweb.cr.usgs.gov/nmpstds/acrodocs/dem/2DEM0198.PDF, 1998 [USGS 2002] U.S. Geological Survey, GTOPO30, http://www.gamasutra.com/features/20000228/ulrich_01.htm,

http://edcdaac.usgs.gov/gtopo30/ [Warmerdam 2002] Frank Warmerdam, Arc/Info Binary Grid Format,

http://gdal.velocet.ca/projects/aigrid/aigrid_format.html [Weisstein 2002a] Eric Weisstein, Eric Weissteins World of Astronomy, http://scienceworld.wolfram.com/astronomy/ [Weisstein 2002b] Eric Weisstein, Polyhedra Interactive

http://polyhedra.wolfram.com [Williams 1983] Lance Williams, "Pyramidal parametrics", Computer Graphics (SIGGRAPH83 Proceedings), 17(3): 1-11, July 1983. [Wynn et al. 1997] William C. Wynn, J. Fritz Barnes, Bernd Hamann & Mark Miller, Multiresolution and Adaptive Rendering Techniques for Structured, Curvilinear Data, Scientific Visualization Methods and Applications, Dagstuhl, Germany, June 1997

Page 72

Appendix - Definition of File Format

A Tiled Quad Tree (TQT) file is composed of Roots, Tiles, Nodes, EdgeNodes and Vertices, related as shown in the following Entity Relationship Diagram:

File Header
m

Root
3

TQT File
2 [0,2] 1 m

Tile
[0,4] m 1 [0,4] 3

EdgeNode

Node

Vertex

In this section, each of these components is defined, from the bottom of the diagram upwards. No components contain any padding bytes, unless explicitly stated. Leastsignificant-byte-first (Intel) byte ordering is used.

Vertex
A vertex contains a single signed short integer. This value is the vertical displacement from the interpolated height to the actual terrain height.

Node
The structure of the Node is as follows: 3 Vertices 1 unsigned byte Error. This is the square root of the maximum distance between the surface formed by interpolating between the vertices of the Node, and the actual surface of the terrain represented by the Node and its children. 1 unsigned short integer Index of first child node within its Tile.

Page 73

In addition to these parameters there are 4 bits indicating the existence of each child Node. The bits are stored in a byte shared between two Nodes. If the index of the Node is even, the byte will be positioned at the back of the structure, and bits 0 3 will be used. If the index of the Node is odd, the byte will be positioned at the front of the structure, and bits 4 7 will be used. The child Nodes are spatially ordered bottom left first, anticlockwise: 3 0 2 1

This is the ordering used throughout the format. The reason for this ordering is to remain consistent with the default ordering for drawing primitives in OpenGL.

EdgeNode
When the tree structure is built, all vertices except those on the right and top edges are represented, with no overlap. To represent vertices on the edges, a separate structure of EdgeNodes is used: EdgeNode: 1 Vertex 1 unsigned short integer index of first child In addition to these parameters there are 2 bits indicating the existence of each child EdgeNode. The bits are stored in a byte shared between two EdgeNodes. If the index of the EdgeNode is even, the byte will be positioned at the back of the structure, and bits 0 3 will be used. If the index of the EdgeNode is odd, the byte will be positioned at the front of the structure, and bits 4 7 will be used. If the EdgeNode is positioned at the top edge of the tree, the presence of its left child is indicated by either bit 0 or bit 4, and its right indicated by either bit 1 or bit 5. If the EdgeNode is positioned at the right edge of the tree, the presence of its bottom child is indicated by either bit 0 or bit 4, and its right indicated by either bit 3 or bit 7.

Page 74

Unused bits must be set to zero. This arrangement is designed to be consistent with the design of the main Node structure.

Tile
The file is built from Tiles. Each Tile can contain either Nodes or EdgeNodes. It has up to 4 child Tiles. A Tile is divided into 4 quartiles. All the Nodes in one quartile will have their child Nodes in the same Tile, which means that the address of this Tile can be stored once for each quartile. Quartiles are ordered bottom left first, anticlockwise. The format for a Tile is as follows: The header section: 1 byte flags: o bit 0 indicates whether Nodes or EdgeNodes are stored: 0 Nodes 1 EdgeNodes

o bit 1 indicates whether Right or Top EdgeNodes are stored (must be 0 if Nodes are stored): 0 Right EdgeNodes 1 Top EdgeNodes

o bits 2 - 4 store the number of child Tiles (a number between 0 and 4). If this value is 0 the tiles Node or EdgeNode content will be compressed to only contain their Vertex data. o Bit 5 indicates whether the length parameter and quartile indicators use 1 or 2 byte unsigned integers: 0 1 byte 1 2 byte

o Bit 6 indicates the size of the vertex parameters of the Nodes or EdgeNodes: 0 1 byte 1 2 byte

o Bit 7 indicates the size of the child index parameters of the Nodes or EdgeNodes:
Page 75

 Tiles.

0 1 byte 1 2 byte

(child count) unsigned long integers the addresses of each of the child 1 (size defined in flags) byte unsigned integer the number of Nodes in the Tile. (child count - 1) (size defined in flags) byte unsigned integers the indices of the first Node of each quartile, except for the first existing quartile, which will always start at index 0.

The header section varies in size between 2 and 25 bytes. The data section: Up to 65536 (256 * 256) optimised Nodes or EdgeNodes.

Root
4 Vertices these are the absolute height values at the corners of the quad. These are ordered bottom left first, anticlockwise. 1 Node, with its child indicator byte positioned at the back end of the Node. 1 unsigned long integer address within file of Tile containing the nodes children. 1 EdgeNode the right edge. 1 unsigned long integer address within file of Tile containing the right EdgeNodes children. 1 EdgeNode the top edge. 1 unsigned long integer address within file of Tile containing the top EdgeNodes children.

Page 76

File Header
The terrain file contains a header, formatted as follows: Name Info Length Info Vertex Type Type Integer String Integer Length (bytes) 4 Info Length 4 Description Length in bytes of file information Miscellaneous textual information about file Indicates the type of data contained in each vertex. At present only one value is defined: 0 vertices store elevation offset values, in Root Count Roots Integer Root 4 metres. Number of roots.

Root Count * The roots from which to start building the

sizeof(Root) world model. The Tile data immediately follows this header.

Page 77