“7th AGILE Conference on Geographic Information Science” 29 April-1May 2004, Heraklion, Greece Parallel Session 3.2- “Visualisation” 231

A VRML Terrain Visualization Approach

Antonios Triantafyllos1, Dimosthenis Anagnostopoulos2, Christos Chalkias3

1 Dept. of Informatics, University of Athens Panepistimiopolis 17671, Athens, Greece

atriant@yahoo.com 2 Dept. of Geography, Harokopio University of Athens

70 El. Venizelou Str, Athens, Greece dimosthe@hua.gr xalkias@hua.gr

ABSTRACT Geographic Information Systems (GIS) are used to store, manipulate and analyze spatially referenced data. In the past, GIS were 2D, map-based systems using non-interactive high-resolution display. Advanced graphical libraries such as VRML (Virtual Reality Modeling Language) make possible to effectively model and thereafter render the third dimension on WWW. Landscape visualization in a GIS involves visualizing and manipulating large-scale terrains, which are typically massive. The time required in rendering such a model would prohibit any real-time interaction using the current generation of VRML browsers. This paper discusses this specific problem and proposes VRML techniques on how to reduce the rendering time needed for large terrain visualization. It also presents a case study where the proposed approach is used to implement a 3D visualization of Attica, Greece.

KEYWORDS: Virtual Reality, VRML, terrain visualization, 3D visualization

1. INTRODUCTION GIS were originally 2D, map-based systems using a non-interactive, high-resolution display. Recently, advanced visualization methods with rendering capabilities began to converge with GIS. Virtual Reality Modeling Language (VRML) is a platform-independent language for virtual reality scene design. The use of VRML for presentation of spatial data is increasing (Fairbain 1997) (Koehnen 2002). Landscape visualization in a GIS involves visualizing and manipulating large-scale terrains, which are typically massive. The time required in rendering such a model would prohibit any real-time interaction using the current generation of VRML browsers (Ping’an et al 1999).

Towards meeting the need for detailed geographic terrain representation with limited computer power, approaches described in the following have been proposed in the literature:

The prototype system FHP_GTOPO30 is an application for VRML-based mid-resolution terrain visualization of the Earth’s surface (Däßler and Neher 2001). It allows the web-based access to the USGS GTOPO30 dataset. Emphasis has been given to the user interface design, allowing even inexperienced users to precisely select from and navigate accurately through the large GTOPO30 dataset. FHP_GTOPO30 covers the Earth at a resolution of 1km. The interface consists of a set of zoom able (2D) maps, selected by user. In the final map selection, the application creates dynamically the VRML file, area of 360 X 360 Km (max) and heights every 1 Km. Further details (algorithms & data structures) of FHP_GTOPO30 can be found in (Däßler and Neher 2001).

FHP_GTOPO30 enables terrain visualization at an average level of detail. To visualize a large terrain (or the earth), and non-stop navigate through the world with a greater level of detail (sample heights per 100m or less), other approaches may be required. It has characterized a simple architecture (a simple

232

database is only needed to keep all heights), low detail graphics and visualization of only a specific default area.

The concept of levels of detail (LOD) (Reddy et al 1999) is an important step towards interactive visualization of large scenes: Objects far away from the viewpoint, only contributing a few pixels in the final image, are rendered using pre-calculated low-level representations. LOD provides an efficient way to render real-time interactive landscape visualization. This approach combines the use of different LOD database tables with a set of different type of VRML files (wrl). In quick, each LOD file is created dynamically from the associated LOD table. The tables and the LOD files have a tree structure mostly in pyramid form.

Figure 1: A tiled pyramid representation. The left image shows four different resolutions of a digital map where each level has been segmented into a regular grid of tiles. The right one demonstrates the use of a

quad-tree technique to alter the resolution of an image in different regions (Reddy et al 1999).

LOD is best achieved for terrain applications using a hierarchical data structure such as a quad-tree (Däßler and Neher 2001) (Reddy et al 1999) (UCSB 1998). This involves progressively down sampling an image or elevation bitmap to produce a multi-resolution pyramid. Each level of this pyramid is then segmented into a grid of equally sized rectangular tiles, e.g. 128 x 128 pixels. A tile at one level of the pyramid will therefore map onto four tiles on the immediately higher-resolution level, i.e. the tiles at the higher-resolution level cover half the geographical area of the former. Using such a representation, it can progressively display higher resolution data around some area of interest (e.g. the user’s viewpoint) while other regions remain in low resolution. Use of tiling also allows fetching and displaying sections of the dataset that are visible from a certain vantage point. These concepts are illustrated in figure 1.

