An Architecture for Constructing Large VRML Worldsbelfore/publications/SCSproof.pdf · an...

24 TRANSACTIONS Volume 18, Number 1

Received: January 2000; Accepted: May 2001

TRANSACTIONS of The Society for Modeling and Simulation InternationalISSN 0740-6797/01Copyright © 2001 The Society for Modeling and Simulation InternationalVolume 18, Number 1, pp. 23-39

An Architecture for Constructing Large VRMLWorlds

Lee A. Belfore II

Department of Electrical and Computer Engineering, Virginia Modeling, Analysis and Simulation Center(VMASC), Old Dominion University, Norfolk, Virginia 23529, [email protected]

The Virtual Reality Modeling Language (VRML) offers capabilities far beyond the virtual exploration of solidmodels. The scripting capabilities and the execution mechanism enable the creation of complex applications.Indeed, applications can be implemented as a collection of modules interacting in a decentralized fashion, com-municating through the exchange of messages. In this paper, an architecture is presented for creating largeVRML worlds. The architecture includes a definition of functional modules that serve as the foundation for theapplication. In addition, object model architectures are structured into three layers that separate pure behaviorfrom editing controls and also from the interface to the visualization, supporting module diversity and reuse. Anurban planning example application is presented that incorporates these ideas and features a graphical userinterface (GUI), collision management, a simple simulation manager, and an interface to a web server. Finally,several object examples are described followed by a presentation of an example session.

Keywords: VRML, virtual reality, architecture, live updates

1. IntroductionThe growth of the Internet has provided opportunities for tech-nological advances in how people communicate information andideas. Among the factors driving the advances is the desire toenhance the way internet content is presented to the user. Onthe surface, displaying a web page appears to be a simple mat-ter of displaying text and images. With the introduction of pro-gramming capabilities offered by Java, Javascript, and other pro-gramming and scripting languages, the web page is dynamicand can be customized for individual users. Paralleling the ad-vances in web technology, advances in computer technologysupport approaches that were until recently beyond the capa-bilities of machines generally available. As evidence and in sup-port of these advances, a 3D interactive visualization language,the Virtual Reality Modeling Language (VRML), was created,has been standardized, and is widely available [1]. VRML of-fers an opportunity to demonstrate the utility in Internet deliv-ery of interactive 3D web content.

Current web technology provides a variety of architecturaloptions that distribute the responsibilities between client andserver in various ways. An excellent overview of virtual worldarchitectural issues can be found in [2,3]. From the literature,several VRML applications have been demonstrated and showpromise in delivering three dimensional content over the Inter-net using the unique capabilities offered by VRML. The typesof VRML applications fall into several broad, but non-exclu-sive, categories. These categories include education and train-ing [4–9], virtual collaboration, [6, 10, 11], information visual-ization and retrieval [12–14], games and entertainment [11, 15,

16], design tools [3, 17], and modeling and simulation [11, 18–20]. Indeed, the applications include components in several ofthese categories. The application domains are also broad andinclude urban planning [19, 21], geographic information sys-tems (GIS) [14, 22], medical [5, 9, 23], engineering [3, 17],business [6–8], and combat simulations [18].

Applications can have many general operational features.These features affect the flexibility of the application and thecomplexity of the implementation. A virtual world is an inter-acting collection of components that compose the world, eachcomponent manifested by solid models and/or behaviors. Thestructure of the virtual world is represented by a scene graphdefining the interrelationship among components in the world.We define the extent of the virtual world by the way compo-nents are allocated. The extent can have a great impact on thecapabilities of the world. In a world with static extent, all com-ponents are loaded and inserted into the scene graph at startup.Throughout the life of the session, the world scene graph doesnot change; components are neither added nor deleted from thescene graph. A world with reconfigurable extent allows compo-nents to be added or removed from the scene graph at run time,but the number of components is fixed at startup. A world withdynamic reconfigurable extent enables the addition of any num-ber of components at run time, limited only by the resources ofthe client machine.

The three extent models vary in their capabilities and per-formance. A static extent world offers high performance that iswell suited to many applications. In the event the world scenegraph must be changed, changes must be made to source filesand the world must be reloaded, resulting in significant laten-cies when reloading complex worlds. A reconfigurable extentworld offers the flexibility to change the scene graph by includ-ing a fixed size pool of components that may be inserted.

L.A. Belfore

Volume 18, Number 1 TRANSACTIONS 25

Since the pool of components is immediately available, the scenegraph can be updated quickly. A reconfigurable extent worldhas two shortcomings. First, the number of components is fixed.If it is not known how users expect to modify the world, manycomponents provided may be unused, resulting in significantstartup latencies and greater resource requirements for manysessions. Second, if several different components are desired,additional demand is required at startup because a fixed alloca-tion of each type must be provided at startup. Indeed, if toomany different components are available, the reconfigurableextent world becomes impractical. A dynamic reconfigurableextent world offers a solution to the start up resource problemsof the reconfigurable extent worlds. In dynamic reconfigurableextent worlds, components are allocated and added at run time,as needed. As a result, startup times are lessened compared withreconfigurable worlds. Dynamic reconfigurable extent worldsincur some implementation complexities not present in the othertwo extent models. The component architectures may requirespecial features and treatment so that the component can be in-serted into the world. Furthermore, inserting the component intothe scene graph may require several steps (i.e., allocation, ini-tialization, scene graph insertion, event routing). This paper de-scribes an architecture for dynamic reconfigurable extent worlds.

Looking in more detail at some of the applications suggeststhe power and also the limitations of VRML technologies. Wedescribe some of the more notable applications. The Nerve Gar-den architecture [10] describes how algorithms mimicking lifeprocesses are used to create and plant artificial plants. NerveGarden is a collaborative laboratory allowing users to createand germinate plants in an applet window with subsequent in-sertion into a scene graph common to all users. Since the num-ber of plots is fixed, the application likely uses a reconfigurableextent model along with some fairly significant coupling to theserver. The CADETT interactive multimedia business learningenvironment (CIMBLE) [6–8] describes a virtual training en-vironment allowing participants at distant locations to collabo-rate. Interaction among users is accomplished using a multi-user domain (MUD). A key contribution of this work is thedescription of a software architecture. [9] describes the archi-tecture of a web based training system for endoscopic proce-dures treating abdominal aortic aneurisms. The architecture in-cludes server and client processes, uses the VRML ExternalAuthoring Interface (EAI) [24]. Computations on the servermodel the dynamics of the simulated procedures. [3] describesan architecture for virtual prototyping in the context of web-based development environments. In this architecture, virtualprototypes are built using virtual components, suggestingreconfigurable extent, whose appearance is defined in VRMLand behavior defined in Java through the EAI. Component in-teraction is managed at the highest level in a virtual realityprototyping simulation engine. In the realm of urban and geo-graphic visualizations, several applications have been reported[14, 19, 25, 26]. Such applications require the manipulation anddisplay of large data sets. The general approach followed is forthe server to accept queries from client machine and then per-form server side processing to satisfy the request. Each modifi-cation requires the entire world to be reloaded and thus uses a

