Database Support for VRML Krzysztof Walczak NPAC Syracuse University 111 College Place Syracuse NY 13244-4100 Topics of Presentation VRML language Why database support for VRML ? Illustra Database System File based terrain rendering in VRML Terrain rendering with database support Objects - storing rich semantic information Multiversion representation Demonstration of example system Conclusions VRML - Virtual Reality Modeling Language Mission Statement: VRML (Virtual Reality Modeling Language) is an interpreted language for describing multi-participant interactive simulations - virtual worlds networked via global Internet and hyperlinked within the World Wide Web. History: VRML concept was proposed by Tim Berners-Lee and David Ragget in spring Ô94 during the first WWW conference in Geneva. After the conference the VRML forum was created by Mark Pesce to discuss the development of a specification. In May Ô95 the first version of specification was available. Current status: VRML is still under development The currently available specification describes version 1.0 Version 1.1 available as draft specifies only small changes Version 2.0 is expected in May Ô96 VRML - Specification The current version of VRML specification - 1.0 is a minimal starting point for a much larger concept. The specification is based on Open Inventor ASCII file format. VRML 1.0 is a subset of Open Inventor with some additions that allow linking the objects with another VRML or HTML sites on the Web. The linking concept is similar to HREF in HTML. VRML 1.0 provides only mechanisms for synthetic 3D Òclickable worldsÓ and does not specify yet any constructs for object animation, behavior and interaction. These issues are currently under intense discussion by the VRML forum and will be included in version 2.0 of the language. VRML Goals The current form of VRML has been strongly influenced by the following requirements: - Platform independence - Extensibility - Ability to work over low-bandwidth connections VRML - Basic Characteristics VRML defines a set of objects that can describe 3D graphics - nodes Nodes are arranged in hierarchical structures - scene graphs Scene graphs define the ordering for the nodes - the state of the scene graph depends on the earlier and affects later nodes Separators can limit the effects allowing parts of the scene to be isolated from other parts VRML - Nodes VRML nodes can be classified into three categories: shape nodes - define the geometry in the scene, property nodes - define the way shape nodes are rendered, group nodes - gather other nodes into collections treated as single objects. Example I - Shapes Shape nodes (Cube, Sphere) define the geometry of the objects in the scene. Example II - Properties The Material node defines the current surface material properties for all subsequent shapes. Example III - Group Nodes Separator node isolates its children from the rest of the scene graph. Standard VRML Storage Characteristics Data is stored as ASCII in text files The files can be accessed locally or through WWW Files may include other files (Inline) Some of the objects can represent links to other VRML or HTML pages Standard VRML Storage Disadvantages Only the geometrical information is available User cannot specify what parts/kind of data he/she needs - no queries possible The whole world description must be sent No possibility of changing parameters of the world creation Why Database Support for VRML ? Database system is used to store the data fast retrieval of data (indexing) language to query and manipulate data simultaneous access by multiple users Database keeps information about the components - not the final VRML form - semantic modeling easy and powerful update more compact storage VRML representation is created dynamically result is up-to-date multiple views on the same data are possible queries can select parts of the data Geometrical vs. Semantical Model Geometrical description only geometrical information no composition structure no identity of components (e.g. name) no type information only geometrical queries possible multiversion visualization not possible selecting of data not possible Illustra Database System Overview The Illustra Server is an Object-Relational DBMS (ORDBMS) It supports Object-Oriented management of rich data types, and at the same time provides an efficient query language based on extensions to industry-standard SQL. Object extensions, called DataBlade modules, define specific kinds of data, extending the SQL. Illustra Database System Object-Relational DBMS The features typical of Relational DBMS: Data access via standard SQL Standard security controls Full server-enforced data integrity Transactions and recovery Performance and scalability Features typical of object-oriented database technologies: Ability to create any data types Optimized access to rich data types Encapsulation, inheritance, polymorphism Illustra Database System Illustra DataBlades DataBlades provide specialized support for some application domains DataBlades consist of several components: data types functions (SQL or C) rules and alerters tables New types can be treated as standard built-in system types Functions defined in DataBlade can be executed on the client or on the server site DataBlade modules can be self-contained or can take advantage of data types and functions defined by other DataBlade modules. Illustra Database System Access to the Data Data can be accessed in various ways: SQL - Unix or MSWindows Client API - LIBMI - C library: - processing SQL queries - direct access Terrain Rendering in VRML First Approach Initially the terrain was modeled as single shape constructed as the set of triangles The performance was poor and strongly depending on the size of the modeled world Maximum available size was limited by the number of polygons the computers were able to display in real time Maximum size of the world was approx. 150 x 150 terrain points Terrain rendering in VRML Second Approach The whole surface is divided into parts covering areas 20 x 20 points. Each part is modeled in VRML separately. Only lighting is common in the main file. The main file is an ÒindexÓ that indicates the parts of world that should be loaded. While moving the viewpoint above the surface the areas that are no longer necessary disappear and new areas are loaded. The rendering resolution of the an area depends on the distance from the user viewpoint. Terrain rendering in VRML Second Approach (cont.) The following VRML structures were used to model the terrain data: - IndexedFaceSet - basic shape representing the surface, - Multivalued Material nodes - defined colors of points, - LOD - Level-Of-Detail node - specified portions of data to be loaded with different resolution levels depending on the distance from the viewpoint, - WWWInline - enabled loading of scene in portions, - WWWAnchor - allowing linking with HTML description pages - DirectionalLight - lighting in the scene Terrain rendering in VRML LOD - Level-Of-Detail LOD - Level-Of-Detail is a group node used to allow applications switching between various representations of objects. The child nodes of LOD represent the same object at varying levels of detail. Which child node is used for the representation of specified object depends on the distance between this object and the camera. The representations for higher distances have lower resolution. Use of LOD reduces the number of polygons to be displayed and increases the rendering speed. Terrain rendering in VRML Level-Of-Detail - Example Different detail levels are achieved by creating separate VRML files for each part of the surface using different resolutions (see pics). The left picture shows an area of 21x21 points in full resolution. The right picture shows the same area with resolution 5x5 points. Terrain rendering in VRML Coloring The system uses 24-bit color. The color is information is obtained from the satellite images. The color is defined for each point separately using Material node. The color of a surface connecting points of different colors is interpolated. This solution is 2-5 times faster than the texture mapping and gives better results. Terrain rendering in VRML Creation of VRML files The creation of VRML files is automatic - a special translator has been developed. The elevation data is transformed to a set of points. The color data defines colors of particular points. The points are linked to obtain surfaces. For each area two VRML files are created: with higher and lower resolution for use with LOD nodes. Terrain rendering in VRML Optimization Initially files are created in VRML format. To achieve better performance an Open Inventor optimization program - ivfix - is used. It creates an equivalent Open Inventor file. Most of Inventor based VRML viewers accept the full Open Inventor syntax. Structure of Terrain Data File-based approach System Architecture GIS in Database System VRML Synthesis Synthesis of VRML representation can be divided into two separate parts: generation of terrain shape generation of object description Why terrain shape description is treated in a special way ? very specialized and optimized VRML object constant - user does not edit the terrain data very big in volume - special mechanisms assure efficient storage and fast retrieval highly parametrized VRML synthesis GIS in Database System Terrain Data Data used for terrain shape modeling 100 meters DEM (Digital Elevation Model) data 30 meters color data - satellite image Values of three color components (RGB) are calculated using six original values: three from the visible range and three infrared GIS in Database System Synthesis of Terrain Description Data is stored in the database in ÒrawÓ format - values describing altitude and color of each point separately. In this form the data is retrieved by the conversion program. New node of VRML 1.1 - ElevationGrid - is used Conversion program produces the VRML representation using parameter values given by user. The parameters the user can set include: color or monochrome option lighting option color corrections altitude magnification (default=2) maximum resolution GIS in Database System Data Storage and Indexing The terrain data is stored in one table with types optimized for the speed of retrieval Each row of the table describes one point To improve retrieval speed of the data, various kinds of indices have been set The indices are optimized for fast retrieval of square parts of terrain data using various resolution levels GIS in Database System Reducing Number of Polygons Reduction of polygons number to be rendered in one scene is crucial for the performance Reduction can be static or dynamic Static reduction is achieved by decreasing the resolution Dynamic reduction uses the Level-of-Detail feature Dynamic reduction can is achieved in two stages: by presenting the same region with different resolution levels by gathering multiple regions into bigger areas GIS in Database System Resolution Index GIS in Database System Terrain Model GIS in Database System Terrain Model GIS in Database System External and Internal Request Loop External: by CGI scripts when VRML browser requests high number of HTTP connections only really needed data is transmitted Internal: in retrieving program - immediately low number of HTTP connections bigger data sets additional (unnecessary) data may be sent Modeling of Objects Object Data Additional data can be represented as ÒobjectsÓ Objects correspond to real world entities Description of objects includes: type of objects position (x,y,z coordinates) orientation scale Modeling of Objects Types Types define the properties of objects Types are named Types may be simple or composite Simple types are VRML description Composite types are built using simple types and transformations Transformation defines: position orientation scale color Definition of Objects - Example Database Schema Multiversion Approach Multiversion approach enables to visualize the same data in various ways Versions correspond to the rules of creation of VRML (types) not the objects. Multiversion enables to create VRML in various ways depending on the clientÕs needs and preferences (e.g. with various levels of detail, including or excluding some types etc.) Multiversion Approach The hierarchy of versions is defined by the version tree Child version while created inherits all parentÕs properties - simple creation of new versions Only differences between parent and child version are stored - no redundancy Multiple inheritance possible Propagation of changes made in parent versions Demo Terrain rendering using data stored in Illustra database defining the starting point (map interface) parametrized creation of VRML Objects on the surface type editor (simple and composite) view of type using authoring tool to edit simple types creation and edition of objects Multiversion support creation of VRML using various database versions Further Work Multiversion approach work needs continuation Defined data types and C functions can be converted to Illustra DataBlade Query language including spatial and semantic information is needed Polygon optimization - ÒsmartÓ algorithm reducing number of polygons in terrain data - indexing Conclusions Database support for VRML provides the developer and user of applications with a wide range of new possibilities This approach is the possible future of VR systems Illustra database system satisfies the requirements of VRML applications, particularly the response time and volume of data that can be processed are sufficient Proposed approach is not platform - depended and can be ported to other systems (hardware, database systems, VRML versions)