The above terrain representation can be implemented by introducing two primary types of VRML files: Tree files and Terrain Tile files. These are the basic building blocks of our VRML terrain representation. Key features of the levels of detail approach are the following:

Efficient implementation of high detail terrain visualization Excellent visual result from any viewing distance Easy navigation from tile to tile without any intermediate loading Large databases with hierarchical structure are needed to support this architecture. For each tile

creation, a different database table is needed.

233

Comparing the aforementioned approaches, it is obvious that the last one is more suitable for Large Terrain Visualization. However, we must point out the need for large database structures and the overlapping height tables for each LOD tile support. The first approach is far simpler, but recommended only for low detail terrains, focusing on the last (and only) tile of this architecture. The time required in rendering such a model would prohibit any real-time interaction using the current generation of VRML browsers.

We propose and employ a simplified technique for terrain visualization by combining some of the above features, considering that the need for detailed representation involves the geographic terrain under view rather all nearby terrains. This technique is based on a combination of easy navigation (used in the first approach) and high-detail terrain representation (used in second approach), using few LOD nodes and only one table, holding all terrain heights.

Specifically, we propose the use of two LODs nodes. The first LOD represents the geographical terrain in 2D. The second LOD is the terrain. The important point is that when the user focuses on a specific terrain tile in a close distance, this is represented 3D whereas all nearby tiles remain in 2D. In this way, more CPU resources can be used for the more-detailed 3D perspective landscape representation of a specific area. The advantages of this technique may be summarized in the following:

Less storage requirements for one database table. Fast navigation using the LOD nodes, independent from user’s computer power. High detail representation depends on the amount of geographic terrain data

In the rest of the paper, we discuss in detail the VRML-based technique and emphasize implementation issues. We also present a case study using real geographical data. Conclusions reside in the last section.

2. TERRAIN VISUALIZATION USING VRML Virtual Reality Modeling Language (VRML) is a platform-independent language for virtual reality scene design (ISO, 1997). A standard format is being devised which will allow Web users to share and link 3D objects and scenes with each other, in much the same way that HTML documents can now be linked together (UCSB 1998). The syntax of VRML is based on objects (nodes) with parameters (fields). A number of nodes are responsible for the design of the scene: description of geometry (regular and irregular shapes, grids, text), illumination of the model (directional, spot, point and ambient lights), materials and textures (draping and mapping of JPEG, GIF, PNG image file formats). Combinations of another nodes, i.e. sensors, routes and interpolators introduce dynamics. Sensors detect viewer actions (e.g. mouse move, click, drag), time changes and viewer positions (visibility, proximity, collision).

The scene designed according to VRML is stored in an ASCII file. Specific visualization software, i.e. Virtual Reality (VR) browser is necessary to display data on the screen. The role of VRML document and VR browsers is different. The VRML document supplies the parameters for scene design and the dynamics of objects while the VR browser takes care of scene rendering and the interface to navigate through and interact with the model. Initially, the basic function of the VR browser, besides visualization, was only real time navigation through the model, i.e. provision of virtual reality techniques: examine, fly-over, walk-trough, pan, zoom (Zlatanova 2002).

There are two nodes used for geographic display: These are the IndexFaceSet and the ElevationGrid functions (figure 2). The IndexedFaceSet node is a collection of faces, which you define manually, and hence, build up your own objects of any shape.

234

Figure 2: An Elevation Grid example

The general terrain architecture decomposes to VRML terrain model and VRML visualization data. Combing these two components, a VRML template can be created. Using the VRML browser, the template becomes visible and exploitable (figure 3).

Figure 3: Unified Terrain Architecture

The node designed specifically to build VRML terrain models is the Elevation Grid. Over the Elevation Grid, terrain can be modeled as: wire framed, shaded and texture mapped (Prakash and Chan 1999). All above form the VRML terrain model. The data used to describe the heights, for a large sample of the terrain points (e.g. for every 1 km), form the VRML visualization data. Terrain Model and Visualization Data can be combined in a VRML rendering template. This template describes a specific terrain area with sampled height values and the selected terrain model from the above (wire framed, shaded or texture mapped).

