A HIERARCHICAL MEMORY MODEL FOR TERRAIN DATA MANAGEMENT IN INTERACTIVE TERRAIN VISUALIZATION By Ricardo Veguilla Gonz´lez a A thesis submitted

in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE in COMPUTER ENGINEERING UNIVERSITY OF PUERTO RICO ¨ MAYAGUEZ CAMPUS December, 2007

Approved by:

Domingo Rodr´ ıguez, Ph.D Member, Graduate Committee Manuel Rodr´ ıguez, Ph.D Member, Graduate Committee Nayda G. Santiago, Ph.D Chairperson, Graduate Committee Pedro V´squez, Ph.D a Representative of Graduate School Isidoro Couvertier, Ph.D Chairperson of the Department

Date

Date

Date

Date

Date

Abstract of Thesis Presented to the Office of Graduate Studies of the University of Puerto Rico in Partial Fulfillment of the Requirements for the Degree of Master of Science A HIERARCHICAL MEMORY MODEL FOR TERRAIN DATA MANAGEMENT IN INTERACTIVE TERRAIN VISUALIZATION By Ricardo Veguilla Gonz´lez a December 2007 Chair: Nayda G. Santiago Major Department: Electrical and Computer Engineering This work describes the use of a hierarchical memory model for the performance estimation of the interactive terrain visualization system as part of the system design process. Such visualization systems must be capable of: a) working with potentially massive datasets which can exceed the both the memory and the disk storage capacity; b) rendering the data at a real-time frame-rate which exceed the capabilities of general-purpose CPUs. While several solutions to these problems have been presented in the literature, they failed to address the general recurrent performance problem of the timely movement of data throughout the complete visualization system. This work presents a model for the estimation of the performance of interactive terrain visualization systems which incorporates the characteristics of hardware components found in visualization systems as well as the characteristics and access patterns associated with terrain data. To validate our model, we performed a test case study. Our results show that the model is able to characterize the general performance behavior of the visualization systems, but the estimated performance diverged from the measured performance as the dataset sizes increased.

ii

Resumen de Tesis Presentado a la Oficina de Estudios Graduados de la Universidad de Puerto Rico como Cumplimiento Parcial de los Requisitos para el Grado de Maestr´ en Ciencias ıa ´ MODELO DE MEMORIA JERARQUICA PARA MANEJO DE DATA ´ EN LA VISUALIZACION INTERACTIVA DE TERRENOS Por Ricardo Veguilla Gonz´lez a Diciembre 2007 Consejera: Nayda G. Santiago Departamento: Ingenier´ El´ctrica y Computadoras ıa e En este trabajo se describe el uso de un modelo jer´rquico de memoria para a estimar el rendimiento de sistemas interactivos de visualizaci´n de terrenos con la o meta de asistir procesos de dise˜o durante el desarrollo del sistems. Dichos sistemas n deben ser capaces de: a) manejar datos cuyo tama˜o puede exceder la capacidad n de la memoria primaria y la capacidad de almacenaje en disco; b) dibujar la data en tiempo real, lo que excede las capacidades de procesamiento de las unidades centrales de procesamiento. A pesar de que numerosas soluciones han sido presentadas en la literatura, estas no consideran el problema recurrente de rendimiento asociado al movimiento de data a trav´s del sistema completo de visualizaci´n. En este e o trabajo presentamos un modelo que incorpora tanto las caracter´ ısticas de los componentes de hardware que forman parte de los sistemas de visualizaci´n, como las o character´ ısticas y patrones de acceso de la data de terrenos. Utilizando el modelo descrito se puede identificar las caracter´ ısticas de los componentes de hardware y de software requeridos para alcanzar las metas de rendimiento deseadas en sistemas de visualizaci´n interactiva de terrenos. o

iii

Copyright c 2007 by Ricardo Veguilla Gonz´lez a .

I dedicate this thesis to my family. .

Carlos P´rez. • Angel Villalain. whose lectures on memory systems were central to the development of the main ideas presented in this work. and Vazjier Rosario e a for their various contributions to the development of the WALSAIP Visual Terrain Explorer. Eric Fortis. Rub´n Nieves. Domingo Rodr´ ıguez for giving me the opportunity to work in the WALSAIP project. Martha Rold´n. Manuel P´rez Qui˜ones who helped me get started in the field of computer e n graphics. • Dr. N´stor Rodr´ e ıguez.ACKNOWLEDGMENTS The author wishes to express his gratitude to the following people: • Dr. Peter Bangdiwala. • Dr. This work has been supported by the National Science Foundation under the CISECNS Grant Number 0424546. H´ctor e e e e Ramos. vi . Nayda Santiago and Dr. H´ctor Irizarry. Javier Malav´.

. 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii iii vi x xi LIST OF ABBREVIATIONS . . 2. . . . . . . .3 Terrain Data Streaming . . . . . . . . . . . . . .1 Terrain rendering optimizations . . 16 2. . . . . . . . . . . . . . . . . . . xiii 1 Introduction . . . . . . . . . . . . . . 1. . . . . . . . 1. . . . . . . . . . . 2.TABLE OF CONTENTS page ABSTRACT ENGLISH . . . .6 1. . . . . . . . Previous Solutions . . . . . . . .1 Visual accuracy . ACKNOWLEDGMENTS . . . . . . . . . . . . .3 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 vii . Performance Problems . 2.5 1. . . . . . .2 Level-of-Detail . . . . . . . . . . . . .4 GPU Optimizations . . . . . . . . .3. . LIST OF FIGURES . . . . . . . . . . . . . . . .1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 Performance Goals .3. . . . . . . . 1. . . . . . . .1. . . . .2 External Memory Management or Out-of-core Rendering Algorithms . . . .4 1.1 Pipeline Model . . . . . . . . . . . . . . . . . . .1. .1 Graphic Hardware Optimizations 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. . . . . . . . . . Contributions . . . . . . . . LIST OF TABLES . . . . . . . . . .7 2 Literature Review .3. . . 1. . . .1. . . . . . . . . . . . . .4 Data Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.2 Multilevel Memory Hierarchies or Hierarchical Memory Model 16 16 25 26 27 28 29 30 30 2. . . . . . . . . . . . . . . . . . . . . . . . . . . .3 External Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . .5 End-to-end Performance Analysis and Optimization . . .1. . . .1 Multi-resolution or Level-of-detail Rendering Algorithms . . . . . . . . ABSTRACT SPANISH . . . . . . . . . . . . Proposed Solution . . . . . . . .2. . . . . . . . 1. . . . . . 2. . . Goals and Objectives . . . 1 4 5 6 7 8 8 9 10 10 10 12 13 14 1.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Processing Models . . . . . . . . . . . . 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. . . . . . . . . . . .1. . . . . . . .2 1. . . . . . . Problem Statement . . . . . . . . . . . . . . . . . . . . . . .2. . . . . . . . . . . . .2 Interactive frame-rate . . . . . . .

. . . 3. . . . . . . . . .3. 3. 4. . . .1 Data Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. . . . . . . . . . . . . . . . . . . . 50 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. . . . . . . . . . . . . .3. . . . . . . . . . . . . . 3. . . . . . . . Closing Remarks .2 Data Access Pattern . . . . . . . .7 System Decomposition Methodology . . . . . . . . . . . . . . . . . . . . . . . . . .3 Hierarchical Memory Model for Terrain Data Management . . . . . . . . . . . . . . 3. .2 Performance Measurement Tests Description Model Validation Results . 33 3. . . . .3 5 Conclusions and Future Work . . . . .5 Java Performance Study . . . . . . Extending the HHM for the terrain visualization 3. . . . . . .10 Model Evaluation . . . . . . . . . . . . . . Model Validation . . . . . . . . 4. . . . . . . . .1 Discussion . . . . . . . . 3. . . 33 34 34 35 37 37 39 40 41 42 42 43 45 46 48 49 3. . . . . .3. . . . . .2 Implementation Technology . . . . . . . Future Work . . . . . . . . . .3. . 5. .1 Test Case System Description .8 High-level System Components . . . . .1. . . . .2 Model Goals . . . . . . . . . . . . .3 Hardware Component Characterization . . . . . . . .3 Conclusions . . . . . . . . . . . . . . . . . . . . . 3. . . . . 50 50 51 52 54 56 59 60 64 65 66 4. . . . . . . . . . . . . .1 Conceptual Representations .2. . . . 5. . . . . . .3. . . . . . . . . .1. . . . . . . . . . . . . . . 3. . . .3 3. . . . . . 4. . . . . .3. .6 System Characterization . . 77 viii . . .1. . . . . . 4. . . . . . . . . problem . . . . .1 5. . .3. . . . .1 WALSAIP Visual Terrain Explorer . . . . . . .2. . . . . . . . 73 A B VTE Java Performance Profiling Results . . . . .1 3.4 Architecture . . . . . . . . 69 70 71 71 71 72 APPENDICES . . . . . . . .4 4 Test Case . . . .3. . . . . . . . . . . . . . . . .1 Model Enhancements . . . . . . . . . . . . Model Description . . . . . . 3. . . . .1 Test Case Model Evaluation Scope . . . . 3. . . . . . . .2 System Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . . .3. . . . . . . . . . . .1. . . . . 4. . . . . . . . . 4. . . . . 74 Terrain Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . .4 Data Transfer Characterization . . .2. . . . . . . . 4. . . . . . . .1. .2 Data Unit Characterization . . . . . . . . . 3. . . . . . . . . . . . . . . .3. . . .2 5.9 Further System Decomposition . . . . . . . . . . 69 5. . . . . . . . . . . . . Model Validation Methodology . . . . . . . . . . . . . . .5 Optimization Technique Characterization 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Problem Domain Studies . . . . . .3. . . . . . . . .2 4. . . . . . . . . . . . . . . . . .2. . . . . . . .3 Application Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . . .

. . . . . . . . . 79 Test Case Results Comparison . . . . . . . . . . . . .C D Test Case Performance Measurements Results . . . . . . . . . . . . . . . . . . . 100 ix . . . 91 BIOGRAPHICAL SKETCH . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 C–7 Guanica . 75 A–4 Execution Time . . . . . . . . . . . . . . . . . . . . . . 89 C–12Jobos Bay . . . . . . .System 2 . . . 74 A–2 Memory Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4–3 Test Systems Specifications .System 3 . . . . . .System 1 . . .System 3 . . . . . 81 C–4 Grand Canyon . . . . . . . . .System 3 . . . . . . . . . . . . . . . . . . . . . . . . . 64 4–5 Model Results . . . . . . 90 x . . . . . 82 C–5 Grand Canyon . . . . .Cumulative. . . . . . . . . . . . . 58 4–2 Dataset characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 C–9 Guanica . . . . . . . . . . . . .System 1 . . . . . . . .Transfer Cost . . . . . . . . . . . . . . .LIST OF TABLES Table page 4–1 Performance Metric provided by Eclipse TPTP. . . . . . . . . . . . . . . 79 C–2 Hawaii .System 3 . . . . . . .Total Instances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 C–6 Grand Canyon . . . . . . . . 66 A–1 Memory Usage . . .System 2 . . . . . . . . . . . . . . . . . . . . . . . . . . .Total Size. .System 2 . . . . . . . . . . . . 80 C–3 Hawaii . . . . . . . . . . . . . . 75 A–3 Execution Time . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 C–1 Hawaii . . .Calls . . . . . . . . . . . . . . . . . . . . . . 64 4–4 Test Systems Actual Parameters . . . . . .System 1 . . . . . 76 A–5 Execution Time . . . . . . . . . . . . . . 85 C–8 Guanica . . . . . .Base. . . . . . . . . . . .System 1 . . . . . . .System 2 . . . . . . . . 87 C–10Jobos Bay . 88 C–11Jobos Bay . . . . . . . .

System 3 . . . . . . . 36 3–3 Data access Pattern . . . . 1–3 Interactive Terrain Visualization. . . . . 41 3–8 Ideal System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .System 1 . . . . 30 2–4 Example of five-level memory hierarchy. . . . . . . . . . . . 1–5 Hardware components. .System 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3–6 Memory Stage . . . . 1–4 Four level-of-detail representations of the same model. . . . . . . . . . . . 31 3–1 Read operations in a) general-purpose computing systems and b) terrain visualization systems. . . . . . 41 3–7 Memory Stage . . . . . . . . . . . . . . . . . . . . . . . . . .Data Transfer Representation . . . . . 11 2–1 Top-down vs. . . . . . . .General Computing System . . . . . . .Data Transfer Representation . . . . . . . . . . . . . . . 21 2–3 Multi-stage pipeline. .LIST OF FIGURES Figure page 2 3 4 9 1–1 Different examples of visualizations. . . . . . . . . . . . . . . . . . . . . rendering optimizations techniques and data flow in interactive visualization systems . . . . . . . . . .Terrain Visualization System . . . . . . . . . . . . . . . . . . . . 61 4–2 Hawaii Test Case Results . . . . . . . . . . . . . . . . . . . . . . . . 43 4–1 Test Case System Decomposition . . . 67 4–3 Hawaii Test Case Results . . . 1–2 3D Rendering Pipeline. 68 xi . . . . . . . . 67 4–4 Hawaii Test Case Results . . . . . . Bottom-up processing direction. . . . . . . . . . . 34 3–2 Data Access Pattern . . . 19 2–2 Hierarchical data structures. . . . .Component Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Component Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3–5 Visualization System . . . . . . . . . . . . . . . . 36 3–4 Visualization System . . . .

. . .System 1 Results Comparison . . . . . . . . 93 D–9 Guanica Dataset . . 92 D–5 Grand Canyon Dataset . . . . .System 3 Results Comparison . . . . . . . . . . . . . . . .4–5 Grabd Canyon Test Case Results . . .System 3 Results Comparison . . . . . . . . . . . . . . . 92 D–7 Guanica Dataset . 78 B–4 VTE visualization of the Jobos Bay dataset. . 91 D–2 Hawaii Dataset . . . . . . . . . . . . . 91 D–4 Grand Canyon Dataset . . . . . . . . 91 D–3 Hawaii Dataset . . . . . . . . . . . . . . . . .System 2 . . . . . . . . . . . . . . . . 94 D–12Jobos Bay Dataset . . . . . . . . . . . . . . . . .System 3 Results Comparison . . .System 2 Results Comparison . . . . . . . . 93 D–11Jobos Bay Dataset . . . . . . . . 94 xii . . . . . . . .System 1 Results Comparison . . . . . . .System 1 Results Comparison .System 2 Results Comparison . . . . 68 B–1 VTE visualization of the Hawaii dataset. . . . 78 B–3 VTE visualization of the Guanica dataset. 93 D–8 Guanica Dataset . . . . . 77 B–2 VTE visualization of the Grand Canyon dataset. . 93 D–10Jobos Bay Dataset . .System 2 Results Comparison . . . . . . . . 92 D–6 Grand Canyon Dataset . . . .System 1 Results Comparison . . . . . . . . . . . 78 D–1 Hawaii Dataset . . . . . .System 2 Results Comparison . . . . .System 3 Results Comparison . .

LIST OF ABBREVIATIONS CPU GPU API LOD EMM DS HMM TIN PCA WALSAIP VTE JOGL FPS GUI MVC J2SE JVM GC JIT RCP TPTP RGB GIS RAID DEM OS RAM AGP PCI Central Processor Unit Graphic Processor Unit Application Programming Interface Level of Detail External Memory Management Data Streaming Hierarchical Memory Model Triangulated Irregular Network Principal Component Analysis Wide Area. Blue Geographic Information System Redundant Array of Independent Drives Digital Elevation Map Operating System Random Access Memory Accelerated Graphics Port Peripheral Component Interconnect xiii . Large-Scale Automated Information Processing Visual Terrain Explorer Java OpenGL Frames per second Graphical User Interface Model View Controller Java 2 Standard Edition Java Virtual Machine Garbage Collection Just-In-Time Rich-Client Platform Test and Performance Tools Platform Red. Green.

Computer based visualization systems have been used for several decades for both general data and terrain visualization scenarios. The general steps performed as part of the 3D rendering pipeline are the following [1]: 1 . the corresponding 3D model is processed to produce a 2D image in which the 3D nature of the object is evident. as part of a cognition. and combine them using 3D Computer Graphics techniques to produce the desired terrain visualization.CHAPTER 1 INTRODUCTION The field of data visualization is concerned with the use of visual representations of abstract data to facilitate human exploration and understanding of patterns and structural relations in the abstract data being displayed. To create a 3D visualization of an object. The most commonly used 3D model is the polygonal model. and reasoning process (see Figure 1–1 for examples). is accomplished via a series of steps which are performed in sequence and are generally referred to as the 3D rendering pipeline. in which a set 3D vertices are interconnected. This process. Performing 3D visualization in a computer requires working with a mathematical description or model of a 3D object. called 3D rendering. forming triangles or polygons which describe the 3D surface of the object of interest. Terrain visualization incorporates visual representations of georeferenced data with a visual representation of the geographic region where the data originated. a visualization system incorporates digital representations of the geographic region surface with corresponding satellite or aerial images. hypothesis building. In order to construct a realistic visual representation of the geographic region of interest.

• Define each object geometry in a coordinate system local to each object (model space). • Transform the scene geometry from the view coordinate system into the screen coordinate system (screen space) based on the perspective projection. • Transform each object from its local coordinate system into the scene’s global or world coordinate system (world space). Figure 1–2 describes the various general transformations. Each transformation is accomplished via a series of translation. view frustum culling . In addition to the operations which transform the geometry between spaces. rotation and scaling operations performed on the 3D geometry being processed at each particular step of the pipeline. processes and spaces involved in the 3D rendering pipeline.2 Figure 1–1: Different examples of visualizations. The most significant of these operations are: the light and surface specifications performed in world space. • Transform the complete scene geometry from the world coordinate system into the camera or view coordinate system (view space). other operations are performed in each particular space. back face culling (removal of geometry facing away from the camera) performed in view space.

