VRML Scene Graphs on an Interactive Ray Tracing Engine

Andreas Dietrich, Ingo Wald, Markus Wagner∗ and Philipp SlusallekSaarland University

Computer Graphics GroupIm Stadtwald - Building 36.1, 66123 Saarbrucken, Germany

{dietrich,wald,wagner,slusallek}@graphics.cs.uni-sb.de

Abstract

With the recent advances in ray tracing technology, high-quality image generation at interactive rates has finally be-come a reality. As a consequence ray tracing will likely playa larger role in visualization systems, enabling the concep-tion and creation of completely new interactive graphics ap-plications.

In this paper we describe the design and development ofa ray tracing-based VRML browser and editor as a casestudy of such an application. It exploits all advantagesof ray tracing, including physically-correct plug and playshading and support for large models.

In particular we demonstrate how to overcome the lim-itations that result from existing scene graph libraries anddata exchange formats still being targeted towards rasteri-zation technology. Also we show how to extend the VRMLlighting model and to optimize scene graph handling for raytracing.

1 Introduction

Over the last years virtual reality (VR) has found its wayinto industrial design processes in particular in the automo-tive industry. The creation of realistic imagery is an impor-tant goal as it is often easier, less expensive, and more effec-tive than manufacturing mockups and prototypes. Ideally, auser should be able to also interact with the model and mod-ify its design, while obtaining high-quality visual feedback

∗Now with DIaLOGIKa GmbH, Dudweiler, Germany.

that also supports quantitative evaluation. Only the knowl-edge that the visual results are reliable and correct within aquantifiable error bound allows the user to trust the resultsand base important design decisions on them.

The almost exclusive use of rasterization-based hardwarein current VR systems makes it hard to obtain reliable re-sults because it relies on the use of approximations evenfor such simple optical effects as shadows and reflection.A real-world example for the need for reliable results is thefact that in a well-known car model the air vents in the dash-board reflect off of the curved side windows exactly wherethey interfere with the backward visibility via the left sidemirror. Because virtual mockups did not allow this reflec-tion to be visualized, this flaw was only discovered when itwas too late to be fixed.

Dealing with these limitations of rasterization technol-ogy has been difficult if not impossible and would requireextensive changes to applications. However, because raytracing closely models the physical transport of light [9], itcan provide correct results easily. An obvious step would beto implement a practical, scene graph driven VR applicationbased on the recent results in real-time ray tracing.

Ray tracing simplifies the modeling and design process,where individual objects and their material properties maybe defined independently, while the underlying ray tracingengine automatically combines the shading results to thecorrect image. There is no need to deal with complex multi-pass rendering in the application. Another inherent featureof ray tracing is its ability to efficiently handle huge scenedescriptions with tens of millions of primitives. This is dueto its logarithmic time complexity with respect to modelsize and its efficient occlusion culling.

109

IEEE Virtual Reality 2004 March 27-31, Chicago, IL USA 0-7803-8415-6/04/$20.00©2004 IEEE.

Please see the color plates on page 282

Proceedings of the 2004 Virtual Reality (VR’04) 1087-8270/04 $ 20.00 IEEE

Typical interactive applications operate with graphicalmodels on a higher level by making use of scene graphlibraries in order to aid in scene management. Exam-ples are OpenGL Performer [13], OpenInventor [19], orOpenSG [12]. Unfortunately, all these scene graph systemsare designed and optimized to run on rasterization hard-ware. Apart from performance issues this leads to the majordrawback that advanced ray tracing features cannot be ad-equately exploited, e.g. there usually is no way to specifyshader plug-ins. On the other hand scene graphs often in-corporate special display modes like multi-pass renderingthat are obsolete in combination with a ray tracing engine.

Similar problems arise from conventional file formatsused for exchange of models such as VRML [7]. Since theytoo assume rendering via rasterization, they only providefixed, simplified lighting models with limited parameters.

In this paper we present our implementation of an in-teractive VRML browser system that tries to exploit mostof the benefits of ray tracing in combination with flexiblescene graph handling. In particular we focus on dealingwith the described difficulties.