static extent model. For small data sets, reloading is not a sig-nificant issue; however, reloading large worlds can add unde-sirable latencies.

The primary contribution summarized in this paper is thedevelopment of a virtual world architecture for creating VRMLbased virtual worlds featuring large scale interactive, modularvisualizations characterized by dynamic reconfigurable extent.Indeed, few VRML applications support the allocation of dy-namic content at run time. The modularity of the application isachieved through the development of generic functional mod-ules for the application infrastructure with a collection of ob-jects composing the visualization. The application demonstratesthe integration of a graphical user interface (GUI), dynamicallyallocated objects, standard architecture for objects, and the vari-ous modules that link these together into an application. Morespecifically, the fixed backdrop defines the work area where alladditions and modifications occur. The object architecture isorganized into three layers implementing the interface to thevisualization, defining editing controls, and specifying the modelbehavior. The interface layer is sufficiently robust to be auto-matically generated, simplifying the integration of new modelsinto the application. Furthermore, our architecture supports somesimulation capabilities whose extent shall be explored in thefuture. The demonstration application is a tool developed for alocal municipality to complement conventional marketing ef-forts for marketing an office park. The architecture is constructedso that updates to the world occur dynamically on the clientmachine, lessening the load on client, server, and network re-sources when compared with a full reload of the virtual world.For any modification to the world, the server logs for the ses-sion are updated. Finally, the server supports save and restoreof client sessions by storing all client sessions and supportinguser authentication [27].

This paper is organized into eight sections, including an in-troduction, a brief tutorial on VRML, a presentation of the ar-chitecture, a description of the object architecture, a summaryof some example objects, a run through of an example session,a discussion of the architecture, and a summary.

2. VRMLA VRML application is typically a hierarchical organization ofgeometries, sensors, light sources, script methods, and group-ing primitives assembled in a meaningful fashion. In VRML,these primitives are termed nodes. Each node can have severalfields to define node appearance and also to define inputs to(eventIn fields) and outputs from (eventOut fields) the node. Anode can define a solid model, such as a box; a capability, suchas tracking the pointing device; or an arbitrary behavior, such aswhat can be defined in a script. Extensibility and model reuseare accomplished with prototype definitions that specify userdefined nodes. The subset of VRML node types (language primi-tives) used in the architecture is discussed in this section. Sev-eral excellent VRML resources exist in the literature [28, 29]that the reader is encouraged to consult. Figure 1 gives an ab-breviated overview and relationships of the more significantVRML nodes used in our application.

March TRANSACTIONS 2001


Grouping Nodes. The Group, LOD, Switch, and Transform nodesdefine how a collection of nodes can be grouped and also pro-vide some useful control over their appearance. The Group nodeis the most basic grouping node that associates groups of chil-dren nodes. One effect that the Group node imparts is to associ-ate a sensor with the entire child hierarchy. The Transform nodeprovides the same capabilities, but additionally allows arbitraryscale, translation, and rotations of the child hierarchy. Nodescan be dynamically added and removed from Group and Trans-form nodes. The LOD node provides some control over the levelof detail, or appearance as a function of the distance from thecamera. The Switch node allows the selection of one node to bevisible from a collection of nodes.

Sensor Nodes. VRML has a total of eight sensor nodes, of whichfour are used here, that generate events when the conditionsoccur to which they are sensitive. For example, the TouchSensornode generates an event when the mouse cursor is over an asso-ciated geometry and the mouse button is depressed. ThePlaneSensor senses mouse drag actions while the mouse buttonis depressed. Using a TouchSensor in conjunction with aPlaneSensor enables a mouse click to select a geometry(TouchSensor) and a mouse drag to change the position of thegeometry (PlaneSensor). The TimeSensor provides a mecha-nism for inserting delays and synchronizing different anima-tions within the visualization.

Figure 1. Abbreviated Overview of VRML Nodes Used in the Architecture

L.A. Belfore


Geometry Specifications. Shape geometries can be basic or gen-eral. Basic shapes such as boxes, cylinders, cones, and spheresare defined by name with fields to specify the expected dimen-sions. More general shape geometries include Extrusion andIndexedFaceSet geometries enabling specification of fairly ar-bitrary geometries. The Extrusion geometry is an analogy withthe shape a material, such as modeling clay, makes after beingforced through an opening with a varying cross section. TheIndexedFaceSet provides a general appearance representing theobject with simple faces.

Scripts. The Script node allows the implementation of arbitrarymethods and behaviors. The script receives input, does the re-quired processing, and then generates the necessary outputevents. For example, a script can take events from a PlaneSensorthat is tracking a mouse drag and transform this into an outputevent consisting of a set of vertices that defines another geom-etry. In addition, Script nodes provide an interface to the browserplug-in to facilitate such things as inserting new nodes into theworld or loading uniform resource locators (URLs). Script func-tionality can be provided using ECMAScript or Java methods.The Script interface can be customized to serve whatever pur-pose necessary. Each ECMAScript is a collection of methodsincluding a method for each input event. ECMAScript methodsprovide basic programming structures (looping, conditional) thatmay call one and other as well as other plug-in browser meth-ods. For dynamic worlds, several browser methods supply es-sential functionality. For example, the loadURL browser methodcan be used to request web content. The createVrmlFromURLbrowser method provides the run time function of allocatingcontent dynamically and then inserting it into the scene graph ata selected point. Additionally, the addRoute and deleteRoutebrowser methods make and respectively break event routes be-tween nodes. In the proper context, createVrmlFromURL inconjunction with addRoute can be used to allocate and then fullyintegrate any dynamic content at run time.

Fields and Events. VRML has a variety of built-in data typesthat can serve as variables or pass information between nodes.The basic types relevant to our application are outlined in Table1. The fields can be further qualified by field, eventIn, eventOut,and exposedField qualifiers. The field qualifier declares a vari-able that can be changed only at instantiation. The eventIn andeventOut fields declare variables that are either inputs or out-puts respectively. An exposedField variable serves as field,eventIn, and eventOut, simultaneously.