The actual calculation required to perform the perspective projection are implemented by a series of matrix transformations applied to each vertex in the model. and b) the changes resulting from the user input are incorporated into the visualization in a timely manner. (removal of geometry outside of the projected viewing area) and hidden surface removal performed in screen space. and finally the rasterization and shading process in which the final pixel color value is calculated for each visible object in the scene. Hardware-accelerated support for performing operations related to 3D rendering is available in consumer-level video cards (GPU) and accessible via application programming interfaces (API). which determines 3D region (view-frustum or viewing-volume) of interest to be rendered. Performing analysis through interactive visualization is qualitatively different from the study of a sequence of .3 Figure 1–2: 3D Rendering Pipeline. Interactive visualization refers to a type of computer-based visualization in which: a) the user of the visualization system controls some aspects of the visualization being performed. The perspective projection is performed from the position of a virtual camera.

or throughput which measures how much work is accomplished per time unit [3]. static images. may take hours. days. the two primary measures of performance are the visual accuracy and the rendering frame-rate. 1. Figure 1–3 presents a conceptual representation of the process required for interactive terrain visualization. computing system performance has been characterized in terms of either response time (also referred to as execution time or latency) which measures how long does it takes to finish a job. or weeks to complete. and optimized primarily for rendering frame-rate. interactive visualization systems have been traditionally characterized as soft real-time systems. In the case of 3D interactive visualization system.1 Performance Goals For many general applications. In the following sections we discuss the different .4 Figure 1–3: Interactive Terrain Visualization. due to the immediate feedback to user interaction which allows for a more dynamic discovery process [2]. On the other hand. Visual accuracy is closely related to throughput while frame-rate is more closely related to response time. depending on the dataset and rendering parameters. This type of visualization system performs batched processing of 3D data which. Traditional non-interactive 3D rendering systems are designed with visual accuracy as primary performance goal.

implies that the visual representation displayed to the user must correctly represent the underlying data being explored. generally referred to as RGB) each consisting of 8-bit or 256 colors per band. visual accuracy. In the case of a dataset consisting of discrete values with variability that exceeds 16.216. green and blue.1.1 Visual accuracy The first criterion.5 issues associated with both visual accuracy and interactive rendering frame-rate. typically 24-bit or 16.777. 1. this may not always be possible due to limitations of the available hardware technology to completely express the full range of the datasets. • Inability of the hardware to store the complete dataset.216 spread on 3 bands (red. The mapping of elevation values .777. the visual representation will always express all information contained in the actual data. The first manifestation of the problem can result in a mismatch between the range of the underlying data and the range of available visual elements used to represent it. Terrain datasets consist of satellite images and elevation maps which are combined in a 3D visual representation using perspective projection. In the simplest example. in the context of interactive 3D terrain visualization. The mapping of color elements values to the display color values is limited either by the range of values produced by the data acquisition system or by the range of color perceptible by the human eye. it would not be possible to attempt a one-toone mapping of data values to colors. In the ideal case. This limitation has two general manifestations: • Inability of the hardware to express the full range of potential values for any element in the dataset. In the case of terrain visualization applications. digital display technology impose limits in terms of the number of colors available for display. However. this is not a current concern thanks to the characteristics of the datasets and the way the data is visually represented.

[2] defines large datasets as those that are considerably larger than the main memory capacity of desktop computer. the hardware will be incapable of displaying all the elements of the dataset at the same time1 . that is. The memory capacity limitations of the hardware are still a concern in terrain visualization applications since advances in data acquisition make larger and larger datasets possible.2 Interactive frame-rate The second performance goals of interactive terrain visualization is sustaining interactive rendering frame-rate. without noticeable latency being present between the user-driven action and the visual update in the visualization screen. As mentioned earlier. First.1. in order to render terrain data. Second. Visualization systems usually operate with large datasets consisting of millions or billions of data elements. The second manifestation of how hardware limitations make difficult the completely express of the dataset accurately is related to the dataset size and the storage capacity available in the system. 1. this approach may result in information overload. for considerably large datasets. every In many cases it may not be desirable to present the full range of the dataset. More specifically: D >> 10 ∗ Md where D is the size of dataset of interest and Md is the main memory capacity of the desktop computer. In such scenarios. where there is simply too much information to be visually digested. even when the hardware is not a limiting factor. in many cases not all the information is different or significant enough in terms of either data variability or number data elements to be useful. 1 .6 to display elements is handled by the perspective projection in which data elements or samples are represented as occupying a position in 3D space. Even larger dataset may also exceed the disk storage capacity of current consumer-level desktop computers. being able to draw or render the 3D visualization at a rate in which interactive visualization is possible.

Rendering a frame is computationally intensive and is usually performed several times per second. The size and complexity . which increases the data set storage space requirement. shaded depending on light position and finally perspective projected. Rendering systems typically aim for a target frame-rate between an average of 10 to 60 frames per second. As the size of the dataset increases. transforming the vertex information to the corresponding pixel in the visualization screen. we want to provide an accurate representation of the geographic region being visualized.2 Performance Problems Building an interactive terrain visualization tool present a series of challenges related to the performance and scalability of the application. As the dataset size increases. In general. Achieving interactive frame-rates is affected by two hardware-related factors: • The hardware input/output capabilities. • The hardware computational capabilities. The I/O capabilities of the hardware limit how much times it takes to transfer the data between memory storage components in the interactive visualization system. Performing interactive rendering implies that user interaction should provide immediate changes in the visualization. the larger the number of frames rendered per second the smoother the animations is perceived by the user. The hardware computation capabilities limit how much time it takes to perform all the vertex transformations and light calculations required to render all the geometry in a frame of animation. rotated or scaled). the more difficult it becomes to be able to render the it interactively. In addition. The more accurate the representation is. The result of this process is a rendered frame of animation.7 vertex in the terrain geometry must be transformed (translated. 1. more elements need to be transferred as part of the rendering of an specific frame of animation. the more complex and detailed the digital representation will be.

3. however. 1. Relying solely on hardware improvements to solve the previously mentioned performance problems is costly and generally insufficient. As consequence. A more in-depth review of the most significant techniques related to each approach is presented in the Chapter 2. We categorize these solutions as: • graphic processing unit optimizations (GPU) • multi-resolution or level-of-detail rendering algorithms (LOD) • external memory management algorithms (EMM) • data streaming techniques (DS) In the following section we briefly introduce each approach. several solutions to the various performance bottlenecks observed in specific parts of the rendering systems have been presented in the in the literature.1 Graphic Hardware Optimizations Current graphic processing units (GPU) provide flexible programmable capabilities for graphics rendering which allow more control over the rendering pipeline than what was available using high-level graphic APIs.3 Previous Solutions Performance optimization related to the interactive 3D visualization of both arbitrary 3D geometry and terrain geometry have been an active area of research for several decades [4]. terrain visualization tools can take advantage of capabilities provided by the GPU to improve . 1. since the hardware may not necessarily scale well for interactive visualization applications [2].8 of the dataset may be too high for the CPU and the GPU to process and render at an interactive frame-rate. High-capacity storage servers can be used to alleviate this problem. As a result. it introduces both additional complexity in terms of data management and network communications overhead. The terrain dataset may be too large to store in conventional memory or even in hard-disk and the required data transfer may stress the I/O handling capabilities of the computer to the limit.

distant portions of the scene to be rendered (see Figure 1–4). This insight is based on the observation that it is inherently inefficient to use many polygons to render object that will only contribute to a few pixels of the rendered scene. while satisfying a geometric and/or visual fidelity error metric in order to maintain a faithful representation. The basic concept behind LOD [5] is to use less detail for small. rendering performance. GPU rendering optimization range from off-loading part of the data management computations to the GPU.9 Figure 1–4: Four level-of-detail representations of the same model. . 1. or devising new GPU-based techniques specifically tailored around the strengths and limitations of the available GPU architectures. we will refer to a level of detail management algorithm as a LOD algorithms. adapting existing data management techniques for GPU-based implementations. and we will refer to the polygonal mesh of a given detail resolution produced by the LOD algorithm as a LOD.3.2 Level-of-Detail Rendering level-of-detail (LOD) algorithms regulate the amount of detail or resolution of the terrain geometry to improve rendering performance. For clarity.

10 1.3.3 External Memory Management

In order to handle datasets that exceed the size of available main memory, an out-of-core or external memory management (EMM) scheme must be employed. Conceptually similar to the paging mechanism employed at the OS-level, the EMM must allow the rendering system to operate in memory only with the subset of the terrain data required for the desired LOD at a given time. As the view position changes, data is loaded into memory as required. 1.3.4 Data Streaming

In many cases, the dataset size may also exceed the storage capacity of available disk storage, or the available disk space quota allocated for the user running the visualization application. To overcome this limitation, the external memory manager can be extended to support data streaming from remote data storage servers. Using a client/server pattern, the visualization application requests multiresolution terrain data from the servers, then stores it on a disk cache. The terrain data transmission is generally performed in a coarse-to-grain fashion, so a simple low-resolution model can be quickly displayed while more detailed data is been received. To optimize network transmission, a data compression scheme can be employed as well as data prefetching based on geographic spatial locality. 1.4 Problem Statement Understanding the performance aspects related to data management and processing is a crucial aspect for the development of effective PC-based interactive 3D terrain visualization systems for scientific research. However, previous works have been focused on a specific performance bottlenecks and do not address the general recurrent performance problem of the timely movement of data throughout the complete rendering system (see Figure 1–5). Earliest efforts related to rendering performance optimization were focused on minimizing the number of triangles to be

11

Figure 1–5: Hardware components, rendering optimizations techniques and data flow in interactive visualization systems processed either by the CPU or the graphic hardware by performing selective geometric simplification during an off-line operation, at run-time or via a combination of both. To scale the rendering capabilities beyond the limitations of main memory, rendering algorithms were extended to incorporate external memory management capabilities in order to load data from secondary disk storage into main memory as required. Subsequently, improvements in networking technology opened the door for data streaming support in rendering algorithms to take advantage of remote, highcapacity data servers. More recently, graphics processing hardware optimization has reemerged as a focus of research due to both the improved processing capabilities, and the flexible programming capabilities of commodity graphic processing units. While extensive work has been done in each particular optimization area, and much work has also been done in various combined areas (GPU-LOD, LOD-EMM, and

12 EMM-DS), there has been very little research in the performance behavior of the complete data processing pipeline for interactive visualization systems2 . The existing situation presents a difficult scenario for system architects and engineers. In order to effectively design and develop efficient interactive terrain visualization systems, a general methodology for identifying the performance characteristics of the software and hardware components required to achieve a desired performance goal. As far as we are aware, such a methodology for the performance analysis of interactive terrain visualization systems has not been presented in the literature. To address this problem, we are proposing the use of a model for characterizing the performance of the interactive visualization system. The model should characterize the system as a data processing pipeline composed of multiple hardware component with specific performance parameters. Using the proposed model we can identify the effect of each potential bottleneck in the total performance of the system. 1.5 Goals and Objectives The primary goal of this research was to develop a model for the performance analysis of interactive terrain visualization systems. The proposed model should help system architects and engineers to easily estimate the expected performance of different hardware and software components under considerations as part of the design, development and implementation of interactive terrain visualization systems.

We must clarify the use of the term pipeline in the context of this work. Previously we referred to the “3D rendering pipeline”, the sequence of steps performed either in software or hardware to transform the 3D data primitives and associated raster images into the final perspective projected image to be displayed. In this work we will use the term “data processing pipeline” to refer to the end-to-end terrain data management system which processes the terrain data from a complete, full resolution dataset at one end of the rendering system, to a partial and/or reduced resolution data subset to be consumed at the other end.

2

Our model is developed as a particularization of the hierarchical memory model commonly used in computer architecture field for characterizing the memory subsystems in computing systems. EMM.6 Proposed Solution In this work we present our model for the performance estimation of interactive terrain visualization systems. Data replacement between levels is determined by geographic spatial locality and view position. Based on this characterization. To that effect. LOD. a terrain visualization tool for exploration of georeferenced . 1. We validate our model with a test case study of the WALSAIP Visual Terrain Explorer(VTE). we model the data transfer cost through the interactive visualization system as a function of the aggregated transfer cost of each component. the proposed model could serve as a foundation for the future development of techniques for the automated selection of the ideal hardware and software components required for achieving an specific performance goal in an interactive terrain visualization systems.13 In addition.and DS are characterized as modifiers associated with a memory stage. we characterize each hardware components in terms of its memory storage and transfer capacity. we developed our proposed model with the following objectives: • Integrate memory related aspects of terrain visualization that so far have been studied in isolation to obtain a holistic view of the performance of the system from end to end from which performance estimations can be performed. Based on this model we estimate the total performance of the system and analyzed the impact of each performance bottleneck across the complete rendering system. Optimizations techniques such as GPU. In particular. The data unit employed in the model is based on a combination of terrain geometry and raster images. • Identify which components related to the terrain data management and processing have the largest performance impact interactive visualization systems.

which we developed as part of the Wide-Area. We also present an overview of existing models which have been used to characterize performance in computing systems. and using the model developed. Automated Information Processing project. we produce a performance estimated. – Implemented in Java and OpenGL for cross-platform application development and deployment. 1. Based on the hardware components of the hardware platforms selected. however.14 data. We analyzed the results and presented various hypothesis as to why the model diverges from the measurements. External memory management.7 Contributions In this research we present the following contributions: • Developed a model for the analysis of interactive terrain visualization systems. We selected various hardware platforms as well as a series of different datasets in order to study the performance of the VTE applications in different scenarios. • Developed a methodology for mapping hardware/software components of interactive terrain visualization systems into the model. In Chapter 3 we present our proposed model . – Supporting Level-of-detail. the performance estimates is higher than the measured performance and diverges even further as the dataset size increases. • Developed an interactive terrain visualization applications called Visual Terrain Explorer. In this chapter we have presented an overview of the different aspects related to the performance of interactive terrain visualization systems. The results obtained show that the model can characterize the general performance behavior of the VTE application running on the different hardware platform. and Data streaming. Large Scale. In Chapter 2 we present a in-depth review of the literature related to the different techniques employed to improve the performance of interactive terrain visualization system.

In Chapter 5 we present our conclusions and propose various potential future works. . as well as the results obtained. In Chapter 4 we describe the visual terrain application called WALSAIP Visual Terrain Explorer which we use to validate our model.15 for the performance analysis of interactive terrain visualization.

produce a corresponding mesh of different resolution. when applied to the initial mesh.1 Terrain rendering optimizations Multi-resolution or Level-of-detail Rendering Algorithms An excellent in-depth overview of multi-resolution or level-of-detail (LOD) rendering can be found in [4]. the overall process is still one of geometric simplification with respect to the original full mesh. In this section we will summarize the most relevant aspects and considerations related to LOD rendering for terrain visualization. Even though a LOD algorithm can begin with a base mesh (simplest representation) and progressively add detail. since the resulting mesh is a simplified version 16 . We will refer to the full resolution representation of a terrain as the full mesh. as well as a review of data processing models. 2. the mesh with the minimum number of polygons required to approximate the full resolution terrain has been called the base mesh. Historically.1 2.CHAPTER 2 LITERATURE REVIEW This chapter presents a literature review of the terrain rendering techniques previously mentioned in Section 1. and a set of updates operations. These two aspects are the basis of our proposed model. which consist of representation of the terrain at either the minimum resolution level or the maximum resolution level. A LOD algorithm is responsible for performing geometric simplification operation to eliminate redundant information where appropriate while satisfying both performance and visual accuracy constrains. that.3. The basic components of a LOD algorithms are the initial mesh.1.

multiple individual models of different resolutions are generated from the terrain data during an off-line processing operation. Per-LOD Detail Distribution Depending on the distribution of geometric detail across the output mesh. • Uniform simplification: In uniform simplification algorithms. in theory. Continuous LOD algorithms are. more efficient since they provided more granularity between LODs. Transition Granularity between LODs A LOD algorithm can be characterized as either discrete or continuous depending on the transition granularity between successive LODs produced by the algorithm. LOD algorithms can be characterized as performing either a uniform or a non-uniform geometric simplification. • Discrete LOD: In discrete LOD algorithms. the level of detail of a resulting mesh is uniformly distributed across the surface geometry.17 of the original. We will now describe the various characteristics which differentiate existing LOD algorithms. Since the bulk of the geometric simplification is performed off-line. we should allow for more efficient resource utilization since the algorithm should only use as many polygons as required to achieve the desired LOD. a continuous spectrum of detail for the terrain is encoded in a data structure from which a model for a desired level of detail can be extracted at runtime. Uniform simplification is usually employed in discrete LODs generation which is performed . • Continuous LOD: In continuous LOD algorithms. discrete LOD algorithms are simpler and their runtime overhead is usually limited to evaluating the selection criteria and handling transitions between LODs. Continuous LOD algorithms are more complex than discrete LOD algorithms and also incur in considerable more runtime overhead. and the appropriate model is selected at runtime. However.

until the desired resolution is achieved. • A top-down LOD algorithm (also referred to as refinement or subdivision algorithm) begins with a base mesh and then proceed to progressively add vertices. LOD Processing Direction As mentioned before. Uniform meshes are also generated by LOD algorithms that aim to optimize mesh layout for GPU processing.It is generally performed for further reducing the number of vertices in the output mesh by only maintaining detail where required in the context of a specific LOD mesh and for supporting view-dependent simplification algorithms.18 off-line when no view-dependent information is available. As a result. incrementing complexity. • A bottom-up LOD algorithm (simplification or decimation) begins with a full mesh and proceed to progressively remove vertices (decreasing complexity) until the target resolution is reached. Bottom-up algorithms have higher memory and computational cost since they start with the full mesh. • Non-uniform simplification: Non-uniform simplification is generally employed to produce meshes where the detail is selectively distributed across the surface geometry.e. discarding polygons that lie outside the view frustum.. the geometric simplification operation performed by a LOD algorithm begins with using either the base mesh (simplest representation) or the full mesh (most complex representation) as the initial mesh. where the level of details varies with respect to the view direction and the region of the mesh contained inside the view frustum. Top-down algorithms are ideally suitable for run-time operations since they complement viewdependant simplification algorithms by supporting view culling i. but are able to find the minimum . the use initial mesh selection allow us to classify the algorithms in terms of the direction in which the update operation introduces complexity into the resulting mesh.

• TINS . LOD data structure In order to implement view-dependent multi-resolution rendering a hierarchical structure capable of representing different parts of the terrain at different resolutions is required. TINs can use the minimum number of elevation samples to approximate a terrain by using few samples to describe large flat areas while using many samples on areas of larger terrain complexity. Bottom-up processing direction. since they store redundant information in regions with no change in elevation. However. bottom-up algorithms are generally used during offline discreet uniform simplification operations. The basic two representations are height fields and triangulated irregular networks (TINs) [6]. The most commonly used structures for this purpose are the quadtree and the bintree [7]. height fields are easier to work due to their simple spatial organization. Figure 2–1 illustrate the relation between the terrain refinement/simplification process and the processing direction.In TINs. Terrain data structure LOD algorithms are also differentiated by the structure employed to represent the terrain. As a consequence.Array of height values at regularly spaced x and y coordinates. In a quadtree structure. a rectangular region is recursively . height fields are considered inefficient in terms of data size. height values are irregularly spaced. In terms of management. • Height fields . Figure 2–1: Top-down vs.19 number of polygons for a given accuracy level.

QSW . A bintree is in essence a kd-tree. A kd-tree is a binary tree that recursively subdivides a space such that a k-dimensional kd-tree divides a k-dimensional space with a (k − 1)-dimensional plane [9].20 subdivided into four uniform quadrants. SE}. and the X-child is the root of the quadtree of the set PX . which is an adaptation of the texture mipmap technique [13] for geometry. N W. then the quadtree is a single leaf where S and P are stored. b) a bintree of four levels. the highest LOD at the bottom of the pyramid and each subsequent LOD is half the resolution of the previous. QN W . and define: – PN E = {p ∈ P : px > xmid ∧ py > ymid } – PN W = {p ∈ P : px ≤ xmid ∧ py > ymid } – PSW = {p ∈ P : px ≤ xmid ∧ py ≤ ymid } – PSE = {p ∈ P : px > xmid ∧ py ≤ ymid } The quadtree contains a root node v. Different LODs of a terrain geometry or texture are stored as different levels of a pyramid. • Otherwise. which contains S. A binary triangle tree structure (or bintree) use the same strategy but subdivide the initial rectangular region into two triangles. SW. c) and d) . More formally. Where v has four children. Another data structure commonly used is the pyramid structure (used by TerraVision [11. Let xmid = (x1 + x2)/2 and ymid = (y1 + y2)/2. Figure 2–2 show the main data structures previously described: a) a quadtree of three levels. 12]). and QSE denote the four quadtrees. let QN E . The main advantages of bintrees over quadtrees are that it is easier to work with LOD transition artifacts [4]. Multi-triangulation [10] is an extremely general TIN data structure which stores a base mesh and the update operation required to refine it. [8] defines a quadtree for the set of points P in a square S = [x1 : x2] × [y1 : y2] as follows: • If |P | <= 1. Dependencies between update operations are represented by a direct acyclic graph which influence when simplification or refinement is performed. where X|X ∈ {N E.

A more sophisticated approach proposed in [14] involves defining a rendering benefit and cost functions for each LOD type (discrete or continuous) and perform the selection on the benefit-to-cost ratio. LOD transition discontinuity (the popping effect) The most common problem faced by all LOD techniques is minimizing the temporal discontinuity that occurs as geometric complexity suddenly changes when . it will be rendered using a particular LOD. The simplest criteria is distance. Figure 2–2: Hierarchical data structures. if an object is at a specific distance of the view position.21 alternate representations of a pyramidal structure where each pattern represents a different resolution. An alternative criteria is the size of the particular element when projected into the screen. Other parameters used in LOD selection may include view orientation and/or surface roughness. one of the most important aspects in a LOD algorithm is the criteria used to characterize an element as being small or distant. but which is also more costly in terms of computation. LOD selection Since the basic LOD premise states that less detail is required for small or distant elements of the scene. which in general is a more accurate way of selecting the LOD. and how that criteria is used to select an appropriate LOD at runtime.

The reverse effect is also common. maintaining visual continuity at the cost of the extra computation required to do so. The two most common approaches to this problem are examples of the inherent trade-off between performance and complexity present in LOD techniques. due to the perspective projection. or just preventing simplification of vertices that lie on the LOD boundaries. it will require maintaining geometric complexity beyond the point where it is perceivable. While this solution does not require extra computation. introducing new polygons to fill the gap o subdivided both polygon to produce a more continuous transition at the cost of adding geometrical complexity. which goes against the basic premise of LOD. as surface detail abruptly disappear when a higher to lower LOD transition occurs. This effect is commonly referred to as the popping effect since it is particularly evident when a transition from a lower to a higher LOD causes more polygons to suddenly pop into view. or b) moving the LOD transition threshold farther away so that any potentially abrupt geometry change will occur before they can be perceived. The popping effect can be easily eliminated by a) geomorphing (geometrical interpolation) between the two LODs as the view changes. continuous LODs algorithms try to minimize as much as possible the computation required during a simplification or refinement process. Terrain spatial discontinuity (surface cracks and tears) A problem generally faced when using quadtrees or any tile-based LOD approaches is that it is possible to introduce artifacts such as cracks and tears in the edges between LODs caused when a polygon from a higher LOD does not share a vertex or lies on an edge of a polygon in a lower LOD.22 a LOD transition occurs. Frame-to-frame coherence In general. Fortunately. Common strategies to eliminate this kind of artifact include: modifying the polygon involved by either adding a vertex at the lower LOD triangle or adjusting the vertex of the higher LOD triangle. for interactive applications where no drastic change in the view position or orientation .