The rest of the paper is organized as follows: Section 2starts with an overview of VRML and our system’s ar-chitecture. Section 3 takes a closer look at actual imple-mentation issues and discusses necessary extensions to theVRML specification as well as scene graph optimizations inthe context of real-time ray tracing. Results are presentedin Section 4, followed by conclusions and some thoughtsabout future extensions in Section 5.

2 System Overview

Our browser VRML Viewer (VV) builds on three mainsubsystems as illustrated in Figure 1. The first subsystem isthe XRML library [2], which implements the VRML scenegraph and is responsible for importing VRML formatedmodels. The next layer is made of the OpenRT API [8],a low-level graphics interface to ray tracing-based render-ing engines that is very similar to OpenGL [11, 1]. Here itis used to drive the distributed RTRT [17, 15, 18] real-timeray tracing engine that performs the actual rendering andoptionally also some global lighting simulation.

2.1 VRML97

The Virtual Reality Modeling Language (VRML) [7]is a file format for describing interactive 3D objects andworlds.1 VRML has been designed to fit into the exist-ing infrastructure of the Internet and the world wide web

1VRML 1.0 was originally based on the OpenInventor fi le format butdid not defi ne an API. Later VRML 2.0 was created to extend the capabil-ities of VRML 1.0 to include animation, interaction, and model behavior.The subsequent ISO/IEC VRML standard is also known as VRML97.

VRML Viewer

Extensible Scene Graph ManagerXRML

Application Programming InterfaceOpenRT

Real−Time Ray Tracing EngineRTRT

VV

Figure 1. Relation of the basic components ofthe presented VRML browser system.

but is also meant as a universal interchange format for inte-grated 3D graphics and multimedia. An example of a simpleVRML scene can be seen in Figure 2.

VRML has been chosen as the primary input format forour ray tracing-based browser for two main reasons: First,it can be seen as a de facto standard exchange format forVR model data. Therefore most industrial CAD systemsare able to directly export VRML files. Secondly, VRMLnot only describes static scenes. It also supports dynamicbehavior and provides features for advanced user interaction(see Section 4).

2.2 XRML

Instead of using a full featured scene graph library, e.g.OpenInventor, we opted for the Extensible Scene GraphManager package XRML [2] due to its lightweight andmodular structure that enables a simpler adaptation to theray tracing back-end.

XRML supplies a number of C++ classes to aid withthe import, creation, and management of VRML scenegraph structures. Although XRML is mainly focused onVRML97, its modular form allows for importing and ex-porting other 3D graphics formats as well as the extensionof its graph node handling capabilities.

2.2.1 Data Types

In XRML, all elementary VRML data types (e.g.SFInt32, SFVec3f, or MFNode, see [7]) have directlycorresponding C++ classes. Consequently, all supportedVRML nodes are also represented by appropriate C++

110Proceedings of the 2004 Virtual Reality (VR’04) 1087-8270/04 $ 20.00 IEEE

#VRML V2.0 utf8

Transform {translation 0 0 5childrenShape {

appearance Appearance {material Material {

diffuseColor 1 0 0}

}geometry Sphere {radius 0.5

}}

}

Figure 2. VRML97 scene description example.A diffuse red sphere is displayed at the centerof the screen if viewed with default camerasettings.

classes. These include field data and pointers to child nodesplus manipulation methods, e.g. to modify the node’s statein case of arriving events.

2.2.2 Scene Graph Traversal

Invoking the render() method on the XRML world ob-ject initiates a top-down scene graph traversal, recursivelycalling the render() member functions of all node ob-jects and their children. This procedure is typically ap-plied to render the virtual world at its current state. How-ever, the actual image generation is controlled by a sepa-rate renderer object that implements callback routinesfor every node type. These routines are then activated by thenodes in the graph during traversal. This way, different ren-dering modes may be realized by replacing the rendererobject, which is of particular interest for our purposes ofemploying a ray tracing back-end instead of a rasterizationengine. A more precise description of this process is pre-sented in Section 3.

