Visualization of Spatial/Geographic Information with Virtual Reality Modeling Language (VRML)
Background
Geographic Information System (GIS) is a system that enables an integration of a spatial data (maps, drawings) and databases. The integration of the two types of data sets create relational database. GIS is capable of analyzing the complex multivariate data sets and visualizing the data in mainly 2D thematic maps. There is a module that can be added on to add 3D capability. The integration of GIS and Virtual Reality (VR) provide potential new way of interactions with complexity of geographic databases. However, it has no effective navigation system allowing users to explore the data representation. The level of control over visual appearance available in many commercial GIS is rather limited (Gahegan, 2000:256). Often, it is restricted to small number of predefined spatial primitives with few visual attributes. Here is where the Virtual Reality Modeling Language (VRML) can be implemented to enhance the visualization of the GIS analysis. The problem for such application of VRML involves the process of transferring, transforming, and formatting the data sets so that the final visualization truly represents the integrity of the data.
There have been a number of developments to generate 3D model of geographic data such as terrain model for real time viewing with some degrees of navigation freedom. Huang and Lin (1999) developed a script, using Avenue Script, called GeoVR for ArcView to generate VRML model from conventional 2D vector data, ArcView’s shape files, using an HTML’s Common Gateway Interface (CGI) form as a front-end to receive parameters defined by users. The VRML model of the geographic information created with this method is still a static model with the degrees of navigation freedom provided by the browser’s VRML plug-in. Thus, the interactivity in the model, besides the real-time navigation, does not exist. Similarly, other VRML models of geographic information often lack the abilities to interact with the model to explore different aspects of the data associated with the geographic entities. For example, the United State Environmental Protection Agency’s (EPA) Geographic Information Systems and Visualization Center (GISVIS, http://www.epa.gov/gisvis/index.html) has applied the VRML to visualize a number of their geographic data with static VRML models. Berry et al (1998) apply 3D virtual reality to visualize realistic visualization of natural environment with static 3D model with real-time navigation. Their visualization of virtual forest was the implementation of the integration of GIS and CAD more than the integration of GIS and VR in the sense that the process was in the CAD modeling of the GIS data and using VRML as a mere viewing tool. The interface of their model was limited to navigation in and around the model. This paper explores the integration of the GIS data within the VRML model that can be explored interactively as the user navigates through the virtual environment.
The basic implementations of the 3D virtual environment using VRML standard have been largely on the simulation and modeling of places, real and virtual. VRML world is a dynamic and interactive 3D environment that has not been fully utilized in interactive visualization of geographic information. Objects in the VRML world can be self-activated animated or moved, rotated by user input. Moreover, complex behavior can be assigned to objects so that it reacts to user input. These capabilities provide possibility to integrate database information to the VRML world so that the data can be visualized in 3D environment. The ability to visualize complex data in 3D can greatly help us to analyze and understand the underlying features of the data. The VRML standard has been developed since 1994 (www.web3d.org/fs_aboutus.htm); and the next generation of VRML standard, X3D, may incorporate new capabilities to access external database and geographic data (geodata). This paper reports the latest developments on the Web database publishing and VRML standard.
Objectives
The objectives for this study are:
· To study the requirements and advances in interactive visualization of geographic information in 3D virtual environment.
· To investigate properties of VRML geometry and interactivity functions.
· To identify an effective way to visualize the integrated database resulting from the GIS spatial analysis with VRML.
· To prepare a VRML prototype that will allow future modifications and customization of a case study on energy consumption data for the University of Michigan's North Campus buildings.
In addition, this study examines the types of data incorporated in both the GIS analysis and the 3D visualization and the preparations of such data. Therefore, it involves the theoretical analysis, as well as, the practical implementation of theory to a specific case. This paper includes the report on my analysis and the documentation of the programming of the case study.
3D Visualization Techniques for Geographic Information
In general, GIS produces visualization graphics in map format. These graphics can be categorized broadly as exploratory graphics, design graphics, reference graphics, and presentation graphics. Exploratory graphics portray the information generated from numerical modeling, especially where there is need to simplify for less ambiguity or more convincing. Design graphics are graphics used in the thinking process. They permit preliminary testing and comparison of solutions to a set of problems. Reference graphics are graphics prepared for a variety of purposes which can be extracted and put to new uses. Presentation graphics may be similar to that of reference graphics, but are usually simplified graphics designed to communicate specific concepts in a particular context (Turk, 1994, pp. 28-29).
The visualization of geographic information is the integration of Visualization in Science Computing (VisSC) principles and cartographic representation methods (MacEachren, 1994). MacEachren et al (1994) introduces four dimensions of variability in typology of visualization techniques. The first is purpose—how the visualization tools are used: data exploration and confirmation (prompt for visual thinking) to the synthesis and presentation (vehicles for communication). Second dimension is the levels of interactivity to the audience. The third dimension is the levels of abstraction in the visualization. This ranges from the highly symbolic to the highly detailed and realistic. Abstract representations may not be accessible to untrained users, thus it is more private in nature. The fourth, and final, dimension is the aspect of the phenomenon to information process. This 4-dimension aspect of visualization can be illustrated in 3-dimension space in Figure 1 below.
Figure 1. Use of geographic information visualization in 3D space of (1) audience correlating with the levels of abstraction, (2) levels of interactivity, and (3) data relations to the aspect of phenomena. (Source: adapted from MacEachren, 1998)
This study of the visualization of geographic and spatial information is expected to benefit the exploratory aspect of data visual analysis. The prototype would facilitate the following analyses:
- Phenomena change. 3D visualization can depict phenomena change over some specific of time period, or the rate of change of a phenomenon or one, or more, of its attributes.
- Visualizations of relationships between phenomena, such as spatial distribution and pattern of one of the attributes, relationships across various attributes.
The 3D environment allows us to examine the multivariate data with high dimension. For example, the prototype from the case study can display at least five dimensions of the data. The first two dimensions represent the geographical locations and the spatial extends of the objects of study. The third dimension, height, can show the value of one of the attributes of the spatial objects. The fourth dimension, color, represents another attribute value. The fifth dimension is the temporal dimension enabled by interactive menu to display data at different times. The high dimensions of the data visualization enable the visual analysis of the relationship among various attributes and among objects.
Model for the Data Integration
Figure 2. Model for the data Integration.
The implementation of VRML to visualize geographic information can be structured to integrate the four systems—CAD, database, GIS, and VRML (see Figure 2). The model starts with 2 types of data from different systems. CAD system provides spatial and geometric information in the form of digital map and prototype of 3D spatial objects. The prototype of 3D spatial objects was prepared base on the 2D spatial and geometric properties of the objects with a single unit, 1 meter, of the third dimension. This is to set the third dimension of the spatial objects ready to correspond to any value of the non-spatial attributes from the database system and any modifier. The 2D properties of the spatial objects are the input to the GIS. They are, then, linked with non-spatial attributes for spatial analysis. Spatial queries can be performed to filter only interested attributes to be further analyzed and visualized.
The following sections describe the elements of the four major modules of the model. The focus of this study is the implementation in VRML programming. Data from the other three modules—CAD, database, and GIS—are integrated in a number of prototype files (PROTOs) and partially embedded in the main VRML file.
The Data
The data sets, both digital maps and the database, for the input to GIS are often prepared with external tools. Computer Aided Drafting and Design (CAD) is usually the tool to create precise maps containing the spatial objects—points, lines, and polygons (areas). CAD allows the spatial objects to be organized in many ways using layers, colors, line attributes, etc. Database or spreadsheet program organizes the data pertaining to the spatial entities.
There are two types of data sets involved in the geographic information analysis—digital maps and attributes data. Both types of data are best to be created and prepared with external programs. GIS has very limited tools and capabilities to create and to modify either data types. Depending on the purposes of the project, the data need to be defined to serve the purposes of the analysis. The first data type is the digital map. It is necessary that the spatial entities are created in their real scale. This means the dimensions to the map elements must have the correct sizes that can be projected on to the earth surface. However, the level of detail may vary depending on the unit of the spatial analysis. The purposes of the maps need to be defined at the early stage in order to specify the level of detail of the digital map needed.
The digital map of the case study provided by the Facility Planning and Design Department of the University of Michigan. It was prepared with Microstationâ CAD system. The data was converted into DXF standard vector format. The DXF file, then, was imported into a 3D CAD program, Form·Zâ, to prepare a uniform-height 3D model. The model was optimized for the VRML application by simplification of the geometries. Curves and complex polylines are straightened. This is to reduce the number of polygons to be rendered in real-time in VRML view.
The uniform-height 3D model was built on a flat ground plane. The reason for this is to restrict the reference of the three dimensional data visualization at the same datum. The actual ground of the University of Michigan North Campus is a non-uniform terrain. However, data visualization of the energy consumption on the terrain surface can easily mislead the users and make it difficult to visually compare the data value because the terrain shifts the bases of the buildings to different elevation. Therefore, the terrain of the ground for the model was eliminated to assist the visual exploratory analysis of the data.
Figure 3. CAD drawing of the University of Michigan North Campus.
Figure 4. 3D model prepared in Form·Zâ with a uniform height.
The 3D uniform-height models of the buildings were named with the Bldgno. The names assigned are important as to be the identifier for the buildings that match the attributes data. When the CAD model was exported into a VRML format, these building names are used in the instancing of the building in VRML programming. The VRML instances can receive events and allow the events to modify they properties such as colors, scale, rotation, and translation.
The second data type is database. There often are multiple data sets for the spatial entities. The attribute data sets can basically be delimited text file. The database in delimited text format is very transportable. It can be read by most of the spreadsheet, database, and statistical applications. The multiple sets of data need to have proper index in order to be linked in a relational data structure. The GIS imports the data sets and links them with the spatial entities. Each data set can be represented as a layer in the map visualization. GIS combines various layers of information and database in the analysis. Thus, multidimensional analysis can be accomplished.
The database of the case study was obtained as several separate data sets. They are originally tab delimited data files. The files were imported into the GIS to be linked to the spatial objects by the Bldgno. The combined data was sorted and analyzed. Data of the North Campus buildings (Campus Code=500) was queried and filtered out to a new GIS layer. The layer was converted to an ArcView shape file which contain the geometry and attributes table. The table was, then, exported into a delimited text. This is to prepare a data text for VRML programming.
GIS Database Management
GIS provides crucial tools for spatial analysis. A large number of records in various data sets can be linked in a relational structure. Spatial queries and measurements can be performed. In the study, the digital map of the City of Ann Arbor and the University of Michigan campuses were imported into the GIS. They were georeferenced to be overlaid properly. The campuses were shown as in distinguish colored areas—Central, Medical, North, Athletic, and others. Campuses’ buildings were split into separate layers, thus, later, only the North campus will be exported for VRML application.
Figure 5. GIS overlays of city map and campus map. Features such as streets, railway, river, bridges are shown with the campus grounds and buildings.
The building digital map contains basic index information, Bldgno. The attribute data sets that were imported into the GIS project file also contain Bldgno. Each attribute value from the data sets can be linked to a proper building. Three attributes of the buildings in North Campus—energy costs (electricity, water, and natural gas from 1991 to 1998)—were selected for this study. A query to filter only buildings with Campuscode = 500 (North Campus) was performed. The result of the query was converted into a separate theme (layer). This new theme contains the combined spatial objects (buildings) and their attributes. GIS can perform further complex queries with mathematical and Boolean operations such as to find buildings that have less electricity costs per square foot and natural gas costs per square foot in 1998 than in 1997. However, for the purpose of the development of VRML application in this study the raw data were needed to create an interactive visualization for data exploration that allows users to see the actual data values in a variety of ways with less artifacts.
Figure 6. Linked data for the entire University of Michigan campuses—buildings’ identification variables (Bldgno, Bldgname, Bldgft3, Campuscode) and attribute data of the energy consumption (89econsump, 89ecost, …, 98ngconsump, 98ngcost).
Figure 7. Linked data of North Campus buildings.
The data was, then, exported into a delimited text. The data was transposed in a spreadsheet application to rearrange the fields and records. The data was arranged so that a building and its attributes were in a column format. This was to prepare an attributes to be an array indexed by Bldgno. Maximums and minimums of the energy types were calculated and arranged as an array indexed by the year (1991 to 1998). A comma delimited text was created from the prepared table.
Figure 8. Attribute data of the energy consumption of the North Campus buildings.
The 3D uniform-height model and the comma delimited data were the two essential data for the development of the VRML visualization. Further interactive components were to be built within the programming of the VRML model.
VRML Standard
VRML, an acronym for the Virtual Reality Modeling Language, was conceived in the spring of 1994 at the first World Wide Web conference, held in Geneva. As a three-dimensional graphical visualization tool, VRML was intended to become the standard language for interactive simulations within the World Wide Web and was rapidly adopted by the wider Internet community. A subset of the Open Inventor ASCII file format was used to form the basis of the language, and the development of VRML was speeded up considerably by the contribution of a VRML file parser into the public domain by the company Silicon Graphics. This and further development took place over the Internet via an internet mailing list and later through a number of news-groups. Web3d consortium was founded in 1999 as the successor of the original VRML Consortium, founded in 1997.
The Virtual Reality Modeling Language (VRML) is a “file format for describing interactive 3D objects and worlds. VRML is designed to be used on the Internet, intranets, and local client systems. VRML is also intended to be a universal interchange format for integrated 3D graphics and multimedia” (www.web3d.org). A VRML document takes the form of a human-readable text file describing a three-dimensional scene. It is capable of representing static and animated dynamic 3D and multimedia objects with hyperlinks to other media such as text, sounds, movies, and images. This text file comprises in effect a list of programming syntax which tell the computer to place objects, of given sizes and colors, at specific locations within a virtual world. Simple 2D and 3D objects can be constructed out of what are referred to as primitives—simple, pre-defined primitive geometric shapes, for example cubes and spheres. More complex objects, for example curved surfaces of landscape and non-rectilinear buildings, that cannot be adequately modeled using simple primitives can be referred to as a face or polygon. Most landscapes and free-form objects, given their near infinite complexity, require many thousands of individual faces, or polygons. This results in much larger text files, thus, slower real-time navigation. Other parts of the virtual environment, such as lights, backgrounds, navigation speed, can also be defined within the same file. A VRML file can be distributed over the internet and parsed by a browser program which sensually renders the document into an interactive form. All browsing is done on the client machine resulting in low bandwidth requirements and hardware independent distribution. VRML browser is a presentation application that accepts user input through real-time responsive user interface that allows users to manipulation of objects and navigation using an input device. The three main components of the browser are: Parser, Scene Graph, and Audio/Visual Presentation (see Figure 2). The Parser component reads the VRML file and creates the Scene Graph. The Scene Graph component consists of the Transformation Hierarchy of nodes and the Route Graph. The Scene Graph also includes the Execution Engine that processes events, reads and edits the Route Graph, and makes changes to the Transform Hierarchy of nodes. User input generally affects sensors and navigation, and thus is wired to the Route Graph component, defined by sensors, and the Audio/Visual Presentation component. The Audio/Visual Presentation component performs the graphics and audio rendering of the Transform Hierarchy that feeds back to the user (www.web3d.org).
Figure 9. Conceptual of VRML browser (source: adapted from www.web3d.org).
Scene Graph Structure
A typical VRML file consists of the header, the scene graph, and event routing. The contents of this file are processed for presentation and interaction by a program known as a browser. The scene graph contains nodes which describe objects and their properties, as well as the environment such as lights, predefined viewpoints. It contains hierarchically grouped geometry to provide an audio-visual representation of objects, as well as nodes that participate in the event generation and routing mechanism.
The header is the identifier for a VRML browser to recognize the file. The standard VRML 97 header is
#VRML V2.0 utf8
“utf8” is the encoding type. The header can have optional comments following the encoding type. It has to end with line terminator, either a linefeed or a carriage-return character.
Following the header is a number of nodes—scene graph. The order of nodes within the scene graph is critical, as changes in position or orientation all subsequent nodes. Nodes represent the building blocks of VRML and describe shapes, lights, cameras, position and orientation (Gillings and Goodrick, 1996). Standard unit in VRML is meter. The coordinate system is a screen base which has x as the horizontal axis, y as the vertical axis, and z as the perpendicular axis to the screen.
A tree-like structure can be created using separator nodes which allows parts of the scene graph to be functionally independent and isolated from subsequent nodes. Specific states, for example color, will then be saved before entering the separator to make specific state changes, and restored upon leaving. All of the objects need not necessarily be defined within the one file. Instances of objects on the same server or elsewhere on the internet may be included within the file. Instancing using DEF statement is used to define objects and USE to subsequently re-use the object, thus allowing some degree of efficient, modular programming. The use of instancing, DEF and USE, optimizes the memory used. When the parser read the nodes from the VRML text file, it puts each node in a memory location and associates it with that memory location whenever it uses that node during rendering. So, whenever the USE is encountered, the computer does not put another copy in memory, but instead keeps a pointer to the original. Therefore, it save time in typing codes, network download time, browser loading time, computer memory usage, and rendering time (Marrin and Campbell, 1997).
Figure 10. Tree structure of scene graph.
Many CAD applications are capable of translating the layers or grouping of the models into proper hierarchical structure and instances in the VRML scene graph. The simple structure of VRML makes the production of macro-language routines for the export of models from CAD formats to VRML relatively straightforward. Routines are already available for packages such as Autodesk's 3-D Studio, form·Zâ. CAD programs also provide the ability to fine-tune scenes; surfaces may be smoothed, component polygon counts reduced for greater speed of rendering, and cameras can be added to provide predefined viewpoints. In addition, the GIS, such as Arc/Info and ArcView, have conversion utilities that can convert GIS layers or theme to VRML. There are also various stand-alone tools for the conversion of the popular AutoCad data exchange format (DXF) into VRML, making the conversion of existing 3-dimensional CAD drawings relatively straightforward (Gillings and Goodrick, 1996). In this study, the 3D uniform-height models created in form·Zâ were named and organized hierarchically with layers in the same fashion required in VRML scene graph.
Although the VRML standard has been released over 3 years, different VRML browsers and CAD modeling programs may use quite different interpretations of the VRML standards to implement very different features. Despite the presence of complex modeling programs to assist in the production of VRML documents, it is often necessary to manually edit the exported VRML code to be able to tweak files to satisfy different browsers and to use capabilities provided in the VRML specification, such as animation with interpolators and behavioral control with sensors.
There are as many as 54 nodes plus instancing, routing and prototype/external prototype statements. VRML nodes can be classified into 5 major types—geometry and appearances, scene environment components, groupings, behaviors, and miscellaneous nodes. Geometry and appearances define objects in the scene and their appearances. Digital image and movie can be mapped onto the object’s surfaces (polygons). Scene environment components comprise lights, viewpoints, navigation, background, fog, and sounds. Light nodes define 3 different lighting models to light up the objects’ surfaces. Grouping nodes are used to arrange the hierarchical structure of the scene graph. Behavior nodes include sensors, interpolators, and script nodes. Miscellaneous nodes are special nodes which may not visually affect the scene graph. For example, the WorldInfo node contains strings of title and text information about the file, PROTO defines customized dynamic node which is not displayed until the node is called in the scene graph.
Table 1. Node types
|
Geometry & Appearances |
Scene Environment Components |
Grouping |
Behaviors |
Miscellaneous Nodes and Statements |
|
Appearance Box Color Cone Coordinate Cylinder ElevationGrid Extrusion FontStyle IndexedFaceSet IndexedLineSet ImageTexture Material MovieTexture Normal PixelTexture PointSet Shape Sphere Text TextureCoordinate TextureTransform |
AudioClip Background DirectionalLight Fog NavigationInfo PointLight Sound SpotLight Viewpoint
|
Anchor Billboard Collision Group Inline LOD Switch Transform |
ColorInterpolator CoordinateInterpolator CylinderSensor NormalIntrepolator OrientationInterpolator PlaneSensor PositionInterpolator ProximitySensor ScalarInterpolator Script SphereSensor TimeSensor TouchSensor VisibilitySensor |
DEF EXTERNPROTO PROTO ROUTE USE WorldInfo
|
A node contains a list of fields which hold values that define parameters for its properties and functions. A node specification is defined with the following syntax:
NodeName {
class type name [initial value]
}
i.e.
Viewpoint {
eventIn SFBool set_bind
exposedField SFFloat fieldOfView 0.785398
exposedField SFBool jump TRUE
exposedField SFRotation orientation 0 0 1 0
exposedField SFVec3f position 0 0 10
field SFString description “”
eventOut SFTime bindTime
eventOut SFBool isBound
}
The texts in bold, node name and field names, are the part to be typed in the VRML file. If a field is not specified, the initial value will be used. The events, eventIn and eventOut, are the functions of the node that allow values to be pass from and to other nodes via ROUTE statement. eventIn defines a property of the node that can receive a new value passed from another node. eventOut send a value out from the node. The eventOut functions as soon as the node is loaded by the browser. These properties and functions of the VRML nodes allow great flexibility for interactivity.
Interactivity in VRML scenegraph
Interaction allows user to control behaviors of the objects while exploring the scene. User can touch an object to start moving the object or a group of objects, to change light intensity, or to change the object’s appearance. Interactivity in VRML (version 2 or 97) is executed by passing a series of properties around to the various objects in the scene graph. When one node wants to pass some information to another node, it creates an event. An event is “something between a function call and an assignment in a programming language. An event contains two pieces of information—the data and a timestamp. A timestamp is when the event was originally generated. In order to maintain a coherent scene, the order of execution is important. The sequences are facilitated by the timestamps of events. The timestamp is the browser’s internal representation of when the event occurred so that it can maintain the correct sequence (Roehl, et al., 1997).
VRML does not contain a function call mechanism for passing information; instead, an explicit connection between two fields of the nodes is created. Table 2 shows accessibility of the node’s properties (class specifiers). A class specifier contains a value. This value has a fixed field type (type specifier), i.e. SFBool, SFVec3f, SFRotation, etc. The value passed from and to node’s property is required to have a matching field type. Either a ROUTE statement or a direct access can execute the value passed from a node to another node with a function in a Script node.
Table 2. VRML class specifiers and access types
Class Specifier |
Access Available to other nodes |
|
field eventIn eventOut exposedField |
No external access Write only Read only Read and write |
Source: adapted from Roehl et al., 1997.
Most, but not all, eventIns correspond to an exposedField in the node. Fore
example, the Transform node has set_translation
eventIn corresponding to translation
field which is an SFVec3f type. An exposedField class can be set to a
particular value or changed when its node receives a corresponding eventIn.
But, a field class is not exposed. It can be set to a particular value
in the file format, but cannot be changed on-the-fly by an event. Most nodes
that have an eventIn corresponding to a field also have an eventOut
corresponding to that same field. For example, the Transform
node, in addition to a set_translation eventIn,
also has a translation_changed eventOut.
This event is sent whenever the set_translation
eventIn is received. This allows the chaining of events through many
nodes.
Figure 11 illustrates an example of event routings from a
click of the mouse on TouchSensor node (typically a sensor is nested
with a geometry as children of a grouping node) to both startTime
of a TimeSensor and a Script. The eventOut from the TouchSensor
activates the TimeSensor and toggle a SFBool field, toggle_changed
to TRUE or FALSE.
The SFBool value of the toggle_changed
is then sent to toggle enabled field of the TimeSensor
to activate or deactivate it. This TimeSensor, then, can be used to
interact with an interpolator to animate an object or a group of objects.
Figure 11. Example of event routing.
In addition to passing value from an eventOut of a
node to and eventIn of another node to change the value of corresponding
exposedField, the exposedField can be instantaneously changed by
the direct access from a function in a Script
node. Script node allows arbitrary, author-defined fields and events, and the
event processing. VRML supports several programming languages for writing
scripts, including the popular Java language, javascript, and VRMLscript. The
script is a powerful and flexible way to create interactivity and behaviors for
VRML objects. An event received by a Script node causes the execution of a
script function which has the ability to send events through the normal event-routing
mechanism, or bypass this mechanism and send events directly to any node to
which the Script node has a reference. Scripts can also dynamically add or
delete routes and thereby change the event-routing topology (Carey and Bell,
1997).
Prototype: PROTO
“The PROTO statement defines a new node type in terms of already defined (built-in or prototyped) node types. Once defined, prototyped node types may be instantiated in the scene graph exactly like the built-in node types” (www.web3d.org). PROTO statement allows customized node to be defined. This customized node is a prototype. A prototype is a combination of standard VRML nodes. Thus, a prototype can be a complex set of geometries, appearances with textures, and behaviors. Once declared, a prototype can be used like any of the standard VRML nodes in the scene graph. Class and type specifiers can be assigned to a prototype with arbitrary names. Prototype need not be in the same VRML file. It can be referred externally using EXTERNPROTO statement.
Prototype is useful for creating parts libraries. Libraries become sets of standard parts that can be reused through many different scenes over and over again. Moreover, the properties of the parts can be modifiable when the class specifiers of the prototype are exposedFields. In this study, prototypes were used extensively for parts of the interactive menu items and the library of building geometries database. This allows the libraries to be updated externally with convenience. In addition, the properties of the parts, such as appearances and position, used in the final VRML scene graph can be articulated differently each time they are used.
Case Study: VRML Components
There are actually many ways to implement the VRML visualization of such data. One technique is to create several versions of the 3D models that represent the values of the energy cost of all the years. With many predefined heights, VRML scene graph can call in a proper version of the 3D model to be visible when a menu is selected. This technique can be accomplished with Anchor node that links to external models or with Switch node with external model files are linked (inlined) to the scene graph. However, the models are static with predefined properties. This makes the updating of the building geometries or the energy data become a tedious task because all models have to be update properly. Moreover, the interactivity is rather limited. For example, it would be difficult to implement the sequential animation of the height values through all the years.
Another possibility of implementing VRML for this type of visualization is to build prototype to contain all building’s energy variables. This prototype has an exposed children field to accept the geometry of a building specified at the time programmed in the scene graph. With this prototype, author or programmer needs to input the data—building geometry and energy data—at the time the scene graph file is created. This means a building in the scene graph has all the data attributes built-in the node. Any attribute can be accessed and passed to script’s functions for interactivities. However, the building geometries need to be maintained in separate files, each file for a building. Then, a building file is inlined into the prototype’s children field. New building geometries can be added to the library of files; and the existing file can be modified individually. This is very convenient to maintain the building geometries data. The problem for this technique is that it is a tedious task to manually input in a large number of energy data values into each building code.
The method implemented in this study, the visualization the energy consumption of the University of Michigan North Campus buildings with VRML, was to create stand-alone interactive VRML with external prototypes and external static models of the context. The structure of this visualization was modeled with three separate sets of VRML files—prototypes, models of the contextual environments, and the main VRML scene graph. They were structured to provide flexibility in updating the databases, either the building geometries or the energy data. The components of this VRML implementation can be illustrated in Figure 12 below. Figure 12 shows the linkages of external prototypes and external VRML models to the main scene graph. In addition, The main VRML scene graph shows its subcomponents and their events routing. The energy consumption database was embedded inside a Script in form of arrays. The data values in each array were indexed by the building numbers. The comma delimited text output of the energy consumption data from GIS was simply cut and pasted into the arrays in the Script. Therefore, these arrays of data in the Script can be easily updated and modified.
Figure 12. VRML components in the visualization of energy consumption case study
Prototypes
There are four prototypes created for the interactive visualization—buildings, dashboard, button, and menu prototypes. They provide a set of library database of both geometries and functionalities. The buildings prototype is a database of all buildings’ geometries which can be called to the scene graph one at a time. The building called from this prototype has a built-in TouchSensor to send and receive events with other components in the scene graph. The dashboard prototype is mainly a set of functions that update the positions and orientations of its children to be visible at a relative position to the viewer at all time. This prototype accepts any VRML nodes as children when specified in the main scene graph file. The button and menu prototypes store geometries and appearances of the menu buttons that make the menu buttons responds to the on/off stages. The button and menu prototypes were used as children of the dashboard in the scene graph.
This prototype has all buildings’ geometrical database
nested under a Switch node that has whichChoice
field exposed. This allows the prototype to be use and call a specific building
to the scene graph. The buildings’ scale and material are exposed to allow
access of new value to modify its properties. In addition, there is a TouchSensor
built-in, with enabled and touchTime
fields exposed, to allow a building called to the scene graph to interact with
the user and perform functions specified in the main VRML scene graph.
The prototype can be easily modified. Each building in an instance, named with the building number. They were sorted by the building number. New geometry of the building can replace the old one by simply cut and paste the new syntax over the old one. New buildings can also be added to the database. The new buildings can be inserted to maintain the ordering by building numbers or be appended to the file at the end.
|
……… ……… |
Figure 13. Buildings prototype.
The dashboard prototype defines parameters and sensors for
the children nodes to be properly displayed in front of the viewer as it moves
through the 3D environment. This prototype has an open children field that
allows geometries and other VRML nodes to be added for flexible functionalities
of the dashboard interface. The ProximitySensor and
Collision
nodes are the main properties of this prototype. The ProximitySensor
tracks the current position of the viewer and send translation (position)
and orientation (rotation) of the viewer to update the translation and orientation
of the dashboard’s children nodes so that all children maintain their relative
position to the view at all time.
|
|
Figure 14. Dashboard prototype.
The button prototype is a library for a square button which can have two texture maps. The purpose of the prototype of a button with two texture maps is to allow the appearance of the button to change when clicked to be on or off. The URLs of the two texture maps are exposed, buttonInactiveTexture and buttonActiveTexture, so that the image texture file can be specified when used in the VRML scene graph. The menu prototype has the exactly the same properties as the button prototype, except the geometry is a rectangle made for the variables menus.
The prototype was built with a Switch node that contains two choices. The Switch node has whichChoice exposed, defined with a customized name buttonSwitch. Each choice has an exposed texture’s URL that can be specified when used in the scene graph. One choice is for the “off” stage with one texture map; the other is for “on” stage, when clicked, with another texture map. The prototype needs a TouchSensor and a Script to register the “on/off” toggle stages in the main scene graph.
|
|
Figure 15. Button prototype.
External Models of the Context
There are two files of static models of the context for the North Campus academic buildings—family housing complex and the ground, with streets and parking lots layout. The two models were products of the 3D CAD models. The family housing complex was exported separately from the overall campus model. The streets and parking lots were, however, converted into an