To minimize CPU calculations. LOD selection is done based on view frustum. This technique uses memory mapping for out-of-core support. Review of LOD algorithms A review of the classic LOD techniques can be found in [4]. followed by bottom-up simplification at the block level until the screen-space error criteria is reached. the vertex data is read from disk. it is possible to exploits the fact that for a particular region of the terrain. the LOD required during the next frame of animation will be either slightly lower (when moving away) or slightly larger when moving forward. For a LOD algorithm to take advantage of frame-to-frame coherence.23 occurs. To exploit temporal coherence. 17]. Hoppe presented a TIN-based. continuous LOD is produced by adding or removing triangles from off-line generated blocks of terrain. an active cut of blocks is used to keep track of the current LOD. view-dependent terrain LOD algorithm [18]. At runtime. it must be capable of encoding the update operations (and the dependencies between each operation) in order to allow incremental updates to the last LOD instead of recomputing the new LOD from scratch. the original mesh is broken into a quadtree of height field blocks which contain discrete LODs. and screen-space geometric error. Upon block selection. In this technique. Extending his previous work on progressive meshes [16. an incremental top-down (coarse to fine) refinement is performed by traversing down the quadtree.[15] presented one of the earliest real-time continuous LOD algorithms. This is known as frame-to-frame or temporal coherence. It employs height fields blocks of different LODs which are stored on disk for out-of-core operation and quad-tree of bounding boxes for view-frustum culling and block selection. Lindstrom et al. surface orientation. The Geometrical MipMapping technique [19] adapts the texture mipmap [13] technique for geometric data. During an off-line operation. here we summarize the most relevant classic works as well as new approaches found in recent literature. LOD transition are selected based .

each nested grid is shifted to maintain the terrain LOD uniformly distributed around the view position and new data is paged into memory to fill the update region where LOD transition occurs. As the view position changes. they may be cached on the video card memory. This technique exploits the flexibility of an irregular mesh to produce better approximations of the original mesh. This reduces CPU overhead by performing view culling per cluster. since clusters stay fixed over several frames. The cluster itself is composed of a few thousand triangles with an associated bounding box which is built off-line. In addition.24 on minimum and maximum viewing distance which are precomputed with the worstcase camera angle (the camera angle from which geometric error is more evident). The basic algorithm works by building a multi-resolution mesh from the combination of nested concentric grids center about the view position. The hierarchy structure is used for visibility culling and each node or cluster consists of a progressive mesh which can be refined as required. and the ability of uniform simplification to produce regularlyconnected meshes which are ideal for creating triangle patches optimized for graphic hardware processing. based on the progressive streaming of discrete mesh elements to the GPU. At runtime. clusters are split or merged as required. each grid from different level of LOD pyramid and sorted by decreasing resolution. The Geometry Clipmap [23] presents a LOD algorithm based on the texture mapping technique. A . CABTT [20] extends the bintree-based LOD approach to work with clusters of aggregated triangles. but implemented on the GPU. QuickVDR [21] provide a general approach based on a cluster hierarchy of progressive meshes (CHPM) where each level of the hierarchy tree represents a different LOD. A different GPU-based approach is presented in [24]. Zhu [22] presents a hybrid technique where irregular meshing is used to construct an input mesh for a uniform simplification process. This technique integrates geometry and texture LOD and also supports terrain compression and synthesis.

This approach delegates all the paging control to the OS.[25] follow a different approach by optimizing data layout for memory coherence. view frustum culling is performed on the CPU and tiles identified as visible are sent to the GPU where they are interpolated in order to obtain a continuous LOD. One of the simplest approaches is to exploit OS based system calls for mapping disk files to memory (memory mapping) in order to access terrain data. A specialized memory manager is used to keep track of which data is on the GPU memory and is used to prevent unnecessary data transfer.1. to terrain tiles on disk. [26] presents a clustering technique based on object space and .25 nested mesh hierarchy of discrete LODs is built off-line.2 External Memory Management or Out-of-core Rendering Algorithms The general approach used for external memory management in terrain rendering applications is to subdivide the terrain geometry into blocks or tiles which are loaded when required. Arguing that OS based services are suboptimal for paging large multiresolution terrain data. but requires optimizing the terrain data on-disk layout (usually in coarse-to-fine order) and/or devising an algorithm to efficiently map terrain coordinates to the vertex data locations on disk. which is presumably more robust and efficient. Other approaches depend on maintaining a mapping of nodes from a quadtrees or bintrees. More specialized techniques may incorporate space location and LOD constrained access patterns into the data manager design for a more efficient mapping of multi-resolution terrain data to external memory. 2. Hoppe presented a technique [18] were terrain data being used as part of a progressive refinement process is partitioned and clustered into square tiles which are loaded using OS provided services. Lindstrom et al. The multiresolution terrain data is linearized in disk and accessed via memory-mapped file mechanism provided by the OS. or levels in a pyramidal data structure. At run-time.

Their approach is based on a hierarchical partitioning of the geometry into compact nodes constructed via clustering-based hierarchical principal component analysis (PCA) of the point geometry. Clientside prediction is used .3 Terrain Data Streaming Supporting terrain data streaming in terrain visualization aims to take advantage of remote high-capacity storage servers while minimizing the data transferred between the client and the server to compensate for the general performance issues related to network latency and bandwidth. and progressively transmit the other nodes depending on view parameters and error metric constrains. The technique presented by Cignoni et al. Vertex duplication between adjacent triangles is eliminated due to the global indexing scheme where a given vertex is referenced by only one index. Several works [28–30] has been done related to the compression of 3D geometry for multiresolution rendering.[27] is based on a hierarchical geometric partitioning using a global indexed representation of the original huge mesh.[32] propose using statistical representation of the geometry in order to improve the geometry bandwidth bottleneck. the server sends the base mesh nodes first.26 LOD constrained access patterns which aims to minimize page faults and reduce loading time. A mesh portion is represented in core memory with indexed lists containing only the loaded vertices and faces.1. 2. Kalaiah et al. Data transfer to the client is reduced by visibility culling and data caching based on the Least Potentially Visible scheme. Partial data load/update/write-back operation are supported via automatic on the fly re-indexing of the loaded data portion. [33] presents an overview of a proposed client-server architecture for terrain data streaming. Geometry decoding is performed by using a quasi-random sampling based on the probability distribution derived from the PCA analysis. [31] address the neighbor dependency constrain in multi-resolution rendering techniques and proposes and scheme for the selective and progressive terrain data transmission by minimizing neighbor dependencies. In this scheme.

One of the earliest works to incorporate modern GPU characteristics into terrain rendering problem is the the GeoMipMap technique [19]. the algorithm sends denser mesh geometry to the GPU (compared to previous algorithms). while keeping the GPU working as much as possible. The transmission scheme allows for the transmission of deltas between different resolution levels for low-end clients scenarios. The GPU optimization approach adopted by Yoon et al. During run time. The basic difference from earlier LOD techniques is the change in emphasis from finding the “perfect set” of triangles for a particular resolution to minimizing CPU utilization and maximizing GPU throughput. Using edge collapse as triangle simplification allows their algorithm to produce a simplified mesh which is a subset of the original mesh. square patches (called geometry clipmaps) centered around the camera and dropping exponentially in resolution as the distance increases.1. Thus. In [34]. terrain mesh is . Geometry data is only transferred to GPU memory when the view parameters changes and new geometry regions become relevant or to fix cracks or tears introduced during the simplification operation. for the case of terrain visualization.27 to drive data prefetching.4 GPU Optimizations The improvements in GPU technology has allowed for the re-evaluation of the performance optimizations traditionally required as part of interactive 3D rendering. The technique uses concentric. which is updated by the CPU when required. particularly so. uniformly tessellated. minimizing the data transferred from main memory.[21] is to cache triangle patches or clusters in the GPU memory. 2. This procedure can be performed by manipulating the vertex connectivity of the geometry already in GPU memory. geometry is fetched from a toroidal buffer residing on the GPU. Terrain data representation is similar to [23]. Losasso et al. requiring less calculation on the CPU.[23] present a GPU LOD technique that abandons any viewdependent re-meshing in order to minimize CPU utilization.

simulate vertex insertions). However. but are not capable of generating new polygons.1. which require sending geometry at full resolution through the bus. and simplified once it is already stored in the GPU memory.[36] tackles the problem of dynamically identifying the optimal cache configuration which minimize absolute latency in remote visualization systems where multiple caches nodes are linearly located between the rendering client and the data server. the actual overhead incurred while transferring the vertices into the desired final mesh make this technique generally slower than LOD techniques based on mesh simplification. This effectively have forced GPU LOD algorithms to operate by means of mesh simplification operations. since such algorithms start from a course level and progressively add vertices to achieve the desired mesh resolution. The approach presented in [36] is based on the notion of an incremental. GPUs are designed to efficiently rasterize huge polygons lists sent through the bus by the CPU. Boubekeur et al. while this approach minimizes the memory footprint of mesh geometry in GPU memory.[35] present a GPU based approach in which a uniform mesh is sent to the GPU memory and manipulated by vertex displacement using vertex shaders. The major limitation of graphics hardware is the lack of geometry generation. 2. It also less intuitive and more complex than other GPU-based approaches. LOD algorithms based on mesh refinement. This approach allows for the arbitrary relocation of vertices (and thus.28 decimated and stored in a nested mesh hierarchy where new vertices from finer resolutions only have to be progressively transmitted and morphed in height onto the previous coarser level already available in GPU memory.5 End-to-end Performance Analysis and Optimization The study of the performance impact of data management from end-to-end in remote visualization systems is a new area of research. A recent work by Sisneros et al. . should provide the additional advantage of minimizing data transfer even further.

to determine the direction of the minimization. Prefetch size was limited to a range between 0 and 6 to minimize data transfer cost. the authors opted for numerical minimization as a heuristic search for better cache configurations. prefetch size and delete size (both defined in number of incrementals).). we can incorporate two closely related models which have been previously used to analyze the performance or search for optimal configurations in multistage systems. 2. For model validation. Deletion size were selected as a random percentage of the cache size. the primary problem is still one of memory management [2]. moving from a cache configuration to another as long as the absolute latency is reduced in the process. Based on the analysis of the configuration parameter space. They used two procedural algorithms. etc.29 which is the portion of data to be delivered or pulled through a chain of networked caching nodes. Cache node configuration was define by three parameters: cache size (defined in number of bytes). Each configuration was tested with 60 random requests. To understand performance aspects related to data movement through the different memory components in a visualization system. These models are the pipeline model and the hierarchical memory model. Each compound key is encoded as a string to simplify the management of incremental requests by means of hash tables.2 Data Processing Models In terms of using current hardware for interactive visualization applications. mesh resolution. . Steepest Descend and Conjugate Gradient. Each incremental is identified by a compound key composed of an arbitrary number of indices corresponding to the client request (view parameters. 200 configuration were selected based on the following guidelines: cache size were distributed between 8 kilobytes and 128 megabytes to match real-world scenarios.

The classical problem is that of a simple. Figure 2–3 illustrates a pipeline consisting of n stages (squares) and N = n + 1 decision points (diamonds). tabu search. Goldstine and von Neumann [39]: “Ideally one would desire an indefinitely large memory capacity such that any particular.30 2. Identifying the optimal configuration is a combinatorial optimization problem.1 Pipeline Model The optimization of multistage pipelines have been a focus of extensive research for scientists and engineers[37].... swarm intelligence. genetic algorithms. It does not seem possible to physically achieve such capacity.. which are located at the beginning of the pipeline. there are over 2 ∗ 1014 possible configurations).2 Multilevel Memory Hierarchies or Hierarchical Memory Model We turn to the concept of memory hierarchies whose motivation was clearly presented in the following quote by Burks. between each compressors and at the end of the pipeline. Different pressures can be specified for N points. each of which has greater capacity than the preceding but which is less quickly accessible.2. neural networks [38]. straight line transmission pipeline (also referred to as a gun-barrel pipeline) with n compressor stations and a specified flow. 2. Thus. These N pressure set points are the decision variables. which can be attacked via meta-heuristics such as local search. and with a discrete set of m possible values. the number of possible configurations for this pipeline system is mN . word would be immediately available.” . Figure 2–3: Multi-stage pipeline. which can be a huge number (for instance if m = 20 and n = 10. simulated annealing. We are therefore forced to recognize the possibility of constructing a hierarchy of memories.2.

the HMM is a specialized pipeline model where the set of possible values for each decision variable increases at each subsequent stages. . In contrast. . In addition. access to any location on level k takes time ≈ k. 2k−1 + 1. the HMM is selective in terms of data flow. for m ≤ i < n.An such that f (Ai ) = f (Ai+l ). For example. and f (Am−1 ) < f (Am ) and f (An ) < f (An+l ). Hierarchical memory can be visualized as a set of discrete levels (see Figure 2–4) where each level is defined as a continuous array of memory elements Am . .e. Since both of these characteristics are pertinent for the ..... For k ≥ 1. which data elements are transferred between each level. if f (x) = log x. each level k contains the 2k−1 locations at addresses 2k−1 . This model mimics the behavior of memory hierarchies consisting of increasingly larger amounts of slower memory. only the total movement of identical elements between endpoint. A typical access cost function is f (x) = log x. Figure 2–4: Example of five-level memory hierarchy. 2k − 1. the traditional pipeline model does not consider individual elements in the pipeline flow. In general terms.31 A hierarchical memory model (HMM) describes a random access machine whose memory access time is non-constant and determined by the non-decreasing access cost function f (x). i.

we choose to based our model primarily on the HMM.32 problem of data management in interactive terrain visualization systems. while reusing the conceptual form of the pipeline model in some cases due to its convenience for expressing composition and decomposition of stages. . In the Chapter 3 we incorporate all these aspects into our proposed model. In this chapter we have presented a review of the most significant techniques and approaches related to performance optimization of interactive terrain visualization systems. We also presented an overview of a previous performance study focused terrain visualization systems with cache nodes between the visualization client and the remote server. Finally we reviewed existing models which can be used study aspects related to performance in computing systems.

In this chapter we describe our proposed model for characterizing the performance of interactive terrain visualization systems.2 we present how interactive terrain visualization systems differ from traditional computing systems in the context of the proposed model. 3.3 we describe the proposed model in detail. In Section 3. As a result.1 Model Goals Our goal is to estimate the performance of different components in an interactive visualization system and how the each component impacts the performance of the whole system. and existing models which have been used to characterize the performance of data processing systems. In Section 3.CHAPTER 3 HIERARCHICAL MEMORY MODEL FOR TERRAIN DATA MANAGEMENT So far we have reviewed different aspects related to the performance of interactive terrain visualization systems. the most critical performance problem of interactive terrain visualization systems is related to the processing of the terrain data.3. In Section 3. our model must be capable of characterizing the data processing behavior of the system and in corporate the system characteristics most relevant to the performance.1 describe two different representations employed for the conceptual presentation of the model. 33 . As described earlier. Section 3.1 we describe the goal of the model. previous work related to performance optimizations.

However. in which a data unit consisting of a number of bits is transferred from or to memory.1 Data Characteristics In a general purpose computing system. Figure 3–1: Read operations in a) general-purpose computing systems and b) terrain visualization systems. 32 and 64 bits). Interactive terrain visualization systems operate over digital terrain geometry. and systems which alter the terrain geometry for . and is typically a multiple of the basic width of the system memory banks (common sizes are 8. The write operation requires two inputs. Access to the terrain data is dominated by read operations. raster images. in concrete systems.2. a) the memory address to write to. The read operation (see diagram a) in Figure 3–1) requires one input. the definition of a data unit can be considered an implementation detail. and b) one output. the data unit read from the input memory address. At the conceptual level. Write operations to terrain data exists primarily in two particular cases: supporting interactive manipulation of terrain geometry. 3. 16.2 Extending the HHM for the terrain visualization problem Extending the hierarchical memory model for the analysis of interactive terrain visualization systems requires adapting the original model to incorporate details that are particular to the terrain visualization problem domain. it is usually specified at the Instruction Set Architecture level by the instruction being used.34 3. The differences between an interactive terrain visualization system and a general computing system are primarily related to the characteristics and access pattern of data being processed. a) the memory address to be read. and b) the data unit to be written. First we must describe how an interactive terrain visualization system differs from a general computing system. a memory access is either a read operation or a write operation. and auxiliary data such as surface normals and texture coordinates.

