Abstract * Foil Index for this file
Given by Krzysztof Walczak at Research Seminar on 9 february 1996. Foils prepared 9 february 1996
Abstract * Foil Index for this file
| 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 |
This table of Contents
Abstract
Full HTML Index
| Krzysztof Walczak |
| NPAC |
| Syracuse University |
| 111 College Place |
| Syracuse NY 13244-4100 |
Full HTML Index
| 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 |
Full HTML Index
| 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:
|
Full HTML Index
| 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. |
Full HTML Index
The current form of VRML has been strongly influenced by the following requirements:
|
Full HTML Index
| 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 |
Full HTML Index
VRML nodes can be classified into three categories:
|
Full HTML Index
| Shape nodes (Cube, Sphere) define the geometry of the objects in the scene. |
Full HTML Index
| The Material node defines the current surface material properties for all subsequent shapes. |
Full HTML Index
| Separator node isolates its children from the rest of the scene graph. |
Full HTML Index
| 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 |
Full HTML Index
| 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 |
Full HTML Index
Database system is used to store the data
|
Database keeps information about the components - not the final VRML form - semantic modeling
|
VRML representation is created dynamically
|
Full HTML Index
| 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 |
Full HTML Index
| 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. |
Full HTML Index
| Object-Relational DBMS |
The features typical of Relational DBMS:
|
Features typical of object-oriented database technologies:
|
Full HTML Index
| Illustra DataBlades |
| DataBlades provide specialized support for some application domains |
DataBlades consist of several components:
|
| 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. |
Full HTML Index
| Access to the Data |
| Data can be accessed in various ways: |
| SQL - Unix or MSWindows Client |
API - LIBMI - C library:
|
Full HTML Index
| 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 |
Full HTML Index
| 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. |
Full HTML Index
| Second Approach (cont.) |
The following VRML structures were used to model the terrain data:
|
Full HTML Index
| 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. |
Full HTML Index
| 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. |
Full HTML Index
| 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. |
Full HTML Index
| 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. |
Full HTML Index
| 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. |
Full HTML Index
| File-based approach |
Full HTML Index
Full HTML Index
| VRML Synthesis |
Synthesis of VRML representation can be divided into two separate parts:
|
Why terrain shape description is treated in a special way ?
|
Full HTML Index
| Terrain Data |
Data used for terrain shape modeling
|
| Values of three color components (RGB) are calculated using six original values: three from the visible range and three infrared |
Full HTML Index
| 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:
|
Full HTML Index
| 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 |
Full HTML Index
| 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:
|
Full HTML Index
| Resolution Index |
Full HTML Index
| Terrain Model |
Full HTML Index
| Terrain Model |
Full HTML Index
| External and Internal Request Loop |
External:
|
Internal:
|
Full HTML Index
| Object Data |
| Additional data can be represented as "objects" |
| Objects correspond to real world entities |
Description of objects includes:
|
Full HTML Index
| 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:
|
Full HTML Index
Full HTML Index
Full HTML Index
| 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.) |
Full HTML Index
| 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 |
Full HTML Index
Terrain rendering using data stored in Illustra database
|
Objects on the surface
|
Multiversion support
|
Full HTML Index
| 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 |
Full HTML Index
| 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) |