Michael Platings

The Tiled Quad TreeA 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 author’s 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 world’s 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 [Röttger 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 Survey’s 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 data—not 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 GridThis commonly used method stores height values at regularly spaced points in a two-

dimensional array, as shown in Figure 1. Horizontal co-ordinates are stored implicitly

by a value’s location within the array.

Figure 1: Vertices in a regular grid terrain model.

This method’s simplicity has meant that it has been adopted for all the major

formats currently in use.

2.2 Multiresolution PyramidThis 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 hard-

disk 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 n2 , the

number of samples in the base level is n22 . If the data is subsampled until a 1*1

sample level is reached, there will be 1+n 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 n2 will be equal to

∑=

−n

i

in

0

2 42

The summation evaluates to 31

2561

641

161

41 11 ≈+++++ , which means that the

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 QuadtreeThe quad tree is a data structure that is used for the recursive decomposition of two-

dimensional 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-of-

two 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

node’s 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

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 tile-

based 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

Slop zones

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 scheme’s 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

node’s 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 TreeThe 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 Gerstner’s 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 NetworkThe 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 naïve 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 Deering’s 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 WaveletIn 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 &

Pearlman’s 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 methodsRegular grid

Advantages Disadvantages1. Its simplicity makes it very easy to

understand.

2. It is by far the most widely used

method of digital terrain storage.

1. It provides no compression, hence it

is unsuitable for large datasets.

2. If a dataset is too large to fit into

memory, then accessing sparse data

elements (as required by most Level-

Of-Detail algorithms) will be very

slow due to the slow speed of

permanent storage devices.

Pyramid and Pointerless Quadtree

Advantages Disadvantages1. Allows data to be loaded at varying

resolutions.

2. Can be easily integrated with

1. Provides no compression.

2. Data redundancy increases storage

requirements by approximately a

Page 25

quadtree and binary tree based terrain

visualisation algorithms.

third.

Pointer Based Quadtree

Advantages Disadvantages1. Can compress data by using few

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.

1. Storage overhead for tree structure.

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.

Binary Tree

Advantages Disadvantages1. Can compress data by using few

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.

1. Storage overhead for tree structure.

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.

TIN

Advantages Disadvantages1. Compresses flat areas by using few

triangles.

2. Data can be progressively loaded to

match the resolution required.

3. No resolution constraints whatsoever.

1. Vertices must be stored explicitly in 3

dimensions, giving a very high

storage overhead.

2. Triangulation process can be

computationally expensive.

Page 26

4. Corresponds directly to TIN Level-of-

Detail algorithm.

3. Triangulation can give ‘sliver’

triangles which look ugly when

rendered.

Wavelet

Advantages Disadvantages1. Likely to give extremely high

compression ratio.

2. Can be partially decompressed as

required.

1. Difficult to implement.

2. Compression and decompression

processes very computationally

expensive.

3.2 Comparative AnalysisFor 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 structure’s 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 computer’s 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 structureThe 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 [Röttger et al. 1998].

A naïve 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

viewer’s 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 naïve 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 co-

ordinates at each of the corner vertices, it is trivial to calculate the x and y co-

ordinates 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 compressionTo 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 ) >> 1A 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 non-

integer 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 1-

dimensional 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 reductionThe 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

node’s 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 node’s 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 node’s 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 node’s 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 orderingAn 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 tile’s 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.

12 9

3 6 10 134 5 7 8 11 12 14 15

Figure 20: The subtree grouping method.

12 3

4 5 6 78 9 10 11 12 13 14 15

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 DataOur 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 two-