Events can be sent and received by most nodes. For example,a TouchSensor node generates an event resulting from a mouseclick on the associated geometry. This event could be receivedby a script resulting in the appearance of a wire frame boundingthe extent of the selected geometry. ROUTE declarations con-nect output events from one node to input events of another.Routes can either be explicitly declared or be dynamicallyformed in script nodes. Events can be simple, passing a simplevalue, or complex, passing a node, enabling many interestingcapabilities. These capabilities include simple interactions withobjects such as dragging an object through the visualization,transmitting information between models, and dynamically in-serting objects. Finally, it is possible to circumvent explicit rout-ing by directly accessing node input and output events within ascript method.

Prototype Nodes. PROTO declarations enable the definition ofnew node types that can be used in much the same way as thestandard VRML nodes. The prototype can be defined either inthe same file or in a separate file declared using anEXTERNPROTO declaration. PROTO nodes provide the in-valuable benefits of model reuse and hiding of implementationdetails.

The VRML Execution Engine. A VRML world can be viewedschematically as a scene graph where nodes describe functionalunits and routes define information flow between nodes. The

Table 1. A Description of some of VRML’s basic types

Field Type DescriptionSFBool BooleanSFInt32 32 bit signed integerMFInt32 Array of SFInt32SFFloat 32 bit floating point number (IEEE 754)MFFloat Array of SFFloatSFVec3f point in 3D space represented as three SFFloat valuesMFVec3f Array of SFVec3fSFColor RGB color represented as three SFFloat values in range [0,1]MFColor Array of SFColorSFRotation rotation in 3D space represented as four SFFloat valuesMFRotation Array of SFRotationSFNode VRML node or reference to a nodeMFNode Array of SFNode

March TRANSACTIONS 2001


VRML execution engine is an integral part of VRML browserplug-in that “executes” the scene graph [29]. Consistent withthe existing routes, the execution engine receives events fromthe scene graph and then delivers the events to the respectivedestinations, assigning a time-stamp along the way. Events thatcascade from an initiating event during the same time delta re-ceive the same time-stamp.

3. The Application ArchitectureIn this paper, we present an architecture for representing largeVRML applications that support dynamic reconfigurable extent.The architecture consists primarily of several generic functionalmodules coupled with an application specific GUI and objects.

A high level overview of the resulting software architecture isshown in Figure 3. The software architecture is a decentralizedcollection of seven interconnected, concurrently operating mod-ules. These modules are (1) the GUI, (2) the resource manager,(3) the arbiter, (4) the fixed landscape (not shown in the figure),(5) the collision manager, (6) a simple simulation manager, and(7) the object models. Object models are self-contained and en-capsulate all object capabilities. The significant events that drivethe flow of information processing are presented in Table 8.The first six modules are discussed in this section. Because ofspecial requirements and capabilities, objects models are dis-cussed separately in Section 4.

Figure 2. Example Call to createVrmlFromURL Browser Method

Signal Purpose Sourcecommand user request menuobjectType send information about selected object,

usually occurs after mouse click onobject

object

request object request for menu control object, resource managergrant grants object menu control main arbiter

Table 2. Major Events