235

Finally, a VRML browser is used to display the template, and help user navigate through it. If the visualization data are few (e.g. elevation sampling every 1km for an area of 100 x 100 km), the browser will display the virtual terrain with enough speed (frames per second – fps), making the virtual world navigation able. However, in most cases, we have to visualize terrains with greatest detail and sample heights per 100 m or per 1 m. Then, it is necessary to build those models with different perspectives, in order to achieve a precise visualization. In this case, a large amount of geographic data (coordinates and height) must be processed and visualized for a specific geographic area. The result is a high detail terrain visualization, but with slow rendering performance due to lack of high computing power.

3. APPLYING THE PROPOSED TECHNIQUE A geographical terrain can be described using a table, which keeps the coordinates and the heights (x, y and z) as records, sampled per an abstract metric unit (e.g. per meter, or per 100 m). With a proper processing, this table can be transformed to a large Elevation Grid in VRML. Because of the large amount of vertices to be displayed, this could lead to low performance and high memory requirements when the user navigates in real time

The need for high performance in navigation and the detailed terrain visualization leads us to make smaller Elevation Grids (tiles). This approach hashes the entire Elevation Grid into smaller ones, which have the same level of detail with the large Elevation Grid. Combining the tiles and applying VRML transformations, we form the entire geographical area to visualize. To gain the required memory, for display and navigation in the terrain with high performance, only the Elevation Grid tile in which the user focuses is displayed with high detail, while the nearby tiles remain flattened. When the user changes tile, the new tile is displayed in high detail and the old one gets flattened.

Initial data need to create terrain visualization is usually a file which contains all the coordinates and heights of the area to be displayed and, optionally, an image of the map of this area with the coordinates of its edges. After the creation of the Elevation Grid, the image (e.g. georeferenced satellite image) can be attached as a texture on it, to have a more realistic effect (Berry et al 1998).

The process creating the file structure for the terrain visualization involves the following steps:

Import of coordinates file into a database table for enabling data manipulation, as later described. Division of the table into sub tables used for the elevation grid tiles, as previous discussed. This

solution is complicated, as a large amount of tables is created, making the database larger. We thus decided to alter the coordinates table by adding two more fields. As above stated, the coords table represents a matrix. By dividing this matrix into n x m sectors, each coord belongs to a specific sector, which is identified by an integer i (in the range 1..n) and an integer j (in the range 1..m) (figure 4). Thus, i and j value for each record were added in the coords table. This corresponds to the creation of a spatial index.

Creation of the VRML files needed for visualization. First, creation of the Terrain Tile Files: for each sector, a Terrain Tile File is created, including the Elevation Grid node. Thus, if there are n x m sectors, there also are n x m Terrain Tile Files. Second, for each Terrain Tile File, a Flat Tile File is created. The Flat Tile File has the same dimensions with the Terrain Tile File, but all its points in the Elevation Grid have a zero height. We thus create two VRML files for each terrain sector: the Terrain Tile File for the high detail version and the Flat Tile File for the low detail.

For this pair of VRML files, we also create a VRML file for control purposes. This file indicates the VR browser which version of the files it must render. When the observer is close enough to a visualized terrain sector, the corresponding Terrain Tile File is rendered, while nearby sectors under visualization are rendered by their Flat Tile File. The “control file” is a VRML LOD Tree File. It contains one LOD node which “inlines” both Terrain Tile File and Flat Tile File. The range parameter in the LOD node determines the radius of a sphere that surrounds each visualized sector. If the observer is beyond this

236

range, the Flat Tile File is loaded, otherwise the Terrain Tile File. Finally one Master LOD File is created to control the LOD Tree Files.

Error!

Figure 4: Division of the coord table into sectors

This imports all the LOD Tree Files for all sectors and a Flat Master File. The Flat Master File is like the Flat Tile Files, but includes all the geographic area. The LOD node in the Master LOD File has a range parameter that determines the radius of a sphere that surrounds the whole geographic area. Beyond this sphere, the geographic area is visualized by the Flat Master File; otherwise, control of the scene is transferred to the LOD Tree Files. In this way, all files created are part of the VRML file hierarchy, depicted in figure 5.

Figure 5: VRML File Hierarchy

237