which dictates that memory locations accessed tend to follow a sequential order. the terrain data unit for the specified spatial position. but three memory access patterns related to locality of reference are common due two the nature of how programs are structured. The two primary components of a terrain data unit are geometry and images.2 Data Access Pattern In terms of data access patterns. The geometry data unit is generally a set of one or more vertices. and executed from memory. which dictates that memory locations which are close to a previously . no clear criteria exist for selecting the image size for a particular geometry. b) spatial locality. or around the spatial position requested (in the case of multiple vertices). The three access patterns are: a) sequential locality. 3. raster images of different sizes can be used as texture for the same surface geometry. and one output. The sizes of the image data can vary independently of the spatial range of the geometry. That is.2. In this research we choose to consider only the read operations. For this reason we cannot generalize beyond the fact that the size of a raster image pixel is 24 bits. Read operations (see diagram b) in Figure 3–1) of terrain data consist of one input. stored. The image data unit consists of raster images composed of n × m pixels of 24-bits (RGB bands of 8 bits each).35 performance reasons such as algorithms performing mesh refinement or geomorphing. the spatial position. general computing system are designed for random data access. which represent the terrain geometry precisely at (in the case of just one vertex). and the second case is only temporary in nature and tied to a particular stage of the rendering system. The definition of a data unit can vary greatly between terrain visualization systems. The first case of write operations is still fairly uncommon in highly interactive visualization scenarios. While images of larger resolution (which are larger in number of pixels) are preferable due to their improved visual quality.

In each diagram. if a spatial location was accessed recently. different shades represent the expected sequence of future memory access. Figure 3–3: Data access Pattern . and c) temporal locality.General Computing System Figure 3–2 illustrates each access pattern. terrain visualization systems follow a data access pattern of geographic spatial locality. In other words. In relation to the terrain data being managed. other spatial adjacent locations will be requested in the future.Terrain Visualization System . Figure 3–2: Data Access Pattern . which dictates that memory locations previously accessed tend to be requested again in the future. where darker shades occur before lighter ones.36 accessed memory location will probably be accessed in the future.

in which green shades represent previous data request and blue shades represent potential future requests. transferring. Each component has a set of characteristics which affect the data transfer performance of the component and the performance of the system as a whole. which is naturally oriented around components. and optionally. we present the components organization similarly to a hierarchical memory model.37 Geographic spatial locality is illustrated in Figure 3–3. but presented in horizontal fashion similar to pipeline diagrams. A secondary access pattern occurs when dealing with multiresolution data. Component Perspective Figure 3–4: Visualization System .3. . These two representations allows us to focus in different aspects of the system as part of the model development process. Graphically.1 Model Description Conceptual Representations As part of the descriptions of the model we employ two different visual representations: • Component representation. If the data for spatial position at a particular resolution was accessed recently. we focus on the dependencies and ordering of the components in a terrain visualization system.Component Representation When using the component representation (see Figure 3–4). data of a level higher or a level lower of resolution may be requested in the future. • Data transfer representation. We define components as a hardware element in a visualization system which is capable of storing. processing data to various degrees. 3. This representation allows us to focus on the decomposition of the system.3 3.

4. different stages or levels in a system will be organized according to the following general rule.3. . 1. the lower element has a lower value for each of the performance characteristics than the next. then: • F (ei . Let: • E be the ordered set of elements of the system. The total data transfer of the system is a function of the transfer cost between every two adjacent components in the system. • C be the set of performance characteristics associated to an element ei where e ∈ E and i ∈ ZN . c) < F (ei+1 .. 2. In other words.3. between two adjacent elements in the system. higher . Element Ordering Constraint In general. ei ∈ E and i ∈ ZN .38 Figure 3–5: Visualization System .. We describe the modeling of transfer cost formally in sections 3. • vi be the value of a performance characteristic c of element ei be given by function vi = F (c. N − 1 be the set of indices to the elements in set E. ei ∈ E and i ∈ ZN .Data Transfer Representation Data Transfer Representation The goal of this representation is to represent the modeling of the data transfer in the interactive visualization system in terms of the component characteristics (see Figure 3–5).3 and 3. ei ) where c ∈ C. The data transfer cost between two adjacent components is a function of the hardware characteristics of both components. • ZN = 0. • |E| = N be the number of elements in set E.. c) where c ∈ C. The data transfer representation allows us to focus on the performance of the system in terms of the data transfer between components and the characteristics of each components.

we define the basic terrain geometry data unit it in terms of terrain height samples. Note. Let R be the rectangular spatial region of terrain with width WR and height HR described by geometry dataset DG and by raster image dataset DI . this translates to the interpretation that lower elements have lower data transfer cost and memory capacity and higher level has higher data transfer cost and memory capacity. As mentioned earlier. Lower transfer cost can be considered to give higher performance. In terms of geometry data. Let V be a 3D vertex or point in DG . or strip layout vs. fan layout). for the case of raster image data. terrain data consists of geometry and raster images. and SV be . that this constraint is defined only in terms of the numeric values of a performance characteristic. while lower memory capacity may limit performance. As a result. we define our basic image data unit in terms of image sample points or pixels. quadrilaterals. the basic terrain data unit should incorporate both geometry and image components corresponding to the same spatial region in the terrain dataset. In the context of this work. However. the choice of polygon patch as basic terrain geometry data unit would bind the model to a particular implementation detail.2 Data Unit Characterization We define a terrain data unit as the basic unit of terrain data to be transferred through the interactive terrain visualization system. Similarly.3.39 element. rightmost elements correspond to highest values. the most attractive choice for basic data unit would be a set of polygons. since the actual polygon patch construction can vary due to different implementation choices (triangles vs. In order to allow for flexibility in terms of the geometry primitives used to render the terrain. 3. not on the interpretation of the value as being high or low in terms of performance. leftmost elements correspond to lowest values. since they are the most commonly used type of primitive used in 3D rendering. Let DG be the set of terrain geometry points. the component and data transfer representation. In both.

3. The primary characteristics taken into consideration in this work are: • Memory capacity • Read or output transfer rate • Write or input transfer rate However. In the traditional HMM. Let B be the smallest rectangular subregion of R to be transferred through the interactive terrain visualization system. we do not place restrictions on the type of characteristics that may included in the characterization. in order to support more flexibility in modeling the data transfer. each memory components is characterized as a memory level or stage with an associated memory capacity and data transfer cost. DG ) + ID(B. we divide the data transfer cost into input transfer cost and output transfer cost. and SP be the size in bytes of P . For example. Let DI be the set of raster image samples. DI )| · SP ). however. Let function GD(B. and the total size in bytes of the terrain data unit is T DU = (|GD(B. Let WB and HB be the width and height of B. Formally.3 Hardware Component Characterization At the core of our model is the hardware component characterization. Similarly to the HMM we model each stage in terms of the memory capacity and data transfer. Then the combined terrain geometry and image data used to represent region B is T D = GD(B. DG ) define the set of V in DG used to represent the terrain subregion B. DI ) define the set of P in DI used to represent the same terrain subregion B. We extend this approach to consider any hardware component capable of data storage transfer as a memory stage (M S). respectively. we define the a memory stage as the set MS of performance related characteristics associated to a particular hardware component in the interactive visualization system. OS related aspects that can affect the .40 the size in bytes of V . DG )| · SV ) + (|ID(B. Let function ID(B. 3. DI ). Let P be a sample or pixel in DI .

A more concrete example would be to incorporate information related to the filesystem for memory stages characteristics corresponding the disk storages units. respectively Figure 3–6: Memory Stage .41 effective performance of the hardware component could be taken into consideration by including additional characteristics as part of the memory stage definition. For performance estimation. Transfer Cost Between Stages The data transfer cost between two adjacent stages M Si and M Si+1 is modeled as a function of the transfer cost associated with reading the data out from the higher stage (M Si+1 ) and the transfer cost associated with writing the data into the lower stage (M Si ).3. transfer cost is defined in terms of time per terrain data unit transferred.Data Transfer Representation 3. we model a memory stage M Si .4 Data Transfer Characterization In this section we describe the modeling of the data transfer cost for the interactive visualization system based on the decomposition of such system into our hierarchical memory model.Component Representation Figure 3–7: Memory Stage . . Formally. T ransf erCostout ) where T ransf erCostin = OT C(M Si+1 ) and T ransf erCostout = IT C(M Si ). in terms of the: • Available memory capacity function M C(M Si ) (TDU) • Input transfer cost function IT C(M Si ) (time per TDU) • Output transfer cost function OT C(M Si ) (time per TDU) Figure 3–6 and 3–7 illustrate the memory stage in the component representation and data transfer representation. the transfer cost function T C(T ransf erCostin . As mentioned earlier.

Looking at the system from the component perspective. and b) identifying the most relevant hardware characteristics of each hardware components.|S| = N is the number of elements in S. then N −1 T otalT ransf erCost = T T C(S) = i=0 T C(M Si . 1. one or all the modifiers may be applied to the elements of the model.3.6 System Characterization In this section we describe the processes of characterizing the interactive terrain visualization system in terms of the hierarchical memory model.3. Stage modifiers are categorized as following: • Data Unit Size Reduction • Available Memory Capacity Increment • Transfer Cost Reduction Between Stages Depending on the optimization technique being consider. Ideal System Characterization We define the Ideal System (see Figure3–8) as: . we must subdivide the system into components with a set of performance related characteristics for each component..42 That is. the transfer cost between memory stages is a function of the output cost of the higher stage and the input cost at the lower stage.. and ZN = 0..5 Optimization Technique Characterization We characterize the different optimization techniques described in Section 2. M Si+1 ) 3. 3. N − 1 is the set of indices to the elements in S. 2.1 as modifiers applied to a particular memory stage. This requires a) to identify all the relevant hardware components of common rendering systems in a way that is meaningful for performance analysis. . Total System Transfer Cost The data transfer cost for the complete system is a function of the data transfer cost associate with transferring data between every adjacent stage in the system. 3. If S is the order set of memory stages.

We define the Ideal Data Source as IdealDataSource = Dsrc if: • M C(Dsrc ) = ∞ • IT C(Dsrc ) = ∞ • OT C(Dsrc ) = ∞ and the Ideal Data Sink as IdealDataSink = Dsink if • M C(Dsink ) = 0 • IT C(Dsink ) = 0 • OT C(Dsink ) = 0 That is. Then we follow a top-down decomposition approach starting at the highest level and recursively decomposing higher-level components into lower-level components until the all relevant components are incorporated into the model. In this ideal system.43 Figure 3–8: Ideal System • A system with the minimum number of components. and a data source. In other words. 3. we start by representing the system as the previously described Ideal System. a single stage. the user input determines which data is read from the data source. The minimum number of components correspond to a data sink. and the ideal data source has infinite memory capacity and transfer cost. • A system with an Ideal Data Source and an Ideal Data Sink. . the performance of this Ideal System is completely determined by the data processing characteristics of the single memory stage.7 System Decomposition Methodology In order to populate the model with all the relevant components. Then we identify the real system components that more closely resemble the ideal data sink and source. transferred trough the single memory stage and consumed by the data sink.3. the ideal data sink has zero memory capacity and zero transfer cost.

which can potentially improve the performance of the component.Physical hardware boundaries generally map to increased transfer cost and memory isolation. additional considerations can aid in the identification of the High-level System Components.44 We begin the decomposition by identifying the endpoints of the systems. it is also the component with the lowest transfer cost. • High computational capacity .Abrupt changes in data transfer cost between stages is significant enough for it to be considered as a stage. We select a remote server as end-point since it is the component with both the largest theoretical memory capacity (storage). both of which can be mapped into the stage model characteristics. Identifying the data sink is easier in visualization systems. • Large changes in transfer cost compared to adjacent stages . the data source and data sink. These are the components that more closely approximate the Ideal System. therefore it is convenient to consider the component as an independent element in the model. This stage acts as an intermediary between the consumer (GPU) and the producer (Remote Server). The initial single stage in the high-level decomposition is the Visualization Workstation. We refer to these components as High-level System Components. the decision to explicitly include a hardware component in the model characterization of the system can be made depending on: • Natural hardware boundaries . since the video card or graphic processing unit at the visualization workstation is the final consumer of terrain data. In more complex scenarios. In addition. In particular. .The computational capacity of a particular hardware component makes it possible to implement more sophisticated data replacement algorithms.