. . .DEF S Script {

eventIn SFBool set_create #some precipitating eventeventIn MFNode set_node #event that receives new nodeeventOut MFNode addChildren #route this to desired group nodefield SFNode S USE S #node that receives new nodefield MFString urls [] #used to help package browser calldirectOutput TRUE. . .url "javascript:

. . .function set_node(val,ts) {

// val contains the newly created node.// Node fields are initialized, routes are added, and// the node is inserted into a grouping nodeaddChildren=val;

}function set_create(val) {

urls=new MFString(’foo.wrl’);Browser.createVrmlFromURL(urls,S,’set_node’);

}. . .

"}. . .

L.A. Belfore


3.1. The GUI

The GUI enables the user to control the major operational modesand make specific input selections. The GUI consists of the menuand the work zone. The menu is a hierarchy of interconnectedgeometries as illustrated in Figure 4. The output produced bythe menu hierarchy is the command event that initiates objectaddition and controls object manipulation. Elsewhere in the ar-chitecture, the command event is monitored by the resourcemanager and existing objects. The menu hierarchy receives theobjectType input event, sent by an object selected by a mouseclick, and results in the relevant menu appearing. Furthermore,the menu hierarchy is enabled or disabled as required duringnew object processing. Edges in Figure 4 represent the flow ofevents between menus. Individual menus are constructed froma collection of button nodes with an accompanying script nodeto encode button events into command events. The button nodeis defined as a PROTO node having the expected behavior. Forexample, the button changes color during the mouse-down in-terval to simulate the appearance of a depressed button. Also,the button function can be disabled and the button itself can behidden. A typical menu is shown in Figure 5. The work zonedefines the working area for adding and modifying objects inthe session. In addition, the work zone provides a visual cue tothe user during object insertion and detects the appropriate num-ber of mouse click events to define the initial geometry of anobject. Figure 6 shows the work zone in both active and inac-tive states. The work zone prototype is designed so that the workzone is specified parametrically.

3.2. Resource Manager

The resource manager is the key module in making architecturesupport worlds with dynamic reconfigurable extent. The resourcemanager manages the sequencing necessary to dynamically al-locate and insert objects into the world. Upon receipt of an addcommand event from the menu, the resource manager creates anew object using the createVrmlFromURL browser method. ThecreateVrmlFromURL browser method enables an applicationto allocate new VRML content, defined by a URL, and thendynamically insert the new content into a declared location inthe scene graph. Figure 2 gives an example call as deployed in

this application. The createVrmlFromURL browser methodshould not be confused with the addChildren events associatedwith grouping nodes. addChildren events require that the VRMLcontent is already allocated within the application, whereas thecreateVrmlFromURL browser method allocates entirely new andeven dynamic content from anywhere on the Internet. Immedi-ately after allocation, the new object is assigned a unique serialnumber and is initialized. Once the object signals thatinitializations are complete, the resource manager connectsroutes between the object and the relevant managers using theaddRoute browser method, fully inserting the object into thescene graph. The resource manager has tables to define the ini-tial properties of objects and to track objects that have beenadded to or deleted from the current session.

3.3. The Arbiter

The arbiter controls access to a common resource, in this appli-cation, the menu, among a collection of objects. An object isselected by a user mouse click on any visible geometry on thatobject. The arbitration scheme employs centralized and decen-tralized processes characterized by two events—request andgrant. Each is an SFInt32 data type that is used to communicatethe serial number of objects involved in the arbitration process.The arbitration process has a centralized arbiter that receives allselection request events from objects and then identifies the ob-ject to be selected through the grant event. During quiescenttimes, the arbiter retains the serial number of the selected objectand simultaneously monitors the request event that can comefrom unselected objects. Each object has a local arbiter modulethat submits requests for selection and then receives the resultsdetermined by the centralized arbiter. The local arbiter will ini-tiate selection and deselection processes for the object. After anobject has been selected, the object issues an objectType event.As described above, the objectType event is used by the menuhierarchy to identify and then display the appropriate menu forthe selected object. A schematic outlining arbiter operation ispresented in Figure 7.

Figure 3. Overview of the Visualization Software Architecture


3.4. Collision Manager

The collision manager monitors spatial extent of all objects andsignals when collisions occur between affected objects. Thecollision manager maintains a sorted list of bounding boxes forall relevant objects in the scene. In our application, only oneobject at a time moves or can have its geometry modified. Whenobjects move or dimensions change, a bounding box event issent to the collision manager. The collision manager compares

the new bounding box to those of all other objects being moni-tored. When a collision is detected, a collision event is transmit-ted to the moving object. In this application, the response issimply to freeze the ability to move or otherwise modify theobject. In more sophisticated simulations, the object behaviorcan use more complex bounding volumes and collision re-sponses. While only simple collision detection is supported, thecollision manager can be extended to support more sophisti-

Figure 4. Menu Hierarchy


Figure 6. Work Zone

(b) Prompting Input(a) Normal

Figure 5. An Example Menu


cated collision response scenarios such as keeping a car on aroad, restricting an object within a set boundary, or enforcingsetbacks.1

3.5. Simulation Manager

A simple simulation manager is included that broadcasts simu-lation data to objects. As a demonstration, the simulation man-ager has been programmed to generate an oscillating wind andthe pine tree model responds by swaying in the wind. The simu-lation manager sends periodic updates to all objects, so each

can respond in its own particular fashion. More advanced capa-bilities envisioned include modeling the mutual interactionamong different objects in the application. For example, the plugand socket interaction model described in [30] is one mecha-nism that can be used to enable objects to exchange informa-tion.

3.6 The Fixed Landscape

The fixed landscape is the solid model for the work zone. Thisincludes information converted from city GIS data, the outlyingarea, example landscaping, roadways, buildings and any othermodels that are anticipated to be permanent and unmovable. Inaddition, contents restored from prior sessions are inserted intothe fixed landscape.

4. Object ArchitectureThe object architecture is designed to serve several purposes.First and foremost, the object architecture is designed to sup-port independence and autonomy of object behaviors in the vi-sualization, placing few restrictions on object behavior. Second,the objects manage their own user interactions and interface tothe visualization. As a result, the visualization architecture issimplified since it is not required to directly handle user-objectinteractions. Third, the object defines a uniform interface be-tween the object and the architecture.

In order to achieve these purposes, the object architecture isstructured into layers that isolate the functions that interface theobject to the visualization, from those that change the objectgeometry, and also from those that define the object behavior.This organization permits modular design of the architectureand provides a framework for adding new capabilities in a regularfashion. Paralleling this structure, the object architecture is or-ganized into three layers—the interaction layer, the edit layer,and the model layer, as shown in Figure 8. The interaction layermanages the interface to the visualization and any user interac-tions that affect the object as a unit, such as object drag androtation. The edit layer defines the nature and appearance of

Figure 7. Arbitration

Figure 8. Object Architecture

1 VRML has a limited collision detection capability, but only betweenthe avatar associated with the active viewpoint and objects that areencountered during certain navigation modes.


controls and provides an interface between the model and theinteraction layer. Finally, in the model layer, the appearance ofthe object is defined as is any ability for the object to changeappearance or shape. The layer structure provides additional ben-efits including the support of reuse of layer methods and sim-pler definition of new objects. Indeed, the interaction layer issufficiently well defined that it is automatically generated formost objects implemented. The objects could have been definedas flat, i.e., without breaking the architecture into layers. In suchan architecture, defining a uniform interface would be more dif-ficult because the details of the interface, editing controls, andmodel behavior may become tangled. Furthermore, the flattenedarchitecture can make it to difficult expand the variety of newobjects.

4.1. The Interaction Layer

The interaction layer encapsulates methods for managing ob-jects, the visualization interface, and the server interface. Theinteraction layer is independent of the behavior and appearanceof the object providing methods that support initialization, ob-ject selection, drag and drop, arbitration, object identity, colli-sion response, and the web server interface. In addition, the in-teraction layer serves as an information conduit from thevisualization to the edit and model layers for initialization andsimulation events. Figure 8 gives a schematic representation ofthe interaction layer. The layer functionality and the interface tothe visualization are discussed in more detail.

4.1.1. Functionality

The interaction layer functionality consists of a collection ofmethods and processes that the user can use to control the ob-ject through mouse input, serve as the interface to the visualiza-tion, and isolate the edit and model layers from the visualiza-tion infrastructure. The functions are partitioned intoinitialization, user requests, object identity, object highlight,object specific views, the monitor, static instantiations, and col-lision response.

Initialization. Objects are created dynamically and initializa-tion occurs in concert with the resource manager that allocatesthe object using the createVrmlFromURL method. The com-plexity arises from the circumstance that no seminal event sig-nals when the object is fully loaded and all data structures arestable. Before the object is loaded, any events sent to the objectmay not be received.2 Since the object includes at least threenested levels of EXTERNPROTO instantiations (for each ofthe object layers), the object signals initialization complete onlyafter all nested nodes report completion of initialization. In ad-dition, using TimeSensor nodes, a delay, whose length is com-mensurate with the model complexity, is inserted to provide amargin against other nondeterministic effects.

User Interactions. Drag and drop functionality is provided bythe coordination of TouchSensor and PlanSensor functionality

associated with each object. Upon detecting a mouse click onthe object, a request is transmitted to the main arbiter for recog-nition and to request control of the necessary resources. At timeswhen it is undesirable to activate an object, such as during theinitialization sequence of another object, the ability to recog-nize a mouse click is disabled. When the main arbiter recog-nizes an object, its interaction layer sends an objectType eventto the menu that responds by displaying the appropriate menu.A PlaneSensor tracks the mouse position and is used to dragand drop the object to another position. The PlaneSensor alonecan provide the drag and drop behavior, but coordinatingPlaneSensor with a TouchSensor provides a way to select anobject for drag and drop. In object rotation, the orientation changeis computed using the vector formed by the mouse position inthe drag plane relative to the initial mouse down point.

Object Identity. Objects are uniquely identified by a serial num-ber assigned when the object is created. When an object is se-lected, the serial number is sent to the visualization’s main arbi-ter. Furthermore, an object can be activated when its serialnumber is broadcast on the grant event. The object with thematching serial number is activated while the rest are deacti-vated. In addition, the serial number appears in all communica-tions with the server.

Object Highlight. Highlighting an object provides a visual cueto the user of the selected object. Two approaches are used tohighlight an object. The first method is to surround the objectwith a wire frame demarking the bounding volume. For example,wire frames are used to highlight a selected tree or street light.The second method requires the object to provide a suitable vi-sual cue. For a roadway object, the cue is the appearance ofediting controls.

Object Specific Views. Objects have particular views that arecustomarily desired to evaluate placement and configuration.The object specific views, including animated view points, areassociated with the interaction layer and are added to the browserviewpoint list when the object is selected.

Monitor. The monitor is the object’s interface to the web serverand consists of loadURL browser method calls to a servlet orcommon gateway interface (CGI) script that performs the pro-cessing necessary to log session information on the server. Theinteraction layer has direct access to the object serial numberand any changes of position and orientation.

Model updates are passed from the edit layer and are thencommunicated to the server in the interaction layer. The infor-mation passed to the server includes the serial number, the kindof manipulation, and specific parameters of the manipulation.For example, an object translation might be logged as

ser. no. : type : mode : x : y

12 : 42 : (translation) : 1000 : 200

2 Indeed, CosmoPlayer can malfunction when an event is sent prema-turely.


where the different fields are separated by colons. Extra whitespace has been added here to enhance readability. The transla-tion mode is an example and other modes have different forms.

Static Instantiation. Objects in the static landscape are staticallyinstantiated. In addition, restoring a previous session requiresthat the previously defined objects be instantiated into the sceneat start-up. Static instantiation is achieved by defining fieldsdesigned to capture all aspects of the object appearance and lo-cation to make the object appear exactly as in a prior session. Inthe roadway initialization method, the roadway is defined by anarray of points defining the course of the roadway, otherwisethe roadway object waits until the appropriate number of pointshave been input.

Collision Response. Collision detection and response is an ex-pected capability when working with solid models that can bemoved or modified. With each translation, rotation, or update ingeometry, the object sends a bounding volume event to the col-lision manager. The collision manager determines whether thecurrent geometry overlaps another and if so, sends relevantevents to the colliding objects. For the present application, col-lision detection simply freezes the object’s position and adjuststhe position in the event that processing latencies result in thecollision being detected too late. The freeze is implemented byfiltering the mouse position tracked by the plane sensor and uponcollision detection, blocking any subsequent position updates.More elaborate collision detection responses can be devised withthe response methods implemented in edit and model layers.

4.1.2. Object Layer Interface

The interface between the visualization and the object layer iscomplex and provides a broad range of capabilities. The at-tributes of major partitions of the interface are summarized inTable 3. Initialization attributes must support both static anddynamic instantiation. For example, in static instantiation, if an

Interface PurposeInitialization initialization sequencing for both static and dynamic

instantiationControl control of object through command events and

communication of status informationInteraction object interactions between the user and the object,

such as selection and drag and dropArbitration menu arbitration among all objectsServer interface enable server communication, mechanism for

passing object update information to serverCollision outputs bounding box when geometry changes,

defines object specific collision responsePipeline enables information to be passed between the

application and through all object layers andprovides a mechanism for defining simulationparameters globally

Table 3. Object Interface Attributes

initial position is given, the object is placed and made visible.For objects added during a session, the remaining fields controlthe sequencing necessary to initialize the object and to integrateit into the visualization. The user interacts with objects in a fash-ion consistent with the function and form of the object. Theobject level interactions supported in the object layer interfaceare selection through mouse clicks, and drag and drop. The ar-bitration process begins with a mouse click on an unselectedobject. As a result of the mouse click, a request is sent to themain arbiter with an orderly transfer of control synchronized bythe clock associated with the main arbiter. The local arbiter moni-tors the progress of the arbitration process and at the appropri-ate time, fully activates the selected object. Object control in-cludes receipt of commands from the menu and covers a widerange of capabilities. The set_command input receives com-mands generated by the resource manager or the menu and theassociated method provides the required response. The inter-face to the web server is implemented using the loadURLbrowser method. The URL is in reality a CGI-script or servletthat logs the parameters supplied with the URL. After any changein appearance or position, the object sends an event to the colli-sion manager updating the bounding volume. In response, thecollision manager determines if a collision has occurred andsends the collision overshoot. The pipeline interface enables in-formation to be transmitted globally to all objects and for anobject to pass information back to the visualization. Informa-tion is synchronized using a latching signal event to ensure thatall parameters are acted upon only after all information has beensupplied. The pipeline can be defined so that any desired infor-mation can be communicated.

4.2. Edit Layer

The edit layer requirements are uniform across all objects, al-though this does not necessarily need to be the case. As notedearlier, this facilitates integration of new models into the appli-cation. The edit layer instantiates the model layer and contains


drag controls for controlling the appearance of the model.Changes to the appearance of the objects are reflected in thepositions of the drag controls in the edit layer. The changes arecommunicated both to the child model layer and the parent in-teraction layer. The edit layer interface is shown in Figure 9.The fields are divided into four groups, representing initializa-tion fields, control fields, geometry change fields, and simula-tion fields. The initialization fields communicate with the inter-action layer when the object is created. The control fields signalthe edit layer when an object is selected, should report debug-ging information, or should reset its state. In the event the ob-ject changes its geometry, the specific changes to the geometryare communicated in sufficient detail to recreate the object andalso to update the bounding volume. Finally, the simulation pa-rameters can be monitored by the edit layer and can be passedto the model layer.

4.3 Model Layer

The model layer is the most deeply nested layer. In the applica-tion presented in this paper, the model layer represents the purebehavior of the model. Requested changes to the geometry aregenerated by the edit layer and then passed to the model layer.After the geometry of an object has been modified, a new bound-ing box is calculated. In addition, as a result of internally gener-ated dynamics or the effects of other external processes, themodel layer can change its appearance or state.

PROTO objectModel [# Initialization fieldseventIn SFVec3f set_positionfield MFVec3f points []eventOut SFBool new_changedeventOut SFBool created_changedeventOut SFInt32 workzonePoints_changedeventIn SFBool set_done # edit done# control fieldseventIn SFBool set_reseteventIn SFBool isActiveeventIn SFBool set_debugfield SFBool debug FALSE# events generated with change in object geometryeventOut MFVec3f points_changed #specific changeseventOut MFVec3f corners_changed #bounding volume# simulation parameters passed directly to modeleventIn SFBool set_latch # synchronizes simulation parameterseventIn MFInt32 set_intParamsfield MFInt32 intParams []eventIn MFFloat set_fltParamsfield MFFloat fltParams []eventIn MFVec2f set__2dParamsfield MFVec2f _2dParams []eventIn MFVec3f set__3dParamsfield MFVec3f _3dParams []

]

5. Example Objects and CapabilitiesIn this section, several objects having a variety of capabilitiesare described. Generically, the capabilities can be related to thecomposition and morphology of the object. For example, thepath for roadway objects is represented by a sequence of linearsegments termed a spine whose path is modified by changingthe underlying spine. Buildings are composite objects whosefinal form depends on the architectural definition and desiredarea. The capabilities are related to the appearance and func-tions of the objects. In each case, the object is an independentand autonomous entity, managing object relevant user interac-tion capabilities, modifications, and collision response.

5.1. Trees and Lights: Simple Geometries

The appearance of simple geometries such as trees and externallighting are defined by solid models. The simplicity of the ge-ometries does not reduce the overhead associated with manag-ing and updating these objects. The only aspect of these modelsthat varies is their location. Furthermore, each of these objectsachieves full collision detection capabilities between each otherand the building solid model.

5.2. Buildings and Parking Lots

The building model is a composite geometry consisting of aone or two story structure integrated with parking lots. General-ity in building appearance is achieved through two mechanisms,the first of which is defined in this subsection, and the second is

Figure 9. Edit Layer Interface


described in the following subsection. The building solid modelis defined using the createVrmlFromURL browser model, al-lowing any solid model to be inserted. In this manner, any build-ing size can be integrated with the same parking lot infrastruc-ture. The parking lot size is determined from city building codes,or if appropriate, through direct entry by the user. The parkinglot area is divided into two pieces that are sized and placed atthe sides of the building. The parking lot models dynamicallycreate the appropriate number of trees to satisfy canopy coverbuilding codes. Furthermore, the parking lot aspect ratio can beadjusted and all trees can be individually placed.

5.3. Buildings: One Model, General Appearance

In the visualization, one or two story buildings may appear withone of eight entrance options, selected through the menu. Thebuilding solid model is defined parametrically by a footprintand a height. To simplify the application, the building footprintand height are hard coded, but do not need to be in principle.The solid model for each story of the building is the three di-mensional shape formed by sweeping the footprint through theheight of the building. As a result, only the area and number ofstories for the building are selected by the user. The buildingmodel scales the inherent foot print to give the appropriate area.If a second story is requested, it is simply a second instantiationof the first floor, translated vertically. In order to render a typi-cal pattern of windows on each floor, two textures have beendefined and are shown in Figure 10. The window tile describesa fixed width texture for a single window. The number of win-dows per side of building is calculated and then is used to de-fine the appropriate texture tiling. Since the building dimen-sions do not typically require an integral number of window

tiles, a variable width corner tile is defined to fill out the build-ing side. Building sides are represented using threeIndexedFaceSet geometries. The three geometries specify threefaces composed of a center face where an integral number ofwindow tiles are placed, and two edges that use the corner tile.The tiles are translated and scaled to fit the building side and togive a natural appearance. The following equation defines thenumber of window tiles that must be placed on a side of thebuilding

P =LS ,

where P is the number of window tiles, L is the length of theside of the building, and S is the natural width of the windowtile. Next the edges of the corner tiles must be filled in. Thelength of each corner tile is

F =L ±SP2

where F is the size of each corner tile. These parameters areused to calculate the vertices of an indexed face set for the build-ing for all four sides. The faces for one side are illustrated inFigure 11. Finally, the origin of the texture must be translated togive symmetric placement of the windows. The translation ofthe coordinate system for the window tilings is

T = -(L - SP),

where T is the desired translation. The translation is negativebecause the VRML TextureTransform node translates the ori-gin rather than the texture itself.

Figure 10. Building Textures

(1)

(2)

(3)

Figure 10a. Window Tile Figure 10b. Corner Tile


In addition to defining one and two story buildings, a build-ing entrance can also be defined. The visualization allows forthree building types, requiring only two structure geometries.An office structure is defined as a rectangular box. Finally, manu-facturing and warehouse structures have a loading dock area atthe rear of the building.

5.4. Roadways and Landscaping Borders

The Extrusion node is used to define the appearance of road-ways and landscaping borders. The appearances of each differin the extrusion cross section and surface texture. The path ofthe extrusion is defined by a spine that defines the course of theobject. Editing controls rather than a wire frame appear for se-lected roadway or landscaping border objects. The controls arelocated in a manner consistent with the geometry type. For ex-ample, the spines for a straight road, berm, and hedge are de-fined by the two end points. The spine of the ring road geom-etry is defined by the center point and one point on the perimeter.Internally, sufficient points are sampled along the circle circum-ference to give the appearance of a smooth curve. The spine ofa curved road is the arc from the circle intersecting the threepoints input by the user. The appearance of each of these ob-jects is calculated and modified as the controls associated witheach are dragged.

6. Example SessionAn example session is presented here, beginning with the open-ing scene of the visualization, and finishing with several viewsof the scene. The opening of the visualization shown in Figure12 is a view from about 2,000 feet (about 600 meters) above thework zone. In addition, the menu appears in the right part of theopening view. A site can be successively built up beginning withthe definition of the site boundary, addition of the building, place-ment of the roadways, arrangement of the landscaping, and place-ment of lighting. Once the site has been created, top and frontviews of the site are shown in Figure 13. Note the menu hasbeen moved to the upper left hand corner of the view port forscreen captures in this figure. Such a scene can be createdquickly, in about a half of an hour. A client based version of the

application can be found at http://www.lions.odu.edu/˜lbelfore/urbanVisualization and currently only operates underCosmoPlayer.

7. DiscussionThe architecture that is presented in this paper provides manyfunctional capabilities. In this section, we discuss some advan-tages and disadvantages of the proposed architecture from dif-ferent perspectives. First, the efforts necessary to develop vir-tual worlds are discussed. Second, the technological aspects ofemploying VRML technology are reviewed. Third, the specificissues relevant to the proposed architecture are discussed.

No formal study was conducted to measure the effort re-quired to create applications for different sites, but some anec-dotal information is provided. The general goal during develop-ment was to construct an architecture that could be easily adaptedto different situations and sites. In support of this, the differentmodules described in Section 3 have been constructed so thatcustom information is defined either in parameters duringinstantiation (work zone), in tables associated with each (re-source manager), or without change at all (arbiters). Construc-tion of new menu hierarchies requires some additional work,but each object menu is defined parametrically using a genericmenu model. The structure and protocols for communicationsbetween different layers in the menu are defined so that auto-mating the construction of the menu hierarchy should be straight-forward. Depending on the detail required for background mod-els, a more significant effort may be necessary in their creation.Furthermore, different applications may require a different col-lection of objects. For simple objects with features similar tothe objects described in object-examples, new objects can bequickly developed and integrated. For example, using the modelfor roadways, complementary railway models were created aswell as the accompanying menus. The time needed to accom-plish this addition required about four hours of developmenttime including menu modifications. On a larger scale, a demon-stration application was created to visualize a hazardous wastecleanup site requiring a total effort of about 200 hours. It shouldbe noted that the majority of this effort was devoted to addingcapabilities beyond what are described here and that approxi-mately 40 hours was devoted to issues directly related to adapt-ing the visualization architecture.

Strictly from a technological perspective, VRML offers threeimportant benefits. First, in addition to the capability of repre-senting virtual worlds, VRML is an internationally standard-ized language. Tools that generate VRML content in conform-ance with the standard are expected to produce content that canbe reviewed on browsers that are also compliant. Second, inprinciple, developers are not restricted to one vendor’s softwarefor either development or rendering. Third, VRML is designedto be delivered over the Internet. Anyone with a browser any-where on the Internet need only download and install a plug-into browse VRML content. On the negative side, complex vir-tual worlds can require significant download times. In addition,because the configuration of the client machines can vary, therealism of the experience can be directly affected.

Figure 11. Panel Placement. Calculated Parameters Indicated


Figure 12. Opening View

Figure 13. View Scene Created

(a) Top View (b) Front View

The proposed architecture offers solutions that compensatefor some of the technological challenges. First, objects can beallocated and added dynamically at the request of the user. Thisimportant capability reduces download times because at startuponly the initial configuration of the world is required. In addi-tion, the dependence on the client machine configuration is re-duced since start-up resources are minimized and additional re-sources are necessary. Indeed, the world does not have to bereloaded in response to additions or modifications to the world.Second, the architecture is designed to be modular, enablingreplacement of any user visible components without modifica-

tion of the underlying architecture. For example, the comple-ment of objects can be changed and new work zone configura-tions can be specified. Among the disadvantages in developingthe architecture include the added complexity necessary to allo-cate and insert content dynamically. An additional disadvan-tage is that the CosmoPlayer [16] plug-in, used to render ourapplication, is neither currently in development nor is new de-velopment expected in the future. Similar to ours, some appli-cation areas still depend on CosmoPlayer 31, but clearly thisdependence cannot continue indefinitely. We have begun ex-ploring porting this work to other VRML plug-ins.


8. Summary and Future WorkIn this paper, we have presented an architecture for creatinglarge virtual worlds. The architecture features dynamicreconfigurable extent where nodes are allocated and insertedinto the world at run time. The application architecture includesmodules comprising the infrastructure of the application thatmanages the application and interactions with the user. Includedin the infrastructure are resource, collision, and simulation man-agers that suggest a wide range of behaviors are possible. Fur-thermore, the object architectures have been designed to sup-port modularity and object independence. The objectarchitectures are organized into three layers that separate theobject interface to the application, from editing controls, andalso from the behavior. In addition, we have demonstrated asignificant application that applies the architecture described inthis paper.

We intend to pursue two avenues of future work. First, weplan to study the types of simulations that can be performed onthe architecture we have presented. In particular, we would liketo experiment more with model dynamics and the collective in-teraction of objects within a visualization. Second, we wouldlike to provide stronger links between the application and a webserver. The web server can provide many valuable capabilitiesincluding access to data bases and generation of models dy-namically.

9. AcknowledgmentsWe would like to acknowledge the City of Portsmouth, Virginiafor funding this work. In addition, we would like to acknowl-edge the Virginia Modeling, Analysis and Simulation Center(VMASC) for providing facilities and other support necessaryto complete this project.

10. References[1] The Web3D Consortium, Incorporated, “The Web3D consortium,”

http://www.web3d.org.

[2] L. H. Coglianese, “Towards a visual integration architecturebaseline,” in Proceedings of the 1998 Virtual Worlds and Simu-lation Conference (VWSIM’98), (San Diego, CA), pp 58–63,January 1998.

[3] M. Salmela and T. Tuikka, “Smart virtual prototypes for web-baseddevelopment environments,” in Proceedings of the 1999 Inter-national Conference on Web-Based Modeling & Simulation,(San Francisco, CA), pp 127–133, January 1999.

[4] R. Pichumani, D. Walker, L. Heinrichs, C. Karadi, W. A. Lorie, andP. Dev, “The design of frog island: A VRML world for biol-ogy,” in Proceedings of the 1998 Virtual Worlds and Simula-tion Conference (VWSIM’98), (San Diego, CA), pp 31–36,January 1998.

[5] P. Dev, D. Engberg, R. Mather, D. Hodge, and M. Dutta, “The col-laborative curriculum web for medicine: A virtual representa-tion of medical school resources,” in Proceedings of the 1998Virtual Worlds and Simulation Conference (VWSIM’98), (SanDiego, CA), pp 29–30, January 1998.

[6] D. P. McKay, P. Matuszek, D. Mateszek, T. Smith, and S. Testani,“An architecture for a training virtual world environment,” in

Proceedings of the 1998 Virtual Worlds and Simulation Con-ference (VWSIM’98), (San Diego, CA), pp 125–130, January1998.

[7] S. Testani, J. Tumasz, and S. Gnanamgari, “CIMBLE: Experientialtraining in a VRML environment,” in Proceedings of the 1998Virtual Worlds and Simulation Conference (VWSIM’98), (SanDiego, CA), pp. 67–71, January 1998.

[8] S. Testani, E. Wagner, and K. Wehden, “CIMBLE: The CADETTinteractive multi-user business learning environment,” in Pro-ceedings of the 1999 Virtual Worlds and Simulation Confer-ence (VWSIM’99), (San Francisco, CA), January 1999.

[9] N. H. El-Khalili and K. W. Brodlie, “Architectural design issuesfor web-based virtual reality training systems,” in Proceedingsof the 1998 International Conference on Web-Based Modeling& Simulation, (San Diego, CA), pp 153–158, January 1998.

[10] B. Damer, K. Marcelo, and F. Revi, “Nerve garden: A virtual ter-rarium in cyberspace,” in Proceedings of the 1999 Virtual Worldsand Simulation Conference (VWSIM’99), (San Francisco, CA),pp 131–135, January 1999.

[11] J. R. Ensor and G. U. Carraro, “Peloton: A distributed simulationfor the world wide web,” in Proceedings of the 1998 Interna-tional Conference on Web-Based Modeling & Simulation, (SanDiego, CA), pp 159–164, January 1998.

[12] N. Jacobstein, W. Murray, M. Sams, and E. Sincoff, “A multi-agent associate system guide for a virtual collaboration cen-ter,” in Proceedings of the 1998 Virtual Worlds and SimulationConference (VWSIM’98), (San Diego, CA), pp 215–220, Janu-ary 1998.

[13] W. M. Darling and M. J. Welch, “Embodied agent for a virtuallibrary,” in Proceedings of the 1998 Virtual Worlds and Simu-lation Conference (VWSIM’98), (San Diego, CA), pp 225–230,January 1998.

[14] M. Reddy, Y. Leclerc, L. Iverson, and N. Bletter, “TerraVision II:Visualizing massive terrain databases in VRML,” IEEE Com-puter Graphics & Applications, vol. 19, pp 30–38, March/April1999.

[15] S. N. Matsuba and B. Roehl, ““bottom, thou art translated”: Themaking of a VRML dream,” IEEE Computer Graphics & Ap-plications, vol. 19, pp 45–41, March/April 1999.

[16] CosmoSoftware, Incorporated, “CosmoSoftware home page,”http://cosmosoftware.com, 1998.

[17] L. S. Indrusiak and R. A. da Luz Reis, “3D integrated circuit lay-out visualization using VRML,” in Proceedings of the 1999International Conference on Web-Based Modeling & Simula-tion, (San Francisco, CA), pp 177–181, January 1999.

[18] J. J. Wynn, J. D. Roberts, and M. O. Kinkead, “Visualizing thewargame—web-based applications for viewing a course of ac-tion (COA),” in Proceedings of the 1999 International Confer-ence on Web-Based Modeling & Simulation, (San Francisco,CA), pp 227–232, January 1999.

[19] A. G. Bruzzone and G. Berrino, “Modelling of urban services byVRML & Java,” in Proceedings of the 1999 International Con-ference on Web-Based Modeling & Simulation, (San Francisco,CA), pp 34–38, January 1999.

[20] P. Fishwick, “A hybrid visualization environment for models andobjects,” in 1999 Winter Simulation Conference Proceedings,(Phoenix, Arizona), pp 1417–1424, December 1999.

[21] L. A. Belfore II and R. Vennam, “VRML for urban visualization,”in 1999 Winter Simulation Conference Proceedings, (Phoenix,Arizona), pp 1454–1459, December 1999.


[22] M. Reddy, L. Iverson, and Y. G. Leclerc, “Under the hood ofGeoVRML 1.0,” in Proceedings of the Fifth Symposium onthe Virtual Reality Modeling Language VRML2000, (Monterey,CA), pp 23–38, February 2000.

[23] H. Holten-Lund, M. Hvidtfeldt, J. Madsen, and S. Pedersen,“VRML visualization in a surgery planning and diagnostics ap-plication,” in Proceedings of the Fifth Symposium on the Vir-tual Reality Modeling Language VRML2000, (Monterey, CA),pp 111–118, February 2000.

[24] The Web3D Consortium, Incorporated, “External authoring inter-face working group,” http://www.web3d.org/WorkingGroups/vrml-eai, 1999.

[25] A. G. Bruzzone, E. Manetti, and P. Perletto, “Object-oriented docu-mentation from simulation for civil protection & industrial plantaccidents shared directly on the web,” in Proceedings of the1998 International Conference on Web-Based Modeling &Simulation, (San Diego, CA), pp 168–173, January 1998.

[26] A. G. Bruzzone and R. Signorile, “Crowd control simulation inJava based environment,” in Proceedings of the 1999 Interna-tional Conference on Web-Based Modeling & Simulation, (SanFrancisco, CA), pp 23–28, January 1999.

Lee A. Belfore II received the BS degree in electrical engineering fromVirginia Tech in 1982, the MSE degree in electrical engineering andcomputer science from Princeton University in 1983, and the PhD de-gree in electrical engineering from the University of Virginia in 1990.From 1982 to 1985, he was a member of technical staff at AT&T Infor-mation Systems. From 1987 to 1988, he was a research scientist in theDepartment of Electrical Engineering, Center for Semicustom Inte-grated Systems at the University of Virginia. From 1990 to 1997, hewas with the Department of Electrical and Computer Engineering atMarquette University, Milwaukee, Wisconsin. Since 1997, he has beenwith the Department of Electrical and Computer Engineering at OldDominion University, Norfolk, Virginia. His research interests includeneural networks, data compression, and Internet-based virtual realityapplications.

[27] L. A. Belfore II and S. Chitithoti, “An interactive land use VRMLapplication (ILUVA) with servlet assist,” in 2000 Winter Simu-lation Conference Proceedings, (Orlando, Florida), pp 1823–1830, December 2000.

[28] D. R. Nadeau, “Tutorial: Building virtual worlds with VRML,”IEEE Computer Graphics & Applications, vol. 19, pp 18–29,March/April 1999.

[29] The Web3D Consortium, Incorporated, “The virtual reality mod-eling language,” http://www.web3d.org/Specifications/VRML97/index.html, 1998.

[30] Y. Araki, “An interactive model for avatar-habilis, avatars withcapabilities to use tools in 3D-MUVES,” in Proceedings of the1999 Virtual Worlds and Simulation Conference (VWSIM’99),(San Francisco, CA), pp 3–8, January 1999.

[31] The Web3D Consortium, Incorporated, “The distributed interac-tive simulation DIS-Java-VRML working group,” http://www.web3d.org/WorkingGroups/vrtp/dis-java vrml, 2000.

An Architecture for Constructing Large VRML Worldsbelfore/publications/SCSproof.pdf · an...

Documents

Transcript of An Architecture for Constructing Large VRML Worldsbelfore/publications/SCSproof.pdf · an...