4. A CASE STUDY The above approach was used to perform a virtual terrain visualization of Attica, Greece. Initial data was the coordinates text file, contains columns x, y and height. This file describes a geographical area of 86 X 64.5 km with height samples per 100 m. A georeferenced satellite image of the area (jpg file) was also draped on the terrain.

To support data manipulation in the coords file, we created a respective table in a RDBMS. The file was imported as a new table, having coordinates as fields. To implement LODs, the next step was hashing the table into 16 subtables. Our first thought was creating 16 subtables from the initial one, each of which would have contained 33540 records (536640 / 16). This would have increased the size of our database by 100%. A second approach was adding two more fields into the coordinates table, X_i and Y_j, to indicate the sector in which every sector belongs. This approach creates sectors inside the coordinates table and leads to the sectorization of the entire area, as shown in figure 6.

Figure 6: Sectorization of the geographical area. The point shown by the blue arrow has X and Y

coordinates and is included in the cords table. It also belongs to sector 3.3.

The last phase of this process was the creation of the VRML files. Four types of VRML files had to be created. A Terrain Tile File includes the Elevation Grid node (215 X 156 points). Thus, the Elevation Grid had dimensions 215 X 156, because spacing between two points, was selected to be equal to 1 for scale reasons. The names of these files had the following format: Ahigh_i_j.wrl ( i, j = 1..4). For each sector, an external program reads the coordinates table and creates the Terrain Tile Files. Each Terrain Tile File has the Elevation Grid node as its sector and transformation information, so if all these files are rendered, the entire geographical terrain would be produced. Also a map texture (1/16 of the initial map image file) was placed on each Elevation Grid, creating a more realistic visualization. For hashing the image map into 16 image tiles, commercial image processing software was used. To recapitulate the creation of the Terrain Tile Files, each Terrain Tile File overall contains i. Transformation Information ii. Elevation Grid and iii. Image Tile map, used as a texture on Elevation Grid (optionally).

238

The creation of the Flat Tile Files is simple. Due to there wasn’t height information included, a simple 4-point Elevation Grid Node was created with a zero height. The dimension of the Grid was 215X156. The result was an Elevation Grid with the same dimensions with the one included in the Terrain Tile Files, but flat. The same tile map image was used as a texture on the Elevation Grid. The Flat Tile Files were named as Alow_i_j.wrl (i, j = 1..4). Every sector thus had a high detail 3D representation through the respective Terrain Tile File (Ahigh_i_j.wrl) and a low 2D by its Flat Tile File (Alow_i_j.wrl).

We now discuss switching between the two modes, accomplished by the LOD VRML node (figure 7). A new VRML file had to be created to include this node. This group of files is named as ALOD_i_j.wrl and its type is LOD Tree Tile File.

Figure 7: Definition and function of LOD node. In the left, the observer is in range and the high detail version is loaded. When the observer leaves this area (is out of range), the LOD node switches to the low

detail version, as shown in the right.

Its role is to include the filenames Alow_i_j.wrl and Ahigh_i_j.wrl in the LOD node and define the range according to which switching is applied, from low detail to high detail (or from one file to another). This range is defined as the half of the max dimension of each sector. Each sector has dimension of 215 X 156, thus the range is close to 100.

The last part of our implementation involves the creation of the Master LOD File, which controls the remaining LOD Tile Files. These files included a LOD node and switches between the LOD Tree Files (ALOD_i_j.wrl i, j = 1..4) and the Flat 2D representation of the entire geographical area. The Flat 2D geographical area was created with the use of the Elevation Grid node, had the same structure with the Flat Tile Files, but it represents the entire area, so that the texture on the Elevation Grid was the entire initial satellite image map. The range for the Master LOD node is defined as the half of the max dimension of the entire geographical area (860 X 624).

To further support easy viewing and navigation, 16 viewpoints were defined and constructed, each one for a corresponding tile.

4.1 Navigation within the Virtual Environment

Virtual navigation starts with the observer at a fixed position (figure 8). The Master LOD File has the control of the scene, so that the 2D Flat representation of the entire geographical area is loaded. In this way, is seems like the user observing the earth from a very high position (like a satellite). The user can click anywhere in the entire area and one of the 16 respective links is activated, to view the specific area

ra ra

239