2.2.3 Event Execution Engine

During the graph traversal, initial events (e.g. timer events)are generated, which causes messages to be sent to nodes.Receiving nodes alter their state according to these signals,possibly generating new events and appropriate messages.An event execution engine handles the routing of all theseevents. Due to resulting modifications to the scene graph,dynamic behavior like animation or user interaction canbe realized. Additionally, flags are maintained, recordingchanges between frames.

2.2.4 Node Extension Mechanism

An important motivation behind the XRML package is itsability to easily extend the set of standard nodes. Thus,it enables the support of graphical applications for whichVRML was not designed in the first place, such as advancedillumination algorithms in our case. New nodes are im-plemented with the help of independently compiled C++plug-in libraries. In order to ease construction of customnodes, XRML comes with an utility called “nodegen”. Thistool takes concise node specifications in a similar form asin [7] as input and produces C++ header and code skele-ton files. Most methods such as constructors and parsingfunctions are generated automatically. Only the above in-troduced render() function has to be implemented man-ually by extending the renderer class. In fact, large partsof the XRML code for standard VRML nodes have beenproduced by “nodegen”.

2.3 OpenRT

OpenRT [8] serves as a low-level graphics rendering in-terface that allows easy creation of interactive applicationsbased on ray tracing. OpenRT is syntactically very similarto OpenGL [11, 1], a well-known and widely accepted pro-gramming interface for 3D graphics. This simplifies portingof existing applications, including scene graph libraries lay-ered on top of OpenGL.

All features of interactive ray tracing needed for high-quality image generation are supported. The ability to shootarbitrary rays enables physically-correct lighting simula-tions. Also, shaders, i.e. custom functions that control il-lumination calculations, can be applied in a plug and playmanner, while the ray tracer automatically produces an ac-curate combination of the desired shading effects.

The OpenRT API is composed of two sub-interfaces:The core OpenRT application programming interface as-sists an application in specifying geometric objects, tex-tures, transformations etc. in a way much like OpenGL. Inmany cases the usual “gl” prefix can just be replaced with“rt”. For example, all the usual OpenGL geometric prim-itives are available, and are issued by implementing cus-tomary rtBegin()/rtEnd() statements. The OpenGLAPI has been extended to allow for loading programmableshader plug-ins, and for setting their parameters values. TheOpenRTS shading language API presents shaders with acommon interface to the renderer. It gives access to geo-metric and lighting information at the shading site.

2.3.1 Relation to OpenGL

Although there are close syntactical similarities, OpenGLand OpenRT differ in four main areas due to the differentunderlying rendering algorithms.

111Proceedings of the 2004 Virtual Reality (VR’04) 1087-8270/04 $ 20.00 IEEE

Rendering Semantics. Unlike OpenGL’s direct render-ing approach, OpenRT manages the scene using objects asit must have access to the entire model for implementingglobal optical effects. It uses geometric objects that en-capsulate primitives, while shader objects represent the sur-face’s optical characteristics using texture objects for tex-ture mapping.

Geometry is then bound to shaders that contain appro-priate appearance parameters. Because the whole scene hasto be specified prior to any visibility calculations, there isno OpenGL-like immediate rendering mode. Also no statemachine exists during rendering, so changes to the param-eters of a particular shader affect all bound geometry whenthe next frame is rendered.

Objects and Instantiation. Despite semantic differences,OpenRT’s object definition scheme behaves mostly likeOpenGL’s display list handling except that it cannot haveside effects or effects due to global state. Objects have to beinstantiated in order to be effective, similar to calling a dis-play list. Note, however, that this will not trigger immediatevisibility calculations. Instantiation can be highly efficientfor a ray tracer as it reduces the memory footprint and onlyaffects rendering time if actually visible.

Multi-Pass Rendering vs. Shaders. With OpenGL, morecomplex lighting situations are usually approximated bycombining images resulting from multiple rendering passes,i.e. for shadows or reflections. Such tricks can be used withray tracing too, yet they are not necessary because of theability to perform physically-correct lighting in a single ren-dering step. Instead, independently implemented shaderscan perform these computations directly.