GPU programmability means that more sophisticated optimization techniques are available for this component. • Memory capacity: Affected by the internal memory of the GPU. local to the graphics processor. We can treat this memory as another level of cache for our geometry data and manage it much as we do the core memory cache. GPU components vary in features and capabilities. The following are the main performance characteristics of interest in this work and the factors that generally affect their value for the case of GPU components: • Input cost: Affected by the memory bandwidth to the GPU. The following are the main performance characteristics of interest . Many GPUs support programmability either for graphic processing or for general purpose processing. GPUs are connected to the computer motherboard via a Accelerated Graphics Port (AGP) or Peripheral Component Interconnect (PCI) bus. Visualization Workstation The Visualization Workstation is basically a personal computer in which the user interaction with the visualization system is performed. GPU Graphic processing units are hardware devices dedicated to the processing of graphics data in common computer systems. In the following sections we describe each of the High-level System Components and the factors that affect their performance in terms of the performance characteristics of interest in the context of the model presented in this work. we proceed to identify the most significant hardware characteristics and map them into model characteristics.3. For the purpose of this work.8 High-level System Components Once the high-level components are identified. The fastest rendering is possible for data stored in video memory.45 3. we consider consumer-level laptops and desktops computers as Visualization Workstations. • Output cost: Affected by the triangle fill rate of the GPU.

memory read speed. the subcomponents of each High-level System Components fall into one of the following categories: Random Access Memory Component Random Access Memory (RAM) components found in common computer are a type of volatile. Generally. single disk systems. • Output cost: Affected by the front-side bus. Actual remote server may consists of multiple CPUs or cores. • Memory capacity: Affected by the disk storage and the main memory. disk read speed. and network bandwidth. writable memory storage based on solid state semiconductors . • Memory capacity: Affected by the disk storage and the main memory. we treat Remote Server as single CPU. Similarly to the case of the Visualization Workstation.9 Further System Decomposition After the High-level System components are identified. we proceed to recursively decompose each of them to identify memory stages of interest.3. multiple disk drives in RAID configuration. The depth of the decomposition process will be determined by the precision required for the performance estimation. and memory write speed and the network bandwidth. and network bandwidth. and memory write speed and the network bandwidth. Remote Server A remote server is basically a computer system which is used for data serving. For the purpose of this work. the performance characteristics and the factors that affect them are: • Input cost: Affected by the disk write speed. • Output cost: Affected by the front-side bus. disk read speed.46 in this work and the factors that generally affect their value for the case of GPU components: • Input cost: Affected by the disk write speed. 3. memory read speed.

Flash memory is commonly used as removable storage devices connectable via USB interface. The term “random access” means that any data element stored in the RAM memory component can be accessed at a constant time independently of previous data requests or of where the data is physically stored in the hardware of the component. current Flash memory support larger capacity than RAM memory. Like RAM component. but these are not considered in this work. 1 . • Memory capacity: Affected by hardware component capacity and the operating system (OS) memory management. data storage in Flash memory is usually The only exception are registers which are smaller and faster. In contrast to RAM memory components. RAM components typically have less memory capacity and transfer cost than other memory components in the system1 . In terms of memory capacity. desktops and server computers. RAM components are are commonly used as main or core memory in: laptops. they are also based on solid stage semiconductor technology. Flash Memory Components Flash memory components are non-volatile writable memory components. Flash memory is generally slower than RAM memory components. although the applications for large capacity Flash memory are few due to its higher price. and as secondary memory or memory storage in many types of embedded systems. The performance characteristics and related factors for the RAM components are: • Input cost: Affected by the memory write speed and front-side bus speed. cache memory in CPUs. and video memory in GPUs. • Output cost: Affected by the memory write speed and front-side bus speed. PDAs and cellular phones.47 technology. data buffer in disk drives and network cards. as removable memory cards in digital cameras.

and the OS and FS in use. the connection BUS speed.3. • Output cost: Affected by the Flash memory read speed. 3. Similarly to Flash memory components. and the OS and FS in use. and the OS and FS in use. • Memory capacity: Affected by the component capacity. • Memory capacity: Affected by the hardware component capacity. Disk storage components employ mechanical components which spin the disk platters and move the read-and-write heads.10 Model Evaluation After decomposing the interactive terrain visualization system into the most relevant hardware components and identifing the most significant performance characteristics of each components. The performance characteristics and related factors for the Disk storage components are: • Input cost: Affected by the disk write speed. and the OS and FS in use. the connection BUS speed. the connection BUS speed. we can characterize each component as a memory . The performance characteristics and related factors for the Flash memory components are: • Input cost: Affected by Flash memory write speed. and the OS and FS in use. Disk Storage Disk storage components (also referred to as secondary or out-of-core memory in the literature) are non-volatile storage devices in which data is stored on the surface of magnetic disks platters. Disk storage component are commonly found in laptops. desktops and server computers (in internal and external. In contrast to RAM and Flash memory components. • Output cost: Affected by the disk read speed. and the OS and FS in use. Disk Storage generally use filesystem organization.48 structured following a filesystem (FS) organization. removable configurations) as well as in many embedded devices. connection BUS speed.

e. • Select the transfer cost function T C(T ransf erCostin . IT C(M S). where T ransf erCostin = OT C(M Si+1 ) and T ransf erCostout = IT C(M Si ). we must: • Select the data unit to be used in the performance estimation.. from the Data Source to the Data Sink. To do so. T ransf erCostout ) to model the data transfer cost between two adjacent memory stages M Si and M Si+1 .49 stage and evaluate the model in order to determine the expected performance in terms of the cost of transferring data from end-to-end. 3. • Select how to model the performance of each memory stage M S in terms of the selected performance characteristics by formally defining each of the performance modeling functions M C(M S). . and OT C(M S) for each component.4 Model Validation In the next chapter we validate our model via a test case study of interactive terrain visualization system. i.

Computation may be performed in a distributed manner in multiple computing nodes. The nature of the computation being conducted is determined by the domain of the research being performed. In Section 4. Raw or processed data can be presented by different Information Rendering Systems (IRS).1 Test Case System Description WALSAIP Visual Terrain Explorer The Wide Area Large Scale Automated Information Processing (WALSAIP) project [40] is concerned with the automated processing of signal-based information obtained from physical sensors.3 we presents the model validation results. The automated information processing framework is designed to operate in a time-space distributed manner. Finally. 50 . meaning that data storage and computation is not necessarily localized to a specific computing/storage server facility at a particular time. In Section 4. namely.1. Data from sensors in multiple locations may be stored in geographically dispersed storage servers.2 we describe the validation methodology. in Section 4. depending on the nature of either the data or the processing performed or being performed on it. 4. which may operate in sequence or in parallel as required. the WALSAIP Visual Terrain Explorer. The main goal of the project is to support environmental monitoring applications by providing a framework capable of performing arbitrary computations on data received from sensors located on dispersed geographical locations.1 we describe the system used for the test case study.1 4.CHAPTER 4 TEST CASE In this chapter we describe the validation of our model via a test case study.

and productive interaction experience for users working with the application. Recent development efforts have focused on improving the GUI and to incorporate additional application functionality not related to the visualization.51 The WALSAIP Visual Terrain Explorer (VTE) is a terrain visualization tool which aims to provide an integrated visualization system for environmental monitoring applications. The main goal of the VTE application is to combine diverse georeferenced data in an interactive terrain visualization.2 Implementation Technology Java 2 Platform The VTE application was developed using the Java 2 Standard Edition. the object-oriented nature of the language simplifies designing and building modular and extensible applications. which facilitate building complex and versatile applications. Previous development efforts had been mainly focused on developing the rendering infrastructure and had only provided a rudimentary graphical user interface (GUI) implemented using Java Swing Toolkit. the VTE applications serves as an IRS which provide an user interface for the interactive. such as infrastructure for remote installation and update. sophisticated. Eclipse Rich-Client Platform The goal of improving the application capabilities not related to visualization respond to the need to provide a solid.1. it presents considerable advantages due to its cross-platform capabilities and due to the rich library of classes it provides. The Eclipse RCP simplifies building sophisticated Java applications by providing a bare-bones skeleton which . To fulfill these goals. In the context of the WALSAIP project . it was decided to port the VTE application to the Eclipse RCP [41] which provides an extensible framework for building Java application. 4. In terms of the application architecture. 3D visualization and exploration of georeferenced information belonging to a particular geographic area. Although Java is not necessarily a language traditional used for 3D visualization.

The actual application logic is programmed in a series of plug-in modules. The pipeline was composed of three stages or layer: • I/O Layer . local and remote file management. . Hardware accelerated execution of the OpenGL API is currently supported by most GPUs.1.Provides improved support for performance critical I/O operations in Java applications.3 Application Design The application design follows the object-oriented and design pattern methodologies [44]. OpenGL The VTE application uses OpenGL [42] as low-level graphic rendering library.Provide abstraction over different data sources and formats. • Java ImageIO .Provides abstraction over different geometric simplification algorithms. • Data Reduction Layer . Integration between Java and OpenGL is provided by the Java OpenGL binding library [43]. OpenGL is a cross-platform. Also provides support for memory mapping. 4.52 already incorporates common functionality related to GUI management. high-level programming model for image processing operations. The initial design process was focused on providing a modular framework for constructing rendering pipelines.Provides a pluggable architecture for working with images stored in different formats. • Java Advanced Imaging . Specialized Java Libraries The VTE implementation also uses the following specialized java libraries: • Java NIO . general-purpose graphic library. network sockets. cross-language. and application update operations.Provide a simple. Support working with ByteBuffer objects which provide a flexible operation for reading and writing to files.

how to encapsulate and when to perform the program logic for handling different data formats presented several problems. This is the result of the fact that different data processing algorithms required specific data layouts in order to perform adequately. which added an undocumented data transformation operation to pipeline. but during the implementation process it became evident that the design was not flexible enough for our purposes. In addition the rigid separation between layers was also too limiting for implementing complex data simplification algorithms which. Similarly. but . different rendering techniques required different data layout. resulted in performance reduction in other layers. The original design allow communication between modules in the pipeline. Changing the internal implementation of the SurfaceData to improve performance in a layer. The original design of the VTE application aimed to provide a flexible. view-dependant LOD algorithms require data loading and simplification controlled by the view parameters. which resulted in having to maintain different terrain representation inside different renderer modules. While the pipeline model seemed like a natural choice for the terrain rendering problem. modular architecture. The main problem was related to the fact the implementation detail of which internal representation was used by the SurfaceData class had different performance impact at different layer.53 • Rendering Layer . In particular. crossed the boundaries between layers. The pipeline was constructed at run-time depending on the inputs files by selecting the appropriate modules for each part of the pipeline. in many cases. the design of the classes used to represent the actual terrain data (the SurfaceData class) became more complicated. In particular.Provides abstraction over different rendering techniques. Variability in terms of performance is provided by using different Module objects which are responsible for implementing a particular stage of the pipeline.

the following the following design decisions were made in order to improve the design of the application: • Move Multi-format support and data reduction and filtering support to an offline pre-processing phase. • Simplify rendering layer to minimize the need for maintaining internal data representations.4 Architecture The VTE application was then built around the following general subsystems. rendering system architectures and a reevaluation of the desired application capabilities.1. The main sub-interfaces used in the application are the following: . After a more in-depth study of LOD algorithms. 4. • Simplify I/O to handle different data sources and only one common data format. • The Module Subsystem • The Module Factories • The Message Bus • The Graphical User Interface In the following sections we describe each subsystem in more detail. The main goal of the Module is to support information hiding and modularity by providing common interfaces to the various classes employed as part of the core logic of the application. • Improve inter-module communication support via a MessageBus communication system. The Module Interface The Module interface provides a common base type from which different specialized interfaces are extended. at the initialization phase of the visualization. This allows to minimize dependency on the implementation details of each class.54 data processing was performed only once. Changing data reduction or filtering parameter required re-initializing the complete pipeline.

The read() method is invoke to load a file from a particular data source into a DataSegment object. query the Camera module for view-dependent LOD managemnet. and sends data to be drawn to the Renderer module. All details related to which actual class implements any of the Interfaces is only known to the appropriate factory. Since the routines related to Module management and instantiation provided by all the Factories are exactly the same. Message Bus In order to provide a simple mechanism to provide communication paths between different parts of the application.Graphic rendering subsystem abstraction. a MessageBus system was developed.Abstraction for different camera objects which provide different camera optical simulations and movement behaviors. The Module Factories Each different Module sub-interface has an associated ModuleFactory which is responsible for instantiating the desired Module implementation. each Factory delegates the actual work to a Java Generic-enabled ModuleFactory which each Factory create and use internally. different Renderer modules may use different rendering techniques or hardware capabilities to render the data. The Camera object collaborates with the TerrainModel module (for LOD management) and with the Renderer module (for view parameters) in order to produce the final 3D rendering. Terrain data elements are sent for rendering by calling different draw() methods on a Renderer module.55 • FileLoader .Abstraction which encapsulates different terrain data management implementations. • Camera . The main method invoked by clients using this interface are the init() draw() and update() methods. It employs the FileLoader to read data the actual data.Data source access abstraction. • TerrainModel . The . Internally. All clients using the different Modules and the ModulesFactories are only aware of the public Interfaces mentioned above. • Renderer .

Each ViewPanel contains a TerrainModel object which encapsulates the terrain data management and rendering modules. Once a JVM is ported to a particular architecture. which is binary format design to execute in a virtual architecture call the Java Virtual Machine (JVM) [46].1. To support platformindependent execution. In this implementation. In order to support different levels of sophistication at the GUI level. The first implementation was based on the Java Swing Toolkit. 4.sendMessage() with new Message object. All object interested in generating messages must only invoke MessageBus.56 MessageBus is a Singleton Mediator class implemented as a Java static class. By registering as a MessageReceiver with the MessageBus. real computer architectures. any Java program can run on that architecture. two different implementation of the application GUI where developed. The JVM itself is implemented natively in different. Graphical User Interface The Graphical User Interface (GUI) of the VTE application is based on a ModelView-Controller architecture [45].5 Java Performance Study To successfully use Java technology for performance critical applications as in the case of interactive terrain visualization. The JVM performs many services that were traditionally performed by the Operating System such as thread management and memory . Java application source code is compiled to byte-code. In this implantation the TerrainModel object is bundled as an RCP plugin. The MessageBus takes care of passing the Message object to the Receivers. a ViewFrame (a subclass of a Swing JFrame) contains a ViewPanel (a subclass of a JOGL GLJPanel). The second implementation is based on the Eclipse Rich-Client Platform. it is crucial to first understand the general aspects related to the performance of Java applications. The two GUI version share the same core classes and messaging infrastructure. each object can receive messages from others objects of interest.

minimizes compilation time. all integrated within the Eclipse Rich Client Platform. we performed a performance study of the VTE application.57 management. solution for data collection and testing development built on a common framework which provides the opportunity for different products to be used seamlessly alongside each others and allowing them to make their data collector available to other tools as well. but extensible. For this performance study we used the Eclipse Test and Performance Tools Platform Project (TPTP) [49]. and performs optimized native-code compilation on the hot-spots. JVM implement automatic memory management via Garbage Collection (GC) [46]. Eclipse TPTP is an open source. This approach avoids wasting time compiling infrequently executed code. which periodically reclaims unused memory. However. detects critical performance ”hot spots”. analyzes the run-time execution of the program. Java performance was substantially improved with the development of JIT compilers [47] in which the byte-code of Java applications is compiled into native machine code ”on the fly” during application startup. collaborative integrated testing. TPTP provides a ready-to-use. and allows for continued dynamic optimization of the program based on the actual run-time metrics. tracing. and then executed. the HotSpot engine runs the Java program immediately using an interpreter. during which the JIT compilation was performed [48]. JIT compilation introduced other performance problems related to the application startup time. . profiling and monitoring platform which encompasses everything from data collectors to a data model and viewers. More recent JVMs introduced the Java HotSpot performance engine [48]. Instead of using the JIT approach. In order to identify how identify potential performance problems caused by the use of Java technology. allows focusing on the critical parts of the program. Performance of Java applications running on early JVMs was severely limited due to the interpreted execution of the byte-code.

Results The results of the performance profiling of the VTE applications are presented in the Appendix A. In particular. Total Instances Live Instances Collected Instances Total Size Active Size Base time Memory Usage Number of instances that had been created. Tables A–1 presents the results for the total memory usage profiling. Analysis The results obtained give us a clear indicator of which are the most critical aspects of the application in terms of performance. Java NIO provides classes . A–3 presents the results for the base execution time profiling. Number of calls made by a selected method. A–4 presents the results for the cumulative execution time profiling. The most critical aspects were the data loading and processing and the level-of-detail implementation. Total size of all live instances combined. Cumulative Time Calls Performance Metrics Table 4–1 describes the performance metrics measured during the performance study of the VTE application using the Eclipse TPTP.58 Table 4–1: Performance Metric provided by Eclipse TPTP. Time taken to execute all methods called from an invocation. and c) the size of terrain data structures maintained in memory. A–2 presents the results for memory usage per object instance. we observe performance problems associated with: a) the use of Java NIO classes. Execution Time Time taken to execute the invocation. b) object creation and method invocation inside critical loops. excluding the time spent in other methods that were called during the invocation. The Java NIO classes play a crucial role during the data loading and conversion process. and A–5 present the results of the execution time per method call profiling. Number of instances that were garbage collected. Number of instances (not garbage collected). Size in bytes of all created instances.

