May 8, 2006 - navigasi bentuk muka bumi secara masa nyata memang tidak dapat ...... Given ai is a length of radii, Ai is a unit vector of radii, L is a unit vector ...
AN EFFICIENT REAL-TIME TERRAIN DATA ORGANIZATION AND VISUALIZATION ALGORITHM BASED ON ENHANCED TRIANGLE-BASED LEVEL OF DETAIL TECHNIQUE
MUHAMAD NAJIB BIN ZAMRI
A thesis submitted in fulfilment of the requirements for the award of the degree of Master of Science (Computer Science)
Faculty of Computer Science and Information System Universiti Teknologi Malaysia
MAY 2006
8 MEI 2006
8 MEI 2006
8 MAY 2006
8 MAY 2006
BAHAGIAN A – Pengesahan Kerjasama* Adalah disahkan bahawa projek penyelidikan tesis ini telah dilaksanakan melalui kerjasama antara
dengan
Disahkan oleh: Tandatangan : Nama
:
Jawatan
:
Tarikh :
(Cop rasmi)
* Jika penyediaan tesis/projek melibatkan kerjasama
BAHAGIAN B – Untuk Kegunaan Pejabat Sekolah Pengajian Siswazah Tesis ini telah diperiksa dan diakui oleh: Nama dan Alamat Pemeriksa Luar
: Prof. Madya Dr. Wang Yin Chai Faculty of Computer Science & Information Technology Universiti Malaysia Sarawak 94300 Kota Samarahan Sarawak
Nama dan Alamat Pemeriksa Dalam
: Prof. Madya Dr. Mohd Noor Bin Md Sap Fakulti Sains Komputer & Sistem Maklumat UTM Skudai
Nama Penyelia Lain
: Noor Azam Bin Md. Sheriff
(jika ada)
Disahkan oleh Penolong Pendaftar di Sekolah Pengajian Siswazah:
Tandatangan
:
Nama
: GANESAN A/L ANDIMUTHU
Tarikh
:
8 MAY 2006
iii
To my beloved father and mother, Zamri Ismail and Rashidah Shariff; my brothers, Azainizam, Shahirman and Hanafi; my sisters, Anira, Aziha and Aizan; and my friends
iv
ACKNOWLEDGEMENT
First of all, thanks to Allah SWT, the Creator, for giving me the strength to complete this thesis. I would like to express my appreciation to the Ministry of Science, Technology and Innovation (MOSTI) for providing me the financial support to further my education to this level under National Science Fellowship (NSF) program. Obviously, without their help, this journey would not have allowed.
I would like to express my sincere gratitude to my main supervisor, Associate Professor Safie Mat Yatim and my co-supervisor, Mr. Noor Azam Md. Sheriff, for their guidance and support through my studies as well as their constructive criticism of my research. This thesis would not have been possible without them. I would like to thank lecturers that involved and gave their brilliant ideas and solutions for this research especially Associate Professor Sarudin Kari, Associate Professor Daut Daman, Mr. Nik Isrozaidi Nik Ismail and Mr. Mohd Shafry Mohd Rahim.
Furthermore, I would also like to acknowledge my fellow postgraduate students, colleagues and housemates who have made my lives so enjoyable. They are Irwandi Hipni, Yusrin, Hamimah, Mun San, Weng, Baldave, Sandilian, Kim Heok, Adlur, Fendi, Amri, Mohd Hafiz, Asyraf and Asrulakmar. Special thanks go to foreign researchers that help me in explaining the related technical processes and developing the prototype system. They are Stefan Röttger, Mark Duchaineau, Peter Lindstrom, Chris Cookson, ZhaoYoubing, Thatcher Ulrich and Ulf Assarsson.
Finally, I am grateful to my parents and my family for their support and patience during my stay at the Universiti Teknologi Malaysia.
v
ABSTRACT
The massive volume of data involved in the development of a real-time terrain visualization and navigation system is inevitable. Based upon the current offthe-shelf hardware capability, it is impossible to process the amount of data using the conventional approach. This is due to the fact that the amount of data to be processed exceeds the capacity that can be loaded into main memory. This problem is further compounded by other hardware constraints such as memory bus speed and data transfer bandwidth from the main memory to the graphics card. Consequently, this limitation has affected the total system performance. The triangle-based level of detail (LOD) technique has been developed in order to reduce the drawback but it still suffers from the main memory constraint and slow data loading. The purpose of this research is to design, develop and implement an algorithm for enhancing the rendering efficiency of triangle-based LOD technique. A prototype system has been developed using digital elevation data for testing purposes. The system was evaluated based on the following criteria, namely: data size, processing time for data partitioning, memory usage, loading time, frame rate, triangle count and geometric throughput. According to the results obtained during the pre-processing, the partitioning of digital elevation data into tiles has successfully reduced the data size although it required a longer processing time. During the run-time processing, the integration of dynamic tile loading scheme, view frustum culling and enhanced triangle-based LOD technique has produced encouraging results with significant overall improvement as compared to the techniques that have been developed earlier. The proposed algorithm in this thesis is very practical in developing interactive graphics applications, which consider real-time rendering as one of the important elements.
vi
ABSTRAK
Data bersaiz besar yang terlibat di dalam pembangunan sistem visualisasi dan navigasi bentuk muka bumi secara masa nyata memang tidak dapat dielakkan. Berdasarkan kepada keupayaan perkakasan terkini yang berada di pasaran, adalah mustahil untuk memproses data tersebut menggunakan pendekatan biasa. Ini disebabkan oleh amaun data yang diproses melebihi kapasiti yang boleh dimuatkan ke dalam ingatan utama. Masalah ini ditambah pula dengan kekangan-kekangan perkakasan lain seperti kelajuan ingatan bas dan lebar jalur penghantaran data dari ingatan utama ke kad grafik. Kesannya, limitasi ini telah mempengaruhi keseluruhan prestasi sistem. Teknik aras keperincian berasaskan segi tiga telah dibangunkan dalam usaha untuk mengurangkan kelemahan tetapi masih perlu berhadapan dengan kekangan ruang ingatan utama dan pemuatan data yang perlahan. Tujuan penyelidikan ini adalah untuk mereka bentuk, membangun dan mengimplementasi sebuah algoritma bagi meningkatkan keberkesanan perenderan teknik aras keperincian berasaskan segi tiga. Satu sistem prototaip telah dibangun dengan menggunakan data ketinggian digital untuk tujuan pengujian. Sistem ini telah dinilai berdasarkan kepada kriteria-kriteria berikut: saiz data, masa pemprosesan bagi pemecahan data, penggunaan ruang ingatan, masa pemuatan, kadar kerangka, serta bilangan dan kadar penjanaan segi tiga. Berdasarkan kepada keputusan yang diperolehi semasa pra-pemprosesan, pemecahan data ketinggian digital kepada blokblok data kecil telah berjaya mengurangkan saiz data walaupun proses ini memerlukan masa pemprosesan yang lebih panjang. Semasa pemprosesan masa larian, gabungan skema pemuatan blok-blok data kecil yang dinamik, teknik penghapusan data berasaskan sudut pandangan dan teknik aras keperincian berasaskan segi tiga yang dipertingkatkan telah menghasilkan keputusan yang memberangsangkan dengan peningkatan keseluruhan yang signifikan jika dibandingkan dengan teknik-teknik yang telah dibangunkan sebelum ini. Algoritma yang dicadangkan di dalam tesis ini adalah sangat praktikal di dalam membangunkan aplikasi-aplikasi grafik yang bersifat interaktif di mana mempertimbangkan perenderan masa nyata sebagai salah satu daripada elemen penting.
vii
TABLE OF CONTENTS
CHAPTER
TITLE
TITLE PAGE
PAGE
i
DECLARATION OF ORIGINALITY AND
1
EXCLUSIVENESS
ii
DEDICATION
iii
ACKNOWLEDGEMENT
iv
ABSTRACT
v
ABSTRAK
vi
TABLE OF CONTENTS
vii
LIST OF TABLES
xii
LIST OF FIGURES
xiii
LIST OF ALGORITHMS
xvi
LIST OF ABBREVIATIONS
xviii
LIST OF APPENDICES
xx
INTRODUCTION
1
1.1 Introduction
1
1.2 Problem Background
5
1.2.1 Massive Terrain Dataset
5
1.2.2 Geometric Complexity
6
1.2.3 Limited Capability of Triangle-Based LOD Techniques
8
1.3 Problem Statements
8
1.4 Goal
8
viii
2
1.5 Objectives
9
1.6 Scopes
9
1.7 Organization of the Thesis
10
LITERATURE REVIEW
11
2.1 Introduction
11
2.2 Spatial Data Structures
12
2.3
2.2.1
Kd-Tree
13
2.2.2
Quadtree
15
2.2.3
R-Tree
16
2.2.4
Tiled Block
18
2.2.5
Comparative Studies
19
Visibility Culling Methods
20
2.3.1 Types of Culling Methods
21
2.3.1.1
Backface Culling
21
2.3.1.2
Small Feature Culling
22
2.3.1.3
Occlusion Culling
23
2.3.1.4
View Frustum Culling
24
2.3.1.5
Comparative Studies
25
2.3.2 Intersection Test Techniques
26
2.3.2.1
Axis Aligned Bounding Box
27
2.3.2.2
Oriented Bounding Box
27
2.3.2.3
Bounding Sphere
29
2.3.2.4
k-Discrete Orientation Polytope
30
2.3.2.5
Comparative studies
31
2.4 View-Dependent LOD Techniques
32
2.4.1 Terrain Representation
32
2.4.1.1
Regular Grid
32
2.4.1.2
Triangulated Irregular Network
33
2.4.1.3
Advantages and Disadvantages
34
ix 2.4.2 Geometric Primitives 2.4.2.1
Independent Triangles
35
2.4.2.2
Triangle Fans
36
2.4.2.3
Triangle Strips
36
2.4.2.4
Comparative Studies
37
2.4.3 Previous Works 2.4.3.1
2.4.3.2
38
Real-time Generation of Continuous LOD for Height Fields
2.4.3.3
37
Real-time Optimally Adapting Meshes
3
35
43
View-Dependent Progressive Meshes
45
2.4.3.4
Out-of-Core Terrain Visualization
48
2.4.3.5
Comparative Studies
52
2.5 Summary
53
METHODOLOGY
55
3.1 Introduction
55
3.2 Partitioning Terrain Data
58
3.2.1 Extracting Data
58
3.2.2
59
Splitting Data into Tiles
3.3 Loading Terrain Tiles
63
3.4 Culling Invisible Terrain Tiles
64
3.4.1 Plane Extraction
64
3.4.2 Intersection Test
67
3.5 Simplifying Geometry of Visible Terrain Tiles
68
3.5.1
Distance Calculation
69
3.5.2
Subdivision Test
69
3.5.3
Generation of Triangle Fans
70
3.6 Summary
71
x 4
IMPLEMENTATION
72
4.1 Introduction
72
4.2 Pre-Processing
73
4.2.1
Reading a DEM File and Creating TXT Files
4.2.2
73
Reading TXT Files and Creating TILE Files
79
4.3 Run-time Processing 4.3.1
Creation of Classes
87
4.3.2
Initialization
89
4.3.3
Rendering
89
4.3.3.1
Configuring Information for Camera
4.3.3.2
5
87
90
Loading and Unloading Terrain Tiles
90
4.3.3.3
Calculating Frustum’s Planes
92
4.3.3.4
Removing Unseen Terrain Tiles
93
4.3.3.5
Generating Quadtree Traversal
94
4.3.3.6
Generating Triangle Fans
94
4.3.4
Interaction
96
4.3.5
Shutdown
96
4.4 Summary
97
RESULTS, ANALYSIS AND DISCUSSIONS
98
5.1
Introduction
98
5.2
System Specifications
99
5.3
Testing Data
100
5.4
Screenshots from the Prototype System
101
5.5
Evaluations of the System
103
5.5.1 Pre-Processing
103
xi 5.5.2 Run-time Processing
5.6
5.7
6
105
5.5.2.1
Memory Usage
106
5.5.2.2
Loading Time
108
5.5.2.3
Frame Rate
109
5.5.2.4
Triangle Count
111
5.5.2.5
Geometric Throughput
113
Comparison with Previous Techniques
114
5.6.1 Memory Usage
115
5.6.2 Loading Time
116
5.6.3 Frame Rate
117
5.6.4 Triangle Count
118
Summary
120
CONCLUSION
121
6.1
Conclusion
121
6.2
Recommendations
124
REFERENCES APPENDICES A - C
126 133 - 139
xii
LIST OF TABLES
TABLE NO. 1.1
TITLE
PAGE
Types of busses and the corresponding memory bandwidth and geometric throughput (Hill, 2002; Peng et al., 2004)
2.1
7
Advantages and disadvantages of visibility culling methods
25
2.2
Comparison of intersection test techniques
31
2.3
Comparison among the geometric primitives
37
2.4
Comparison of view-dependent LOD techniques
53
3.1
Clipping planes with corresponding co-efficients
66
4.1
Data structure
75
4.2
Declaration of variables
80
5.1
Hardware specifications
99
5.2
Software specifications
99
5.3
Testing data
100
5.4
Environment settings for testing the proposed algorithm
5.5
101
The results of time required for converting DEM data and the corresponding file size for number of vertices per tile: 129 x 129 and 257 x 257
103
5.6
Number of generated tiles
104
5.7
Environment settings for comparison purpose
115
xiii
LIST OF FIGURES
FIGURE NO. 1.1
TITLE
PAGE
Visualization of full resolution terrain model (number of vertices = 16,848,344,430 and number of triangles = 33,695,786,468)
6
2.1
Kd-tree
14
2.2
Quadtree
15
2.3
R-tree
17
2.4
Partitioning data into tiles
18
2.5
Tree structure for tiles
19
2.6
Vector angle between view direction and polygons normal
21
2.7
Small feature culling a) OFF, b) ON
22
2.8
Occlusion culling of occluded object
23
2.9
Camera’s view frustum
24
2.10
The red objects lie completely outside the viewfrustum and will be discarded from rendering when view frustum culling is performed
24
2.11
AABB of an object
27
2.12
OBB of a rotated object
28
2.13
BS of an object
29
2.14
Aircraft model and the corresponding k-dops a) Level 1, b) Level 2, c) Level 3, d) Level 4
30
2.15
Variations of grid representations
33
2.16
TIN representation
33
2.17
Independent triangles
35
2.18
Triangle fan
36
xiv 2.19
Triangle strip
36
2.20
Levels 0-5 of a triangle bintree
38
2.21
Split and merge operations on a bintree triangulation
39
2.22
Forced splitting process
39
2.23
Wedgies in ROAM implementation
40
2.24
A sample triangulation of a 9 x 9 height field a) quadtree matrix, b) the corresponding quadtree structure
43
2.25
Measuring surface roughness
44
2.26
Vertex split and edge collapse operations
45
2.27
Steps in pre-processing block-based simplification
46
2.28
Interleaved quadtree structure
49
2.29
Four levels of longest-edge bisection operation
50
3.1
Research framework
56
3.2
Overlapping tile
62
3.3
Dynamic load management
63
3.4
Six planes of view frustum
64
3.5
Plane-sphere intersection test for view frustum culling technique a) sample scene, b) intersection test, c) result after culling
68
3.6
Distance (l) and edge length (d)
69
3.7
Generation of triangle fans
70
3.8
Terrain tiles after applying view-dependent LOD technique
71
4.1
Menu for partitioning DEM data
73
4.2
Structure of a DEM file
74
4.3
First data point for DEM data a) West of the central meridian b) East of the central meridian
4.4
Parameters after extraction of important header information
4.5
77
78
The indices and the corresponding elevation values
79
xv 4.6
List of generated TILE files
85
4.7
Structure in a TILE file
86
4.8
Class diagram
88
4.9
Sixteen possibilities of generating triangle fans
95
5.1
Small dataset a) wireframe, b) textured
102
5.2
Moderate dataset a) wireframe, b) textured
102
5.3
Large dataset a) wireframe, b) textured
102
5.4
Total time for converting DEM datasets to TILE files
104
5.5
Memory usage for the proposed system
106
5.6
The results of memory usage
107
5.7
The results of loading time
108
5.8
The results of average frame rate based on different FOV
5.9
The results of average frame rate based on different length of view frustum
5.10
110
The results of average triangle count based on different FOV
5.11
109
111
The results of average triangle count based on different length of view frustum
111
5.12
The results of frame rate versus triangle count
112
5.13
The results of average geometric throughput based on different FOV
5.14
113
The results of average geometric throughput based on different length of view frustum
114
5.15
Comparison based on memory usage
116
5.16
Comparison based on loading time
117
5.17
Comparison based on frame rate
118
5.18
Comparison based on triangle count
119
xvi
LIST OF ALGORITHMS
ALGORITHM NO.
TITLE
PAGE
2.1
Pseudo code for split queue
41
2.2
Pseudo code for merge queue
42
2.3
Pseudo code for selective refinement
47
2.4
Pseudo code for force vsplit
48
2.5
Pseudo code for mesh refinement (meshrefine)
2.6
Pseudo code for sub mesh refinement (submesh-refine)
2.7
51
Pseudo code for generating triangle strips (trianglestrip-append)
4.1
51
52
Pseudo code for obtaining maximum number of vertices per side for original terrain data
4.2
Pseudo code for assigning new maximum number of vertices per side for terrain data
4.3
81
81
Pseudo code for determining the maximum number of vertices per side for tiles in vertical direction (Vt_v_max)
4.4
Pseudo code for obtaining starting point and existence status for each tile
4.5
83
Pseudo code for partitioning data and creating TILE files
4.6
82
84
Pseudo code for obtaining starting coordinates of existing tile
85
xvii 4.7
Pseudo code for obtaining the current tile index based on camera position
4.8
Pseudo code for obtaining the terrain indices to be loaded
4.9
91
92
Pseudo code for detecting the visibility status and assigning flag for loaded tiles
93
xviii
LIST OF ABBREVIATIONS
ABBREVIATION
DESCRIPTION
2D
-
Two-dimensional
3D
-
Three-dimensional
AABB
-
Axis Aligned Bounding Box
API
-
Application Programming Interface
BS
-
Bounding Sphere
CBIS
-
Computer-based information system
CFD
-
Computational fluid dynamics
CPU
-
Central processing unit
DEM
-
Digital Elevation Model
DSS
-
Decision Support System
DTED
-
Digital Terrain Elevation Data
ESS
-
Executive Support System
FOV
-
Field of view
FPS
-
Frames per second
GIS
-
Geographic Information System
GPU
-
Graphics processing unit
GRASS
-
Geographic Resources Analysis Support System
IS
-
Information system
KMS
-
Knowledge Management System
LOD
-
Level of detail
MBB
-
Minimal bounding box
MBR
-
Minimal bounding rectangle
MIS
-
Management Information System
NE
-
Northeast
xix NW
-
Northwest
OAS
-
Office Automation System
OBB
-
Oriented Bounding Box
OS
-
Operating system
PC
-
Personal computer
RAPID
-
Rapid and Accurate Polygon Interference Detection
ROAM
-
Real-time Optimally Adapting Meshes
SE
-
Southeast
SW
-
Southwest
TIN
-
Triangulated irregular network
USGS
-
United States Geological Survey
UTM
-
Universal Transverse Mercator
VDPM
-
View-dependent progressive meshes
ViRGIS
-
Virtual Reality GIS
xx
LIST OF APPENDICES
APPENDIX
TITLE
PAGE
A
DEM Elements Logical Record Type A
133
B
DEM Elements Logical Record Type B
138
C
List of Published Paper Works
139
CHAPTER 1
INTRODUCTION
1.1
Introduction
Computer-based information system (CBIS) has changed the people works from traditional manual system to an automation system that provides more effective and systematic way in solving specific problems. In addition, the works can be done and completed much faster than the previous approach. Thus, time consumption can be reduced and managed efficiently. This is due to the rapid development of computer’s technology over the last few years. Several types of CBISs have been developed and those systems have contributed to the evolution of information system. Among of them are Management Information System (MIS), Office Automation System (OAS), Executive Support System (ESS), Decision Support System (DSS), Knowledge Management System (KMS), Geographic Information System (GIS) and Expert System (Gadish, 2004).
Geographic information system (GIS) is one of the important developments of CBIS that combines digital map and geographic data; and facilitate assessments of related characteristics of people, property and environmental factors. In general, GIS is a set of computer tools for collecting, storing, retrieving, transforming and displaying data from the real world for a particular set of purposes or application domains (Burrough and McDonnell, 1998). There are two main elements in developing GIS applications: database and visualization. This system provides an opportunity to store both kinds of spatial data (location-based data) and non-spatial
2 data (attribute data) in a single system. In current GIS applications, these two types of data are often stored in two separate databases. However, these databases are linked or joined together later depending on the particular characteristic.
Computer graphics disciplines are exploited in visualizing the GIS data. It is useful for analyzing and verifying the related activities in terms of accuracy, efficiency and other factors. For this reason, GIS is becoming increasingly important to a growing number of activities in many sectors including urban planning, flood planning, oil exploration, evaluations of vegetation, soil, waterway and road patterns (Fritsch, 1996; Burrough and McDonnell, 1998).
Lacking in several aspects such as user interaction (limited to panning and zooming operations), presentation (points, lines and symbols) and interpretation in two-dimensional GIS (2D GIS) was lead to the development of higher dimensional GIS especially three-dimensional GIS (3D GIS), which is also known as Virtual GIS (Burrough and McDonnell, 1998). The use of colors and symbols representation in previous GIS is replaced with 3D photo-textured models, which improves the level of understanding of the system. Moreover, Virtual GIS has the ability to have detailed 3D views and provide real-time navigation whether fly-through or walkthrough for analyzing large volumes of spatial data and related information. At the same time, the operations used in 2D GIS can be integrated easily into the system (Noor Azam and Ezreen Elena, 2003).
Real-time terrain visualization is one of the subfield in GIS that attracts a number of researchers involved in this area. Normally, terrain and the other objects such as trees, buildings and roads are managed separately due to their different data representation. Speed and realism are two factors frequently considered in solving related terrain problems. At present, there are more than 800 commercial terrain visualization software have been developed by different vendors and developers as reported by United States Army Topographic Engineering Center (2005). Among the popular software are ESRI® ArcGIS, ERDAS® Imagine VirtualGIS, Geographic Resources Analysis Support System (GRASS) and Manifold System.
3 In this thesis, the research focuses on real-time 3D terrain data organization, visualization and on-the-fly navigation. There are two key issues have to be encountered in developing terrain-based applications in GIS field: spatial database management and fast interactive visualization (Kofler, 1998). These two obstacles take into account with the capabilities of current hardware technology that supports the system to be developed. Large amount of terrain dataset need to be handled efficiently in real-time environment with restricted main memory capacity. These include the management of geometric and texture data. At the same time, the interactive frame rate needs to be achieved consistently when facing with too many polygons generated for each frame. The detailed information on problem background is covered in Section 1.2.
There are many solutions have been proposed by a number of researchers in the last few years. Among of them are the implementation of hierarchical data structure, visibility culling methods and level of detail (LOD) techniques. Briefly, the most common types of data structures can be employed to manage data are Kdtree (Bentley, 1975; Bittner et al., 2001; Langbein et al., 2003), quadtree (Samet, 1984; Röttger et al., 1998; Pajarola, 1998), R-tree (Guttman, 1984; Kofler, 1998; Yu et al., 1999; Zlatanova, 2000) and tiled block (VTP, 1999; Lindstrom et al., 1996; Pajarola, 1998; Ulrich, 2002). The difference is depending on how the space (data) is divided in hierarchical manner (Gaede and Günther, 1998).
For visibility culling, there are four types of methods can be adopted: backface culling (Laurila, 2004), small feature culling (Burns and Osfield, 2001; Assarsson, 2001), occlusion culling (Stewart, 1997; Mortensen, 2000; Martens, 2003) and view frustum culling (Hoff, 1996; Assarsson and Möller, 2000). These are useful for removing the unneeded data from being processed. One of the important components in culling methods is the intersection test. The related research works include Axis Aligned Bounding Box (Beckmann et al., 1990; Morley, 2000), Oriented Bounding Box (Gottschalk et al., 1996; Assarsson and Möller, 2000), Bounding Sphere (Hubbard, 1995; Dunlop, 2001; Morley, 2000; Picco, 2003) and k-Discrete Orientation Polytope (Klosowski et al., 1998).
4 LOD techniques are used to reduce the number of polygons and give details to the certain area in a scene. The examples of well-known techniques are Real-time Optimally Adapting Meshes (Duchaineau et al., 1997), Real-time Generation of Continuous LOD (Röttger et al., 1998), View-Dependent Progressive Meshes (Hoppe, 1998) and Out-of-core Terrain Visualization (Lindstrom and Pascucci, 2001). Although the LOD technique can reduce the problem complexity but lots of polygons that are out-of-sight still being rendered, thus deteriorating the system performance. Most of the abovementioned researchers have integrated their system with culling method at vertices or polygon level in order to solve the problem. However, lots of computations involved in implementing such method especially when facing with large amount of datasets.
In this thesis, a set of techniques has been designed and proposed for handling massive terrain dataset in interactive rate. The idea behind this research is to expand the capability of triangle-based LOD technique and improve the performance of real-time terrain visualization and navigation system. Triangle-based LOD technique has been chosen for this research because it has potential to remove lots of terrain geometry and capable to speed up the system at interactive rates without losing the visual appearance of visualization part (Duchaineau et al., 1997; Hoppe, 1998; Pajarola, 1998; Röttger et al., 1998; Lindstrom and Pascucci, 2001).
There are two separate phases involved, which are pre-processing and runtime processing. In first phase, the specific terrain data is converted to the internal data structure that is based on tile representation. The original terrain data is partitioned into several small tiles or patches. In run-time, several tiles are loaded depending on camera position. Then, these tiles are tested for determining the visibility status to remove the unseen block of data. Finally, the geometric simplification of visible terrain tiles is done which is based on triangle-based LOD technique in order to minimize the number of triangles to be processed and being rendered.
5 1.2
Problem Background
There are three challenging issues in developing terrain-based applications. These involve the massive terrain datasets, geometric complexity and capability of current triangle-based LOD techniques.
1.2.1
Massive Terrain Dataset
Various types of terrain datasets are widely being used in GIS applications, including Digital Elevation Model (DEM), Digital Terrain Elevation Data (DTED), satellite data and aerial photographs. Commonly, terrain consists of geometry and imagery data. Geometric data represents the location or coordinate of related terrain’s vertices, while imagery data represents as a texture map for producing realistic 3D model. In fact, large amount of this terrain dataset have to be faced when dealing with GIS applications. It is not surprising if the size of dataset will occupy a number of Gigabytes or even Terabytes of storage (Gaede and Günther, 1998).
The use of this massive dataset will affect the capability of main memory to load and store data for visualization. A number of researchers have pointed out that it is impossible to hold the entire detailed dataset at once (Kofler, 1998; Pajarola, 1998). Besides that, accessing this data quickly enough to use it in real-time rendering is a difficult problem. It will limit the performance of the system during interactive visualization. This is because when the new frame is generated, all polygons will be displayed whether they are within the view frustum or not. It is time consuming to compute and render the unneeded data continuously in real-time (Hill, 2002).
6 1.2.2
Geometric Complexity
For any detailed terrain model, the number of triangles that must be rendered is prohibitively high. For instance, a 100 km x 100 km terrain sampled at 1-meter resolution and represented as a regular grid will contain roughly 20,000,000,000 triangles. At present, it is not be able to render anywhere near this full resolution data in real-time. According to the research that has been done by Hill (2002) in managing large terrains, rendering 20,000,000,000 triangles per second would not be feasible until 2010. Furthermore, rendering this many triangles at 60 frames per second would not be possible until 2016.
Figure 1.1 shows an example of
visualizing original terrain model with billion of vertices and polygons. The white line shows the triangles generated in wireframe mode and the black color is a background of a scene.
Figure 1.1 Visualization of full resolution terrain model (number of vertices = 16,848,344,430 and number of triangles = 33,695,786,468)
7 With current graphics hardware, all communications between the card and the CPU takes place over the memory bus. Presently, the primary bottleneck related to rendering performance is the memory bandwidth on the bus. The graphics hardware is capable of rendering substantially more geometry per second than can be read in over the bus. In order to render 60 million triangles per second, over 5 Gigabytes of data would need to be transferred to the card each second. According to the maximum memory bandwidth and million triangles per second can be transferred to the graphics card as shown in Table 1.1, it is impossible to achieve the maximum rendering speed directly. Moreover, this bandwidth is also used for transferring texture data to the card, so the 60 million triangles per second target are even further out of reach (Hoppe, 1999; Hill, 2002).
Table 1.1: Types of busses and the corresponding memory bandwidth and geometric throughput (Hill, 2002; Peng et al., 2004) Type of Bus
Bandwidth Limitation
Geometric Throughput
(MB/s)
(Million triangles per second)
PCI
133
1.385
PCI64
533
5.552
AGP 1x
266
2.771
AGP 2x
533
5.552
AGP 4x
1066
11.104
AGP 8x
2150
22.396
PCI Express
4300
44.792
8 1.2.3 Limited Capability of Triangle-Based LOD Techniques
In order to deal with so much dataset, level of detail (LOD) techniques need to be employed. Theoretically, terrain close to the viewer must be presented with more geometry than terrain that far away from the viewer; and rough terrain requires more geometry than flat terrain does. Frequently, triangle-based LOD algorithm is applied for simplifying the terrain geometry. Although this technique provides fast visualization through polygon simplification in real-time but it is not practical for very large terrain dataset because the amount of data to be loaded exceeds the data that can be stored into main memory. Even if the system is able to load the data, it is time expensive for waiting the loading process completed (Hill, 2002).
1.3
Problem Statements
According to the problems mentioned earlier, the following question needs to be solved in this research:
How to store and display large amount of terrain datasets efficiently for real-time visualization and navigation system with restricted capacity of current main memory and memory bus bandwidth?
1.4
Goal
The research goal is to expand the capabilities of triangle-based LOD technique by developing a set of techniques using hybrid method that will enhance the efficiency of real-time 3D terrain visualization and navigation for the development of Virtual GIS.
9 1.5
Objectives
In order to accomplish the main goal, several objectives have to be fulfilled. These include: (i)
To design and construct an efficient data structure that will be able to store arbitrary-sized terrain model.
(ii)
To develop an algorithm that will be able to provide fast data loading and reduce the memory usage in run-time.
(iii)
To develop a culling technique that will be able to remove large amount of terrain geometry.
(iv)
To integrate aforementioned data structure, loading algorithm and culling technique with the chosen triangle-based LOD technique into the real-time terrain visualization and navigation system.
1.6
Scopes
The research focuses on managing large-scale terrain dataset in real-time. Several scopes need to be considered. These include: (i)
The system manages static terrain dataset. It does not include the buildings, trees, rocks and other related objects.
(ii)
The system focuses on managing terrain geometry. Imagery terrain data is only used as a texture map for enhancing the visual appearance.
(iii)
Terrain datasets are the regular grid representation.
(iv)
Triangle-based LOD technique is based on view-dependent LOD technique.
(v)
The system is developed in real-time environment, which involves user interaction through computer’s keyboard and mouse on desktop PC.
10 1.7
Organization of the Thesis
The thesis is organized into six chapters. Chapter 1 gives a general picture on related research fields, problem background and existing solutions involved in developing real-time terrain visualization and navigation in Virtual GIS. Besides that, the goal, objectives and scopes of this research have been specified.
Chapter 2 provides surveys on spatial data structures, visibility culling methods, intersection test techniques and view-dependent LOD techniques.
Chapter 3 presents the methodology of this research, which consists of four main steps. The explanations include partitioning original terrain data, loading tiles, culling invisible tiles and simplifying geometry of visible tiles.
Chapter 4 describes the implementation details of prototype system from preprocessing to run-time processing. For pre-processing, there are two pairs of steps have been explained, which are reading a DEM file and creating TXT files, and reading TXT files and creating TILE files. For run-time processing, the section has been divided into five subsections: creation of classes, initialization, rendering, interaction and shutdown procedure.
Chapter 5 presents and discusses the results obtained from the implementation phase. System specifications and testing data have been specified. Subsequently, the evaluations of the system and comparison among the existing technique have been explained in further details.
Chapter 6 summarizes the thesis and includes recommendations of future works that can be extended with the prototype system.
CHAPTER 2
LITERATURE REVIEW
2.1
Introduction
In order to achieve the goal and the objectives as specified in previous chapter, the literature review have been made. First, the spatial data structures have been reviewed in details. The explanations involve the organization of the data and the indexing mechanism.
Then, the reviews on visibility culling methods have been done. The explanations are divided into two parts: types of culling methods and intersection test techniques. The first part describes the culling methods have been developed by previous researchers. The second part explains the technique can be used to detect the intersection between two different objects.
Lastly, the reviews on triangle-based LOD techniques were made. There are three main parts: terrain representation, geometric primitives and the previous works on view-dependent, triangle-based LOD techniques.
The comparative studies were done for all the abovementioned data structure, culling methods and LOD techniques in order to obtain the strengths and weaknesses of those approaches.
12 2.2
Spatial Data Structures
Spatial data structure is crucial in organizing large data in a systematic way. There are three main approaches can be adopted: hashing, space-filling curve and hierarchical tree.
Hashing is one of the bucketing methods. According to this approach, the records or data are sorted on the basis of the space that they occupy and are grouped into cells of a finite capacity (Hjaltason and Samet, 1995). The drawback of using hashing approach is performance may degenerate depending on the given input data (Gaede and Günther, 1998). The examples of hashing methods are linear hashing (Larson, 1980; Litwin, 1980), extendible hashing (Fagin et al., 1979), grid file (Nievergelt et al., 1984) and EXCELL (Tamminen, 1982).
Space-filling curve has been extensively used as a mapping scheme from the multidimensional space into the one-dimensional space. It is a thread that goes through all the points in the space while visiting each point only one time (Mokbel et al., 2002). An advantage of space-filling curve is that it creates an efficient indexing mechanism for fast data retrieval. However, this approach is difficult to integrate with different types of input data (Gaede and Günther, 1998). The examples of space-filling curves are row-wise (Samet, 1990), Z-order (Orenstein and Merrett, 1984), Hilbert curve (Faloutsos and Roseman, 1989; Jagadish, 1990) and Gray code (Faloutsos, 1988).
Hierarchical tree is an approach that is based on spatial decomposition. In tree structure, there are a root node, internal nodes and leaf nodes. Hierarchical method is frequently being used in many related applications due to its simplicity, scalability, well-organized structure and capabilities to handle different type and size of data (Gaede and Günther, 1998). For this reason, the remainder of this thesis is focusing on hierarchical tree in order to create an efficient data structure.
13 2.2.1
Kd-Tree
Kd-tree was introduced by Bentley (1975). It is also called multidimensional binary tree. The way it stores the data is same as binary search tree. It represents a recursive subdivision where two new nodes (child nodes) will be produced during the node splitting for each current node (parent node). Splitting process is parallel to the Cartesian axis (x-axis and y-axis). The root node contains a vertical line through the median x-coordinate of the points, which splits the plane into a left and right region. The left child node contains a horizontal line through the median ycoordinate of the points in the left region, which splits the left region into an upper and lower region. Similarly, the right child node contains a horizontal line through the median y-coordinate of the points in the right region, which splits the right region into an upper and lower region. This process continues splitting the plane with vertical lines at nodes of even depth and horizontal lines at nodes of odd depth. Figure 2.1 depicts an example of plane subdivision and the corresponding Kd-tree.
From this basic idea, Bittner et al. (2001) have applied Kd-tree into their system to organize the whole scene and then integrate it with other data structure for constructing hierarchical visibility algorithm. Besides that, Langbein et al. (2003) have used this technique in visualization of large unstructured grids for computational fluid dynamics (CFD) used in industrial applications.
14
Figure 2.1 Kd-tree
15 2.2.2
Quadtree
Hierarchical quadtree is based on the principle of recursive decomposition. It has been proposed by Samet (1984). In general, the top-level node in this tree represents the area of the entire dataset and each child in the quadtree represents onefourth the region of its parent (Northwest, Northeast, Southwest and Southeast quadrants). Each node in the tree corresponds to a block of terrain with the same number of data points. The highest resolution data blocks belong to the deepest level of the tree. Figure 2.2 shows an example of block decomposition with its corresponding tree structure.
Due to its simplicity, many researchers have employed this technique into their system as one of the major component. Röttger et al. (1998) generated hierarchical quadtree with 2D matrices for handling multiresolution terrain model. Pajarola (1998) has created a restricted quadtree algorithm in order to reduce the terrain geometry in scene.
Figure 2.2 Quadtree
16 2.2.3
R-Tree
R-tree is an alternative hierarchical access methods that has high performance in order to search and retrieve rapidly spatial data in real-time. R-tree is derived from B+-tree. It was originally created by Guttman (1984). R-tree encompasses index records for each node where leaf nodes reference to the actual data items. The term minimal bounding box (MBB) or minimal bounding rectangle (MBR) was used to represent search region for spatial object. For leaf nodes in an R-tree, it contains index record entries of the form: (R, data-item-pointer) where R is an n-dimensional rectangle which is the bounding box of the spatial object indexed and data-item-pointer refers to a record in the database. While nonleaf nodes or interior nodes contain high-level index entries of the following form: (R, child-pointer) where child-pointer is the address of a lower node in the R-tree. An R-tree must satisfy the following properties: (i)
Every leaf has between m and M entries where m refers to minimum number of entries in a node and M denotes to maximum number of entries in a node.
(ii)
Leaf-entries (R, data-item-pointer): R is the MBR of object.
(iii)
Every non-leaf has between m and M children.
(iv)
Non-leaf-entries (R, child-pointer): R is the MBR of entries in child node.
(v)
Root (if no leaf) has at least two children.
(vi)
All leaves are on the same level.
17 In general, searching an R-tree is done by finding all index records whose MBRs overlap a search rectangle. The algorithm will start with the root and will follow recursively all entries in the current node whose MBRs overlap the search rectangle. At the end of each path, a leaf node is processed and the MBRs of all entries in that leaf are tested against the search pattern. The index records found to have an overlapping rectangle are stored as a list of result candidates. Figure 2.3 illustrates an R-tree structure where N refers to index record and R refers data entries.
Figure 2.3 R-tree Due to the potential used in virtual GIS, it was implemented in numerous applications. In SATURN system, a modified R-tree (combination of R-tree and kdtree) has been produced to manage various types of objects in scene (Yu et al., 1999). Pajarola (1998) has used the R-tree for clustering the 3D objects based on viewer position. Kofler (1998) has created R-tree based LOD for managing terrain dataset in Vienna Walkthrough System. Zlatanova (2000) has developed 3D R-tree for LOD and spatial indexing in his 3D urban system.
18 2.2.4
Tiled Block
Tiled block is a simple data structure that partitions the terrain data into square patches or tiles (Figure 2.4 and Figure 2.5). It can be used for handling large geometry and imagery data. There are two types of approaches commonly being applied: naïve and overlapping tile (VTP, 1999). The difference between two of them is the dimension or size of the data to be used. The dimension for the naive approach is power-of-two (2n), while the overlapping tile approach uses power-oftwo plus one (2n+1) dimension. The second approach is frequently being implemented in the visualization of large-scale data due to its capability to reduce and avoid the cracks occurrence between the boundaries of tiles.
Lindstrom et al. (1996) have implemented this approach in their block-based simplification of real-time continuous LOD rendering of height fields. Then, Lindstrom et al. (1997) extended their research by developing a tile data structure in integrated global GIS and visual simulation system that is based on globe or spherical representation. Pajarola (1998) developed a dynamic scene management, which consists of two-dimensional of terrain tiles (also known as scene map) for the visible scene in his ViRGIS. Ulrich (2002) implemented the tile approach for both textures and terrain elevation data in his Chunk LOD.
Partition Data
Original Data Figure 2.4 Partitioning data into tiles
Tiles
19
Figure 2.5 Tree structure for tiles
2.2.5
Comparative Studies
The comparison is made in order to distinguish the capabilities of each technique described earlier. The advantages and disadvantages of each are stated out and the evaluation is made regarding on the investigation done by previous researchers on related techniques.
Kd-tree is a simple data structure in managing data. Although the structure can minimize the main memory usage but it is sensitive to the order in which the points are inserted. Furthermore, data points are scattered all over the tree (Gaede and Günther, 1998). Searching and insertion of new nodes are straightforward but deletion may cause reorganization of the tree under the deleted node, which makes it more complicated to handle. In Kd-tree data structure, the decomposition process is made depending on position of the points, thus resulting non-uniform spaces. Consequently, it does not divide the plane at the best possible positions and produce an unbalanced tree (Ahn et al., 2001).
20 Quadtree is one of the early proposed techniques that being used until recently. It has ability to manage multidimensional and vast databases capacity with its simple representation. However, the resolution of the data used in quadtree is limited by the size of the basic grid cell (Guttman, 1984). Besides that, each node in quadtree needs additional space for the pointer to its sons. The space is wasted frequently on null pointers for each invisible node and consequently the overhead will occur (Samet, 1984, Burrough and McDonnell, 1998).
Dynamic data structure of R-tree (Guttman, 1984) makes it attractive for many fields. It allows for the efficient dynamic update, handling of large geographic databases and range searching (Sheng and Liu Sheng, 1990). The disadvantage of this structure is the complex algorithms have been used to split nodes, thus it will result in either slow insertions or horrible bounding boxes. Furthermore, the handling of overlapping is difficult to implement (Kofler, 1998).
Tiled block is easy to understand and implement. In general, it is crucial for handling massive data with limited main memory (Peng et al., 2004). Memory can be managed efficiently with the combination of existing optimization techniques. However, due to size of data need to be in the form of 2n or 2n+1, the unnecessary data will be generated, thus consuming a lot of storage space (VTP, 1999). Besides that, when integrating this approach with multiresolution technique, the cracks will be occurred automatically (VTP, 1999; Ulrich, 2002). Another algorithm needs to be inserted in order to solve the problem.
2.3
Visibility Culling Methods
Visibility culling is one of the optimization techniques often being adopted in computer graphics to enhance the system performance. It is developed in order to reduce the complexity of large data geometry especially in real-time that requires higher frame rate. In the next subsections, the types of culling methods will be reviewed in further details.
21 2.3.1
Types of Culling Methods
The main objective of visibility culling methods is to remove as much as possible the unneeded objects or data. This will accelerate the rendering process during run-time. In general, visibility culling can be categorized into backface culling, detail culling, occlusion culling and view frustum culling.
2.3.1.1 Backface Culling
Backface culling is based on the observation that if all objects in the world are closed, then the polygons that do not face the viewer cannot be seen. The status of the polygon whether it is front or back from the viewer can be determined by the vector angle between the view direction and the normal of the polygon (Laurila, 2004). If the angle is more than 90 degrees, the polygon can be discarded (Figure 2.6). Backface culling is often performed by the rendering Application Programming Interface (API) such as Dierct3D and OpenGL.
Figure 2.6 Vector angle between view direction and polygons normal
22 2.3.1.2 Small Feature Culling
Detail culling or small feature culling is a method that sacrifices quality for achieving fast rendering. It is based on the size of the projected bounding volume. If the object is too small in world space according to the distance between viewpoint and position of object, it can be discarded (Haines, 2001; Shen, 2004).
This culling method was implemented in the development of OpenSceneGraph (Burns and Osfield, 2001) and ABB Robotics Product (Assarsson, 2001). Figure 2.7 depicts the related objects and the implementation of small feature culling by Assarsson (2001). According to the figures, there is no much difference but actually, it is 80 to 400 percents faster than the original scene.
(a)
(b) Figure 2.7 Small feature culling a) OFF, b) ON
23 2.3.1.3 Occlusion Culling
Occlusion culling is a method that discards objects, which are occluded. There are few previous works have been done related to this method. Stewart (1997) has integrated hierarchical occlusion culling in his terrain model in order to test the visibility of terrain surfaces based on camera position. Mortensen (2000) has inserted this method into his real-time rendering of height fields system, which consists of different LOD. Martens (2003) have developed occlusion culling for the real-time display of complex 3D models. Figure 2.8 shows an example of occlusion culling.
Figure 2.8 Occlusion culling of occluded object
24 2.3.1.4 View Frustum Culling
View frustum culling is based on the fact that only the objects in the current view volume must be rendered. View volume is defined by six planes, which are near, far, left, right, top and bottom clipping planes whereby all the planes together form a truncated pyramid (Figure 2.9).
top left
frustum right bottom near far
Figure 2.9 Camera’s view frustum
If the objects are entirely outside of the view volume, it cannot be visible and can be discarded as illustrated in Figure 2.10. If object is partially inside (intersect with view frustum), then it is clipped or special refinement method need to be done to the related planes so that the outside parts are removed.
View frustum culling
View frustum
Figure 2.10 The red objects lie completely outside the view-frustum and will be discarded from rendering when view frustum culling is performed
25 Previous works have been made by several researchers in order to achieve higher system performance. Hoff (1996) explored the effective intersection mechanism of view frustum and Axis Aligned Bounding Box (AABB) or Oriented Bounding Box (OBB). Most of the terrain rendering algorithms (Duchaineau et al., 1997; Röttger et al., 1998) used this method to simplify the number of polygons in a scene. Assarsson and Möller (2000) proposed one basic intersection test and four optimization techniques (plane-coherency test, octant test, masking and translationand-rotation coherency test) related with the fundamental comparison of view frustum and bounding volume of objects.
2.3.1.5 Comparative Studies
The comparison is made in order to identify the strengths and drawbacks of four different visibility culling methods that have been explained earlier. All the information have been collected from various researchers (Stewart, 1997; Mortensen, 2000; Assarsson, 2001; Burns and Osfield, 2001; Martens, 2003; CGL, 2004; Laurila, 2004; Shade, 2004). Table 2.1 summarizes the advantages and disadvantages of backface, small feature, occlusion and view frustum culling.
Table 2.1: Advantages and disadvantages of visibility culling methods Type of Culling
Advantages
Backface
• Fast computation
culling
• Discard roughly half of the
Disadvantages • Not a complete solution if the objects are not convex
polygons inside the view frustum Small feature
• Speed up the system
culling
• Efficient when the movement is made
• Decrease the quality of a scene
26 Occlusion culling
• Capable to remove lots of occluded objects efficiently
• Not all algorithms work well on all kinds of scenes • Lots of steps and complex calculations need to be faced
View frustum
• Easy to implement
culling
• Easy to integrate with other techniques • Effective when only a small part of the scene is inside
• Additional optimization techniques are required for complex environment that has lots of geometry inside the view frustum
the view frustum
2.3.2
Intersection Test Techniques
Intersection test is a main component in culling process. In general, it depends on two criteria: the tightness of input geometric primitives and speed of intersection test (Klosowski et al., 1998). Intersection test can be represented in point-based or bounding volume-based. Point-based intersection test can be performed on huge model polygonal model but the test itself would probably become slower (Morley, 2000). Therefore, the bounding volume-based intersection test is the better way in handling complex models.
The purpose of this process is to determine the object’s location is whether entirely inside, outside or partially inside/outside. According to the recent research works, there are four types of bounding volumes can be used to enclose the objects, which are Axis Aligned Bounding Box (AABB), Oriented Bounding Box (OBB), Bounding Sphere (BS) and k-Discrete Orientation Polytope (k-DOP). The detailed information on those bounding volumes is explained in the next subsections.
27 2.3.2.1 Axis Aligned Bounding Box
Basic idea came from Beckmann et al. (1990) when they attempt to develop an efficient and robust access method using R*-tree. They manipulated the hierarchical tree in order minimize the area of each enclosing rectangle (MBR) for spatial objects. In this technique, box is parallel to the world axis. It needs eight corner points or one minimum and one maximum point to form the bounding volume. The main process is to test all eight corners against each plane and then count how many corners are in front of the plane. If none of the corners is in front, the entire box is outside the view frustum. If all of the corners are in front, the entire box is inside the view frustum. Otherwise, the intersection has occurred (Morley, 2000). Figure 2.11 illustrates the bounding box of an object.
Figure 2.11 AABB of an object
2.3.2.2 Oriented Bounding Box
Oriented Bounding Box (OBB) has become popular bounding volume technique, which surrounds an object with a bounding box where the orientation is arbitrary with respect to the coordinate axes. It is based on local coordinate system.
28 One leading system publicly available for performing collision detection among arbitrary polygonal models is the RAPID (Rapid and Accurate Polygon Interference Detection) system, which is based on a hierarchy of OBBs called OBBTree, implemented by Gottschalk et al. (1996). They introduced fast box-box intersection test where the main parameters are the radii (half-dimension of box), unit vectors for each radii, unit vector that parallel to the axis and radius of the box. Given ai is a length of radii, Ai is a unit vector of radii, L is a unit vector that parallel to the axis. Here is the formula to obtain the radius, r of the bounding box: r = ∑ ai Ai • L
(2.1)
i
In view frustum-OBB intersection test, eight corner points need to be tested with the plane like AABB. If the result of distance calculation is more than r, the object is outside the view frustum. If the result of distance calculation is more than –r, the object is intersect. Otherwise, the object is entirely inside the view frustum (Assarsson and Möller, 2000). Figure 2.12 depicts the bounding box that encloses an object.
Figure 2.12 OBB of a rotated object
29 2.3.2.3 Bounding Sphere
Sphere is among the simplest geometric structures to represent an object. Sphere-tree has been developed by Hubbard (1995) in order to solve the collision detection for interactive applications. He has integrated the hierarchical octree with bounding sphere. Bounding sphere is defined by a 3D coordinate representing the center of the sphere and a scalar radius that defines the maximum distance from the center of the sphere to any point in the object (Dunlop, 2001).
For view frustum-bounding sphere intersection test, if the result of distance calculation is less than negative radius of the sphere, then it is outside the view frustum. Otherwise is whether all inside or partially inside depending on the total number of intersection counter. If the value of counter is six, then the object is entirely inside the view frustum. Otherwise, the intersection has occurred (Morley, 2000; Picco, 2003). Figure 2.13 shows the bounding sphere of an object.
Figure 2.13 BS of an object
30 2.3.2.4 k-Discrete Orientation Polytope
A k-Discrete Orientation Polytope (DOP) has been proposed by Klosowski et al. (1998) to handle complex polygonal convex hull effectively. It minimizes the bounding volume that encloses the object depending on the k value. The tight fit bounding volume will be produced if the higher k value is set. In their research, they have produced 6-dops (AABB), 14-dops, 18-dops and 26-dops. Intersection test can be done by testing the surface of the bounding volume with each frustum plane. Figure 2.14 depicts the example of hierarchical k-DOP with 6-dops, 14-dops, 18dops and 26-dops.
(a)
(b)
(c) (d) Figure 2.14 Aircraft model and the corresponding k-dops a) Level 1, b) Level 2, c) Level 3, d) Level 4
31 2.3.2.5 Comparative Studies
The comparison has been made for intersection test techniques according to the previous works (Gottschalk et al., 1996; Klosowski et al., 1998; Morley, 2000). All the information have been tabulated in Table 2.2.
Table 2.2: Comparison of intersection test techniques Features Accuracy
AABB
OBB
BS
k-DOP
Not accurate
Not accurate
Accurate
Accurate
(return false
(return false
(no false
(tightly fit
positive)
positive)
positive)
the object shape)
Parameter
Eight corner
Eight corner
Center
Depend on
involved
vertices of box
vertices of
coordinates
k value
box
and radius of sphere
Memory
Take more
Take more
Take less
Take more
requirement
memory
memory
memory
memory
Object
Not suitable
Suitable for
Not suitable
Suitable for
handling
for long-thin
long-thin
for long-thin
complex
oriented object
oriented
oriented object convex
(produce an
object
(produce an
empty space)
object
empty space)
Motion object
Need to
Need to
No need to
Need to
handling
redefine
redefine
redefine
redefine
bounding box
bounding
polytope
area
box area
area
Fast
Slow
Very fast
Slow
Simple
Simple
Difficult
Speed
Implementation Simple complexity
due to complex structure
32 2.4
View-Dependent LOD Techniques
The purpose of view-dependent LOD technique is to build meshes with a minimum number of generated polygons through the approximation model. It is done continuously on-the-fly and the viewer’s position (viewpoint) plays an important role as an element that influences the updating of a polygon meshes in each frame. The computation of deviation between corresponding points on the two meshes in object space is needed for measuring the level of terrain roughness (Lindstrom and Pascucci, 2001). It depends on the approach to be used in representing terrain data whether using top-down approach (refinement methods) or bottom-up approach (decimation method). The next subsections will explain the terrain representation, geometric primitives and previous research works that have been done by researchers for the last few years.
2.4.1
Terrain Representation
In computer graphics, terrain can be represented as a regular grid or triangulated irregular network (TIN). Each representation has its own capabilities to perform terrain model. The detailed information about those representations is described in the next subsections.
2.4.1.1 Regular Grid
Regular grid is a straightforward method. Fundamentally, it divides the terrain data into several blocks, which are then sub-sampled to obtain lower resolution models (Blekken and Lilleskog, 1997). It uses an array of height values at regularly space x and y coordinates. There are many variations in generating the regular grid depending on the developed system as depicted in Figure 2.15. For
33 examples, this representation was used by Lindstrom et al. (1996), Duchaineau et al. (1997) and Röttger et al. (1998) in testing their proposed technique.
Figure 2.15 Variations of grid representations
2.4.1.2 Triangulated Irregular Network
Triangulated irregular network (TIN) is a contiguous representation of the terrain consisting of the non-overlapping or arbitrary variable sized triangles (Blekken and Lilleskog, 1997). It allows changeable spacing between vertices. This representation has been adopted in view-dependent progressive meshes by Hoppe (1998) and multi-triangulation (DeFloriani et al., 2000). Figure 2.16 shows the TINbased geometric representation of terrain model.
Figure 2.16 TIN representation
34 2.4.1.3 Advantages and Disadvantages
The comparison between the regular grid and TIN has been made to obtain the strengths and the weaknesses of each terrain representation. It is compiled from various sources including Kumler (1994), Blekken and Lilleskog (1997), Ögren (2000) and He (2000).
Regular grid is a simple representation that easy to store and manipulate. It is easy to integrate with raster databases and file formats such as DEM, DTED and TIFF formats. Besides that, it requires less storage for the same number of points because only an array of elevation values needs to be stored rather than full coordinates (x, y, z). It provides fast rendering using triangle meshes (triangle strip or triangle fan). Unfortunately, it tends to be far less optimal then TIN approach because the same resolution is used across the entire terrain.
On the other hand, TIN can approximate a surface to a required accuracy with fewer polygons generated than regular grid. Furthermore, it offers great flexibility in the range and accuracy of the features that can be modeled. For examples are the ridges, valleys, caves and coastlines. Nevertheless, TIN makes the related functions such as view culling, collision detection, paging and dynamic deformation become more complex because of arbitrary position or coordinate of data points. Besides that, it needs a lot of memory to store data. The use of independent triangles for tessellating the whole data has decreased the system performance (rendering speed).
35 2.4.2
Geometric Primitives
All geometric primitives are eventually described in terms of their vertices, which are coordinates that define the points themselves, the endpoints of line segments or the corners of polygons (Woo et al., 1999). In order to display the 3D objects, the use of these primitives are very important. The explanation will focus on how to construct polygons according to the 3D geometric objects coordinates. The basic representation of 3D objects can be done in triangle form. In current graphics APIs such as OpenGL and DirectX, the triangle representation is utilized in three ways: independent triangle, triangle fan and triangle strip. The following subsections will describe in details about those geometric primitives.
2.4.2.1 Independent Triangles
Triangles are formed by drawing the sequence of three vertices v0, v1, v2, then v3, v4, v5 and so on (Figure 2.17). If the number of vertices, n is not an exact multiple of three, the final one or two vertices are ignored.
Figure 2.17 Independent triangles
36 2.4.2.2 Triangle Fans
Triangles are formed by drawing the three vertices v0, v1, v2, then v0, v2, v3, then v0, v3, v4, and so on (Figure 2.18). A v0 is an important vertex that works as a center of fan.
Figure 2.18 Triangle fan
2.4.2.3 Triangle Strips
Triangles are formed by drawing the three vertices v0, v1, v2, then v2, v1, v3, then v2, v3, v4, and so on (Figure 2.19). The ordering is to ensure that the triangles are all drawn with the same orientation so that the strip can correctly form part of a surface. Preserving the orientation is crucial for some operations such as culling.
Figure 2.19 Triangle strip
37 2.4.2.4 Comparative Studies
There are many aspects need to be considered in choosing the type of geometric primitive to be used. It involves the triangle count, triangle definition, redundancy, performance and complexity. The comparison has been made and summarized in Table 2.3. Given n is a total number of vertices.
Table 2.3: Comparison among the geometric primitives Independent
Triangle
Triangle
Triangle
Fan
Strip
Triangle Count
n/3
n-2
n-2
Triangle
Vertices 3n-2, 3n-1
Vertices 1, n+1
For odd n:
Definition
and 3n
and n+2
vertices n, n+1
Feature
and n+2. For even n: vertices n+1, n and n+2. Redundant data
Yes
No
No
Performance
Slow
Faster
Fastest
Complexity of
Easy
Easy
Difficult because
implementation
need an efficient indexing mechanism
2.4.3
Previous Works
Rendering algorithms are necessary in reducing the complexity of the generated polygon in a large-scale scene. The purpose of this operation is to obtain higher frame rate especially in real-time visualization and navigation. In the next subsections, four popular triangle-based LOD techniques are explained in details.
38 2.4.3.1 Real-time Optimally Adapting Meshes
Duchaineau et al. (1997) have proposed their technique called Real-time Optimally Adapting Meshes (ROAM). ROAM is usually being used in game development. For examples, several game companies such as Trade Marks, Genesis3D and Crystal Space have implemented it (Luebke et al., 2002). ROAM uses an incremental priority-based approach with a binary triangle tree (bintree) structure. A bintree is a tree in which each node is a right triangle (an isosceles triangle with one right angle) and has either zero or two children. The children are formed by splitting a node along the midline of the triangle (the line between the apex and the center of the base). Figure 2.20 shows the steps of building a bintree with a depth of six.
Figure 2.20 Levels 0-5 of a triangle bintree
A continuous mesh is produced using this structure by applying a series of split and merge operation on triangle pairs that share their hypotenuses referred to as diamonds (Figure 2.21).
39
Figure 2.21 Split and merge operations on a bintree triangulation
The ROAM algorithm uses two priority queues to drive split and merge operations. One queue maintains a priority-ordered list of triangle splits so that refining the terrain simply means repeatedly splitting the highest-priority triangle on the queue. The second queue maintains a priority-ordered list of triangle merge operations to simplify the terrain. This allows ROAM to take the advantage of frame coherence. Besides that, ROAM automatically eliminates the crack between two difference blocks of terrain by using force split operation which take into consideration the neighbor triangle. The current neighbor triangle must have the same level of resolution with the current triangle. If the condition is not fulfilled, the recursive triangle subdivision needs to be done. The forced splitting of triangle is showed in Figure 2.22.
Figure 2.22 Forced splitting process
40 The priority of splits and merges in the queues is determined using a number of error metrics. The principal metric is a screen-based geometric error that provides a guaranteed bound on the error. This is done by using a hierarchy of bounding volumes called wedgies that envelop around each triangle. A wedgie covers the (x, y) extent of a triangle and extends over a height range z - eT through z + eT where z is the height of the triangle at each point and eT is the wedgie thickness, which is all in world-space coordinates.
A pre-processing step is performed to calculate appropriate wedgies that are tightly nested throughout the triangle hierarchy, thus providing a guaranteed error bound. Figure 2.23 illustrates side view of the wedgies in triangle meshes. At runtime, each triangle’s wedgie is projected into screen space and the bound is defined as the maximum length of the projected thickness segments for all points in the triangle. This bound is used to form queue priorities and could potentially incorporate a number of other metrics such as backface culling and view frustum culling.
Figure 2.23 Wedgies in ROAM implementation
Duchaineau et al. (1997) have constructed two algorithms that generate optimized triangulations: split queue and merge queue. The first queue is based on a rough triangulation that is iteratively refined by a sequence of forced splits. A
41 priority split queue (Qs) contains monotonic priorities (pf(T)) for all triangles in the bintree to determine the order of these splits. The priority of a triangle (T) is determined by the error caused by using T instead of the finest triangulation. The detailed algorithm of split queue is listed in Algorithm 2.1. The |T| denotes the number of triangles in T and E(T) denotes as the maximum error of all triangles in T. The first two statements in the while loop create the triangulation, while the last two update the split queue.
Input: (i)
A base triangulation (T)
(ii)
An empty priority queue (Qs)
(iii)
Maximum number of triangles (Nmax)
(iv)
Maximum error (εmax)
Output:
An optimal triangulation
Pseudo code: 1.
for all triangles T
2.
insert T into Qs
∈ T do
3.
end for
4.
while |T| < Nmax or E(T) > εmax do
5.
identify highest-priority T in Qs
6.
split(T)
7.
remove T and other split triangles from Qs
8.
add any new triangles in T to Qs
9.
end while
Algorithm 2.1: Pseudo code for split queue
A second priority queue, that is, merge queue (Qm) contains the priorities for all mergeable diamonds in the current triangulation. The priority for a mergeable diamond (T, TB) is defined as the maximum priority, mp = max{pf(T),pf(TB)} of the individual triangles. The detailed algorithm of merge queue is listed in Algorithm 2.2. The Smax(T) denotes the maximum split priority and Mmin(T) is defined as the minimum merge priority. In general, this algorithm is done by computing the minimum number of split and merge operations. It exploits coherence between the consecutive frames to reduce the time to calculate and generate triangles for next frame.
42
Input: (i)
A base triangulation (T)
(ii)
An empty priority split queue (Qs) and merge queue (Qm)
(iii)
Maximum number of triangles (Nmax)
(iv)
Maximum error (εmax)
Output:
An optimal triangulation for all frames
Pseudo code: 1.
for all frames f do
2.
if f = 0 then do
3.
compute priorities for T’s triangles and diamonds
4.
insert them into Qs and Qm respectively
5.
else
6.
let T = Tf-1
7.
update the priorities for all elements of Qs and Qm
8.
end if
9.
while |T| > Nmax or E(T) > εmax or Smax(T) > Mmin(T) do
10.
if |T| > Nmax or E(T) < εmax then do
11.
identify the lowest-priority pair (T,TB) in Qm
12.
merge(T,TB)
13.
remove the merged children from Qs
14.
add the merged parents T and TB to Qs
15.
remove (T,TB) from Qm
16.
add all newly mergeable diamonds to Qm
17.
else
18.
identify highest-priority T in Qs
19.
split(T)
20.
remove T and other split triangles from Qs
21.
add any new triangles in T to Qs
22.
remove any diamonds whose children were split from Qm
23.
add all newly mergeable diamonds to Qm
24.
end if
25.
end while
26.
set Tf = T
27.
end for
Algorithm 2.2: Pseudo code for merge queue
43 2.4.3.2 Real-time Generation of Continuous LOD for Height Fields
Röttger et al. (1998) have developed a continuous terrain rendering algorithm that extends the previous work done by Lindstrom et al. (1996). This algorithm uses top-down strategy in order to simplify the terrain data. The hierarchical quadtree data structure has been adopted. This structure is a tree where each node has either zero or four children where nodes with zero children are the leaf nodes. In order to represent the quadtree structure, a numeric matrix of size W x H is used where W is the width of terrain and H is the height. This matrix is called the quadtree matrix. Each node in the tree corresponds to one value in the quadtree matrix, which indicates if the node should be subdivided or not. A value of zero represents a leaf node and a value other than zero represents a parent node with four children. Figure 2.24 shows the matrix representation of the quadtree. The arrows indicate the parentchild relations in the quadtree.
(a)
(b)
Figure 2.24 A sample triangulation of a 9 x 9 height field a) quadtree matrix, b) the corresponding quadtree structure
This algorithm also dealt with mesh discontinuities (cracks) between the adjacent levels of the quadtree by skipping the center vertex of the higher resolution edge. To simplify this solution, Röttger et al. (1998) implemented a bottom-up
44 process from the smallest existing block to guarantee that the level difference between adjacent blocks did not exceed 1.
In order to generate the triangulation, they introduced a new error metric that took into consideration the distance from the viewer and the roughness of the terrain in world space. The formula is as follows: f =
l d × C × MAX (c × d 2,1)
(2.2)
Here, l is the distance to the viewpoint, d is the edge length of a quadtree block, C is a minimum global resolution (a value of 8 was found to provide good visual results) and c specifies the desired global resolution that can be adjusted per frame to maintain a fixed frame rate. The quantity d2 incorporates the surface roughness criteria by representing the largest error delta value at six points in the quadtree: the four edge midpoints and the two diagonal midpoints. An upper bound on this component is computed by taking the maximum of these six absolute delta values (Figure 2.25). This criterion is used to decide the subdivision process. If the value of f is less than one, the subdivision is done to produce the children nodes. Otherwise, the process is stopped.
Figure 2.25 Measuring surface roughness
45 2.4.3.3 View-Dependent Progressive Meshes
Hoppe (1998) from Microsoft Research developed view-dependent progressive meshes (VDPM) technique. It provides a TIN-based framework. In general, the terrain model is divided into several blocks and then recursively simplifying and merging the blocks. Out-of-core algorithm has been implemented in his system through the Windows API, VirtualAlloc() and VirtualFree(). The core operations in VDPM are the vertex split and edge collapse.
The vertex split is parameterized as vsplit(vu, vs, vt, fl, fr, fn0, fn1, fn3, fn4) and edge collapse is parameterized as ecol(vu, vs, vt, fl, fr, fn0, fn1, fn3, fn4). As shown in Figure 2.26, the vertex split replaces a vertex vu by two other vertices vs and vt. Two new triangle faces are introduced in this operation, fl = (vl, vs, vt) and fr = (vs, vr, vt), between two pairs of neighboring faces (fn0, fn1) and (fn3, fn4). The edge collapse applies the inverse operation. Two vertices vs and vt are merged into a single vertex vu. The two faces fl and fr vanish in this process. Meshes with boundary are supported by letting the face neighbors fn0, fn1, fn3 and fn4 representing special nil values. A vertex split with fn3 = fn4 = nil creates only a single face fl.
Figure 2.26 Vertex split and edge collapse operations
Cracks between adjacent blocks are handled by not allowing simplification of those vertices that lie on a block boundary. This restriction will produce larger triangle counts. However, Hoppe (1998) performed a pre-process in which blocks
46 were hierarchically merged and then resimplified at each step so that the actual polygon increase was small (Figure 2.27). Error metric that being used in VDPM is:
δ v > k (v − e ) • e where k = 2τ tan
φ 2
,
(2.3)
δ v is the neighborhood’s residual error (i.e. the vertex’s delta
value), e is the current viewpoint, e is the viewing direction, v is the vertex in world space, τ is the screen space error threshold and φ is the field of view (FOV) angle.
Figure 2.27 Steps in pre-processing block-based simplification
Hoppe (1998) has developed an algorithm that incrementally adapts a mesh for selective refinement. The vertex front (leaf nodes) is stored as a list of active vertices together with a list of all active triangles. The vertex list is traversed before each frame is rendered and a decision is made for each vertex whether to leave it as it is, split it or collapse it. A query function (qrefine) determines whether a vertex (v) should be split based on the current view parameters. It returns false either if v is outside the view frustum, if it is oriented away from the observer or if a screen-space geometric error is below a given tolerance. Otherwise, it returns true. The algorithm for selective refinement is listed in Algorithm 2.3.
47 Input:
A set of active vertices (V) in a VDPM
Output:
A refined triangulation
Pseudo code: 1. 2. 3. 4. 5.
for each v
∈ V do
if v has children and qrefine(v) then do force vsplit(v) else if v has a parent and edge collapse is legal for v.parent and not qrefine(v.parent) then do
6. 7. 8. 9.
ecol(v.parent) end if end if end for
Algorithm 2.3: Pseudo code for selective refinement
Algorithm 2.3 checks each vertex and splits if necessary. If qrefine(v) evaluates to true, the vertex v should be split. If the preconditions for splitting v are not fulfilled, a sequence of other vertex splits is performed in order for vsplit(v) to become legal. This is performed by Algorithm 2.4 as listed below. If either v has no children or qrefine(v) returns false, v is checked for a parent. If v has a parent and the edge collapse of v and its sibling is legal, the edge collapse is performed if qrefine returns false for the parent of v.
Algorithm 2.4 keeps all vertices that have to be split in a stack. The parent of each vertex (v) in the stack is pushed onto the stack if v is not active. If v is active and vsplit(v) is legal, then v is split. This is repeated until the original vertex is split.
48
Input:
A vertex v in a VDPM
Output:
A refined triangulation
Pseudo code: 1.
insert v into stack
2.
while v is equal to stack.pop() do if v has children and v.fl ∈ F then do
3. 4.
stack.pop()
5.
else if v ∉ V then do
6. 7.
stack.push(v.parent)
8.
else
9.
if vsplit(v) is legal then do
10.
stack.pop()
11.
vsplit(v)
12.
else
13.
for each of i, i=0,1,2,3 do if v.fi ∉ F then do
14.
stack.push(v.fni.parent)
15. 16.
end if
17. 18. 19.
end for end if end if
20.
end if
21.
end while
Algorithm 2.4: Pseudo code for force vsplit
2.4.3.4 Out-of-Core Terrain Visualization
Lindstrom and Pascucci (2001) have presented a new terrain LOD approach that is memory efficient and independent of the particular error metric used. Different from the previous work done by Lindstrom et al. (1996), they used topdown approach rather than bottom-up strategy. Out-of-core view-dependent refinement of large terrain surfaces has been performed via mmap() function which is handled by operating system. This algorithm builds the terrain in a unique way compared to the other algorithms described earlier. Instead of formatting the data as
49 a tree and simply traversing the tree for rendering, the terrain is built into a single long triangle strip.
In order to build the triangle strip effectively, the actual vertex data is stored in interleaved quadtrees. Each vertex is labeled as white if it is added to the triangle strip at an odd level of refinement or black if added at an even level. The sequence of white vertices forms a white quadtree and the black vertices form a black quadtree. Figure 2.28 shows the first three levels of the white quadtree (top) and the black quadtree (bottom).
Figure 2.28 Interleaved quadtree structure
The refinement algorithm recursively subdivided each triangle using longestedge bisection (other terms are bintree or restricted quadtree triangulation) as depicted in Figure 2.29. It guarantees that a continuous is formed with no cracks by enforcing the nesting of error metric terms and hence implicitly forcing parent vertices in the hierarchy to be introduced before their children. Nested spheres have been used in order to handle this situation.
50
Figure 2.29 Four levels of longest-edge bisection operation
There are three main procedures have been developed for generating the triangulation: mesh refinement, sub mesh refinement and triangle stripping. Pseudo codes for those procedures are listed in Algorithm 2.5, Algorithm 2.6 and Algorithm 2.7 respectively. The refinement procedure builds a generalized triangle strip V = (v0, v1, v2, …, vn) that is represented as sequence of vertex indices. The outermost procedure mesh-refine starts with a base mesh of four triangles and calls submeshrefine once for each triangle. Here ic is the vertex at the center of the grid, {isw, ise, ine, inw} are the four grid corners and {in, ie, is, iw} are the vertices introduced in the first refinement step. The triangle strip is initialized with two copies of the same vertex to allow the condition on line 1 in trianglestrip-append to be evaluated. The first vertex, v0, is then discarded after the triangle strip has been constructed.
The procedure submesh-refine corresponds to the innermost recursive traversal of the mesh hierarchy, where cl and cr are the two child vertices of the parent, j. This procedure is always called recursively with j as the new parent vertex and the condition on the line 1 is subsequently evaluated twice, once in each subtree. It is done because the evaluation constitutes a significant fraction of the overall refinement time so that it is more efficient to move it one level up in the recursion, thereby evaluating it only once and then conditionally making the recursive calls.
A vertex (v) is appended to the strip using the procedure trianglestripappend. Line 5 is used to “turn corners” in the triangulation by effectively swapping the two most recent vertices, which results in a degenerate triangle that is discarded by the graphics system. Swapping is done in order to ensure that the parity (whether a vertex is on an even or odd refinement level) is alternating, which is necessary to
51 form a valid triangle mesh. To this end, the two-state variable parity(V) records the parity of the last vertex in V.
Input:
(i)
A triangle strip (V)
(ii)
Number of refinement levels (n)
Output:
An optimal triangulation
Pseudo code: 1.
parity(V) = 0
2.
V = (isw, isw)
3.
submesh-refine(V, ic, is, n)
4.
trianglestrip-append(V, ise, 1)
5.
submesh-refine(V, ic, ie, n)
6.
trianglestrip-append(V, ine, 1)
7.
submesh-refine(V, ic, in, n)
8.
trianglestrip-append(V, inw, 1)
9.
submesh-refine(V, ic, iw, n)
10.
V = (V, isw)
Algorithm 2.5: Pseudo code for mesh refinement (mesh-refine)
Input:
(i)
A triangle strip (V)
(ii)
Directed edge (i, j) where i is a vertex at the apex of the triangle and j is a midpoint of triangle’s hypotenuse
(iii) Output:
Level of interleaved quadtree (l) An optimal triangulation
Pseudo code: 1.
if l > 0 and active(i) then do
2.
submesh-refine(V, j, cl(i,j), l-1)
3.
trianglestrip-append(V, i, l mod 2)
4.
submesh-refine(V, j, cr(i,j), l-1)
5.
end if
Algorithm 2.6: Pseudo code for sub mesh refinement (submesh-refine)
52 Input:
(i)
A triangle strip (V)
(ii)
Vertex (v)
(iii)
Parity of a vertex (p)
Output:
List of triangle strips
Pseudo code: 1. 2. 3. 4. 5.
if v is not equal to vn-1 and vn then do if p is not equal to parity(V) then do parity(V) = p else V = (V, vn-1)
6.
end if
7.
V = (V, v)
8.
end if
Algorithm 2.7: Pseudo code for generating triangle strips (trianglestrip-append)
2.4.3.5 Comparative Studies
Ögren (2000) has developed the ROAM algorithm with some modification and then compared the result with VDPM technique. According to him, ROAM has shown to generate a triangle mesh faster than VDPM due to geomorphing process. Besides that, ROAM is capable to avoid slivers (thin) triangles automatically, while VDPM needs extra computations to guarantee their absence.
Youbing et al. (2001) have pointed out that VDPM demands too much storage and suffered from many constraints due to its lack of generality. Though it can produce a triangle mesh with far less triangle than regular grid, it spends too much time on optimization (complex calculations are needed).
53 Bradley (2003) has developed three terrain rendering algorithms which are ROAM (Duchaineau et al., 1997), Real-time Generation of Continuous LOD (Röttger et al., 1998) and out-of-core terrain visualization (Lindstrom and Pascucci, 2001). The evaluation has been measured depending on several criteria. The summary of the comparison is displayed in the Table 2.4 below:
Table 2.4: Comparison of view-dependent LOD techniques Criteria
Duchaineau et al.
Röttger et al.
Lindstrom and
(1997)
(1998)
Pascucci (2001)
Frame rate (fps)
Low
Medium
High
Polygon count
Fewest triangles
Few triangles
Fewer triangles
generated
generated
generated
Produce optimal
Produce nearly
Low
meshes
optimal meshes
Flat area handling
Low
High
High
Polygon
Independent
Triangle fan
Triangle strip
tessellation
triangle
Implementation
Moderate because
Easy (based on
Difficult because
complexity
it involves the dual
quadtree
there are many
queue
decomposition)
complex
Terrain accuracy
maintenance.
algorithms (error metrics) need to be done
2.5
Summary
There are four well-known hierarchical-based spatial data structures can be used to organize data, which are Kd-tree, quadtree, R-tree and tiled block. Each technique has its strengths and weaknesses depending on its complexity to implement, memory management and computation time. Among of them tiled block
54 is the simplest data structure and capable to provide fast data retrieval as well as dynamic data loading with simple indexing scheme.
Visibility culling method is used to remove the unneeded data from being processed. Backface, small feature, occlusion and view frustum culling are examples of culling methods. Based on the comparison that has been made, the research focuses on view frustum culling due to its potential to remove lots of polygons, which are outside the viewing volume and it is suitable for real-time visualization and navigation system. In testing the intersection between view frustum and the desired object, there are four techniques can be adopted, which are Axis-Aligned Bounding Box (AABB), Oriented Bounding Box (OBB), Bounding Sphere (BS) and k-Discrete Orientation Polytope (k-DOP). BS has better characteristic compared to the other techniques due to its simplicity, fast computation and capability to handle various types of objects efficiently.
View-dependent LOD technique is developed in order to reduce the number of polygons for a scene and give details to the desired area continuously in real-time. Terrain can be represented as regular grid or TIN approach. Regular grid is easy to implement and integrate with other optimization techniques compared to complex operations in TIN. In general, the terrain surfaces can be generated by using three types of geometric primitives: independent triangles, triangle fans and triangle strips. According the comparison that has been done, the triangle fans can be implemented easily without requiring a complex indexing mechanism. The examples of viewdependent LOD techniques are ROAM (Duchaineau et al., 1998), Continuous LOD (Röttger et al., 1998), VDPM (Hoppe, 1998) and Out-of-core terrain visualization (Lindstrom and Pascucci, 2001). Due to its simplicity and capability to give details on certain terrain region, Röttger’s algorithm has been chosen to integrate with the data structure, dynamic data loading and culling method that have been designed and proposed in this research.
CHAPTER 3
METHODOLOGY
3.1
Introduction
The algorithm that is based on hybrid method has been proposed as a foundation in solving the problems in this research. It is integration of overlapping tile data structure, dynamic load scheme, view frustum culling and triangle-based LOD technique. In general, the system has two main phases: pre-processing and runtime processing. Each of these phases is implemented as a separate subsystem. As shown in Figure 3.1, there are four main steps involved in developing an effective terrain visualization and navigation system. Each step represents the objective need to be achieved in this research.
In fact, the proposed algorithm can be used to organize and visualize different formats of terrain datasets. These include procedural data, which is generated using algorithm and data obtained from real world. Generally, terrain data is represented in the form of grid, vector, raster or image. In order to use the data within the proposed algorithm, the structure of data format need to be studied, so that the important information such as elevation profiles can be retrieved and processed easily. Due to this research is focusing on GIS field, it is appropriate to use the data that is taken from real world as testing data.
56
STEP 1: Partition terrain data Extract data
PHASE 1: Pre-Processing
Split data into tiles
STEP 2: Load terrain tiles Identify tile index of current camera position Determine tiles to be loaded
STEP 3: Cull invisible terrain tiles Extract frustum’s planes
Test intersection between view frustum and tiles
STEP 4: Simplify geometry of visible terrain tiles Calculate distance between the viewpoint and the center of current node in quadtree
Refine node
Generate triangle fans
Figure 3.1 Research framework
PHASE 2: Run-time Processing
57 In this research, a standard digital elevation model (DEM) provided by United States Geological Survey (USGS, 1992) is used as a raw terrain data because the file data format is well-documented, so that it will facilitate the conversation process of DEM data into proposed data structure; and it provides large amount of real terrain data with different terrain size. This data is based on regular grid representation and in the form of ASCII data format. Besides that, it encloses Arizona area which uses Universal Transverse Mercator (UTM) coordinate system with 10-meter x 10-meter data spacing between each elevation data. A DEM consists of three data records named Record A, Record B and Record C. Record A contains the header information of terrain data; Record B contains the elevation profiles; and Record C contains the statistic on the accuracy of the data.
In pre-processing, the conversion of raw data into proposed data structure is done by partitioning the terrain data into small tiles. Firstly, a DEM data is read to determine the location of Record A, Record B and Record C. Then, the important information are extracted and divided into two parts: general information and elevation profiles. According to the general information, the elevation profiles are split into small data that is based on tile approach. Finally, these data are stored into database.
In run-time processing, there are three steps need to be made in order to develop a continuous real-time terrain visualization. The dynamic load management is applied in the research where only several terrain tiles are selected and loaded into main memory based on current camera position. The purpose of this step is to reduce memory usage to store data as well as to provide fast data loading. Then, the loaded tiles are tested with the viewing volume (view frustum) for removing the unseen tiles. The final step is to reduce the geometry of visible terrain tiles before transferring the data for rendering process. The steps in run-time processing are repeated and updated if there is any change of camera position or orientation within the scene.
58 3.2
Partitioning Terrain Data
The main purpose of this step is to transform raw terrain data (DEM) to the proposed data structure, which works as an internal representation for the system. This is done in pre-processing phase. In order to store terrain data into data structure, spatial data retrieval based on hierarchical method is employed. For this research, the overlapping tile technique as implemented by Pajarola (1998) has been chosen due to the fact that it is simple and easy to implement. The difference between the Pajarola’s technique and the proposed technique is on how the elevation data are stored. In Pajarola’s technique, the elevation data are stored in a single file. The data are retrieved using complex searching algorithm, thus wasting time to find the exact data. While the proposed technique stores the elevation data into several files with simple indexing scheme that is assigned to the filename. Each file stores the elevation data for one tile. Actually, this step is useful for rapidly accessing data during run-time process. At the same time, the proposed technique attempts to develop an algorithm that is able to support arbitrary size and shape of terrain model. This step contains two sequential processes: extract data and split data into tiles, which are covered in details in the next subsections.
3.2.1
Extracting Data
The process is divided into two parts: the extraction of general information and the extraction of elevation profiles. General information is obtained by reading Record A in DEM data format which contains header information about the related DEM data. The important parameters are extracted from this record. These include ground coordinates for the corners; minimum and maximum elevation values; and column and row data. The ground coordinates consist of four control points (Northwest, Northeast, Southwest and Southeast) work as the boundaries of data. The minimum and maximum elevation values are the range of z coordinates to represent the terrain height. Those are useful for normalizing the elevation values in certain extent. The column and row data are the number of data points or vertices for
59 determining the terrain size in vertical and horizontal directions respectively. All the information are stored into database in the form of flat text files.
Then, the elevation profiles are read one by one from Record B according to the general information obtained before. An index for each elevation data is created based on one-dimensional array. This means the index value will be in the range of 0 to [(2n+1) x (2n+1)-1]. This approach is applied instead of using two-dimensional array in order to reduce the memory usage for holding data when running the program especially for very large dataset. Each elevation data and its related index are stored in another text file. Information in Record C is ignored because there is no important information can be used for this research.
3.2.2 Splitting Data into Tiles
This process is the core component of the pre-processing phase. In this research, the overlapping tile technique is adopted due to its simplicity and indexing efficiency. However, the terrain data must be in the size of (2n+1) for both vertical and horizontal directions (Duchaineau et al., 1997; Röttger et al., 1998; Pajarola, 1998; Lindstrom and Pascucci, 2001; Kim and Wohn, 2003).
Firstly, the terrain size needs to be determined in order to ensure the size conform the above rule. There are two suggested steps: (i)
Find the maximum number of vertices per side for terrain data (Vmax).
(ii)
Assign an appropriate power-of-two plus one (2n+1) value to the Vmax.
The first step can be done by comparing the number of vertices for vertical direction (Vv) with the number of vertices for horizontal direction (Vh). In order to ensure that Vmax must be in the size of (2n+1), the second step is required, which the new value is assigned to the Vmax by detecting the range of Vmax obtained from the first step.
60 After calculating and obtaining the new number of vertices per side (Vmax) for terrain data, it is necessary to specify manually the tile size per side (number of vertices per side for a tile). Choosing a proper tile size depends on data density, CPU speed and available memory. Hence, the size must not too small or too big for the efficiency purpose (Peng et al., 2004). The tile size per side (Vt) must also be in the size of (2n+1). The Vmax and Vt are used to calculate the number of generated tiles per side. Number of tiles per side =
Vmax − 1 Vt − 1
(3.1)
Then, the starting point for each tile is determined by computing the index of terrain vertices. The calculation is made column-by-column beginning from left column and the tile is read from bottom to up. For this reason, Vmax and Vt are required to calculate the number of tiles’ vertices per column for obtaining the starting point of each lowest tile in the vertical direction. The formula is:
Number of tiles ' vertices per column = Vmax × (Vt − 1)
(3.2)
At the same time, a test is made to check the existence status for each tile. This is done because when the terrain size is expanded to the (2n+1) x (2n+1), the possibility to generate non-existing tiles (‘dummy’ tiles) is high (Lindstrom and Pascucci, 2001). The purpose of this step is to reduce the amount of hard disk storage to be used after creating files for tiles. This can be made by not storing the unnecessary tiles (non-existing tiles). Figure 3.2 shows the related calculation involves in implementing the overlapping tile technique.
The maximum number of vertices per side of existing tiles for both vertical (column) and horizontal (row) direction are needed before each tile is assigned with a flag value. The existing tiles are assigned with 1 (true flag), while the non-existing tiles are assigned with 0 (false flag).
61 After gaining all basic requirements, the elevation values are read from the output text file created before by searching and comparing the starting point for each existing tiles with the index from the output file. Subsequently, the normalization of elevation data is made for each existing tiles. Thus, the elevation values will be in the range of 0 to 255 for facilitating the computation for the run-time process. The minimum and maximum elevation values from the general information are required for this computation. The formula is: Elevation values after normalization
=
(Elevation values − Minimum Elevation )
(Maximum Elevation − Minimum Elevation )
× 255
(3.3)
Each tile’s starting coordinate (based on column and row location) and elevation values are stored in different output file (*.tile file). This approach is used in order to achieve fast searching and retrieving of terrain tiles rather than using single output file with complicated searching mechanism that will slow down the whole system (Lindstrom et al., 1997; Pajarola, 1998).
62
Figure 3.2 Overlapping tile
63 3.3
Loading Terrain Tiles
The idea behind this step is to load only several terrain tiles instead of loading the whole data. This can reduce the amount of data to be stored in main memory. The tiles to be loaded only depend on current camera position. The total number of tiles will be loaded are M x M where M refers to the number of tiles per side that manually set for a scene. There are two steps need to be followed: (i)
Identify the tile index corresponding to the current camera position.
(ii)
Determine the tiles to be loaded.
The first step can be done by testing the current camera coordinate with the bounding square of corresponding tile. After obtaining the desired tile index, the indices for M x M tiles to be loaded are determined beginning from the lowest-left side.
After that, tile indices are compared with the name of text files created in preprocessing, which the elevation values are stored. Then, M x M tiles can be loaded into main memory. When the camera moves to the other tile, the processes are repeated. Several old tiles are discarded from main memory and remainders of them are retained. The new tiles are loaded to replace the discarded tiles. Time for loading data can be reduced with this approach. Figure 3.3 illustrates this updating process.
Figure 3.3 Dynamic load management
64 3.4
Culling Invisible Terrain Tiles
View frustum culling technique is utilized to remove the unseen terrain tiles depending on viewing volume and therefore reduce polygons to be computed in the next step. This technique involves two main operations, which are plane extraction and intersection test.
3.4.1
Plane Extraction
View frustum consists of six planes: left, right, top, bottom, near and far as shown in Figure 3.4. Each plane has its own plane equation. General plane equation is:
Ax + By + Cz + D = 0
Figure 3.4 Six planes of view frustum
(3.4)
65 The co-efficients, A, B, C and D need to be defined in order to complete the frustum’s plane equation. This involves three steps: (i)
Get the clipping matrix.
(ii)
Extract the plane.
(iii)
Normalize the plane.
In order to obtain the clipping matrix (Cl), the multiplication of the model view matrix (M) and the projection matrix (P) need to be calculated as indicated below:
Cl = M × P
⎡ M 11 ⎢M Cl = ⎢ 21 ⎢ M 31 ⎢ ⎣ M 41
M 12 M 22
M 13 M 23
M 32
M 33
M 42
M 43
⎡Cl11 ⎢Cl Cl = ⎢ 21 ⎢Cl 31 ⎢ ⎣Cl 41
Cl12
Cl13
Cl 22
Cl 23
Cl 32 Cl 42
Cl 33 Cl 43
M 14 ⎤ ⎡ P11 M 24 ⎥⎥ ⎢⎢ P21 × M 34 ⎥ ⎢ P31 ⎥ ⎢ M 44 ⎦ ⎣ P41
Cl14 ⎤ Cl 24 ⎥⎥ Cl 34 ⎥ ⎥ Cl 44 ⎦
P12 P22
P13 P23
P32
P33
P42
P43
P14 ⎤ P24 ⎥⎥ P34 ⎥ ⎥ P44 ⎦
(3.5)
Plane extraction can be made by obtaining the co-efficients, A, B, C and D in plane equation. Gribb and Hartmann (2001) have done the extraction of view frustum’s planes and the coefficients for the plane equation are listed in Table 3.1.
66
Table 3.1: Clipping planes with corresponding co-efficients Clipping plane
Left
Coefficients for the plane equation
A = Cl41 + Cl11 B = Cl42 + Cl12 C = Cl43 + Cl13 D = Cl44 + Cl14
Right
A = Cl41 - Cl11 B = Cl42 - Cl12 C = Cl43 - Cl13 D = Cl44 - Cl14
Bottom
A = Cl41 + Cl21 B = Cl42 + Cl22 C = Cl43 + Cl23 D = Cl44 + Cl24
Top
A = Cl41 - Cl21 B = Cl42 - Cl22 C = Cl43 - Cl23 D = Cl44 - Cl24
Near
A = Cl41 + Cl31 B = Cl42 + Cl32 C = Cl43 + Cl33 D = Cl44 + Cl34
Far
A = Cl41 - Cl31 B = Cl42 - Cl32 C = Cl43 - Cl33 D = Cl44 - Cl34
67 Thus, the plane equations for each frustum’s plane are: Cl L = (Cl 41 + Cl11 )x + (Cl 42 + Cl12 ) y + (Cl 43 + Cl13 ) + (Cl 44 + Cl14 )
(3.6)
Cl R = (Cl 41 − Cl11 )x + (Cl 42 − Cl12 ) y + (Cl 43 − Cl13 ) + (Cl 44 − Cl14 )
(3.7)
Cl B = (Cl 41 + Cl 21 )x + (Cl 42 + Cl 22 ) y + (Cl 43 + Cl 23 ) + (Cl 44 + Cl 24 )
(3.8)
ClT = (Cl 41 − Cl 21 )x + (Cl 42 − Cl 22 ) y + (Cl 43 − Cl 23 ) + (Cl 44 − Cl 24 )
(3.9)
Cl N = (Cl 41 + Cl 31 )x + (Cl 42 + Cl 32 ) y + (Cl 43 + Cl 33 ) + (Cl 44 + Cl 34 )
(3.10)
Cl F = (Cl 41 − Cl 31 )x + (Cl 42 − Cl 32 ) y + (Cl 43 − Cl33 ) + (Cl 44 − Cl 34 )
(3.11)
After that, all plane equations need to be normalized. Normalizing a plane equation, Ax + By + Cz + D = 0 means to change the plane equation to become a unit vector. The calculation for normalizing process is to divide each of its components by the magnitude of the vector. The formula is: Ax + By + Cz + D A2 + B 2 + C 2
3.4.2
=0
(3.12)
Intersection Test
Intersection test is done in order to check the visibility status of terrain tiles has been loaded. In this research, plane-sphere intersection test technique has been selected. The key factor of this selection is due to its simplicity and fast computation capability as mentioned in Section 2.5.2.5. Each frustum’s plane is tested with bounding spheres that represent terrain tiles (Figure 3.5).
Each terrain tile is assigned with particular flag: ALL-OUTSIDE, ALLINSIDE or INTERSECT. This can be done by calculating the distance between plane and center of related bounding sphere. The terrain tiles with the status ALLINSIDE or INTERSECT will go to the next step. Otherwise, the terrain tiles are deleted from being processed for the next step.
68
(a)
(b)
(c) Figure 3.5 Plane-sphere intersection test for view frustum culling technique a)
sample scene, b) intersection test, c) result after culling
3.5
Simplifying Geometry of Visible Terrain Tiles
View-dependent triangle-based LOD technique is used to simplify the polygons of visible terrain tiles. The Röttger’s algorithm is chosen due to its simplicity to divide the space for a scene and capability to reduce lots of polygons per frame as well as preserving the quality of visual appearance (Röttger et al., 1998; Kim and Wohn, 2003). Hierarchical quadtree with top-down approach is a core of this technique. The important steps in developing hierarchical quadtree are described in the next subsections.
69 3.5.1
Distance Calculation
The distance between the center of node and the viewpoint are calculated using L1-Norm representation. It is a faster version of the distance formula and linear rather than quadratic like L2-Norm (Polack, 2003). The L1-Norm distance calculation equation is: l = x 2 − x1 + y 2 − y1 + z 2 − z1
(3.13)
where l is the distance parameter. Figure 3.6 illustrates the related distance in general.
Figure 3.6 Distance (l) and edge length (d)
3.5.2 Subdivision Test
Subdivision test is needed to refine the mesh at the optimal triangulation. The decision variable, f is computed based on Equation 2.2. This variable is used to decide whether to subdivide a node or not.
70 3.5.3
Generation of Triangle Fans
The main elements in generating triangle fans are the center of the terrain block (node) and the order of the fan. The test is essential for determining what kind of triangle fan (full or partial) is used for triangulation.
Firstly, the node is checked whether it is the highest LOD. If it is and the adjacent nodes are at the same LOD, the full triangle fan can be generated. If the adjacent nodes are at the lower LOD, skip the vertex on that side of the fan that shared edge (Figure 3.7). This way automatically eliminates the cracks that can be occurred in the boundaries of the terrain blocks. If the node is not the highest LOD, the special calculation needs to be made for adapting the current triangle mesh with the adjacent triangulations. The sample output after this step is shown in Figure 3.8.
Figure 3.7 Generation of triangle fans
71
Triangles of a tile that have been simplified
Camera’s viewing volume
Figure 3.8 Terrain tiles after applying view-dependent LOD technique
3.6
Summary
Research methodology has been discussed in details in this chapter. The proposed algorithm which is based on hybrid method has been designed. There are two main phases involved: pre-processing and run-time processing with four important steps. Spatial data structure that is based on overlapping tile has been designed and adopted in order to convert standard USGS DEM data into tiles and then store them into database (text files). This is done in pre-processing phase.
During run-time process, dynamic load management is employed for minimizing main memory usage and therefore, providing fast data loading for the proposed system. View frustum culling that is based on plane- sphere intersection test is used for deleting the unseen terrain tiles whereas view-dependent LOD that is based on Röttger’s algorithm is used to reduce the geometric complexity of visible terrain tiles. The integration of all techniques is necessary for providing an effective real-time rendering system for the implementation of prototype system.
CHAPTER 4
IMPLEMENTATION
4.1
Introduction
A prototype has been developed in order to test the efficiency of the proposed technique. This chapter is divided into two parts: pre-processing and run-time processing. In general, the first part works in converting the original terrain data format (DEM) to the specific data structure, while the second part is used for realtime rendering and visualization. This research was implemented using Microsoft Visual C++ 6.0 in Windows environment.
For pre-processing, the simple program was developed under Win32 console application. For run-time processing, the graphics library, OpenGL has been used to assist the rendering of terrain model. The reasons of using this library are due to its simplicity, capability of improving rendering speed using available graphics processing hardware and platform independence compared to Microsoft DirectX (Hawkins and Astle, 2002).
73 4.2
Pre-Processing
Original USGS DEM data was used to extract the important parameters and then store them into internal representation that is based on overlapping tile technique. There are two pairs of steps exploited sequentially for completing the pre-processing part: (i)
Read a DEM file and create TXT files.
(ii)
Read TXT files and create TILE files.
In order to facilitate those steps, a simple menu has been created in the program as shown in Figure 4.1.
Figure 4.1 Menu for partitioning DEM data
4.2.1
Reading a DEM File and Creating TXT Files
An original USGS DEM file (*.dem) is read depending on its file format as written in National Mapping Program Technical Instructions (USGS, 1992). This ASCII data format can be viewed in any text editor. Figure 4.2 illustrates an example of DEM file of Adams Mesa area which consists of Record A (header
74 information), Record B (elevation profiles) and Record C (statistic of accuracy of the data). Record C was ignored because there is no important information can be used for the implementation phase. For more detailed information about Record A and Record B of DEM data, please refer to Appendix A and Appendix B.
Figure 4.2 Structure of a DEM file
Firstly, the data structure was constructed in order to define the input fields for holding DEM information. The variables with the corresponding data types for defining the data structure are listed in Table 4.1. The first sixteen variables came directly from the DEM file, while the remaining variables were used to compute and store related information that is not provided in DEM file. Besides that, the declaration of variables for file pointers was made for reading existing DEM file and creating new output text files.
75 Table 4.1: Data structure No
Data Type Name of variable
Description
1
char
cMapLabel[145]
DEM quadrangle name
2
int
iDEMLevel
DEM level code
3
int
iElevationPattern
Elevation pattern
4
int
iGroundSystem
Ground planimetric reference system
5
int
iGroundZone
Zone in ground planimetric reference system
6
double
dProjectParams[15]
Parameters for various projections
7
int
iPlaneUnitOfMeasure
Unit of measurement for ground plani-metric reference system
8
int
iElevUnitOfMeasure
Unit of measurement for elevation coordinates throughout the file
9
int
iPolygonSizes
Number of sides in the polygon, which defines the coverage of the DEM file
10
double
dGroundCoords[4][2]
Ground coordinates for all four corners (SW, NW, NE and SE)
11
double
dElevBounds[2]
Minimum and maximum elevation for the DEM
12
double
dLocalRotation
Counterclockwise angle in radians
13
int
iAccuracyCode
Accuracy code for elevations
14
double
dSpatialResolution[3]
DEM spatial resolution for x, y and z
15
int
iProfileDimension[2]
Number of rows and columns of profiles in the DEM
76
16
float
fElevation[]
Temporary variable for storing elevation values per column data
17
18
double
double
dEastMost
Furthest east/west easting
dWestMost
value
dSouthMost
Furthest south/north northing
dNorthMost
value
19
int
iEastMostSample
Furthest east sample point
20
int
iWestMostSample
Furthest west sample point
21
int
iSouthMostSample
Furthest south sample point
22
int
iNorthMostSample
Furthest north sample point
23
int
iRows
Regular elevation grid
iColumns
dimensions
fDEMFile
File pointers
24
FILE*
fOutputHeader fOutputProfiles
Before reading a DEM file, all variables in data structure must be initialized based on the corresponding data types. After that, the DEM data was read starting with Record A. Each parameter in Record A was stored in its matching variable. Then, according to the header information, the comparisons were made among the four corners of ground coordinates (SW, NW, NE and SE) to obtain the furthest east/west easting value and furthest south/north northing value. This step was done because most of the DEM data is not originally in the form of square or rectangle and therefore it is important to detect where the starting data point needs to be read (Figure 4.3).
77
(a)
(b) Figure 4.3 First data point for DEM data a) West of the central meridian b) East of the central meridian
78 Then, the calculation was made in order to obtain number of vertices for column and row directions. All these information were stored in output text file named “OutputHeader.txt” (Figure 4.4).
Figure 4.4 Parameters after extraction of important header information
After gaining the general information about DEM data, the elevation profiles (Record B) were read column-by-column (left to right) and each data point was read from bottom to up. At the same time, TXT file for storing elevation data was created and it was named “OutputProfiles.txt”. A variable that based on floating-point array (fElevation[]) was used to store elevation data per column instead of storing the whole elevation data. This was done in order to reduce the memory usage when running the program especially when dealing with massive data. The variable stored the elevation data for current column temporarily starting from bottom to up. The index and its corresponding elevation data were written to the output text file as shown in Figure 4.5. For the next column, the new elevation data were assigned to the same variable and the other processes were repeated until the end of the elevation data.
79
Indices Elevation values
Figure 4.5 The indices and the corresponding elevation values
4.2.2
Reading TXT Files and Creating TILE Files
The output files (OutputHeader.txt and OutputProfiles.txt) that have been created before were used as input files in this step. Firstly, several variables were declared. These include the variables for holding general DEM properties and tile information as well as for reading the input files (*.txt) and creating the output files (*.tile). Table 4.2 lists the related variables for creating TILE files.
80 Table 4.2: Declaration of variables Data Type
Name of variables
Description
int
iColumns
Original number of vertices for vertical
iRows
and horizontal direction
fMinElev
Minimum/maximum elevation value for
fMaxElev
the USGS DEM
iTerrainSize
Number of vertices per side for terrain
float
int
data int
iVertTile
Number of vertices per side for a tile
int
iNumTiles
Number of tiles per side
int
iMaxColumn
Maximum number of vertices for
iMaxRow
specific column and row
int
iTilesVertPerColumn
Number of tiles’ vertices per column
int*
iPStart
Dynamic array for storing the starting point for each tile
int*
iIsExist
Dynamic array for storing the flag (0 or 1) to ensure the status of existing tiles
int
iStartingPointTile
Starting point (X, Y) of a tile
FILE*
fInputHeader
File pointers
fInputProfiles fTile
The initialization of all variables was made except the variable for storing the starting point for each tile (iPStart) and the status of existing tiles (iIsExist) because they rely on number of tiles per side (iNumTiles). The number of vertices per side for a terrain tile (iVertTile) must be assigned first because it will be used as a parameter for splitting the DEM data into small square tiles.
Then, the OutputHeader.txt was read in order to obtain the general information of DEM data. After reading and storing the DEM information into corresponding variables, the maximum number of vertices per side for terrain data (iTerrainSize) was determined which must be followed the size of (2n+1).
81 Algorithm 4.1 and Algorithm 4.2 present the pseudo codes for obtaining maximum number of vertices per side for terrain data (Vmax) as suggested in Section 3.2.2.
Subsequently, the number of tiles per side and the number of tiles’ vertices per column were calculated according to Equation 3.1 and Equation 3.2 respectively. This is crucial for identifying the starting point for each tile.
Input: (i)
Number of vertices per side for vertical direction (Vv)
(ii)
Number of vertices per side for horizontal direction (Vh)
Output:
Maximum number of vertices per side for terrain data (Vmax)
Pseudo code: 1. 2. 3. 4. 5.
if (Vv is larger than Vh)then do Vmax = Vv else Vmax = Vh end if
Algorithm 4.1: Pseudo code for obtaining maximum number of vertices per side for original terrain data
Input:
Maximum number of vertices per side for original terrain data (Vmax)
Output: New maximum number of vertices per side for terrain data (Vmax) which in the size of (2n+1) Pseudo code: 1.
initialize counter, c = 0
2.
while Vmax is not in the range of 2c+1 and 2c+1+1 do
3.
c = c + 1
4.
end while
5.
Vmax = 2c+1+1
Algorithm 4.2: Pseudo code for assigning new maximum number of vertices per side for terrain data
82 This was followed by calculating the maximum number of vertices per side for existing tiles in both vertical and horizontal direction. The detailed algorithm for determining the maximum number of vertices per side for tiles in vertical direction (Vt_v_max) is shown in Algorithm 4.3. The same algorithm was used for determining the maximum number of vertices per side for tiles in horizontal direction (Vt_h_max).
Input: (i)
Number of vertices per side for vertical direction (Vv)
(ii)
Number of vertices per side for tile (Vt)
Output:
Maximum number of vertices per side for tiles in vertical direction
(Vt_v_max) Pseudo code: 1.
initialize temporary variable, temp = 0
2.
while Vv is not in the range of temp and (temp+Vt-1) do
3.
temp = temp + (Vt - 1)
4.
end while
5.
Vt_v_max = temp + (Vt - 1)
Algorithm 4.3: Pseudo code for determining the maximum number of vertices per side for tiles in vertical direction (Vt_v_max)
Then, the two remaining variables, iPStart and iIsExist were initialized. Depending on the total number of tiles, the first dynamic array was assigned with 0 for initial value and the second dynamic array was assigned with 1, which assumes all the tiles are exist for the first time.
The next process is to identify the starting point and the existence status of each tile. To determine the starting points, the calculations as depicted in Figure 3.4 were adopted beginning from the lowest-left tile. This depends on the number of vertices per side for a tile (Vt) and the number of tiles’ vertices per column (Vt_c) to assign the right index for each tile’s starting point. At the same time, the existence status for each tile was checked one by one. The existence status (iIsExist) was assigned with 0 for representing the non-existing tile (‘dummy’ tile). Algorithm 4.4 indicates the pseudo code of related process.
83
Input: (i)
Number of vertices per side for a tile (Vt)
(ii)
Number of tiles’ vertices per column (Vt_c)
(iii)
Maximum number of vertices per side for terrain data (Vmax)
(iv)
Maximum number of vertices per side for tiles in vertical direction (Vt_v_max)
(v)
Maximum number of vertices per side for tiles in horizontal direction (Vt_h_max)
Output: (i)
Starting point for each tile (iPStart)
(ii)
Existence status for each tile (iIsExist)
Pseudo code: 1.
initialize counter, c = 0
2.
for each of i, i=0,Vt_c,…,[(Vt_h_max-1)*Vmax] do
3.
for each of j, j=0,(Vt-1),…,[(Vmax-1)-( Vt-1)] do
4.
iPStart[c] = i + j
5.
if iPStart[c] is larger than [(Vt_v_max-1)+i] and less than [(Vmax-1)+i] then do
6.
iIsExist[c] = 0
7.
end if
8.
if iPStart[c] is larger than [(Vt_h_max-1)*Vmax] then do
9.
iIsExist[c] = 0
10.
end if
11.
c = c + 1
12. 13.
end for end for
Algorithm 4.4: Pseudo code for obtaining starting point and existence status for each tile
Then, the partitioning of DEM data was done by creating the TILE files (*.tile). The starting coordinate and elevation data of a tile were stored in OutputN.tile where N refers to the number of tiles to be created as shown in Figure 4.6 and Figure 4.7. The detailed processes of partitioning DEM data are listed in Algorithm 4.5 and Algorithm 4.6.
84
Input: (i)
Number of vertices per side for a tile (Vt)
(ii)
Existence status for each tile (iIsExist)
(iii)
Starting point for each tile (iPStart)
(iv)
Maximum number of vertices per side for terrain data (Vmax)
(v)
Number of tiles per side (Nt)
Output:
TILE files (*.tile)
Pseudo code: 1. 2.
for each of c, c=0,1,…,(Nt2-1) do if iIsExist[c] is not equal to 0 then do
3.
open file: “OutputProfiles.txt”
4.
create new TILE file: “Outputc.tile”
5.
get starting coordinates of current tile
6.
store starting coordinates into “Outputc.tile”
7.
end if
8.
for each of i, i=0,Vmax,…,[Vmax * (Vt-1)] do
9.
for each of j, j=0,1,…,(Vt-1) do
10.
CalculatedIndex = iPStart[c] + i + j
11.
if iIsExist[c] is not equal to 0 then do
12.
while not end of file “OutputProfiles.txt” do
13.
read index and elevation data
14.
if CalculatedIndex is equal to index from “OutputProfiles.txt” then do
15.
normalize elevation data
16.
store elevation data into “Outputc.tile”
17.
exit loop
18.
end if
19.
end while
20. 21.
end if end for
22.
end for
23.
close file: “OutputProfiles.txt”
24.
close file: “Outputc.tile”
25.
end for
Algorithm 4.5: Pseudo code for partitioning data and creating TILE files
85
Input: (i)
Maximum number of vertices per side for terrain data (Vmax)
(ii)
Starting point for each tile (iPStart)
Output:
Starting coordinates of current tile (TSCoordx, TSCoordy)
Pseudo code: 1.
for each of i, i=0,1,…,(Vmax-1) do
2.
for each of j, j=0,1,…,(Vmax-1) do
3.
CalculatedPStart = i * Vmax + j
4.
if CalculatedPStart is equal to iPStart then do
5.
TSCoordx = i
6.
TSCoordy = j
7.
exit loop
8. 9. 10.
end if end for end for
Algorithm 4.6: Pseudo code for obtaining starting coordinates of existing tile
Figure 4.6 List of generated TILE files
86
Starting coordinates of a tile (x, y)
Elevation values after normalization
Figure 4.7 Structure in a TILE file
87 4.3
Run-time Processing
For this part, the object-oriented programming approach has been chosen and implemented. This is because it provides a systematic management of entities or objects in the form of classes, which makes an easy way for the development of this research.
4.3.1
Creation of Classes
In this research, the creation of classes can be divided into two types:
(i)
Main classes Main classes consist of terrain (CTERRAIN), quadtree (CQUADTREE) and camera (CCAMERA).
(ii)
Base classes Base classes are entities that support the main classes. They are OpenGL application (CGL_APP), mathematic operations (CVECTOR), image (CIMAGE), timer system (CTIMER) and log (CLOG).
The relationship among classes with the corresponding attributes (variables) and behaviors (functions) in C notation is depicted in Figure 4.8.
88
CLOG
CTIMER
m _s zFileNam e m _bEnabled
m _fTim e1 m _fTim e2 m _fDiffTim e m _fFPS m _iFram es Elaps ed
Init() Write() Enable() Dis able() Is Enabled()
Init() Update() GetTim e() GetFPS()
CTERRAIN m _heightData m _texture m _bTextureMapping m _iTris PerFram e m _iSize
CVECTOR m _fVec[] Trans form () Norm alize() Length() DotProduct() Cros s Product() Negate() Get() Set()
LoadDEM() UnloadDEM() GetTextureCoords () SetHeightAtPoint() GetTrueHeightAtPoint() GetNum Tris PerFram e() LoadTexture() UnloadTexture()
CIMAGE m _ucpData m _uiWidth m _uiHeight m _uiBits PerPixel m _iID m _bIs Loaded LoadData() LoadTGA() Create() Unload() GetData() GetWidth() GetHeight() GetBits PerPixel() GetID() SetID() Is Loaded()
CQUADTREE m _ucpQuadMatrix m _pCam era m _fDetailLevel m _fMinRes olution Init() Render() Update() Shutdown() PropagateRoughnes s () RefineNode() RenderNode() RenderVertex() GetMatrixIndex() SetDetailLevel() SetMinRes olution() GetQuadMatrixData()
Figure 4.8 Class diagram
CCAMERA m _vecEyePos m _vecLookAt m _vecUp m _vecForward m _vecSide m _fYaw m _fPitch m _viewFrus tum [][] Com puteViewMatrix() SetViewMatrix() CalculateViewFrus tum () SetPosition() SphereInFrus tum ()
89 4.3.2
Initialization
This process was only made once before the rendering process and need not to be updated. There are three components should be initialized. The first one is to configure the environment of OpenGL application. These include: (i)
Initiating the timer system
(ii)
Initiating the log file
(iii)
Customizing the window’s parameter
(iv)
Creating the window
(v)
Setting up the perspective view
(vi)
Initializing the movement speed and the mouse sensitivity
The timer system was used for calculating the frame rate of the system. The log file was created in order to report the status of certain processes that involve when running the program. While the parameters involved in creating the window include the window’s position, width and height. The movement speed and the mouse sensitivity were initialized for navigation purpose.
The second component is to set up the camera position and orientation (pitch and yaw) for navigation purpose. The last component is to set up the desired resolution (detail level) and minimum resolution for generating hierarchical quadtree-based view-dependent LOD technique.
4.3.3
Rendering
The rendering process was done continuously for each frame. It consists of six main steps. Every step is explained in further details in the following subsections.
90 4.3.3.1 Configuring Information for Camera
It involved the determination of the position of the eye point (camera position), the reference point (camera look at) and the direction of the up vector. These parameters were gathered and put in the OpenGL function called “gluLookAt()”. In general, this function created a viewing matrix for the system. The matrix mapped the reference point to the negative z-axis and the eye point to the origin. The direction described by the up vector was mapped to the positive y-axis.
4.3.3.2 Loading and Unloading Terrain Tiles
In this research, the 5 x 5 tiles have been used because it is not too small or too big for loading purpose. Firstly, the current camera position was obtained to determine which tiles to be loaded. Then, the algorithms for obtaining the current tile index and all tiles to be loaded were applied as shown in Algorithm 4.7 and Algorithm 4.8. The TILE files (OutputN.tile) were retrieved and loaded regarding on the tile indices obtained from those algorithms.
When the camera moves to the other tile, the system needs to be updated. Several tiles were unloaded in order to allow the loading of new tiles. The number of tiles needs to be loaded depends on two conditions: (i)
if the camera moves to the left, right, upper or lower tile, only five tiles will be loaded
(ii)
if the camera moves to the upper-left, upper-right, lower-left or lowerright tile, only nine tiles will be loaded
91
Input: (i)
Camera position (CamPosx, CamPosy)
(ii)
Number of tiles per side (Nt)
(iii)
Number of vertices per side for tile (Vt)
Output: Current tile index (It) Pseudo code: 1.
initialize temporary variables, temp1 = 0, temp2 = 0
2.
for each of i, i=0,1,…,(Nt-1) do
3.
if CamPosx is in the range of temp1 and [temp1+(Vt-1)]then do
4. 5.
for each of j, j=0,1,…,(Nt-1) do if CamPosy is in the range of temp2 and [temp2+(Vt-1)]then do
6.
It = Nt * i + j
7.
exit loop
8.
end if
9.
temp2 = temp2 + (Vt-1)
10.
end for
11.
end if
12.
temp1 = temp1 + (Vt-1)
13.
temp2 = 0
14.
end for
Algorithm 4.7: Pseudo code for obtaining the current tile index based on camera position
92
Input: (i)
Current tile index (It)
(ii)
Number of tiles per side (Nt)
(iii)
Number of loaded tiles per side (Nl_t)
Output: (i)
Starting tile index (Is_l_t)
(ii)
Array of tile index (I[Nl_t* Nl_t])
Pseudo code: 1.
Is_l_t = It – [(Nl_t-1)/2] * (Nt+1)
2.
initialize temporary variable, temp = 0
3.
for each of i, i=0,1,…,(Nl_t-1) do
4.
for each of j, j=0,1,…,(Nl_t-1) do
5.
I[Nt*i+j] = Is_l_t + j + temp
6.
end for
7.
temp = temp + Nt
8.
end for
Algorithm 4.8: Pseudo code for obtaining the terrain indices to be loaded
4.3.3.3 Calculating Frustum’s Planes
Firstly, the current projection matrix and model view matrix were obtained through the OpenGL function called “glGetFloatv()”. The results from this function (16 floating-point values) were stored separately into two variables (onedimensional array). Then, those two matrices were multiplied in order to get the clipping matrix based on Equation 3.5. Depending on clipping matrix, the coefficients of six planes (A, B, C and D) were calculated as indicated in Table 3.1 and then, saved in one-dimensional array consists of four values. Lastly, all planes were normalized based on Equation 3.12.
93 4.3.3.4 Removing Unseen Terrain Tiles
Each loaded tiles has its own bounding sphere. This bounding volume was tested with six planes of view frustum in order to determine the visible tiles. Algorithm 4.9 presents the pseudo code for detecting the visibility status and assigning flag for loaded tiles. The terrain tile that has ALL-INSIDE or INTERSECT flag will go to the next step.
Input: (i)
Center of bounding sphere (Sc)
(ii)
Radius of bounding sphere (Sr)
(iii)
Number of view frustum planes (Nv_f_p)
(iv)
Co-efficient of view frustum plane
Output: (i)
Distance between bounding sphere and plane (D)
(ii)
Flag represents the visibility status of loaded tiles
Pseudo code: 1.
for each of i, i=0,1,…,Nv_f_p do D = Sc(x)*Co-efficient(Ai) + Sc(y)*Co-efficient(Bi) +
2.
Sc(z)*Co-efficient(Ci) + Co-efficient(Di) if D is less than -Sr then do
3. 4.
return ALL-OUTSIDE
5.
end if
6.
if D is less than Sr then do
7.
return INTERSECT
8.
end if
9.
end for
10.
return ALL-INSIDE
Algorithm 4.9: Pseudo code for detecting the visibility status and assigning flag for loaded tiles
94 4.3.3.5 Generating Quadtree Traversal
Each tile represents a single quadtree structure. There are two main processes need to be done. First, the initialization of quadtree was made. These include: (i)
Creating and allocating memory for the quadtree matrix in the form one-dimensional dynamic array.
(ii)
Initializing the quadtree matrix to 1 for all possible nodes.
(iii)
Propagating the roughness in the elevation data in terrain tiles so that more triangles can be applied in rough spots of terrain surfaces using bottom-up approach.
Next, the refinement of quadtree node was done. Based on top-down approach, the root node (original tile) was split into four small tiles and the process was repeated until certain condition is met. Firstly, the distance between the current camera position and current node in quadtree (center of tile) is calculated using L1Norm distance calculation (Equation 3.13). Then, the f value (decision variable) is computed based on Equation 3.14 for subdivision test. The current node is subdivided if the f value is less than 1. Otherwise, the subdivision is stopped.
4.3.3.6 Generating Triangle Fans
The purpose of this step is to render the triangle fans that represent the nodes in quadtree. According to the explanation in Section 3.5.3, there are two conditions need to be considered. If the current node is the smallest node in quadtree, the rendering of a triangle fan is done based on the center vertex, which is the middle of current node. During the rendering process, lower-middle vertex, right-middle vertex, upper-middle vertex and left-middle vertex are compared with the adjacent node. If the adjacent node is of a lower detail level then the generation of triangle that has this vertex is skipped. Actually, the process was done in order to avoid cracks between two boundaries.
95 If the current node is not the smallest node, there are 16 possibilities of generating and rendering the triangle fans as illustrated in Figure 4.9. It involves the rendering of complete fans and partial fans as well as the node that needs to be traversed down. In order to implement it, the calculation of the bit-code for the fan arrangement that is based on binary representation was used.
There are four calculations were made sequentially as suggested by Polack (2003): (i)
For upper right of current node, the quadtree matrix data was multiplied with 8.
(ii)
For upper left of current node, the quadtree matrix data was multiplied with 4.
(iii)
For lower left of current node, the quadtree matrix data was multiplied with 2.
(iv)
For lower right of current node, the quadtree matrix data was multiplied with 1.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Indicator: Render the node Recurse down to the node’s children Figure 4.9 Sixteen possibilities of generating triangle fans
96 Then, the calculated bit code was compared with the declared bit code in order to detect the fans to be rendered. Lastly, the triangle fans were rendered using OpenGL function, GL_TRIANGLE_FAN for generating the desired triangle meshes.
4.3.4
Interaction
The keyboard and the mouse were used as input devices for interaction between the user and the system. The functions of keyboard are to: (i)
Move forward and backward for camera
(ii)
Strafe left and right for camera
(iii)
Enable or disable texture mapping
(iv)
Show the wireframe model or shaded model
(v)
Quit the system
On the other hand, the mouse has been used for changing the orientation of the camera in the related axis (pitch and yaw).
4.3.5 Shutdown
The purpose of making shutdown procedures is to free the allocated memory being used during the system is running. This situation was done when user exits the system. It involves unloading of quadtree matrices for each terrain tile, elevation data for each tile, imagery data (texture map) and application’s configuration.
97 4.4
Summary
The implementation can be broken down into two important steps, which are pre-processing and run-time processing. Pre-processing step focuses on splitting the DEM data into patches for efficient data retrieval, while the run-time processing works as real-time visualization and navigation tasks that need to be maintain continuously.
In pre-processing, original DEM data was converted into TXT files in order to extract the general information and elevation profiles. Then, according to the TXT files, the TILE files were generated.
In run-time processing, object-oriented approach has been exploited in this research for facilitating the integration of various methods into the system. The classes were created and categorized into two parts: main and base classes. There are four major processes have been done, which are initialization, rendering, interaction and shutdown procedure. The combination of all those processes is crucial for producing an effective real-time terrain visualization and navigation system.
CHAPTER 5
RESULTS, ANALYSIS AND DISCUSSIONS
5.1
Introduction
In this chapter, the results from the implementation of the prototype system are presented. Three different sizes of terrain datasets have been used to assess how far the efficiency of the proposed algorithm and it affects the performance of the system. The terrain size is determined by the number of vertices of original DEM dataset for both vertical and horizontal direction.
Then, the discussions are made and divided into two parts: (i) evaluation of the prototype system and (ii) comparison with the previous technique. For the first discussion, the system was evaluated based on two different numbers of vertices per tile to represent the terrain. For the second discussion, the comparison was made among four techniques, which are brute force, triangle-based LOD, Pajarola’s algorithm, and the proposed algorithm. Several criteria were taken into consideration. These include time for partitioning data, file size of converted data, memory usage, loading time, frame rate, triangle count and geometric throughput.
99 5.2
System Specifications
The prototype system has been developed depending on several specifications. The detailed information of hardware and software specifications are listed in Table 5.1 and Table 5.2 respectively.
Table 5.1: Hardware specifications Hardware
Specification
Motherboard
Gigabyte GA-74400-L1 (AGP 8x)
Processor
AMD Athlon XP 1800+ (1.53 GHz)
Main memory (RAM)
1 GB DDR400 Kingston
Graphics card
Asus NVIDIA GeForce FX 5700 (256 MB, 128-bit, AGP 8x)
Hard disk
40 GB Maxtor (7200 rpm)
Table 5.2: Software specifications Software
Specification
Operating system
Microsoft Windows XP Professional (Service Pack 1)
Development tools
Microsoft Visual C++ 6.0
Graphics library
OpenGL 1.2
DEM viewer and
Global Mapper v6.03
texture generation Image editor
Adobe Photoshop CS
100 5.3
Testing Data
The original DEM datasets were used in this research to test and evaluate the performance of proposed algorithm as well as the prototype of real-time terrain visualization and navigation system. All of them are 7.5-minute DEM (Arizona area). Each dataset corresponds to the USGS 1:24,000-scale topographic quadrangle maps which is represented in Universal Transverse Mercator (UTM) coordinate system and have a grid or data spacing of 10 meters in both directions. The size of terrain datasets is determined based on the total number of vertices. According to the research works that have been done by Duchaineau et al. (1997), Pajarola (1998), Röttger et al. (1998) and Lindstrom and Pascucci (2001) in developing terrain rendering algorithm, one million vertices is sufficient to be classified as a large dataset. In order to facilitate the explanations and discussions on the next sections, the testing data were categorized into three types, which are SMALL, MODERATE and LARGE. Table 5.3 shows the details on the testing data for this research.
Table 5.3: Testing data Feature
Types of Data SMALL
MODERATE
LARGE
Number of vertices
1167 x 1393
3992 x 4032
10115 x 11082
Minimum elevation
461.40
947.00
192.00
1122.80
2722.00
1467.00
Elevation data
value (meter) Maximum elevation value (meter) Texture data
101 5.4
Screenshots from the Prototype System
The prototype system has been run depending on certain settings. Table 5.4 indicates the environment settings for this system. The first two parameters were defined to generate the desired window. The movement speed and mouse sensitivity were used for navigation purpose. The field of view (FOV), near clipping plane and far clipping plane are the camera information. As listed in Table 5.4, three different FOVs and far clipping planes are needed for testing the impact of those parameters to the system performance. The remaining parameters are the constant values used for determining the level of details for the specific terrain tiles.
Table 5.4: Environment settings for testing the proposed algorithm Parameter
Description
Viewport resolution (column x row)
1024 x 768
Bits per pixel
16
Movement speed
5.0
Mouse sensitivity
1.0
Near clipping plane
0
Far clipping plane
500, 750, 1000
Field of view (FOV)
30o, 45o, 60o
Detail level
10.0
Minimum resolution
8.0
The following figures are some screenshots obtained from the implementation of the proposed technique. The outputs comprise of wireframe and textured model.
102
(a)
(b)
Figure 5.1 Small dataset a) wireframe, b) textured
(a)
(b)
Figure 5.2 Moderate dataset a) wireframe, b) textured
(a)
(b)
Figure 5.3 Large dataset a) wireframe, b) textured
103 5.5
Evaluations of the System
Each type of DEM dataset was partitioned into TILE files, which consists of two different tile sizes (number of vertices per tile): 129 x 129 and 257 x 257. This was done in order to evaluate on how the number of vertices per tile affects the measurement criteria that have been mentioned earlier. The evaluations were made on both of the pre-processing and run-time processing phase as described in the next subsections.
5.5.1
Pre-Processing
Two criteria were considered in this phase: time for converting DEM data into tiles and file size of each data format. Table 5.5 and Table 5.6 show the results of those two criteria based on the types of data mentioned earlier and the number of generated tiles respectively.
Table 5.5: The results of time required for converting DEM data and the corresponding file size for number of vertices per tile: 129 x 129 and 257 x 257 Type of
File
Data
Format
SMALL
MODERATE
LARGE
Time Required
File Size
(seconds)
(MB)
129 x 129
257 x 257
129 x 129
257 x 257
DEM
-
-
10.1
10.1
TXT
9.672
9.671
44.8
44.8
TILE
194.171
62.016
7.1
7.4
DEM
-
-
93.5
93.5
TXT
50.063
49.734
205.0
205.0
TILE
10197.969
2632.375
72.8
75.2
DEM
-
-
657.0
657.0
TXT
711.172
710.594
3342.8
3342.8
TILE
704280.112
47160.645
453.3
515.4
104 Table 5.6: Number of generated tiles Type of Data
Number of Tiles 129 x 129
257 x 257
SMALL
110
30
MODERATE
1024
256
LARGE
6960
1760
Total Time 800000
Time Required (seconds)
700000 600000 500000 129 x 129
400000
257 x 257
300000 200000 100000 0 SMALL
MODERATE
LARGE
Type of Data
Figure 5.4 Total time for converting DEM datasets to TILE files
According to the results, the time required for converting a DEM data into tile files is depending on terrain resolution (number of vertices). If the higher resolution terrain data is used, then the longer time is required to do the process. This can be seen from the use of the abovementioned datasets. For example, the time required for generating 1292-TILE files of LARGE dataset is around 8 days. Based on Figure 5.4, the conclusion can be made that the time required for converting a DEM dataset to TILE files increases exponentially over the terrain resolution.
105 Less time is needed to create TXT files compared to the time to generate TILE files. This is because there is only the extraction of general information and elevation profiles are made in creating TXT files. While the generation of TILE files involve so many steps and tests before writing them into hard disk space (storage).
Besides that, the different number of vertices per tile (tile size) also has affected the converting time. As indicated in Table 5.5, the time required to generate the 1292-TILE files is three or four times longer than the creation of 2572-TILE files. This is because a lot of testing procedures as well as read and write processes need to be done for the small size of tiles.
However, the evaluation that is based on file size of each data format has performed the opposite results. Although less time is required to generate TXT files, but in size, it consumes a lot of storage that is between two and five times larger than the original DEM data. This is due to the creation of additional non-existing data, which match the size of (2n+1) x (2n+1) and extra indices for the elevation profiles. In contrast, the total file size of generated tiles is smaller than the file size of DEM data. The file size is reduced around 15 to 30 percents compared to the original data. This is because no “dummy” tiles were created for the final output.
5.5.2
Run-time Processing
For this phase, a simple navigation path that consists of 1000 frames was created in the scene for fairly evaluation of the system. This path includes the locations that were close and far to the terrain surfaces as well as the flat and rough regions. Five criteria were taken into account in evaluating the effectiveness of the proposed algorithm in real-time.
106 5.5.2.1 Memory Usage
This criterion refers to the amount of main memory consumed along the prototype system is run. These include the use of variables to store elevation data and quadtree matrices of terrain tiles. Memory usage was obtained from the Windows Task Manager, which shows the current running program with its memory usage. Figure 5.5 illustrates the example of the memory usage of the prototype system (TileLOD.exe). The results of memory usage for all type of data with two different tile sizes are shown in Figure 5.6.
Figure 5.5 Memory usage for the proposed system
107
Memory Usage 14000
12850
12581
12881
Amount of Memory (KB)
12000 10000
9237
9213
9240
8000
129 x 129 257 x 257
6000 4000 2000 0 SMALL
MODERATE
LARGE
Type of Data
Figure 5.6 The results of memory usage
Based on the results above, there is no much difference amount of memory used in the system among the different type of data which using the same tile size. This is because only 5 x 5 tiles were loaded at once, which means the total number of vertices to be loaded is fix during the system is running.
However, the comparison can be observed obviously between the different tile sizes. According to the results in Figure 5.6, a lot of memory has been used for loading the 2572-TILE files (approximately 12 MB) than the 1292-TILE files (approximately 9 MB). This is due to the number of vertices need to be loaded into the system.
108 5.5.2.2 Loading Time
This refers to the time used to load terrain tiles for the first time into the system. It was obtained using C functions that capture the time before and after the loading process. Figure 5.7 presents the results of the loading time.
Loading Time 0.171
0.18
0.17
0.16
0.147
Time (seconds)
0.14 0.12 0.1
129 x 129
0.08
257 x 257
0.06 0.04
0.041 0.031
0.028
0.02 0 SMALL
MODERATE
LARGE
Type of Data
Figure 5.7 The results of loading time
As the results show, there is no big difference the time needed to load tiles among the different type of data which using the same tile size. Like the memory usage, the loading time depends on amount of vertices involved. However, the time required for loading the terrain tiles can be distinguished based on the tile size used for each dataset. The higher tile size to be used, the longer time is needed to load and store the elevation data into the specific variable.
109 5.5.2.3 Frame Rate
This parameter is used to evaluate overall performance of the system based on rendering speed. Frame rate was obtained by calculating the number of frames per second (fps). The equation is:
FPS =
FrameElapsed (New Time − Pr evious Time )
(5.1)
The results are shown in Figure 5.8 and Figure 5.9, which are based on three different field of view (FOV) and length of view frustum.
Vertices Per Tile and Type of Data
129 x 129 x 129 x 257 x 257 x 257 x 129 129 129 257 257 257
Average Frame Rate 1 41.682 46.813
LARGE
56.741
47.076 50.141 56.181
MODERATE
49.178 55.549 60.382
SMALL
60° 45°
63.999 67.015
LARGE
64.696
MODERATE
75.441
72.067
SMALL 0
20
40
60
30°
87.213
80
86.449
80.995
89.426
100
Frames Per Second (fps)
Figure 5.8 The results of average frame rate based on different FOV
110
Vertices Per Tile and Type of Data
129 x 129 x 129 x 257 x 257 x 257 x 129 129 129 257 257 257
Average Frame Rate 2 39.647 46.813 51.322
LARGE
44.311 50.141
MODERATE
59.699
48.583 55.549 60.458
SMALL
1000 750
60.508 67.015 75.132
LARGE
67.14
MODERATE
75.441 84.112
72.067
SMALL 0
20
40
500
60
80
80.995 87.165
100
Frames Per Second (fps)
Figure 5.9 The results of average frame rate based on different length of view
frustum
The minimum and maximum of frame rate obtained from the above tests for all datasets are 33.267 fps and 119.919 fps respectively. In general, the prototype system has successfully surpassed the interactive rate (more than 20 fps) which means it qualifies to be classified as a ‘real-time’ application (Lindstrom et al., 1996; Duchaineau et al., 1998; Pajarola, 1998; Hill, 2002).
According to the experiment that has been done, the adjustment of FOV and length of view frustum are capable to influence the results of frame rate. The use of larger values for both parameters has decrease the number of frames per second, thus reducing the system performance (rendering speed). Another element needs to be considered is how the tile size affects the frame rate of the system. Based on the results, the higher fps can be obtained if the smaller tile size is adopted. This is due to the number of vertices need to be processed for each frame.
111 5.5.2.4 Triangle Count
This parameter is calculated based on the number of triangles generated per frame. It indicates how much detail can be represented in a frame. Figure 5.10 and Figure 5.11 illustrates the results of triangle count.
Vertices Per Tile and Type of Data
129 x 129 x 129 x 257 x 257 x 257 x 129 129 129 257 257 257
Average Triangle Count 1 LARGE
25606
21274
MODERATE
21090
28133
25187 23944
60°
24149 23014 22051
SMALL
45° 30°
19423 17823 15988
LARGE MODERATE
14479
SMALL
18848 17675 19037
15933 14834
0
5000
10000
15000
20000
25000
30000
Number of Triangles Per Frame
Figure 5.10 The results of average triangle count based on different FOV
129 x 129 x 129 x 257 x 257 x 257 x 129 129 129 257 257 257
Vertices Per Tile and Type of Data
Average Triangle Count 2 LARGE
22728
MODERATE
20227
SMALL
19620
26865 25606
24300 23944 24809 23014
1000 750
18316 17823 16696
LARGE
500
19135 17675 15930
MODERATE
15933 14748
SMALL 0
5000
10000
15000
18651
20000
25000
30000
Number of Triangles Per Frame
Figure 5.11 The results of average triangle count based on different length of view
frustum
112 Based on the results, the 2572-TILE data have generated many triangles than the smaller one. This is because it involves many vertices to form the triangle meshes that represent terrain surfaces, especially on rough and curvy areas. Besides that, the number of triangles increases when the larger FOV and length of view frustum are used. This occurs due to many terrain tiles need to be covered and rendered, thus generating many triangles per frame are inevitable.
In fact, there exists a strong relationship between the triangle count and frame rate as shown in Figure 5.12. The number of triangles per frame is inversely proportional to the number of frames per second. If the triangle count is high, then as a result, the low frame rate is obtained and vice versa.
Frame Rate versus Triangle Count Frame Rate
Triangle Count 30000
90
25000
70 60
20000
50
15000
40
10000
30 20
5000
10 0
0 SMALL
MODERATE
LARGE
SMALL
MODERATE
LARGE
129 x 129
129 x 129
129 x 129
257 x 257
257 x 257
257 x 257
Type of Data and Vertices Per Tile
Figure 5.12 The results of frame rate versus triangle count
Number of Triangles
Frames Per Second (fps)
80
113 5.5.2.5 Geometric Throughput
Geometric throughput refers to the number of triangles can be rendered per second. This gives an indication of how close the system comes to the theoretical geometric throughput of the graphics card. It can be obtained by applying the following formula:
Triangles Per Second = Triangle Per Frame × FPS
(5.2)
The results of geometric throughput are summarized in Figure 5.13 and Figure 5.14. According to the results, the range of generated polygons is between 1.0 and 1.3 million triangles per second. Therefore, around 94 percents of triangles has been reduced for each second (based on maximum geometric throughput for AGP 8x). In addition, if the comparison is made between the results and the maximum number of triangles can be transferred to the graphics card as shown in Table 1.1 (Section 1.2.2), it indicates that all types of graphics cards can be adopted. Thus, the bandwidth bottleneck can be solved.
257
LARGE
257
MODERATE
257
SMALL
129
LARGE
129
MODERATE
129
129 x 129 x 129 x 257 x 257 x 257 x
Vertices Per Tile and Type of Data
Average Geometric Throughput 1
SMALL
1172639 1198693 1207108 1185703 1200576 1184857 1187599 1278404 1331483 1243052 1194408 1394361
60° 45° 30°
1219390 1333419 1251695 1371939 1290493 1326545
0
500000
1000000
1500000
Tria ngle s Pe r Se cond
Figure 5.13 The results of average geometric throughput based on different FOV
114
257
LARGE
1065116 1198693 1166446
257
MODERATE
1076757 1200576 1207531
257
SMALL
1205295 1278404 1186185
129
LARGE
129
1108264 1194408 1254403
MODERATE
1284723 1333419 1339904
129
129 x 129 x 129 x 257 x 257 x 257 x
Vertices Per Tile and Type of Data
Average Geometric Throughput 2
SMALL
1344121 1290493 1285509
0
500000
1000000
1000 750 500
1500000
Tria ngle s Pe r Se cond
Figure 5.14 The results of average geometric throughput based on different length of
view frustum
5.6
Comparison with Previous Techniques
The comparison has been made between the proposed algorithm and the previous techniques. These include brute force, triangle-based LOD and Pajarola’s algorithm. Brute force technique is a conventional way of rendering terrain. It provides the highest amount of detail to the terrain by rendering full resolution mesh. Meanwhile, the triangle-based LOD technique to be compared is based on Röttger’s algorithm (Röttger et al., 1998) as described in Section 2.6.2.2 and Section 3.5. The last technique is a combination of tile-based data structure and triangle-based LOD algorithm (restricted quadtree) developed for ViRGIS (Pajarola, 1998).
Four evaluation criteria were used to measure the performance of each technique. They are memory usage, loading time, frame rate and triangle count. For the first two criteria, all datasets were used. The remaining criteria only used the SMALL dataset because the same results will be obtained if the other datasets are implemented. The predefined navigation path is developed to fairly assess the
115 performance of 1000 consecutive frames. For the proposed algorithm and Pajarola’s algorithm, the 5 x 5 tiles with number of vertices per tile: 129 x 129 are used. The environment settings for running all of the techniques are presented in Table 5.7 below:
Table 5.7 Environment settings for comparison purpose Parameter
Description
Viewport resolution (column x row)
1024 x 768
Movement speed
5.0
Mouse sensitivity
1.0
Near clipping plane
5.6.1
0
Far clipping plane
750
Field of view (FOV)
45o
Memory Usage
According to the results in Figure 5.15, triangle-based LOD technique has consumed the highest amount of memory compared to the other techniques. This is due to the data redundancy involved in order to implement this technique. All the vertices and the corresponding quadtree matrices need to be stored in main memory at once. If the larger size of terrain is employed using this technique, perhaps the insufficient memory will be occurred where the amount of memory required to store the data exceeds the available memory used in the system. Furthermore, the consideration needs to be made in order to allocate main memory for the system because this memory is also shared together with other applications run on operating system.
The second highest of memory usage is using brute force technique. Unlike the triangle-based LOD technique, this technique only load the data based on original terrain size. The brute force technique only consumes less than half of triangle-based
116 LOD technique’s memory usage. In contrast, the Pajarola’s algorithm and proposed algorithm show a great memory management for the system. This is because the size of loaded data is small than the other techniques.
Techniques
Memory Usage
Proposed Algorithm
9237 9213 9250
Pajarola's Algorithm
9369 9297 9344
SMALL MODERATE
17292 54296
Triangle-based LOD
LARGE 542808
8044 50893
Brute Force
220052 0
100000
200000
300000
400000
500000
600000
Amount of Memory (KB)
Figure 5.15 Comparison based on memory usage
5.6.2
Loading Time
In comparing the performance of the techniques in terms of loading time, the results in Figure 5.16 shows that the brute force and triangle-based LOD technique have used a lot of time to load data. This happens because they need to store completely large data into memory at once.
On the other hand, there is no big difference in loading time between Pajarola’s algorithm and the proposed algorithm. Both techniques took no longer times to load the parts of terrain (tiles) because only 25 tiles were loaded for different types of data and the size of data is small which involves 416,025 vertices (25 x 1292) compared to brute force technique, 112,094,430 vertices (10115 x 11082) and triangle-based LOD technique, 268,468,225 vertices (16385 x 16385) for LARGE dataset.
117
Techniques
Loading Time
Proposed Algorithm
0.028 0.041 0.031
Pajarola's Algorithm
0.042 0.048 0.05
SMALL MODERATE
1.797 Triangle-based LOD
LARGE
17.75 153.793
Brute Force
0.109 12.765 96.218 0
20
40
60
80
100
120
140
160
180
Time (seconds)
Figure 5.16 Comparison based on loading time
5.6.3
Frame Rate
The drawback of applying brute force technique can clearly be observed in Figure 5.17. Average frame rate achieved is lower than 1 fps, which means it is not suitable for real-time application. In addition, it took several seconds to render only a frame and thus, making the unsmooth navigation as well as slow down the system performance. This is because there are too many triangles need to be sent to the limited capability of graphics card.
The triangle-based LOD technique also shows not a good result when dealing with large terrain data. Although this technique can improve the rendering speed of the system compared to the brute force technique but it does not surpass the interactive rate. It only obtained the average frame rate, 15.699 fps. This is because the polygon simplification implemented using this technique took into account all the vertices and triangles whether they are inside or outside the view frustum. As a result, a lot of process needs to be done including the unneeded data.
118 Pajarola’s algorithm has surpassed the real-time rate but it cannot beat the results obtained by using the proposed algorithm. The number of vertices needs to be processed and number of triangles needs to be rendered influences the results of those techniques. Pajarola’s algorithm simplified and rendered triangles for 5 x 5 tiles but the proposed algorithm only processed the data for visible loaded tiles. In this matter, the proposed algorithm has shown best performance among the other techniques.
Frame Rate 180 160
Frames Per Second
140 120 Proposed Algorithm 100
Pajarola's Algorithm
80
Triangle-based LOD Brute Force
60 40 20 0 1
87
173 259 345 431 517 603 689 775 861 947 Number of Frames
Figure 5.17 Comparison based on frame rate
5.6.4
Triangle Count
In fact, the brute force technique has generated the highest number of triangles which conforms the formula, 2 x (Vv - 1) x (Vh - 1) where Vv is the number of vertices for vertical direction and Vh is the number of vertices for horizontal direction. As mentioned earlier, this technique is used to generate full resolution mesh to represent the terrain surfaces.
119 Based on Figure 5.18, the triangle-based LOD technique has successfully reduced approximately 97.62 percents of triangles generated using the brute force technique. This is because only the rough and close regions were given with more triangles than the far and flat areas. However, this amount of polygons is still big and capable to reduce the rendering speed. This is because the triangles were also being rendered for each frame whether they were inside or outside the view frustum. This situation is also similar in implementing Pajarola’s algorithm. Although the average number of triangles rendered per frame is lower than using the trianglebased LOD technique, but the triangles that were out-of-sight still being rendered.
In contrast, the proposed algorithm only generated and rendered the triangles for the visible tiles. Around 99.51 percents triangles have been reduced compared to the brute force technique. The unseen terrain tiles have been removed using the view frustum culling method, which is part of the proposed algorithm.
Average Triangle Count 3500000
3246144
Triangles Per Frame
3000000 2500000 2000000 1500000 1000000 500000 77145
26037
15933
0 Brute Force
Triangle-based LOD Pajarola's Algorithm Proposed Algorithm Techniques
Figure 5.18 Comparison based on triangle count
120 5.7
Summary
In general, the number of loaded tiles and the tile size (number of vertices per tile) have influenced the performance of the prototype system. The right decision needs to be made in order to determine the right tile size to handle large terrain data. It cannot be too small or too large. If a bigger number of vertices per tile are used, then more data need be processed and this will slow down the system. Besides that, there is a strong relationship between the frame rate and triangle count. More triangles generated for each frame will decrease the frame rate or rendering speed of the system and vice versa.
The results of implementing the prototype system performed that the proposed algorithm is better than previous technique in many aspects. A dynamic memory management was achieved by loading parts of tiles instead of entire data. View frustum culling and view-dependent LOD technique was adopted in order to optimize the rendering speed of the system, which can be seen in the results of frame rate, triangle count and geometric throughput. The proposed system has achieved the lowest memory usage, loading time and triangle count as well as the highest frame rate when comparing with three other techniques: brute force, triangle-based LOD and Pajarola’s algorithm.
There are two disadvantages of applying this algorithm. The first one is the storage required for creating TXT files. Although these files are only used as temporary files but they consumed more than three times of original DEM’s file size. Secondly, the process of partitioning the USGS DEM data into TILE files in preprocessing is time-consuming especially when converting very huge data, which is more than 500 MB. However, this process is done once for each dataset.
CHAPTER 6
CONCLUSION
6.1
Conclusion
In this research, a set of techniques has been developed to organize and visualize large-scale terrain that considers the capability of current hardware technology. Actually, the proposed algorithm is an extended version of existing triangle-based LOD technique, which tends to overcome the problems that cannot be handled by the triangle-based LOD technique especially the memory constraint and limitation of geometric throughput can be transferred to the graphic cards. The main contributions of this research are: (i)
Developing a simple and efficient data structure based on overlapping tile approach.
(ii)
Developing an algorithm that can manage memory usage and reduce loading time in real-time.
(iii)
Developing an effective algorithm to cull and reduce the amount of terrain geometry based on view frustum.
(iv)
Integrating the data structure and algorithms with the present trianglebased LOD technique in the implementation of prototype system.
122 For the first contribution, original terrain data has been converted into tiles with a simple indexing scheme that is based on filename (OutputN.tile). This was done in pre-processing phase. According to the results that have been produced, the total size of tile files generated is smaller than original DEM data, thus reducing the storage utilization. There are two drawbacks identified from the implementation of this approach. Firstly, the generated TXT files have consumed three times more than the original terrain’s file size. However, those files were temporarily being used and have been deleted after the TILE files completed. Secondly, the time required to complete the partitioning process took much time especially for a very large terrain size. Therefore, tradeoff needs to be made in order to gain a great performance for real-time visualization and navigation.
For the second contribution, the loading of several tiles (5 x 5 tiles) into the system instead of all tiles is a better approach in order to solve the memory constraint and time required to load terrain data. The loading and unloading of tiles that is based on camera position is adopted to reduce the memory usage of the system in real-time. At the same time, the straightforward tile searching and file retrieval have been implemented in avoiding longer time to wait the loading process.
The polygon reduction at tile level using view frustum culling technique is the third contribution in this research. This culling technique has successfully reduced many triangles to be processed and rendered per frame and per second. This can be clearly observed from the results of triangle count between the proposed technique (with culling) and Pajarola’s algorithm (without culling). Besides that, the bandwidth bottleneck and limited geometric throughput can be sent to graphics card has effectively been tackled by not allowing the number of rendered triangles per second exceed the maximum amount of data can be handled by the memory bus.
Lastly, it is a right decision to integrate the tile data structure, dynamic load scheme, view frustum culling and triangle-based LOD technique into the system. According to the analysis that has been done, the proposed technique has produced better results than the other techniques. High frame rate has been achieved for all different test datasets. Although only one triangle-based LOD technique has been
123 used in this research but actually, the proposed technique can be combined with any triangle-based LOD techniques.
Although this research is focusing on GIS field, but the use of the proposed technique is not limited to that area. It can be applied in the following fields: (i)
Virtual tourism Terrain can be combined with other objects such as buildings, roads, trees and so on into the system. Virtual tourism needs an interactive system that allows people or tourists to take a virtual walkthrough to the desired places smoothly.
(ii)
Military Terrain can be applied in battlefield simulation and flight simulator. This is useful for new army in order to train them before facing with the real environment and situation.
(iii)
Games development Terrain models are frequently being used in outdoor-based games especially in first-person and third-person games. The important feature in developing such games is to achieve high frame rate (frames per second). According to the impressive results obtained from this research, it is really suitable for games development.
(iv)
3D modeling software Most conventional 3D modeling software tools such as 3D Studio Max, Maya and Softimage have very poor support for terrain model. The only way to represent the terrain is with a very large number of small triangles as implemented using brute-force technique. By inserting the proposed technique in the research into these tools, it will improve the performance of the software.
124 6.2
Recommendations
In order to enhance the performance of real-time terrain visualization and navigation, several suggestions can be made for future works. These include: (i)
Applying occlusion culling In this research, only view frustum culling is adopted. Although this technique has removed many triangles per frame but the triangles that are behind the terrain surfaces are still being rendered. Occlusion culling technique can be inserted into the proposed system in order to reduce more triangles in a scene.
(ii)
Integrating with out-of-core algorithm Actually, the proposed technique developed in this research can be classified as an in-core technique, which means all the terrain data is located in main memory. In out-of-core technique, only part of the data is kept in main memory and the rest is left on secondary storage (hard disk). Therefore, this approach can solve the memory constraint when dealing with massive terrain data. However, the technique is depending on operating system (OS) to be used. The developer needs to identify the specific function embedded in OS that can allocate and activate the usage of virtual memory (hard disk) for the system.
(iii)
Using graphics processing unit (GPU) GPU can be exploited instead of using central processing unit (CPU) power as implemented in this research. It has been designed for fast display of geometric primitives. By using this processing, the bandwidth bottleneck (limitation of memory bus) in order to transfer the geometric primitives to the graphics card can be overcome. The data is sent directly to the GPU for processing and rendering purposes. Currently, the capability of GPU is still under the performance of CPU. However, the peak performance of GPU has been increasing at the rate of 2.5 - 3.0 times a year, much faster than
125 Moore’s law for CPU. Thus, the implementation of real-time terrain system using this processing can be well-suited for the next few years. (iv)
Implementing parallel processing The prototype system developed in this research can be expanded to the networking environment. By adopting the client-server communication, parallel processing can be done in order to obtain higher level of system performance. The use of load balancing algorithm can be used to distribute the job efficiently based on priority and burden of processing power.
REFERENCES
Ahn, H.K., Mamoulis, N. and Wong H.M. (2001). A Survey on Multidimensional Access Methods. COMP630c - Spatial, Image and Multimedia Databases: Technical Report UU-CS-2001-14. Assarsson, U. (2001). Detail Culling for Robotic Products. ABB. http://www.abb. com/global/abbzh/abbzh251.nsf!OpenDatabase&db=/global/seitp/seitp161.ns f&v=17ec2&e=us&c=76133777536BC959C12569CE006C6EE3 Assarsson, U. and Möller, T. (2000). Optimized View Frustum Culling Algorithms for Bounding Boxes. Journal of Graphics Tools. 5(1): 9-22. Beckmann, N., Kriegel, H.P., Schneider, R. and Seeger, B. (1990). The R*-tree: an efficient and robust access method for points and rectangles. Proceedings of ACM SIGMOD International Conference on the Management of Data. May 23-25. New York, USA: ACM Press, 322-331. Bentley, J.L. (1975). Multidimensional binary search trees used for associative searching. Communications of the ACM. 18(9): 509-517. Bittner, J., Wonka, P. and Wimmer, M. (2001). Visibility Preprocessing for Urban Scene using Line Space Subdivision. Proceedings of Pacific Graphics 2001. October 16-18. Tokyo, Japan, 276-284. Blekken, P. and Lilleskog, T. (1997). A Comparison of Different Algorithms for Terrain Rendering. Spring semester project. CS Dept., Norwegian U. of Science and Technology. unpublished. Bradley, D. (2003). Evaluation of Real-time Continuous Terrain Level of Detail Algorithms. Charlton University: COM4905 Honours Project. Burns, D. and Osfield, R. (2001). Introduction to the OpenSceneGraph. OSG Community. http://www.openscenegraph.com Burrough, P.A. and McDonnell, R.A. (1998). Principles of Geographical Information Systems. New York: Oxford University Press Inc.
127 CGL (2004). Backface Culling. CS488/688: Introduction to Interactive Computer Graphics. Computer Graphics Lab, University of Waterloo. http://medialab.di.unipi.it/web/IUM/waterloo/node66.html DeFloriani, L., Magillo, P. and Puppo, E. (2000). VARIANT: A System for Terrain Modeling at Variable Resolution. GeoInformatica. 4(3), 287-315. Duchaineau, M., Wolinsky, Sigeti, D.E., Miller, M.C., Aldrich, C., and MineevWeinstein, M.B. (1997). ROAMing Terrain: Real-time optimally adapting meshes. Proceedings of the 8th Conference on Visualization ’97. October 1824. Los Alamitos, CA, USA: IEEE Computer Society Press, 81-88. Dunlop, R. (2001). Collision Detection, Part 1: Using Bounding Spheres. Microsoft DirectX MVP. http://www.mvps.org/directx/articles/using_bounding_spheres .htm Fagin, R., Nievergelt, J., Pippenger, N. and Strong, R. (1979). Extendible Hashing: A Fast Access Method for Dynamic Files. ACM Transactions Database Systems. 4(3): 315-344. Faloutsos, C. (1988). Gray Codes for Partial Match and Range Queries. IEEE Transactions on Software Engineering. 14(10): 1381-1393. Faloutsos, C. and Roseman, S. (1989). Fractals for Secondary Key Retrieval. Proceedings of the 8th ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems. March. New York, USA: ACM Press, 247252. Fritsch, D. (1996). Three-Dimensional Geographic Information Systems – Status and Prospects. Proceedings of International Archives of Photogrammetry and Remote Sensing. July 12-18. Vienna, Austria: ISPRS, 215-221. Gadish, D. (2004). Information System for Management. CIS 500 Summer 2004: Slide show. Gaede, V. and Günther, O. (1998). Multidimensional Access Methods. ACM Computing Surveys. 30(2): 170-231. Gottschalk, S., Lin, M.C. and Manocha, D. (1996). OBBTree: A Hierarchical Structure for Rapid Interference Detection. Proceedings of the 23rd Annual Conference on Computer Graphics and Interactive Techniques. New York, USA: ACM Press, 171-180.
128 Gribb, G. and Hartmann, K. (2001). Fast Extraction of Viewing Frustum Planes from the World-View-Projection Matrix. unpublished. Guttman, A. (1984). R-trees: A Dynamic Index Structure for Spatial Searching. Proceedings of SIGMOD ‘84. Jun 18-21. Boston, MA: ACM Press, 47-57. Haines, E. (2001). 3D Algorithmic Optimizations. California, USA: SIGGRAPH 2001 Course. Hawkins, K. and Astle, D. (2002). OpenGL Game Programming. Ohio, USA: Premier Press. He, Y. (2000). Real-time Visualization of Dynamic Terrain for Ground Vehicle Simulation. University of Iowa: Ph.D. Thesis. Hill, D. (2002). An Efficient, Hardware-Accelerated, Level-of-Detail Rendering Technique for Large Terrains. University of Toronto: M.Sc. Thesis. Hjaltason, G.R. and Samet, H. (1995). Ranking in Spatial Databases. Proceedings of the 4th International Symposium on Advances in Spatial Databases. August 69. London, UK: Springer-Verlag, 83-95. Hoff, K. (1996). A Fast Method for Culling of Oriented-Bounding Boxes (OBBs) Against a Perspective Viewing Frustum in Large Walkthrough Models. http://www.cs.unc.edu/hoff/research/index.html Hoppe, H. (1998). Smooth View Dependant Level-of-Detail Control and its Application to Terrain Rendering. Proceedings of IEEE Visualization 1998. July 29-31. Los Alamitos, CA, USA: IEEE Computer Society Press, 35-42. Hoppe, H. (1999). Optimization of mesh locality for transparent vertex caching. Proceedings of the 26th Annual Conference on Computer Graphics and Interactive Techniques. New York, USA: ACM Press, 269-276. Hubbard, P.M. (1995) Collision Detection for Interactive Graphics Applications. IEEE Transactions on Visualization and Computer Graphics. 1(3): 218-230. Jagadish, H.V. (1990). Linear Clustering of Objects with Multiple Attributes. Proceedings of the ACM SIGMOD International Conference on Management of Data. May 23-26. New York, USA: ACM Press, 332-342. Kim, S.H. and Wohn, K.Y. (2003). TERRAN: out-of-core TErrain Rendering for ReAl time Navigation, Proceedings of EUROGRAPHICS 2003. September 16. New York, USA: ACM Press.
129 Klosowski, J.T., Held, M., Mitchell, S.B., Sowizral, H. and Zikan, K. (1998). Efficient Collision Detection Using Bounding Volume Hierarchies of kDOPs. IEEE Transaction on Visualization and Computer Graphics. 4(1): 2136. Kofler, M. (1998). R-trees for Visualizing and Organizing Large 3D GIS Databases. Technischen Universität Graz: Ph.D. Thesis. Kumler, M.P. (1994). An Intensive Comparison of Triangulated Irregular Networks (TINs) and Digital Elevation Models (DEMs). Cartographica Monograph 45. 31(2): 1-99. Langbein, M., Scheuermann, G. and Tricoche, X. (2003). An Efficient Point Location Method for Visualization in Large Unstructured Grids. Proceedings of 8th International Fall Workshop on Vision, Modeling and Visualization 2003. November 19-21. Munich, German: Aka GmbH, 27-35. Larson, P.A. (1980). Linear Hashing with Partial Expansions. Proceedings of the 6th International Conference on Very Large Data Bases. October 1-3. Washington, DC, USA: IEEE Computer Society, 224-232. Laurila, P. (2004). Geometry Culling in 3D Engines. GameDev.net, LLC. http://www.gamedev.net/reference/programming/features/culling/default.asp Lindstrom, P. and Pascucci, V. (2001). Visualization of large terrains made easy. Proceedings of IEEE Visualization 2001. October 24-26. Washington, DC, USA: IEEE Computer Society Press, 363–371. Lindstrom, P., Koller, D., Ribarsky, W., Hodges, L.F., Bosch, A.O. and Faust, N. (1997). An Integrated Global GIS and Visual Simulation System. Georgia Institute of Technology: Technical Report GIT-GVU-97-07. Lindstrom, P., Koller, D., Ribarsky, W., Hodges, L.F., Turner, G.A. and Faust, N. (1996). Real-time, continuous level of detail rendering of height fields. Proceedings of the 23rd Annual Conference on Computer Graphics and Interactive Techniques. New York, USA: ACM Press, 109-118. Litwin, W. (1980). Linear Hashing: A New Tool for File and Table Addressing. Proceedings of the 6th International Conference on Very Large Data Bases. October 1-3. Washington, DC, USA: IEEE Computer Society, 212-223.
130 Luebke, D., Reddy, M., Cohen, J.D., Varshney, A., Watson, B. and Huebner, R. (2002). Level of Detail For 3D Graphics. San Francisco: Morgan Kaufmann Publishers. Martens, R. (2003). Occlusion Culling for the Real-time Display of Complex 3D Models. Limburgs Universitair Centrum, Belgium: M.Sc. Thesis. Mokbel, M.F., Aref, W.G. and Kamel, I. (2002). Performance of Multi-Dimensional Space-Filling Curves. Proceedings of the 10th ACM International Symposium on Advances in Geographics Information Systems. November 8-9. New York, USA: ACM Press, 149-154. Morley, M. (2000). Frustum culling in OpenGL. http://www.markmorley.com Mortensen, J. (2000). Real-time rendering of height fields using LOD and occlusion culling. University College London, UK: M.Sc. Thesis. Nievergelt, J., Hinterberger, H. and Sevcik, K. (1984). The Grid File: An Adaptable, Symmetric Multikey File Structure. ACM Transactions Database Systems. 9(1): 38-71. Noor Azam, M. S. and Ezreen Elena, A. (2003). 3D Virtual GIS Architecture. Proceedings of Advanced Technology Congress 2003. May 20-21. Putrajaya, Selangor: The Institute of Advanced Technology (ITMA). Ögren, A. (2000). Continuous Level of Detail In Real-Time Terrain Rendering. Umea University: M.Sc. Thesis. Orenstein, J.A. and Merrett, T.H. (1984). A Class of Data Structures for Associative Searching. Proceedings of the 3rd ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems. April 2-4. New York, USA: ACM Press, 181-190. Pajarola, R. (1998). Access to Large Scale Terrain and Image Databases in Geoinformation Systems. Swiss Federal Institute of Technology (ETH) Zurich: Ph.D. Thesis. Peng, W., Petrovic, D. and Crawford, C. (2004). Handling Large Terrain Data in GIS. Proceedings of the XXth ISPRS Congress – Commission IV. XXXV(B4): 281-286. Picco, D. (2003). Frustum Culling. FLIPCODE.COM, INC. http://www.flipcode.com/articles/article_frustumculling.shtml Polack, T. (2003). Focus on 3D Terrain Programming. Ohio, USA: Premier Press.
131 Röttger, S., Heidrich, W., Slusallek, P. and Seidel, H.P. (1998). Real-Time Generation of Continuous Levels of Detail for Height Fields. Proceedings of WSCG ‘98. February 9-13. Plzen, Czech Republic: University of West Bohemia, 315-322. Samet, H. (1984). The Quadtree and Related Hierarchical Data Structure. ACM Computing Survey. 16(2): 187-260. Samet, H. (1990). The Design and Analysis of Spatial Data Structures. Reading, MA: Addison-Wesley. Shade, J.W. (2004). View-Dependent Image-Based Techniques for Fast Rendering of Complex Environments. University of Washington: Ph.D. Thesis. Shen, H.W. (2004). Spatial Data Structures and Culling Techniques. Slide Show CIS 781. Sheng, J.M. and Liu Sheng, O.R. (1990). R-trees for large geographic information systems in a multi-user environment. Proceedings of the 23rd Annual Hawaii International Conference on System Sciences. January 2-5. Washington, DC, USA: IEEE Computer Society Press, 10-17. Stewart, A.J. (1997). Hierarchical Visibility in Terrains. Proceedings of the Eurographics Workshop on Rendering Techniques ’97. June 16-18. London, UK: Springer-Verlag, 217-228. Tamminen, M. (1982). The Extendible Cell Method for Closest Point Problems. BIT 22. 27-41. Ulrich, T. (2002). Rendering Massive Terrains using Chunked Level of Detail Control. Course Notes of ACM SIGGRAPH 2002. July 21-26. Texas, USA: ACM Press, Course 35. United States Army Topographic Engineering Center (2005). Survey of Terrain Visualization Software. Alexandria (U.S.): Technical Report. USGS (1992). Standards for Digital Elevation Models. U.S. Department of the Interior, United States Geological Survey, National Mapping Division, USA: National Mapping Program Technical Instructions. VTP (1999). Applying Ground Textures. Virtual Terrain Project. http://www.vterrain.org/Textures/ground_textures.html Woo, M., Neider, J., Davis, T. and Shreiner, D. (1999). OpenGL Programming Guide. Canada: Addison-Wesley Longman, Inc.
132 Youbing, Z., Ji, Z., Jiaoyang, S. and Zhigeng, P. (2001). A Fast Algorithm for Large Scale Terrain Walkthrough. Proceedings of the International Conference on CAD & Graphics. August 20-22. Kunming, China. Yu, H., Mehrotra, S. Ho, S.S., Gregory, T.C. and Allen, S.D. (1999). Integration of SATURN System and VGIS. Proceedings of the 3rd Symposium on the Federated Lab on Interactive and Advanced Display. February 2-4. Aberdeen, MD: Army Research Lab, 59-63. Zlatanova, S. (2000). 3D GIS for Urban Development. Graz University of Technology: Ph.D. Thesis.
133 APPENDIX A DEM Elements Logical Record Type A
Data Element
1
Type (FORTRAN Notation)
Physical Record Format Starting Ending Byte Byte 1 40
File name
ALPHA
Free Format Text
ALPHA
41
80
Filler SE geographic corner
--INTEGER*2, REAL*8
81 110
109 135
Process Code
ALPHA
136
136
---
137
137
ALPHA
138
140
Filler Sectional Indicator
Description
The authorized digital cell name followed by a comma, space, and the two-character State designator(s) separated by hyphens. Abbreviations for other countries, such as Canada and Mexico, shall not be represented in the DEM header. Free format descriptor field, contains useful information related to digital process such as digitizing instrument, photo codes, slot widths, etc. Blank fill. SE geographic quadrangle corner ordered as: x = Longitude = SDDDMMSS.SSSS y = Latitude = SDDDMMSS.SSSS (neg sign (S) right justified, no leading zeroes, plus sign (S) implied) 1=Autocorrelation RESAMPLE Simple bilinear 2=Manual profile GRIDEM Simple bilinear 3=DLG/hypsography CTOG 8-direction linear 4=Interpolation from photogrammetric system contours DCASS 4direction linear 5=DLG/hypsography LINETRACE, LT4X Complex linear 6=DLG/hypsography CPS-3, ANUDEM, GRASS Complex polynomial 7=Electronic imaging (nonphotogrametric), active or passive, sensor systems. Blank fill. This code is specific to 30minute DEM's. Identifies 1:100,000-scale sections.
134
2
Origin code
ALPHA
141
144
3
DEM level code
INTEGER*2
145
150
4
Code defining elevation pattern
INTEGER*2
151
156
5
Code defining ground planimetric reference system
INTEGER*2
157
162
6
Code defining zone in ground planimetric reference system
7
Map projection parameter
8
9
10
INTEGER*2
163
168
REAL*8
169
528
Code defining unit of measure for ground planimetric coordinates throughout the file
INTEGER*2
529
534
Code defining unit of measure for elevation coordinates throughout the file
INTEGER*2
Number (n) of sides in the polygon which defines the coverage of the DEM file
INTEGER*2
535
540
Free format Mapping Origin Code. Example: MAC, WMC, MCMC, RMMC, FS, BLM, CONT (contractor), XX (state postal code). Code 1=DEM-1 2=DEM-2 3=DEM-3 4=DEM-4 Code 1=regular 2=random, reserved for future use. Code 0=Geographic 1=UTM 2=State plane Code 0 represents the geographic (latitude/ longitude) system for 30minute, 1-degree and Alaska DEM's. Code 1 represents the current use of the UTM coordinate system for 7.5-minute DEM's. Codes for State plane and UTM coordinate zones. Code is set to zero if element 5 is also set to zero, defining data as geographic. Definition of parameters for various projections. All 15 fields of this element are set to zero and should be ignored when geographic, UTM, or State plane coordinates are coded in data element 5. Code 0=radians 1=feet 2=meters 3=arc-seconds Normally set to code 2 for 7.5minute DEM's. Always set to code 3 for 30-minute, 1degree, and Alaska DEMs. Code 1=feet 2=meters Normally code 2, meters, for 7.5-minute, 30-minute, 1degree, and Alaska DEM's.
541
546
Set to n=4.
135 11
12
13
14
A 4,2 array containing the ground coordinates of the quadrangle boundary for the DEM A two-element array containing minimum and maximum elevations for the DEM Counterclockwise angle (in radians) from the primary axis of ground planimetric reference to the primary axis of the DEM local reference system Accuracy code for elevations
REAL*8
547
738
REAL*8
739
786
REAL*8
787
810
INTEGER*2
811
816
The coordinates of the quadrangle corners are ordered in a clockwise direction beginning with the southwest corner. The array is stored as as pairs of eastings and northings. The values are in the unit of measure given by data element 9 in this record and are the algebraic result of the method outlined in data element 6, logical record B. Set to zero to align with the coordinate system specified in element 5.
Code 0=unknown accuracy 1=accuracy information is given in logical record type C. Only integer values are permitted for the x and y resolutions. For all USGS DEMs except the 1-degree DEM, z resolutions of 1 decimal place for feet and 2 decimal places for meters are permitted. Some typical arrays are: 30, 30, 1; and 10, 10, .1 for 7.5-minute DEM 2, 2, 1; and 2, 2, .1 for 30minute DEM 3, 3, 1 for 1-degree DEM 2, 1, 1; and 2, 1, .1 for 7.5minute Alaska DEM 3, 2, 1; and 3, 2, .1 for 15-minute Alaska DEM.
15
A three-element array of DEM spatial resolutionfor x,y,z.
REAL*4
817
852
16
A two-element array containing the number of rows and columns (m,n) of profiles in the DEM Largest primary contour interval
INTEGER*2
853
864
When the row value m is set to 1 the n value describes the number of columns in the DEM file.
INTEGER*2
865
869
Present only if two or more primary intervals exist (level 2 DEM's only).
17
136 18
Source contour interval units
INTEGER*1
870
870
19
Smallest primary contour interval
INTEGER*2
871
875
20
Source contour interval units
INTEGER*1
876
876
21
Data source date
INTEGER*2
877
880
22
Data inspection and revision date
INTEGER*2
881
884
23
Inspection flag
ALPHA*1
885
885
24
Data validation flag
INTEGER*1
886
886
Corresponds to the units of the map largest primary contour interval 0=N.A., 1=feet, 2=meters (level 2 DEM's only). Smallest or only primary contour interval (level 2 DEM’s only). Corresponds to the units of the map smallest primary contour interval. 1=feet, 2=meters (Level 2 DEM’s only). “YYYY” 4 character year, e.g. 1975, 1997, 2001, etc. Synonymous with the original compilation data and/or the date of the photography. “YYYY” 4 character year. Synonymous with the date of completion and/or the date of revision. "I" Indicates all processes of part3, Quality Control has been performed. 0= No validation performed. 1=RMSE computed from test points (record C added), no quantitative test, no interactive DEM editing or review. 2=Batch process water body edit and RMSE computed from test points. 3=Review and edit, including water edit. No RMSE computed from test points. 4=Level 1 DEM's reviewed and edited. Includes water body editing. RMSE computed from test points.
25
Suspect and void area flag
INTEGER*1
887
888
5=Level 2 and 3 DEM's reviewed and edited. Includes water body editing and verification or vertical integration of planimetric categories (other than hypsography or hydrography if authorized). RMSE computed from test points. 0=none 1=suspect areas 2=void areas 3=suspect and void areas
137
26
Vertical datumn
INTEGER*1
889
890
27
Horizontal datumn
INTEGER*1
891
892
28
Data Edition
INTEGER*2
893
896
29
Percent Void
INTEGER*2
897
900
30
Edge match flag
INTEGER
901
908
31
Vertical datumn shift
REAL*8
909
915
1=local mean sea level 2=National Geodetic Vertical Datum 1929 (NGVD 29) 3=North American Vertical Datum 1988 (NAVD 88). 1=North American Datum 1927 (NAD 27) 2=World Geodetic System 1972 (WGS 72) 3=WGS 84 4=NAD 83 5=Old Hawaii Datum 6=Puerto Rico Datum 01-99 Primarily a DMA specific field. (For USGS use, set to 01). If element 25 indicates a void, this field (right justified) contains the Percentage of nodes in the file set to void (32,767). Edge match status flag. Ordered West, North, East, and South. Vertical datum shift - Value is in the form of SFFF.DD Value is the average shift value for the four quadrangle corners obtained from program VERTCON. Always add this value to convert to NAVD88.
138 APPENDIX B DEM Elements Logical Record Type B
Data Element
1
2
3
4
Type (FORTRAN Notation)
Physical Record Format Starting Ending Byte Byte 1 12
A two-element array containing the row and column identifycation number of the DEM profile contained in this record. A two-element array containing the number (m,n) of elevations in the DEM profile
INTEGER*2
INTEGER*2
13
24
A two-element array containing the ground planimetric coordinates (xgp,ygp) of the first elevation in the profile Elevation of local datum for the profile
REAL*8
25
72
REAL*8
73
96
97
144
5
A two-element array of minimum and maximum elevations for the profile
REAL*8
6
An m,n array of elevations for the profile.
INTEGER*4
6x(146 or 170) 146 = max for first block. 170 = max for subsequent blocks
Description
The row and column numbers may range from 1 to m and 1 to n. The row number is normally set to 1. The column identification is the profile sequence number. The first element in the field corresponds to the number of rows of nodes in this profile. The second element is set to 1, specifying 1 column per B record. -
The values are in the units of measure given by data element 9, logical record type A. The values are in the units of measure given by data element 9 in logical record type A and are the algebraic result of the method outlined in data element 6 of this record. A maximum of six characters are allowed for each integer elevation value. A value in this array would be multiplied by the“z “spatial resolution (data element 15, record type A)” and added to the “Elevation of local datum for the profile (data element 4, record type B)” to obtain the elevation for the point.
139 APPENDIX C List of Published Paper Works
1. Research Issues in Development of Three-Dimensional Virtual Geographical Information System, In Proceedings of International Conference on Computer Graphics, Imaging and Visualization (CGIV 2004), ParkRoyal Penang, Penang, July 2004. 2. Virtual GIS Real-time Data Retrieval Techniques, In Proceedings of International Conference on Computer Graphics, Imaging and Visualization (CGIV 2004), ParkRoyal Penang, Penang, July 2004. 3. The Framework for Multi-Display Virtual GIS System, In Proceedings of International Symposium and Exhibition on Geoinformation 2004 (ISG 2004), Kuala Lumpur, September 2004. 4. A Review on Real-Time Terrain Rendering Techniques, In Proceedings of Malaysian Science and Technology Congress 2004 (MSTC 2004), Kuala Lumpur, October 2004. 5. Three-Dimensional Terrain Database Design and Management for Development of Virtual Geographical Information System, In Proceedings of MMU International Symposium on Information and Communications Technologies 2004 (M2USIC 2004), Putrajaya, October 2004. 6. View Frustum Culling for Three-Dimensional Virtual Geographic Information System, In Proceedings of Conference on Computer Graphics and Multimedia 2004 (CoGRAMM 2004), Bangi, December 2004. 7. Spatial Data Retrieval Based on Hierarchical Method for 3D Virtual GIS, In Proceedings of Postgraduate Annual Research Seminar 2005 (PARS’ 05), D07, FSKSM, UTM Skudai, May 2005.