Fragment and 2D Operations. Up to now, OpenRTserves as pure 3D graphics interface. 2D imaging and frag-ment operations like stencil tests, alpha tests, or blendinghave no direct OpenRT equivalents. Typically, such effectscan be easily achieved through the use of suitable shaders.

2.4 RTRT

Our RTRT Real-Time Ray Tracing engine implementsthe OpenRT interface. It is designed as an interactive, dis-tributed ray tracing engine that supports all the interest-ing ray tracing effects outlined in Sections 1 and 2.3 in-cluding support for dynamically changing scenes. Similarto OpenGL, RTRT currently only implements triangles asprimitives for performance reasons.

Apart from a few assumptions for the sake of perfor-mance (see next Section), the inner workings of the core

are kept completely transparent to the front-end applica-tion. Thus, we refer to previous publications for more de-tails about its implementation [17, 15, 18].

3 Browser Implementation Issues

Producing a simply lighted still image from some VRMLscene description via OpenRT is fairly straight forward. Theexploitation of all the benefits of interactive ray tracing,however, requires careful adjustment of the above subsys-tems, especially when coping with VRML limitations.

3.1 Rendering

Section 2.2.2 already reviewed XRML’s modular ren-dering concept that allows to freely replace the render-ing methods. XRML not only offers a base rendererclass, it also brings along a ready-to-use OpenGL-basedrenderer derivative.

Although this class applies only basic OpenGL features,i.e. no multi-pass rendering or special extensions, it stillmakes use of immediate mode graphics and OpenGL mate-rial and lighting calls. As this is not supported in OpenRT,it is not sufficient to just adapt some calls, and it is moreappropriate to write a custom-made renderer. Neverthe-less, large parts of the original class consist of geometrycommands like primitive definitions and matrix operations,which can easily be copied and ported by just replacing the“gl” prefix with “rt”.

VRML is not regarded as a true geometric modeling lan-guage, because of its lack of richer geometric primitives andmodeling mechanisms. Still it offers more primitive typesthan OpenGL or OpenRT. Fortunately, this is not a problemof the renderer class, as each available VRML geometrynode implementation already includes triangle tessellationprocedures as also required by OpenGL.

During the traversal stage we do not perform any render-ing operations, but only update the scene description withinthe OpenRT rendering back-end. Only after traversal of theVRML scene graph, the application triggers rendering bycalling rtSwapBuffers().

3.2 Shading

For shading purposes, standard VRML is limited to asingle appearance model, an extended version of the Blinn-Phong [6] model with a single texture. This severely lim-its the appearances and the realism that can be achieved.Because ray tracing can easily support almost arbitraryshaders, we need to extend the appearance model of VRML.

We used the node extension mechanism of XRML (Sec-tion 2.2.4) and the “nodegen” utility to create several newnode types. The most important one, ORTAppearance,

112Proceedings of the 2004 Virtual Reality (VR’04) 1087-8270/04 $ 20.00 IEEE

replaces the original VRML Appearance node, and ex-tends it by a new field named shader. With another newnode type, ORTShader, that follows the shader field, itis now possible to assign a different shader object to eachShape and therefore to the corresponding geometric ob-ject. An example can be seen in Figure 3.

appearance ORTAppearance {material Material {

diffuseColor 1 0 0}shader ORTShader {

name "Glass"file "libGlass.so"options ["1f refractionIndex 1.5"

]}

}

Figure 3. Appearance node extension. AnORTAppearance node additionally incorpo-rates a shader field plus an ORTShader node.In this example, it selects a glass shader plug-in and initializes the shader’s refractive indexparameter.

The name field provides the shader class name, whereasfile points to the location of the corresponding shared li-brary plug-in. Additionally, an options field can containone or more parameter strings. Here we have a single float-ing point argument (1f) together with its name and initialvalue.