of interest. The control of the scene is then transferred to one of the ALOD_i_j.wrl. By clicking, the proper Viewpoint is called and the user is placed on it. The Viewpoint is set within the range specified in the LOD node of the ALOD_i_j.wrl. Then, the ALOD_i_j.wrl is loading the Ahigh_i_j.wrl. All nearby LOD Tree Files load the low-detail version, as the observer is beyond their LOD range. When the user leaves this tile, view falls to low detail, while the current tile rendered in high detail (figures 8 and 9). Also the user can zoom, pan, rotate and change viewpoint for the entire scene, using the VRML plugin buttons.

Figure 8: VRML representation of the Master Tile File (Attica.wrl) using Internet Browser with Cosmoplayer plugin. Using the mouse pointer the user can click anywhere in the terrain.

4.2 Compressing for Internet Use.

The above terrain visualization approach produces rather large VRML Terrain Tile Files, i.e. each one was approximately 0.5 MB. This was critical, as it prevents web access from users having a typical Internet access connection of 64 Kbps. To reduce downloading time of the VRML files, compression techniques were necessary. However, the widely known compression tools (Winzip, WinRar etc.) create compressed files unreadable by the current VRML plugged-in browsers.

An efficient solution to that was the use of “gzip” program, which implements the LZ 77 compression algorithm. When a VRML file (.wrl) is compressed using gzip, a new file is created with extension (.wrl.gz). Renaming it to “.wrl”, we have a compressed VRML file. This file has the following properties: (i) has the same file extension with an uncompressed “.wrl” file, (ii) is compressed at a 90% ratio, and (iii) is readable by the current VRML plugged-in browsers and also by some VRML editor programs (VrmlPad, Cosmoworlds, Internet Space Builder etc.). This solution considerably enhanced web usability of our implementation.

240

Figure 9: User clicks on an area and is then transferred above this area, now represented in 3D.

All nearby areas remain flat (in 2D).

5. CONCLUSIONS 3D Terrain visualization in GIS involves visualizing and manipulating large-scale terrains, which are typically massive. The time required in rendering such a model would prohibit any real-time interaction using the current generation of VRML browsers. We addressed specific problems encountered and proposed VRML techniques on how to reduce the rendering time needed for large terrain visualization.

The proposed approach offers considerable advantages, such as interoperability (portability across different operating systems and hardware platforms), independence from commercial GIS packages (although imports and exports are supported), compliance with web-enabled technology and advanced landscape visualization functions using VRML standards.

BIBLIOGRAPHY Berry J.K., Buckley D.J., Ulbricht C., 1998: Visualize Realistic Landscapes. In GIS World, vol. 11, no. 8,

42-47 Däßler R., Neher G., 2001, FHP_GTOPO30: User Interface to Geo-Referenced Data on the Web.

http://fabdp.fh-potsdam.de/infoviz/paper/web3d2001.pdf (also submitted to Web3D) Fairbairn D., 1997: The use of VRML for cartographic presentation. In Computers and Geosciences, vol

23, no 4, pp. 475-481 ISO, 1997: Virtual Reality Modeling Language International Standard ISO/IEC 14772-1:1997 Koehnen R.T., 2002: Building 3D Geographic Models in VRML: An Experiment Using USGS DEMs to

Build Internet Browser Viewable Terrains, University of Minnesota, http://www.socsci.umn.edu/~koeh0017/building3d.pdf

Ping’an C., Prakash E., Chan T.K.Y., 1999: Additive LOD Management for Geographic Data Using VRML. In Computer Graphics Topics, vol 11, no. 6, pp. 14-16

Prakash E., Chan T.K.Y., 1999, Unified Terrain Modelling, Rendering and Visualization in VRML. In Computer Graphics Topics, vol 11, no. 6, pp. 17-18.

241

Reddy M., Leclerc Y. G., Iverson L., Bletter N., Vidimce K., 1999: Modeling the Digital Earth in VRML. In Proceedings of SPIE (International Society for Optical Engineering), vol. 3905

UCSB Center for Research in Electronic Art Technology, 1998: CREATE DRIVE Project Distributed Real-Time Interactive Virtual Environments http://www.create.ucsb.edu/drive/phase2/intro

Zlatanova S., 2002: VRML for 3D GIS. In Proceedings of the 15th Spring Conference on Computer Graphics, Budmerice, Slovakia, pp. 74-82