each new sample read is compared to determine the minimum and maximum elevation values.2 Model Validation Methodology We employ the following methodology to validate our model via test case study. the most critical part of the application is the LOD implementation. it is possible to use the NIO classes in a sub-optimal way. The LOD implementation builds various quadtrees where each leaf is a block of the original data. do to a naive implementation of the BoundingBox class. Performance Optimizations In order to improve the performance of the application during loading time. the following stratagems were adopted: • Use arrays instead of single values when using NIO Buffers in order to minimize method invocations.59 and methods for high-performance IO operation in Java. during run-time. The third important observation extracted from the results is that. However. • Construct model of test case system. The second observation is that. • Move terrain data processing operations to a offline preprocessing stage. the application invokes buffer. During data loading phase. However. • Minimize method invocation and object creation inside critical loops. In this case. Such is the case of the use of the getters/setters method for minElevation and maxElevation in the BoundingBox class. . which means that even though the algorithm may be able to allow us better interactive rendering. classes and interface that will be used in performance critical methods must be carefully designed in order to minimized any potentially unnecessary overhead. 4. its implementation may require more memory to contain the quadtrees and images.put(floatValue) method inside a loop. each comparison incurred in over six getter/setter operations. as observed in the results for the number of calls metric. This approach results in unnecessary number of method invocations.