If a standard Appearance node is encountered orORTAppearance includes no shader definition, a defaultshader class will be instantiated that implements the VRMLappearance model. In any case, where a Material nodeis present, the application assumes that the relevant shaderhas a built-in set of default parameter slots, which receivethe standard VRML material parameters. For example, thediffuseColor value will be sent to a shader parame-ter also named diffuseColor. Note, that it is up tothe shader to implement them and use them as intended.A shader is free to interpret these value as it sees fit. So,VRML materials may also be used e.g. by global illumina-tion shaders. More information about OpenRT shader han-dling can be found in [8].

3.3 Scene Graph Mapping

It has already been mentioned that ray tracing algorithmscan have sub-linear time complexity with respect to scenesize. To this end they maintain acceleration structures, i.e.a hierarchical spatial index that allows to quickly query for

geometry near a ray (RTRT utilizes k-d trees for this pur-pose [5, 10]).

These acceleration structures may be considered an in-ternal scene graph, onto which an external one, i.e. the ap-plication’s scene graph, has to be mapped. This mappingis performed using the OpenRT API. The application canoptimize this mapping by considering the usage of the ac-celeration structures for ray tracing.

3.3.1 Object Grouping

In analogy to OpenGL, the OpenRT API specifica-tion offers multi-level geometric object nesting, i.e. be-tween an rtBeginObject()/rtEndObject() defini-tion rtInstantiateObject() calls are allowed. Eachsingle object maintains its own (low-level) spatial index.These object indices are then inserted into a high-level in-dex. This scheme localizes any changes and thus the costlyupdate of the index structure when changing parts of thescene. Only the higher-level indices must then be updated,while all other objects remain unaffected.

A straightforward way to process a VRML scene graphwould be to encapsulate each Shape’s geometry inside anOpenRT object. Unfortunately, many small objects wouldadd considerable overhead when ray traversal would haveto switch often between high- and low-level indices. Anobvious solution is to group small static objects together.However, this is not a trivial task as the whole VRML scenegraph may potentially be changed at any time. This is simi-lar to an OpenGL-based scene graph library trying to mini-mize state changes during rendering.

VRML includes no means to signal which parts of ascene remain static over time. Instead we have to use heuris-tics. Nodes that may receive incoming events, i.e. that havebeen connected via ROUTE statements, indicate where thescene graph can be split up. If there are no further rout-ings below such a point, subsequent nodes will not changethrough events. For example, if a transformation node re-ceives events, but its Shape children nodes do not, we cancombine them into one single OpenRT object. Conversely,if e.g. a Shape node acts as an event receiver, it must beput into a separate object.

In a VRML browser this optimization works very wellunless nodes are created, destroyed, or moved at runtime.Scripting and the External Authoring Interface (EAI) havethese options (see Section 3.4). Currently, we are restrictedto scripts that do not perform such actions. A trivial butnon-optimal solution would be to rebuild the changed hier-archies whenever necessary. Note, that custom applicationsusually have full control over handling of the scene graph.

The current RTRT version only implements a two-levelindex structure and must flatten the hierarchy, which addssome overhead [14].

113Proceedings of the 2004 Virtual Reality (VR’04) 1087-8270/04 $ 20.00 IEEE

Figure 4. Industrial design applications. Both models are rendered interactively by our VRML browser.Their VRML representations contain additional nodes to specify custom shaders. Left: A car head-light featuring physically-correct reflection and refraction. Right: A complete car, also visualized ina physically-correct manner using special glass and car paint shaders.

3.3.2 Dynamic Scenes

Handling dynamic VRML scenes can be easily accom-plished using the hierarchical index structures. XRML itselftakes care of event processing, and automatically marks allnodes whose fields have been altered.

OpenRT allows for changing object transformationswithout having to rebuild the object’s index. For example,when a Transform node is changed, we traverse its sub-tree, and recursively transform all associated OpenRT ob-jects. Each such object may actually be a combination ofseveral VRML child nodes (see above). This will automati-cally trigger an update of RTRT’s high-level index k-d tree.

Non rigid body transformations are somewhat morecomplicated as objects need to be deleted and must be recre-ated with the updated geometry. Modification of appear-ance properties is even simpler as we just have to updatethe relevant shader parameters.