dimensional 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 [Röttger 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 viewer’s 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 vertex’s 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 ConstructionThe 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 other’s 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 facet’s

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 facet’s 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 doesn’t 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 doesn’t have a neighbour on the same level of the tree on that

edge, then it forces its parent’s 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 [Röttger 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 don’t

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 facet’s 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.

2 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 renderingThe 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 facet’s 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 facet’s 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 facet’s 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 co-

ordinates are transformed to the correct texture co-ordinates. The texture matrices for

facets in global scenes are constructed using the following formula3:1

1111000

01111000

01000110 −

•

− zzz

yyy

xxx

cbacbacba

3 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 ScreenshotsIn this section we present a series of screenshots taken from a virtual flight from

approximately 10000 km above the Earth’s 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 DatasetsThis 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 dataset’s 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 resultsHere 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.

2830323436384042

2 4 8 16 32 64 128 256

Tile Width (Nodes)

Com

pres

sion

(%)

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.

0

10

20

30

40

50

60

70

80

0 1 2 3 4 5 6 7

Error (m )

Com

pres

sion

(%)

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

1.6m

12.8m

0.4m

6.4m

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.

20

30

40

50

60

70

80

90

0 100 200 300 400 500 600 700

Horizontal Spacing (m etres), Vertical Error (decim etres)

Com

pres

sion

(%)

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 methodsIn 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.

0

30

60

90

120

150

180

210

240

0 2 4 8 16 32 64 128 256 512 1024

Maxim um Error (m etres)

File

Siz

e (M

b) 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 per-

vertex 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).

0

10

20

30

40

50

60

0 2 4 6 8 10 12 14 16

Root Mean Square Error (m etres)

Com

pres

sion

(%)

TQT

Wavelet

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 ResultsIn 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

0

2000

4000

6000

8000

10000

0 100 200 300 400 500

Fram es

Cum

ulat

ive

cach

e m

isse

s16

32

64

128

256

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

0

10000

20000

30000

40000

50000

0 500 1000 1500 2000 2500 3000 3500 4000

Fram es

Cum

ulat

ive

cach

e m

isse

s

16

32

64

128

256

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.

0

0.5

1

1.5

2

2.5

3

0 100 200 300 400 500

Fram es

Cum

ulat

ive

load

ing

time

(sec

onds

)

16

32

64

128

256

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

0

2

4

6

8

10

12

14

0 500 1000 1500 2000 2500 3000 3500 4000

Fram es

Cum

ulat

ive

load

ing

time

(sec

onds

)

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.

0

20

40

60

80

100

120

140

160

(0, 1] (1, 2] (2, 4] (4, 8] (8, 16] (16, 32] (32, 64] (64,128]

>128

Loading tim es (m illiseconds)

Freq

uenc

y

16

32

64

128

256

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

0

200

400

600

800

1000

1200

1400

(0, 1] (1, 2] (2, 4] (4, 8] (8, 16] (16, 32] (32, 64] (64, 128]

Loading tim es (m illiseconds)

Freq

uenc

y

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.

0

1000

2000

3000

4000

5000

6000

7000

0 1000 2000 3000 4000 5000

Fram es

Cum

ulat

ive

cach

e m

isse

s

Figure 42: Accumulated cache misses for the flyover test.

0

2

4

6

8

10

12

14

0 1000 2000 3000 4000 5000

Fram es

Cum

ulat

ive

load

ing

time

(sec

onds

)

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

Page 63

1896

959771 687

556

130 280

500

1000

1500

2000

>0 >1 >2.5 >5 >10 >25 >50

Loading tim es (m illiseconds)

Freq

uenc

y

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 WorkThere 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 Mapping Inc., “ECW

Compression/Decompression SDK for Windows 2.46”,

http://www.ermapper.com 2002

[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, 6-

9 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 für

Informatik, University of Tübingen, 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 363–370.

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 19-

26 & 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/

[Röttger et al. 1998] Stefan Röttger, Wolfgang Heidrich, Philipp Slusallek & Hans-

Peter 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. 187–260, 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”, http://www.gamasutra.com/features/20000228/ulrich_01.htm,

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://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 Weisstein’s 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

(SIGGRAPH’83 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:

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. Least-

significant-byte-first (Intel) byte ordering is used.

VertexA vertex contains a single signed short integer. This value is the vertical displacement

from the interpolated height to the actual terrain height.

NodeThe 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

TQT File3

3

[0,4]

[0,4]

[0,2]

2 m

m

m 1

1

File Header

Root

Tile

Node

Vertex

EdgeNode

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:

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.

EdgeNodeWhen 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

0 1

23

Unused bits must be set to zero.

This arrangement is designed to be consistent with the design of the main Node

structure.

TileThe 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 tile’s 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

0 – 1 byte

1 – 2 byte

• (child count) unsigned long integers – the addresses of each of the child

Tiles.

• 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.

Root4 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 node’s children.

1 EdgeNode – the right edge.

1 unsigned long integer – address within file of Tile containing the right EdgeNode’s

children.

1 EdgeNode – the top edge.

1 unsigned long integer – address within file of Tile containing the top EdgeNode’s

children.

Page 76

File HeaderThe terrain file contains a header, formatted as follows:

Name Type Length

(bytes)

Description

Info

Length

Integer 4 Length in bytes of file information

Info String Info Length Miscellaneous textual information about fileVertex

Type

Integer 4 Indicates the type of data contained in each

vertex. At present only one value is defined:

0 – vertices store elevation offset values, in

metres.Root

Count

Integer 4 Number of roots.

Roots Root Root Count *

sizeof(Root)

The roots from which to start building the

world model.The Tile data immediately follows this header.

Page 77