1 Test Case Model Evaluation Scope Here we describe the scope of the test case in terms of components considered in the study.z. – Measure actual performance. as well as datasets. – Calculate estimated performance based on the model.a). .w). Each vertex is composed of 4 floats (x. we only consider the main components obtain from the decomposition of the visualization workstation component in the complete interactive visualization system. • Evaluate model for each test platform. data unit characterization.b.y. for a total of 147456 bytes per data unit. Figure 4–1 illustrates the system decomposition process and the final set of components selected for evaluation.60 – Map components into model elements. and each pixel is composed of 4 bytes (r. • Benchmark each test platform. we selected as data unit as combination of a geometry mesh constructed from a 64x64 regular height field and a raster image of 64x64 pixels. The components are: • GPU memory • Main memory • Local disk storage Data unit characterization For the purpose of this test case study. – Measure actual component performance. System Decomposition For the purpose of this test case study.g. • Validate benchmark results against model results. and test systems used to conduct the study.2. 4. The geometry mesh is constructed as a triangle strip where each height samples is represented by two triangles.

z. therefore SP = |P |× 1 byte = 4 bytes. w). We define P = (r. where each value is a byte. DG ) defines a rectangular array of terrain geometry points with width WGD and height HGD . DI )| × SP ) = ((WGD × HGD ) × SV ) + ((WID × HID ) × SV ) = ((64 × 64) × 16) + ((64 × 64) × 4) = 81920 bytes. . Then T DU = (|GD(B. therefore SV = |V |× 4 bytes = 16 bytes. We define V = (x. we restrict both function GD(B. DG )| × SV ) + (|ID(B. pixel and spatial points in the terrain region being transferred. DI ) defines a rectangular array of terrain image pixels with width WID and height HID . • ID(B. DI ) so that: • GD(B. b. a). We use WB = HB = 64. DG ) and function ID(B. • WGD = WID = WB • HGD = HID = HB In other words there is a one-to-one correspondence between geometry points. so every data unit consists of 64x64 points and 64x64 pixels. g. y. where each value is stored as single-precession binary floating point number.61 Figure 4–1: Test Case System Decomposition In this work.

we used four different datasets of 4 different geographic areas: • Island of Hawaii . Figure B–2 shows a screenshot of the visualization of this dataset.This dataset is a generally flat rectangle.This dataset exhibits more surface variability. that is. we choose to model the memory capacity. T ransf erCostout ) = max(T ransf erCostin . • Municipality of Guanica. Datasets For this study. valleys and rivers. Puerto Rico . with high surface detail around the gorge formed by the Colorado River. mountains. with the same conditions in which we start every performance measurement for the formal performance study of the VTE application. we conducted a performance measurement to identify each of the characteristics of interest for each system under the same test conditions. input transfer cost and output transfer cost of each Memory Stage using constant functions. • Grand Canyon National Park . Figure B–1 shows a screenshot of the visualization of this dataset. For each component. Between-Stages Transfer Cost Modeling To model the transfer cost between stages M Si and M Si+1 where: • T ransf erCostin = OT C(M Si+1 ) • T ransf erCostout = IT C(M Si ) we use the transfer cost function: • T C(T ransf erCostin . Figure B–3 shows a screenshot of the visualization of this dataset. since the geographic region features coastlines. .The terrain dataset consists of an island geography dominated by the Mauna Loa and Mauna Kea volcanoes.62 Memory Stage Modeling For the purpose of the validation of our model. The actual values used for the modeling of each component is presented in Table 4–4. T ransf erCostout ).

879. and data units.840 2760 8192 × 5520 723.608 2. The transfer cost units are in seconds per data unit transferred.864 4096 8192 × 8192 1.097.826.152 524.217.304. Table 4–2 describe the size of each dataset in terms of number of pixels/samples.777.728 33.767.104 19456 1024 × 690 11.416 318.216 1024 4096 × 4096 268.879.240 172.944 4.152 128 2048 × 1024 33. we conducted actual performance measurements for each component.While generally similar to the Guanica datasets. Figure B–4 shows a screenshot of the visualization of this dataset.960 2. Table 4–4 presents the performance values for each hardware components.5 2048 × 1380 45.432 8.980.435. Table 4–3 presents the vendor specifications for the components selected for the test case study.922. Table 4–2: Dataset characteristics Area Hawaii-1 Hawaii-2 Hawaii-3 Hawaii-4 GrandCanyon-1 GrandCanyon-2 GrandCanyon-3 GrandCanyon-4 Guanica-1 Guanica-2 Guanica-3 Guanica-4 JobosBay-1 JobosBay-2 JobosBay-3 JobosBay-4 Dimensions Size (bytes) Size (pixels) Terrain Image (Data Units) 1024 × 1024 16. Puerto Rico .068.456 67.554.108.360 11040 Test Systems All test were performed on three different system configurations.741.288 32 1024 × 512 8.691.776 4864 8192 × 9728 1.388.767.736 304 2048 × 2432 79.776 19. this dataset has more pronounced mountain areas and less elevation in the shore region.194.432 2048 1024 × 1216 19.219.922.108.435.304 256 2048 × 2048 67.63 • Jobos Bay Reserve.275.960 690 4096 × 2760 180. In order to analyze the performance of each system based on the hardware performance parameters that approximate more closely the actual performance available during the execution of interactive visualization system.840 11.097.304.360 45.388. .219.608 512 4096 × 2048 134.456 16384 512 × 256 2.517.073.440 180.691.864 16.824 268.554. The memory capacity values are in data units.104 79.944 1216 4096 × 4864 318. bytes.777.216 4.

8278 78. Due to the nature of the HotSpot compiler that is part of the modern JVM.3950 Input Cost 36. the VTE application was enhanced with instrumentation to obtain the pertinent performance metrics. the HotSpot compiler performs analyzes the performance of the code and performs optimizations on-the-fly before the Java code runs at optimal speed.5941 0.0066 45.6871 Component GPU System 3 32 MB 6.31 0.0112 Main Memory Disk Storage 4.03 Output Cost 0.4 GB/s Main Memory Memory Capacity 2 GB 2 GB Memory Bandwidth 5336 MB/s 4264 MB/s Disk Storage Storage Capacity 80 GB 80 GB Transfer Rate 300 MB/s 59.4 MB/s Table 4–4: Test Systems Actual Parameters Component GPU Parameter System 1 Memory Capacity 227. VTE.2.1209 67838.2482 Input Cost 0. Performance measurements obtained .64 Table 4–3: Test Systems Specifications Parameter System 1 System 2 Memory Capacity 256 MB 256 MB Memory Bandwidth 32 GB/s 19. When the JVM loads a Java class.4930 0.44 0.5941 1. These are: • Average frames per second. During these initial phase.86 53. special attention had to be taken in the implementation of the instrumentation code in the VTE.3599 0.1805 0. • Average data units per second.56 0.56 Output Cost 25.4 GB/s 1 GB 2133 MB/s 80 GB 43.86 37.8 MB/s System 3 28.2786 System 2 227.4293 0.1223 Memory Capacity 1338. • Total Transfer Cost.2 Performance Measurement Tests Description In order to measure the performance of the test case system. the initial execution performed via the JVM built-in interpreter.8586 67838.2028 1274.4431 Memory Capacity 67811.56 Output Cost 0.1088 Input Cost 0. • Average triangles per second. running on each of the test platform.

65 during this initial phase will be inaccurate and not indicative of the true performance of the the application. Therefore, before beginning rendering performance measurements, the instrumentation code waits for a fixed time period to allow the HotSpot compiler to stabilize. In addition, to avoid measuring too frequently (which would also hamper rendering performance), the instrumentation code only compute the metrics at fixed time intervals. The default sampling duration is 10 seconds. After waiting for the initial HotSpot optimization phase, the instrumentation code performs a calibration routine, where it computes the number of frames rendered during the sampling period. After doing this calibration, the instrumentation code reports the measurements after these many frames are rendered. In order to obtain a performance measurement representative of real usage patterns while minimizing variability, the test performed consists of a pre-recorded set of viewing operations. These operations form a virtual flight path in which the complete terrain surface is explored by moving the virtual camera over the complete terrain at a predefined set of distances and angles. The same predefined flight path is performed 5 times for each dataset. 4.3 Model Validation Results The complete listing of the test case results are presented in Appendix C. All results are presented in terms of data units. The results of the model performance estimates for each of the data sets are presented in Table 4–5. The results of the performance measurement for the Hawaii dataset are presented in Tables C–1, C–2, and C–3. Figures D–1, D–2 and D–3 present a comparison between the model results and the performance measurements. The results of the performance measurements for the Grand Canyon dataset are presented in Tables C–4, C–5, and C–6. Figures D–4, D–5 and D–6 present a comparison between the model results and the performance measurements.

66 Table 4–5: Model Results - Transfer Cost Dataset # Data Units System 1 System 2 System 3 Dataset # Data Units System 1 System 2 System 3 Dataset # Data Units System 1 System 2 System 3 Dataset # Data Units System 1 System 2 System 3 Hawaii 1 256 0.8206 1.1979 1.7415 Grand Canyon 1 32 0.102572751 0.14974348 0.217687218 Guanica 1 304 0.97444113 1.422563058 2.068028569 Jobos Bay 1 173 0.552931233 0.807210946 1.173470159 Hawaii 2 1024 3.282328016 4.791791353 6.965990971 Grand Canyon 2 128 0.410291002 0.598973919 0.870748871 Guanica 2 1216 3.8978 5.6903 8.2721 Jobos Bay 2 690 2.211724933 3.228843783 4.693880635 Hawaii 3 4096 13.12931206 19.16716541 27.86396388 Grand Canyon 3 512 1.641164008 2.395895677 3.482995485 Guanica 3 4864 15.59105808 22.76100893 33.08845711 Jobos Bay 3 2760 8.846899731 12.91537513 18.77552254 Hawaii 4 16384 52.51724826 76.66866166 111.4558555 Grand Canyon 4 2048 6.5647 9.5836 13.9320 Guanica 4 19456 62.36423231 91.04403572 132.3538284 Jobos Bay 4 11040 35.38759892 51.66150053 75.10209015

The results of the performance measurements for the Guanica dataset are presented in Tables C–7,C–8, and C–9. Figures D–7, D–8 and D–9 present a comparison between the model results and the performance measurements. The results of the performance measurements for the Jobos Bay dataset are presented in Tables C–10,C–11, and C–12. Figures D–10, D–11 and D–12 present a comparison between the model results and the performance measurements. 4.3.1 Discussion

Observing the results obtained, we notice that in general, both the model results and the test results follow a similar pattern of exponential increase as the dataset

67

Figure 4–2: Hawaii Test Case Results - System 2 size increases. The only exceptions are the results obtained for the Hawaii Dataset for System 2 and 3 (see Figures 4–2 and D–3) were the model estimated larger transfer cost than what was actually measured . However, we also observed that the curves for the model and the test results diverge as the dataset size increases. With the exception of the last test (which uses the largest dataset), the model results for the Hawaii set on System 1 (see Figure 4–4) were the ones that most

Figure 4–3: Hawaii Test Case Results - System 3

System 1 Figure 4–5: Grabd Canyon Test Case Results . On the other hand.System 2 closely approximated the actual performance. All other results showed the same general behavior of divergence between the estimated and the actual performance results.68 Figure 4–4: Hawaii Test Case Results . the results for the last test of the Grand Canyon set on System 1 (which consists of the smallest datasets) produced the results with the smallest difference between the estimated and the actual performance (see Figure 4–5). .

CHAPTER 5 CONCLUSIONS AND FUTURE WORK 5. The divergence observed in the results can be attributed to several factors: • Choice of modeling function: – The use of constant functions to model the performance characteristics of the memory stages. 69 . When the dataset size increases beyond certain point. • A Java-based cross-platform interactive terrain visualization tool called Visual Terrain Explorer. Our model can be successfully used to estimate the performance of the system for certain dataset sizes.1 Conclusions In this work we have presented: • A hierarchical memory model for the performance estimation of interactive terrain visualization systems. – The maximum transfer cost as modeling function for the transfer cost between adjacent stages. • A methodology for mapping hardware components in an interactive terrain visualization system into memory stages in the hierarchical memory model. the performance estimations obtain using the model diverge considerably from the performance measurements obtained for our test case. • Software-related characteristics that affect hardware component performance: – OS overhead related to memory management and filesystem management.

and game consoles. By incorporating terrain data characteristic into the hierarchical memory model we were able to construct an improved picture of visualization system in which the most critical performance aspects can be identified. Understanding the performance capabilities required by a visualization system will continue to be critical for the design and implementation of interactive terrain visualization systems. should be capable of providing a consistent and productive user experience. laptops. PDAs. smart-phones. 5.70 – Overhead caused by the choice of Java as implementation technology. Understanding which components of the visualization system are the most critical performance bottlenecks can aid system designer in the selection of both hardware components and software techniques for terrain data management. . for both research and commercial purposes. larger and larger datasets become available due to improved data acquisition systems and larger data storage technology. This future scenario of highly heterogeneous computing systems may limit the effectiveness of previous PC-oriented techniques for terrain data management. and the effect of the automatic memory management by the Java Virtual Machine. As technology continue to advance. the management of terrain data is still the biggest challenge faced by the designer of interactive terrain visualization system. Current technology trends point toward a future of ubiquitous computing. interconnected via the Internet.2 Closing Remarks After more than 30 years of research and enormous advances in computer hardware technology. Future visualizations systems. a great variety of computing platforms such as desktop. The model presented in this research serves as a foundation for characterizing the the hardware components in interactive visualization systems. tablets.

• Remote server data layout and indexing. In particular: • Parallel GPUs. • Parallel Disk1 .2 System Studies In terms of system configurations used as part of the performance study. 5.3. a performance study should be performed focusing on interactive terrain visualization systems implemented in other programming languages or technologies other than Java.3 Future Work We propose the following areas as potential future extensions to the work presented here: 5. .71 5.3. can be extended to take into consideration system configurations with parallel components. Additional System Components Extend the depth of the performance study by taking into account more components in the visualization system. For example: 1 Parallel disks are considered in the HMM-related literature. System Implementations In order to further validate the model. several future research direction are possible. in particular: • CPU cache. • Parallel Remote Servers. Different High-level System Configurations Performing studies using visualization systems view different composition than the configurations considered in this work.1 Model Enhancements The model presented in this research.

3.72 • Mobile and embedded devices. the model presented can be extended or adapted to incorporate data characteristics and access patterns for other problem domains.3 Problem Domain Studies 2 . such as: • Visualization of arbitrary 3D geometry. 2 Incorporating the work previously presented in [36]. • Game consoles. . • Data streaming with multiple cache nodes 5. Finally. • General multimedia systems.

APPENDICES .

APPENDIX A VTE JAVA PERFORMANCE PROFILING RESULTS Table A–1: Memory Usage .Vertex 96 vte.TerrainBlock 128 vte.datatypes.LODTerrainModel 80 vte.model.data.datatypes.geomipmap.GeoMMLandscape 72 vte.Light 96 vte.Thread 672 java.model.geomipmap.Vector 240 vte.Class 33408 vte.datatypes.model.model.BoundingBox 72 vte.lang.model.Angle 96 vte.geomipmap.messagebus.Patch 200 vte.ModuleFactory 48 74 .util. Class Total Size java.datatypes.module.model.geomipmap.datatypes.geomipmap.lang.TimerThread 416 vte.datatypes.QuadTreeNode 176 vte.Message 120 vte.Position 160 vte.SurfaceData 96 vte.TerrainBlock 1152 java.Total Size.

TimerThread 4 vte.TerrainBlock 4 vte.png.data.data.geomipmap. int.QuadTreeNode 6 vte.ModuleFactory 2 vte.07 1.geomipmap.geomipmap.camera.geomipmap.SurfaceData 2 vte.model.Vertex 6 vte.Fully3DCamera 1 Table A–3: Execution Time .nio.Light 2 vte.Total Instances.messagebus.geomipmap. int) biLinearInterp(int[]) calcDn2(float) read(int.25 0.TerrainBlock sun.24 0.geomipmap.Random vte. float) ix(int) checkIndex(int) gluBuild2DMipmaps(GL) get(int.88 0.TerrainBlock java.model.plugins.DirectFloatBufferU java.lang. int) putFloat(long. Class Total Instances java.Angle 6 vte. float) findBlockCenter() Time 17.29 0.7 2.Thread 7 vte.nio.Math vte.94 1.datatypes.geomipmap.21 0.Unsafe java.mipmap.model.lang.lang.nio. int.TerrainBlock vte.datatypes.datatypes.12 6.65 0.geomipmap.98 3.misc.geomipmap.data.25 0.Buffer opengl.DataType 3 vte.Vector 15 java.file.source.model.model.TerrainBlock Method put(int.17 . float) setupTextures(GL) abs(float) putSample(int.TerrainBlock imageio.75 Table A–2: Memory Usage .72 0.model.SurfaceData vte.FileLoaderFactory 2 vte.datatypes.BoundingBox 3 vte.Base.LODTerrainModel java.55 1. float) setVertexAndShading(int.95 4. Class java.HeightMap2Df vte.util.geomipmap.data.model.Class 348 vte.ImageReadParam) renderBlock(GL) next(int) access(GeoMMLandscape) max(float.loader.GeoMMLandscape java.util.71 3.impl.Patch 5 java.geomipmap.Position 5 vte.Math vte.model.datatypes.77 0.model.model.datatypes.model.Message 5 vte.PNGImageReader vte.lang.DirectFloatBufferU vte.TerrainBlock 16 vte.model.Mipmap vte.

awt.model.gui. float) checkIndex(int) ix(int) putFloat(long.Math java.DataBuffer Method put(int.TerrainBlock vte.Math vte. int) setVertexAndShading(int.Patch vte.model.82 4. ActionEvent) openActionPerformed(ActionEvent) calcDn2(float) Time 38.nio. float) GeoMMLandscape(HeightMap) initPatches(int.model.misc.geomipmap.geomipmap.model.model.geomipmap.SunWritableRaster vte.TerrainBlock java.nio.MultiFrameGUI vte.geomipmap. int) next(int) getMaxElevation() getMinElevation() setSample(int. float) putSample(int. float) abs(float) biLinearInterp(int[]) getSample(int.TerrainBlock vte.datatypes.nio. int.model.geomipmap.GeoMMLandscape vte.Buffer java.awt.MultiFrameGUI vte.BoundingBox java.MultiFrameGUI vte.84 11.82 4. int.model. int.lang. int.gui.geomipmap.model.model.geomipmap. float) getElemFloat(int. float) init(GLAutoDrawable) init(GL) putFloat(long.TerrainBlock sun.gui. float) get(int.awt.geomipmap.Random vte.HeightMap2Df vte.Cumulative.image. int) Calls 5591040 5591040 5591040 5591040 2854256 931840 931840 436912 371377 371376 196608 131072 66050 66050 66049 66049 66049 66049 .67 4. Class vte.TerrainBlock vte.model.76 Table A–4: Execution Time .LODTerrainModel sun.geomipmap.77 38.gui. int.model.DirectFloatBufferU vte.51 11.model.TerrainBlock Method display(GLAutoDrawable) draw(GL) render(GL) render(GL) render(GL) renderBlock(GL) setVertexAndShading(int.geomipmap.util. int.datatypes.model.78 4.nio. int.67 4.misc.awt.BandedSampleModel sun.BoundingBox vte.lang.77 38.Unsafe vte.image.Calls Class java.model. DataBuffer) setSample(int.78 38. float) TerrainBlock(GeoMMLandscape) actionPerformed(ActionEvent) access(MultiFrameGUI.geomipmap.GeoMMLandscape java.78 38.geomipmap.image. int.51 Table A–5: Execution Time .GeoMMLandscape vte.98 4.LODTerrainModel vte.DirectFloatBufferU java.SurfaceData java.78 29. int.image.TerrainBlock vte.77 37.77 38.GeoMMLandscape vte.ByteInterleavedRaster java.model.Unsafe vte.ViewPanel vte.DirectFloatBufferU sun.82 4.data.gui.67 4. int.geomipmap.ViewPanel vte. int) put(int. int) access(GeoMMLandscape) max(float.

APPENDIX B TERRAIN DATASETS Figure B–1: VTE visualization of the Hawaii dataset. 77 .

78 Figure B–2: VTE visualization of the Grand Canyon dataset. Figure B–3: VTE visualization of the Guanica dataset. Figure B–4: VTE visualization of the Jobos Bay dataset. .

797.572.565.1421 0.7260 305.6910 391.924.1724 0.6230 256.0107 1.432.2790 104.0133 2.0472 87.9288 1.6708 3.1318 Average Average Average Triangle Rate Data Units Rate Transfer Cost 1.767.4378 864.3000 394.9543 1.8030 104.8370 1.9464 Hawaii-1 Average Hawaii-2 Average Hawaii-3 Average Hawaii-4 Average 79 .7825 1.764.9210 87.040.4452 2.2853 18.7202 1.7230 376.419.4612 1.199.3450 102.5140 401.601.9590 28.5650 48.1794 1.9067 10.382.APPENDIX C TEST CASE PERFORMANCE MEASUREMENTS RESULTS Table C–1: Hawaii .8390 1.864.6620 927.252.6000 393.087.9794 382.2770 112.541.2810 368.0770 87.0000 1.1260 346.7430 113.5417 10.5100 872.0989 10.9360 382.9246 1.124.7560 18.1106 2.7080 87.530.6495 1.619.579.565.3246 10.8769 0.736.754.076.5235 3.497.885.507.153.4700 31.611.603.0800 385.4138 1.6140 2.8350 349.862.0780 33.1054 108.6799 1.1934 1.6323 2.8275 10.5780 113.308.1370 934.7852 17.880.060.7999 0.7407 10.829.249.4782 2.7197 1.919.1818 17.9756 17.5520 24.6185 1.660.614.134.3130 292.2528 3.9320 469.8480 675.0620 102.9298 3.093.0490 24.7470 102.994.731.1858 305.645.0320 913.System 1 Average Frame Rate 108.9670 276.742.8743 1.8508 0.542.8481 2.7230 87.4900 112.4390 112.7828 3.3960 87.057.048.1030 33.7642 390.

3150 363.7298 48.80 Table C–2: Hawaii .949.6470 45.0730 112.6930 36.488.4020 36.9220 71.2350 36.904.1529 411.0555 5.6580 280.343.6555 25.7691 11.2995 379.6860 327.058.3600 297.5744 34.316.3670 69.8130 100.4480 280.7917 49.6005 505.0632 345.194.7249 10.2440 71.5877 3.9108 2.6552 1.3366 50.1172 1.383.982.6154 9.634.342.5960 36.9098 14.4543 58.0496 408.3272 487.8420 51.7007 210.5960 118.4498 45.341.5290 45.690.1758 3.6640 45.0873 417.571.5122 1.206.148.2031 860.665.5870 45.0791 1.4490 84.1610 101.3380 95.5068 1.799.0360 99.4030 48.7488 41.6046 461.361.System 2 Average Frame Rate 71.557.395.0664 436.3620 33.2270 337.9838 196.150.2574 55.606.2270 71.566.6130 45.217.9781 19.4230 92.0600 67.5304 69.1216 77.9830 1.361.9870 Hawaii-1 Average Hawaii-2 Average Hawaii-3 Average Hawaii-4 Average .4920 209.7290 106.6798 10.0382 391.4301 2.835.7980 68.6492 321.5812 653.1870 36.1448 101.0226 Average Average Average Triangle Rate Data Units Rate Transfer Cost 283.696.3610 45.5940 123.8050 66.7024 416.6848 9.070.740.3662 4.5490 317.2789 48.4195 1.5330 71.6150 69.9540 69.8948 10.0038 159.290.7260 71.

7060 19.556.6180 49.584.4498 19.2683 19.5980 176.6497 19.5392 202.0480 18.3721 19.5230 19.7640 36.962.7573 Hawaii-1 Average Hawaii-2 Average Hawaii-3 Average Hawaii-4 Average .9615 8.8076 140.7230 939.6070 229.8080 45.8950 838.687.8619 19.341.3000 30.5441 18.990.8877 8.8640 164.6826 19.2583 18.8040 19.7580 118.930.2104 22.912.9720 5.6427 129.1201 12.830.5102 20.7738 19.222.9310 466.4240 18.3400 144.501.1970 779.2160 437.549.1958 23.3320 412.81 Table C–3: Hawaii .8310 143.793.181.9080 199.3189 18.2990 126.9420 208.0535 19.9624 18.9262 19.3719 18.692.9300 1.732.8280 126.0114 35.221.2480 853.8510 649.4510 35.493.6701 103.3620 223.8480 158.1160 55.370.5220 185.2167 18.3060 229.7902 6.7210 40.3390 48.7450 54.1392 152.921.1002 39.0026 7.9014 1.412.752.6516 19.4309 19.3138 19.0820 43.9584 19.0660 518.3908 71.1750 6.8923 38.3634 7.8900 28.3081 21.7570 150.9520 190.357.818.6772 80.3615 19.4252 34.6120 114.6380 21.227.1570 591.8128 26.728.2980 19.1498 625.8500 106.9760 204.323.4212 28.System 3 Average Average Average Average Frame Rate Triangle Rate Data Units Rate Transfer Cost 19.

158.1037 0.2120 2.1761 11.System 1 Average Frame Rate 61.9310 40.5390 40.656.921.0139 9.3973 0.949.452.592.858.5470 2.218.8903 0.911.960.8970 2.923.3965 0.7157 11.0201 0.6661 0.6150 40.7110 GrandCanyon-1 Average GrandCanyon-2 Average GrandCanyon-3 Average GrandCanyon-4 Average .9740 2.0479 11.384.415.859.8720 2.3988 2.1921 0.863.7324 0.061.327.6550 2.0580 2.1761 11.7040 41.8149 0.7460 40.873.0025 0.5302 0.4970 63.108.7800 38.357.727.3676 43.721.9270 2.907.8110 61.543.0270 2.0133 9.1486 55.6481 0.2080 2.7285 0.283.0134 10.0132 9.4583 0.7790 2.0132 9.784.431.455.0474 10.880.964.895.6299 0.632.798.7083 0.767.1768 11.0477 10.0310 2.8003 0.1830 2.8010 53.710.9902 2.5228 42.0210 52.7245 0.0135 9.7330 2.171.142.966.6270 53.2226 Average Average Average Triangle Rate Data Units Rate Transfer Cost 9.6943 12.174.655.936.82 Table C–4: Grand Canyon .9912 0.963.8680 38.861.878.907.5722 0.3760 2.7950 62.0493 10.3126 0.7990 2.082.888.660.681.898.894.908.766.3760 40.772.0481 11.1752 11.887.9980 2.1440 2.8350 61.0432 0.051.5530 52.420.829.822.384.972.595.3182 2.5500 39.8300 2.6279 0.700.6120 53.982.7509 11.6908 11.7065 12.441.398.8420 41.8050 61.6531 0.6060 2.1773 11.5240 2.669.370.043.330.898.307.0482 10.1753 11.

5590 38.797.043.230.030.864.3714 0.928.112.9600 2.0593 10.1800 31.471.905.042.489.7860 2.525.1570 2.686.0968 0.542.408.0168 8.9570 0.5270 29.2126 10.648.4760 31.081.936.036.519.8900 2.0038 0.6206 2.0172 7.9905 0.7640 2.2090 9.751.631.2500 37.8286 10.843.5896 0.137.903.598.5290 31.4050 44.0574 8.468.0163 7.374.459.2117 9.055.207.6560 1.450.444.467.244.986.912.960.076.System 2 Average Frame Rate 43.0588 9.8300 1.6649 0.0610 8.631.6890 45.0876 30.0300 1.297.7522 2.0615 8.9380 45.195.863.9430 0.0174 7.5020 2.012.7030 0.8630 2.7847 0.835.949.0993 0.2095 10.4110 37.0166 8.7894 Average Average Average Triangle Rate Data Units Rate Transfer Cost 7.031.519.6170 2.7901 0.105.036.023.6560 1.7013 0.1318 0.2562 38.317.425.8325 10.839.260.0580 9.120.103.3688 0.8230 29.3107 0.4410 2.158.5810 2.9176 29.897.099.2160 43.456.1735 0.4640 2.83 Table C–5: Grand Canyon .9320 2.7370 2.6450 37.2033 10.0830 29.2546 0.6990 29.418.5050 2.847.134.939.2660 2.930.8150 29.9252 0.8295 GrandCanyon-1 Average GrandCanyon-2 Average GrandCanyon-3 Average GrandCanyon-4 Average .123.0422 0.905.9355 0.0166 7.2166 0.1438 1.7230 37.8336 10.175.4290 2.673.2990 30.0330 43.7187 0.5470 1.472.8301 10.3774 0.2111 9.9540 32.8227 10.062.

467.4359 4.9960 729.0431 2.487.7480 1.4388 4.6889 0.171.1717 3.3800 14.396.2290 12.8130 16.6290 1.1689 3.916.822.166.4660 5.421.671.1392 0.368.9756 1.453.8150 16.5472 0.172.7370 16.608.155.7392 0.9730 757.3053 0.523.688.171.2520 1.662.4371 5.170.176.052.84 Table C–6: Grand Canyon .999.4170 14.0454 2.9065 1.770.0437 2.8982 0.0440 3.778.011.174.2580 726.055.5156 745.723.1693 3.2384 Average Average Average Triangle Rate Data Units Rate Transfer Cost 2.368.4962 5.System 3 Average Frame Rate 16.5377 1.9944 13.3800 14.959.2534 0.3322 13.8545 0.4357 1.4730 GrandCanyon-1 Average GrandCanyon-2 Average GrandCanyon-3 Average GrandCanyon-4 Average .6189 0.6722 727.1754 3.053.2910 704.009.722.606.0436 3.801.799.3870 734.974.237.4886 5.4373 4.0831 0.2380 1.103.5990 16.472.6780 14.2550 732.3690 756.7677 0.266.0510 1.7713 1.795.032.4062 13.811.4370 4.7560 16.037.200.8732 0.5950 740.4028 13.8850 1.2334 13.635.797.694.7455 1.3286 1.388.8876 0.885.6900 16.4747 5.963.4367 4.4408 5.825.2930 0.7420 16.3970 14.9100 1.0441 3.981.8146 16.4169 1.1716 4.4687 0.820.2957 0.1700 741.9300 16.989.9120 1.6885 0.4570 14.096.785.8300 16.7149 1.6826 0.5510 16.6450 745.375.390.3117 1.1729 2.

7420 22.786.2856 1.7130 22.3880 10.0580 2.6890 22.8000 2.651.2730 2.4300 1.8631 2.259.571.750.2099 0.5466 7.5594 8.5579 8.315.8430 2.9720 1.9854 1.966.173.138.636.144.2090 59.737.5936 Average Average Average Triangle Rate Data Units Rate Transfer Cost 7.684.526.5944 0.7017 12.6800 2.7016 0.5009 8.0700 28.504.9910 1.7767 0.5670 7.832.85 Table C–7: Guanica .9690 2.148.9418 10.7170 2.633.730.580.7440 22.3777 10.2480 59.782.086.8982 7.8740 77.1547 0.6922 7.644.638.928.582.954.1000 2.801.179.System 1 Average Frame Rate 75.1220 7.5841 8.0216 22.9766 0.9570 38.637.8120 77.0830 2.3310 75.740.5763 0.042.4170 44.5120 1.2220 2.7680 59.2130 36.745.806.5640 7.432.4568 7.697.939.0864 0.9210 2.735.1050 2.800.1705 7.677.944.128.2720 2.3680 77.390.184.7010 2.063.858.149.1742 7.185.951.7167 0.707.630.9630 2.974.537.081.995.927.760.0752 59.6640 60.0712 2.930.784.3298 0.9527 1.7553 1.977.1747 7.8846 11.2474 10.429.2255 10.3784 10.4436 0.3570 Guanica-1 Average Guanica-2 Average Guanica-3 Average Guanica-4 Average .754.775.4510 31.159.301.9910 78.0800 22.8260 1.3958 10.711.4714 0.153.8690 2.102.1733 7.000.5293 2.169.8772 1.7320 49.5685 8.6462 10.303.6260 1.7710 59.1757 7.903.5656 8.1737 8.

550.6306 6.2368 5.3636 0.713.3940 51.6006 55.3700 18.289.7873 0.8010 51.8426 40.6877 10.532.5697 1.408.2390 2.3089 0.1940 1.605.301.8530 1.9436 7.6269 7.8707 0.518.328.311.956.865.8082 2.909.046.324.5639 0.9083 0.517.945.674.222.7843 6.624.4790 49.725.2053 9.2262 5.4864 9.5770 1.504.215.066.1171 1.4203 12.283.3999 6.7750 1.8600 15.6320 959.1550 7.7530 1.049.289.6420 1.System 2 Average Frame Rate 50.857.3070 23.301.7350 1.2350 24.3630 1.1570 3.592.6232 14.258.5605 11.2349 3.278.343.350.012.7021 12.6613 6.704.8160 9.103.440.6660 1.543.282.5510 41.838.965.6690 51.0390 Average Average Average Triangle Rate Data Units Rate Transfer Cost 5.2970 17.2406 5.6760 37.6204 Guanica-1 Average Guanica-2 Average Guanica-3 Average Guanica-4 Average .3050 17.258.553.3508 2.2357 5.254.3462 0.2760 1.4987 3.928.7595 0.1900 51.536.2629 0.490.263.412.8740 1.5951 8.6330 12.0890 11.2470 16.174.5146 2.6160 12.6060 10.916.924.2678 5.7020 1.4220 2.939.147.8160 39.152.8335 10.2354 5.361.6910 44.2072 2.9490 52.6860 2.734.457.030.7500 2.291.403.053.1890 3.86 Table C–8: Guanica .168.9164 7.3333 0.1798 1.548.4148 1.2049 6.9214 2.6940 2.722.4200 1.7048 7.372.294.9460 23.218.288.0770 5.6374 0.341.

System 3 Average Frame Rate 17.1702 11.006.9720 253.2384 4.6719 4.7373 3.8710 13.4529 1.107.0018 1.956.8880 453.267.959.362.3844 3.6160 14.1863 2.026.244.4746 4.4912 1.0868 1.482.1056 2.8291 4.8720 992.823.7191 1.0760 15.0190 403.6933 3.1440 1.018.1050 4.0980 15.2700 516.288.943.3230 279.9498 1.2688 0.097.3631 2.311.534.349.729.299.4420 1.7876 1.789.665.836.039.0022 17.7538 1.3970 1.6340 512.7544 910.1769 17.2400 303.368.2020 834.670.1950 12.0160 13.4572 1.3660 466.234.452.4800 320.9400 12.3790 1.5400 12.513.7960 11.242.3330 578.140.4060 260.947.066.1229 1.728.4327 5.0318 4.7856 494.2730 2.594.3300 14.527.9790 14.114.087.866.4076 13.893.87 Table C–9: Guanica .5124 14.2136 5.8824 13.8625 2.5216 5.065.417.0533 15.4305 14.1500 478.8170 14.4166 16.275.0009 10.6004 5.2658 4.4164 1.918.491.3557 2.855.1025 2.4130 15.438.1979 1.1510 1.651.9140 12.8853 41.5726 Guanica-1 Average Guanica-2 Average Guanica-3 Average Guanica-4 Average .4970 15.662.996.5410 389.1674 1.145.3641 4.036.584.6328 19.3870 1.7960 14.3438 1.4179 5.7870 12.4720 13.8150 Average Average Average Triangle Rate Data Units Rate Transfer Cost 1.975.5425 2.3745 2.416.912.0729 0.

0150 46.933.6430 77.622.4281 6.734.996.001.592.1486 7.4287 5.495.5050 1.439.8605 9.0910 73.6160 1.9450 79.0050 1.853.607.3923 4.569.7584 6233439.429.644.88 Table C–10: Jobos Bay .621.1430 37.9786 6.0973 6.4351 6.0989 6.471.4260 53.1019 6.757.379.2140 1.443.736.2287 8.5770 73.6840 0.184.9062 5.8170 79.580.3500 1.8136 3.2390 37.1690 1.199.7190 78.6353 13.0640 36.5220 37.System 1 Average Frame Rate 84.869.6400 1.142.233.6120 1.382.2421 0.6450 1.743.150.6371 1.2990 839.4496 6.4832 0.2580 1.5655 0.670.285.1630 58.3272 83.1000 1.580.772.9750 1.8374 1.067.688.0424 1.263.0230 2.4183 0.639874 5.146.9590 77.102.8166 76.842.3233 4.4290 6.773.1620 1.1870 2.7468 6.925 1866.616.9434 1.0657 0.4131 6.6341 7645756.447.8169 0.303.5460 73.201.1510 71.9300 2.0995 7.8582 0.509.6540 1.2710 72.9708 Average Average Average Triangle Rate Data Units Rate Transfer Cost 6.468.703.713.611.9021 1.814.733.497 1521.609.4195 6.259.4605 0.9730 1.4194 5.982.9144 JobosBay-1 Average JobosBay-2 Average JobosBay-3 Average JobosBay-4 Average .7502 0.7072 6.1850 1.394.835815 1.802.977.8740 1.2854 1.1142 7.585.206.1013 7.534.8669 0.400.625.5806 38.602.5090 60.8893 0.271.930.7900 49.3400 9.692.8860 40.

529.6550 0.097.7990 847.7210 399.0040 54.9920 68.2130 53.4305 1.1910 54.170.423.3510 46.4333 199.788.827.385.070.608.065.8935 0.7457 0.4986 9.4307 1.360.833.7004 0.7800 392.2680 1.349.6760 953.4323 13.1950 0.5910 847.996.019.102.5810 54.9660 38.9800 1.0235 2.906.6218 0.4321 1.5060 350.1173 4.436.722.7592 3.629.4769 2.376.2150 1.9640 400.3106 Average Average Average Triangle Rate Data Units Rate Transfer Cost 1.905879 2.359.9420 61.3275 2.407.641.89 Table C–11: Jobos Bay .3000 1.6820 60.48 1067.396.7235 2.6005 13.630.771.8630 40.7230 825.926 1094.7326 53.0520 50.6546 5.3260 64.7910 43.382.9010 908.6170 1.4949 0.6460 46.847.166.055.308.4800 1.7380 400.471.6580 48.5647 4374142.253888 10.068.8292 1.5334 1.0276 4.055.770.5703 2.3372 5.4368 4482063.324.2410 43.1430 53.416.System 2 Average Frame Rate 71.6928 617.3530 1.0250 3.321.143.6161 4.4260 1.7210 60.426.8264 49.5050 397.471.1815 8.073.6508 0.0891 JobosBay-1 Average JobosBay-2 Average JobosBay-3 Average JobosBay-4 Average .6810 41.9668 3.1416 0.635.5714 4.5565 8.4337 1.0210 40.082.2008 1.1312 2.683.064.640.0220 39.5888 14.076.178.4394 1.1416 398.5781 4.5928 4.6162 35.847.8357 3.5845 3.

269.254.9135 6.5160 199.004.32 1.9397 32.1320 19.8120 295.2680 19.443.90 1.145.5136 31.0990 18.298.4303 966.8302 789.3270 283.2140 341.003.52 JobosBay-1 Average JobosBay-2 Average JobosBay-3 Average JobosBay-4 Average .8250 15.567.8430 766.6691 2.429.5426 18.403.0540 17.5970 298.64 1.873.78 1.1939 7.7047 815.9231 1.0128 0.1390 3.6870 102.162.2612 0.585.37 1.05 1.0660 18.533.1315 0.223.29 1.3220 349.9146 2.7790 15.0950 16.9750 15.675.602.4130 16.130.089.836.7460 352.444.044.6090 348.2540 18.4660 204.5799 31.6610 207.3350 266.5560 13.0479 2.5260 16.197.028.078.System 3 Average Frame Rate 20.8248 838.456.6254 0.400.4010 245.8054 16.7200 457.90 Table C–12: Jobos Bay .1878 236.0379 11.9480 17.167.03 1.895.3019 31.3288 Average Average Average Triangle Rate Data Units Rate Transfer Cost 851.4780 254.390.0900 15.2512 314.2440 19.5674 31.060.9088 31.8760 192.211.5140 187.9224 820.3708 6.673.83 1.430.6950 19.0423 10.5950 350.8614 421.852.9620 355.31 1.7656 0.9750 18.434.4910 18.5152 8.4649 1.709.7030 209.288.9210 13.7707 0.914.9310 10.6032 2.3337 1.3740 19.8440 200.4440 352.8949 856.26 1.3108 1.

System 3 Results Comparison 91 .System 1 Results Comparison Figure D–2: Hawaii Dataset .APPENDIX D TEST CASE RESULTS COMPARISON Figure D–1: Hawaii Dataset .System 2 Results Comparison Figure D–3: Hawaii Dataset .

System 2 Results Comparison Figure D–6: Grand Canyon Dataset .System 1 Results Comparison Figure D–5: Grand Canyon Dataset .92 Figure D–4: Grand Canyon Dataset .System 3 Results Comparison .

93 Figure D–7: Guanica Dataset .System 2 Results Comparison Figure D–9: Guanica Dataset .System 1 Results Comparison .System 1 Results Comparison Figure D–8: Guanica Dataset .System 3 Results Comparison Figure D–10: Jobos Bay Dataset .

System 3 Results Comparison .System 2 Results Comparison Figure D–12: Jobos Bay Dataset .94 Figure D–11: Jobos Bay Dataset .

[9] A. Variable resolution triangulations. Patterson and J. A. The Quadtree and Related Hierarchical Data Structures. 1993. Elsevier Science Inc. pages 199–207. Puppo. Morgan Kaufmann Publishers Inc. CA. [5] J. K. 1979. NY. Hansen and C. Samet.REFERENCE LIST [1] A. Ogren.H..D.A. Computer organization & design: the hardware/software interface. Zachmann. Little. Advanced Animation and Rendering Techniques: Theory and Practice. [6] R. Peters. [4] David Luebke. 19(10):547–554. 1976. Watt and M. Addison-Wesley Pub. Clark. and Amitabh Varshney. New York. Martin Reddy.. [2] C. San Francisco. Continuous Level of Detail In Real-Time Terrain Rendering. The Visualization Handbook. [10] E. Elsevier. Benjamin Watson. Langetepe and G. Geometric Data Structures for Computer Graphics. Level of Detail for 3D Graphics. 95 . USA. USA.H. Computational Geometry: Theory and Applications. Hennessy. 2000. Proceedings of the 6th annual conference on Computer graphics and interactive techniques. Hierarchical Geometric Models for Visible Surface Algorithms. Watt. [7] H. Communications of the ACM. 2006. 1998. Sweden: Sweden Umea University. 16(2):187–260. Automatic Extraction of Irregular Network Digital Terrain Models. [3] D. [8] E.J. 1992.R.. Ltd. 2005. 2002.J. USA. Fowler and J.L. Natick. 1984. Johnson. ACM Computing Surveys (CSUR). 11(3-4):219–238. Jonathan D. Cohen. MA.

continuous level of detail rendering of height fields. [20] J. W. Hoppe. available at http://www. Leclerc and S. [17] H. Fast view-dependent level-of-detail rendering using cached geometry. pages 1–8.H.F. ACM Press New York. pages 1–11. [21] S. Hoppe. and N. Time-critical rendering of discrete and continuous levels of detail. 19(2):30–38. Quick-VDR: Interactive View-Dependent Rendering of Massive Models. Mantler. Salomon. Proceedings IEEE Visualization’02. Fast Terrain Rendering Using Geometrical MipMapping. Iverson. 1998. Unpublished paper. and G. Progressive meshes. [12] M. Pyramidal parametrics. TerraVision: A Terrain Visualization System. Hoppe. Technical Note. Gayle. Real-time.G. 1997. [19] W. pages 259–266. 1996. 1994. View-dependent Refinement of Progressive Meshes. IEEE. NY. R. and D. 31:35–42. Proceedings of the 24th annual conference on Computer graphics and interactive techniques. [15] P. and K. 1999. Smooth View-Dependent Level-of-Detail Control and Its Application to Terrain Rendering. SRI International. L. pages . com/articles/article geomipmaps. Yoon. Levenberg. Leclerc. Reddy.Q. USA. [18] H. IEEE Visualization ’98. flipcode. S. Faust. 2002. IEEE Visualization 2004. Proceedings of the 23rd annual conference on Computer graphics and interactive techniques. Proceedings of the ACM symposium on Virtual reality software and technology. 2002. pages 189–198. Bletter. 1983. Manocha.96 [11] Y. Hodges. Koller. L.pdf.A. TerraVision II: Visualizing Massive Terrain Databases in VRML. B. 2000. Turner. Lindstrom. Ribarsky. Proceedings of the 10th annual conference on Computer graphics and interactive techniques. Karner. Y. 1996. de Boer. Lau. N. pages 99–108. [13] L. Computer Graphics and Applications. [16] H. D. Williams. 540. [14] C. Zach.E.

2004. M. 2005. and R. 2004. Proceedings of the conference on Visualization ’01. pages 439–442. Scopigno. 2003. Zhu. 2002. Multiresolution compression and reconstruction. [29] A. Sweldens. Cignoni. 278. Visualization of Large Terrains Made Easy. Proceedings of IEEE Visualization 1997. 9(4):525–537.G. Visualization and Computer Graphics. Proceedings of the 27th annual conference on Computer graphics and interactive techniques. [23] F. 235. External Memory Management and Simplification of Huge Meshes. Montani. Vertex data compression through vector quantization. 2005. IEEE Transactions on Visualization and Computer Graphics. International Conference on Computer Graphics and Interactive Techniques. [28] O.97 131–138. Progressive geometry compression. Real-time visualization of large textured terrains. pages 769–776. Hoppe. [26] X. [22] Y. Visualization and Computer Graphics. pages 363–371. Weber. 11(3):306–316. Gross. and W. 2000. C. Khodakovsky. IEEE Transactions on. Pajarola. and R. Pascucci. P. [27] P. [25] P. [30] PH Chou and TH Meng. In GRAPHITE ’05: Proceedings of the 3rd international conference on Computer graphics and interactive techniques in Australasia and South East Asia. Staadt. 1997. C. Proceedings SPIE Conference on Visualization and Data Analysis. Lindstrom and V. . 2003. Bao and R. Geometry Clipmaps: Terrain Rendering Using Nested Regular Grids. Uniform Remeshing with an Adaptive Domain: A New Scheme for View-Dependent Level-of-Detail Rendering of Meshes. Losasso and H. 8(4):373–382. Rocchini. Schroder. [24] Anders Brodersen. IEEE Transactions on.H. LOD-based Clustering Techniques for Efficient Largescale Terrain Storage and Visualization. 2001.

2007. Varshney. Journal of WSCG (S1213-6972). Lemieux. To. Byung-Hoon Park. [32] A. A method for progressive and selective transmission of multi-resolution models. 2005. Jian Huang. Carter. Eclipse Rich Client Platform: Designing. Generic Mesh Refinement on GPU. [33] S.uprm.G. N. 14(1):49–56.98 [31] D. IEEE Transactions on Visualization and Computer Graphics. [37] R. 1998. ACM Transactions on Graphics (TOG). and S. 2005.S. Streaming terrain rendering. and M. 1946. Princeton. Springer. 1996. Schlick. Meta-Heuristics: Theory and Applications. [40] The walsaip project. McAffer and J. 2006. Proceedings of the 30th PSIG Annual Meeting.P. [39] Preliminary Discussion of the Logical Design of an Electronic Computing Instrument. Westermann. Jinzhu Gao. of Advanced Study. pages 99–104. [38] I. Osman. Bhattacharjee. Schneider and R. Proceedings of the ACM SIGGRAPH/EUROGRAPHICS conference on Graphics hardware.H. PJ Narayanan. [41] J. Chad Jones. http://walsaip. GPU-Friendly High-Quality Terrain Rendering. Lau. Boubekeur and C. 24(2):348– 373. A multi-level cache model for run-time optimization of remote visualization. 2006. Proceedings of the ACM symposium on Virtual reality software and technology. . pages 88–95. Addison-Wesley Professional.edu/. [36] Robert Sisneros.W. 13(5):991–1003.. and Nagiza Samatova. R. Deb. 2005. [35] T. and Packaging Java (TM) Applications. Inst. Kalaiah and A. 1999. International Conference on Computer Graphics and Interactive Techniques. Green. Pipeline optimization: dynamic programming after 30 years.J.M. [34] J. Coding. Statistical geometry representation for efficient transmission and rendering.H.

1987.. Design patterns: elements of reusable object-oriented software. Helm. MA. [47] W.java. R. 1999. and J. https://jogl. . R. Vlissides.dev. Technical report. Inc. [43] Jogl: Java binding for opengl.org/tptp/. The Java Hotspot Performance Engine Architecture. sun. McGraw-Hill Professional.org. 39(1):135–150. Johnson. Softsmarts Inc. [44] E. Applications Programming in Smalltalk-80 (TM): How to use Model-View-Controller (MVC).net. [48] S. Microsystems. Gamma. 1995. http://www. White paper (http://java. com/products/hotspot/whitepaper.. 2006. Burns.opengl. [49] Eclipse test & performance tools platform project. Sun Microsystems. IBM Systems Journal. USA. Inside the Java Virtual Machine.eclipse. Burbeck. Gu and N. 2000. [46] B. Evolution of a high-performing Java virtual machine. April. html). http://www. Addison-Wesley Longman Publishing Co. Boston. [45] S.99 [42] Opengl the industry standard for high performance graphics. Venners.

S. Gonz´lez Flores. degree in Computer Engineering at the University of Puerto Rico. and software tester. He has worked as software developer. Mayag¨ez Campus. object-oriented programming. 100 .BIOGRAPHICAL SKETCH Ricardo Veguilla Gonz´lez was born in June 29. system administrator. His area of interest includes u software engineering. visualization. automated information processing. and distributed computing. Veguilla is a member of the ACM. Mayag¨ez Campus in May 2005 with specialization in the area of Comu puting Systems. He is currently pursuing his M. Puerto a Rico. Mr. He is particularly interested in the design of software architectures and middleware for the integration of diverse information coming from and being processed by distributed resources and how to exploit such technologies in order to easily provide people with the information they need. 1976 in Hato Rey. design patterns. a He received the Bachelors Degree in Computer Engineering from the University of Puerto Rico. Ricardo is son of Eduardo Veguilla Zayas and Carmen S.

Santiago Degree: Master of Science Graduation Date: December 2007 .A HIERARCHICAL MEMORY MODEL FOR TERRAIN DATA MANAGEMENT IN INTERACTIVE TERRAIN VISUALIZATION Ricardo Veguilla Gonz´lez a (787) 365-3288 Department of Electrical and Computer Engineering Chair: Nayda G.