3.4 Scripting

In addition to the standard nodes that provide meansfor dynamic actions (e.g. PositionInterpolator),VRML includes Script nodes to incorporate pro-grammable behavior.2

We have extended XRML with a plug-in scripting mech-anism, thereby significantly extending its capabilities foranimation and interaction without modifying the VRMLbrowser itself. These extensions to the XRML libraryalso enable other XRML-based applications to make use ofscripting.

Rather than hard-coding script interpreters, externalshared libraries serve as scripting engines. Special customnodes are used to associate individual scripting languagetypes with appropriate engine plug-ins. If a Script node

2ISO/IEC 14772 does not require browsers to support a specifi cscripting language, however, it defi nes language bindings for Java andECMAScript.

includes a reference to a file containing a script program,or if the script is inlined inside such a node, an associatedlibrary (if available) is loaded on demand and executes thescript. Of course, one may also apply engines that do notevaluate any scripting code but perform hard-coded opera-tions (e.g. input from external sensors).

As an example we implemented an engine capable ofinterpreting Tcl/Tk scripts. This not only allows pro-grammable behavior but also enables graphical user inter-faces, e.g. control panels for positioning geometric objectsor for modifying shader parameters.

4 Results

In order to evaluate the benefits of combining interac-tive ray tracing and VRML scene graphs we used a varietyof test scenes. These ranged from industrial design appli-cations to complex global illumination situations. Exper-iments were conducted on a cluster of 8 commodity PCseach fitted with two AthlonMP 1800+ CPUs executing thedistributed ray tracing code in software.

Performance for the shown examples ranges from 3.5up to 6 frames per second at video resolution (640 × 480).Higher rates can be achieved by utilizing more or faster PCsas the RTRT core scales almost linearly in the number ofCPUs [15]. Alternatively, quality settings (e.g. image reso-lution, recursion depth etc.) can be adapted.

4.1 Industrial Design Applications

Figure 4 shows two typical VR settings in industry. TheVRML model of the car headlight on the left has beenexported from the same CAD dataset that is also used inthe actual manufacturing processes. It contains more than800,000 triangles. Special reflector and glass shaders areapplied that carefully model the physical material proper-ties [3].

114Proceedings of the 2004 Virtual Reality (VR’04) 1087-8270/04 $ 20.00 IEEE

Figure 5. Animated global illumination. Left: A VRML scene incorporating animation paths for amoving lamp and a rotating globe. All lighting calculations are performed by a global illuminationshader plug-in. Right: Depending on where the globe is lit by the lamp, different lighting patternsappear on the surrounding objects.

To accurately simulate the visual appearance up to 25levels of recursion and up to 50 rays per pixel are needed insome image locations. This level of realism is impossibleto compute with rasterization hardware due to the complexscattering of light. This is the first time automotive design-ers and headlight manufacturers can interactively evaluateoptical design proposals.

The car model on the right of Figure 4 demonstrates thecapability of visualizing reflections off of curved surfaces.Note, that this is no simple environmental mapping. In con-trast to rasterization multi-pass rendering procedures, mul-tiple reflections are correctly calculated in one single ren-dering step. For example, the side mirrors are reflected inthe car body and vice versa, also all reflections and refrac-tions in the windows are simulated according to physicalequations.

4.2 Animation and Sophisticated Lighting

In the next example (Figure 5) a rotating globe is dy-namically lit by a moving lamp, projecting complex lightpatterns onto its environment. This scene has been modeledwith the help of commonly available CAD design packagesthat are able to export VRML files including all animationpaths. Apart from some procedural texture shaders (e.g. thewooden table), the scene has been kept unaltered. By sim-ply assigning a global illumination plug-in as default sur-face shader, advanced global lighting with indirect diffuseinter-reflection can be instantly combined with VRML’s dy-namic capabilities.

This is made possible by recent real-time global illumi-nation algorithms based on the same real-time ray tracingengine used for our VRML work [16, 4]).

4.3 Advanced User Interaction

Our previous example was based on predefined anima-tions. The next scene additionally allows for complex userinteraction via VRML scripting. Figure 6 shows an inter-

active chess game. All its chessmen can be controlled byan external Tcl/Tk script, whose execution is handled by ascripting engine plug-in. Tcl/Tk not only enables arbitrarycomputations, one can also generate customized graphicaluser interfaces such as the control panel depicted in the mid-dle of Figure 6. All functions of the VRML browser are stillavailable, so for example it is always possible to change ma-terial and shader parameters of geometric objects.

5 Conclusions and Future Work

The above examples show that it is feasible to place full-featured scene graph applications on top of a ray tracing-based rendering engine combining all the advantages ofboth worlds. This is possible by extending VRML withsupport for programmable shading and optimizing the scenegraph by grouping it into suitable large objects that can beefficiently used by a ray tracer.

While our browser can efficiently make use of most ad-vantages of the OpenRT/RTRT ray tracing engine, someimportant features are still missing. For instance, thereis currently no browser support for instantiating an ob-ject multiple times, as it is difficult to gain the necessaryinformation from a VRML scene description. VRML’sDEF/USE mechanism might be seen as some kind of in-stancing. But these directives are mere pointers that linkdifferent parts of the scene graph, which is more generalthan the reuse of objects. For example, one Shape’s geom-etry part can be reused in another Shape node with a dif-ferent Appearance. OpenRT on the other hand only pro-vides instantiation of complete objects including geometricand material properties. Another difficulty comes from thefact that instantiation can interfere with our object groupingstrategies (see Section 3.3.1) because it is not possible tomerge several instantiated objects into a larger one.

Both problems could be eased by applying modifiedheuristics. Instancing could e.g. be restricted to completeShape nodes. Also, depending on memory usage and on

115Proceedings of the 2004 Virtual Reality (VR’04) 1087-8270/04 $ 20.00 IEEE

Figure 6. VRML scripting. A chess game controlled by a Tcl/Tk scripting engine. Left: Chessboardoverview from inside our VRML browser. Middle: Graphical user interface produced by the Tcl/Tkscript. Right: Closeup view on some of the chessmen showing multiple reflections.

the number of the involved objects we could decide wheterto group them by replicating their geometry, or to use in-stancing instead.

A probably better way is to extend the VRML97 stan-dard with additional nodes that provide detailed informa-tion about which parts of the external VRML scene graphremain static, and how it can be efficiently mapped to aninternal ray tracing-based scene graph.

Acknowledgements

Special thanks to Philippe Bekaert for providing his XRMLlibrary and for helping with the implementation of the VRMLbrowser. Dmitri Rubinstein developed the scripting engine sys-tem and wrote the Tcl/Tk script for the chess scene, based on anoriginal script by Mark Oakden. The car headlight was suppliedby Hella Corporation. The animated globe scene was modeledby Tim Dahmen using Maya, and Wenxiang Ying helped with thechess scene. HDR images courtesy of Paul Debevec. Finally, wewould like to thank Andreas Pomi and Carsten Benthin for helpfulcomments and suggestions.

This work has been supported by AMD and Intel Corporation.

References

[1] K. Akeley. Reality Engine Graphics. Computer Graph-ics, pages 109–116, July 1993. (Proceedings of ACM SIG-GRAPH 1993).

[2] P. Bekaert. Extensible Scene Graph Manager, August 2001.http://www.cs.kuleuven.ac.be/∼graphics/XRML/.

[3] C. Benthin, I. Wald, T. Dahmen, and P. Slusallek. InteractiveHeadlight Simulation – A Case Study of Distributed Interac-tive Ray Tracing. In Proceedings of Eurographics Workshopon Parallel Graphics and Visualization (PGV), pages 81–88,2002.

[4] C. Benthin, I. Wald, and P. Slusallek. A Scalable Approachto Interactive Global Illumination. Computer Graphics Fo-rum, 22(3):621–630, 2003. (Proceedings of Eurographics).

[5] J. L. Bentley. Multidimensional Binary Search Trees Usedfor Associative Searching. Communications of the ACM,18(9):509–517, 1975.

[6] J. Blinn. Models of Light Reflection for Computer Syn-thesized Pictures. Computer Graphics, 11(2):192–198, July1977. (Proceedings of ACM SIGGRAPH 1977).

[7] R. Carey, G. Bell, and C. Marrin. ISO/IEC 14772-1:1997 Virtual Reality Modelling Language (VRML97),April 1997. http://www.vrml.org/Specifi cations/VRML97.

[8] A. Dietrich, I. Wald, C. Benthin, and P. Slusallek. TheOpenRT Application Programming Interface – Towards ACommon API for Interactive Ray Tracing. In Proceedings ofthe 2003 OpenSG Symposium, Darmstadt, Germany, 2003.

[9] A. Glassner. An Introduction to Ray Tracing. Morgan Kauf-mann, 1989. ISBN 0-12286-160-4.

[10] V. Havran. Heuristic Ray Shooting Algorithms. PhD thesis,Czech Technical University, 2001.

[11] J. Neider, T. Davis, and M. Woo. OpenGL ProgrammingGuide. Addison-Wesley, 1993. ISBN 0-20163-274-8.

[12] OpenSG-Forum. http://www.opensg.org, 2001.[13] J. Rohlf and J. Helman. IRIS Performer: A High Perfor-

mance Multiprocessing Toolkit for Real-Time 3D Graphics.Computer Graphics, 28(Annual Conference Series):381–394, July 1994.

[14] I. Wald, C. Benthin, and P. Slusallek. Distributed InteractiveRay Tracing of Dynamic Scenes. In Proceedings of the IEEESymposium on Parallel and Large-Data Visualization andGraphics (PVG), 2003.

[15] I. Wald, C. Benthin, M. Wagner, and P. Slusallek. InteractiveRendering with Coherent Ray Tracing. Computer GraphicsForum, 20(3):153–164, 2001. (Proceedings of Eurographics2001).

[16] I. Wald, T. Kollig, C. Benthin, A. Keller, and P. Slusallek. In-teractive Global Illumination using Fast Ray Tracing. Ren-dering Techniques 2002, pages 15–24, 2002. (Proceedingsof the 13th Eurographics Workshop on Rendering).

[17] I. Wald, T. J. Purcell, J. Schmittler, C. Benthin, andP. Slusallek. Realtime Ray Tracing and its use for Inter-active Global Illumination. In Eurographics State of the ArtReports, 2003.

[18] I. Wald, P. Slusallek, and C. Benthin. Interactive DistributedRay Tracing of Highly Complex Models. Rendering Tech-niques 2001, pages 274–285, 2001. (Proceedings of the 12thEurographics Workshop on Rendering).

[19] J. Wernecke. The Inventor Mentor. Addison-Wesley, 1994.ISBN 0-20162-495-8.

116Proceedings of the 2004 Virtual Reality (VR’04) 1087-8270/04 $ 20.00 IEEE

Figure 4. Industrial design applications. Both models are rendered interactively by our VRML browser.Their VRML representations contain additional nodes to specify custom shaders. Left: A car head-light featuring physically-correct reflection and refraction. Right: A complete car, also visualized ina physically-correct manner using special glass and car paint shaders.

Figure 5. Animated global illumination. Left: A VRML scene incorporating animation paths for amoving lamp and a rotating globe. All lighting calculations are performed by a global illuminationshader plug-in. Right: Depending on where the globe is lit by the lamp, different lighting patternsappear on the surrounding objects.

Figure 6. VRML scripting. A chess game controlled by a Tcl/Tk scripting engine. Left: Chessboardoverview from inside our VRML browser. Middle: Graphical user interface produced by the Tcl/Tkscript. Right: Closeup view on some of the chessmen showing multiple reflections.

Color plate of paper VRML Scene Graphs on an Interactive Ray Tracing Engine on page 109

282Proceedings of the 2004 Virtual Reality (VR’04) 1087-8270/04 $ 20.00 IEEE