Papers in PDF format

Figure 2: Interfae components to external applications
Interface nodes provide a simple but very powerful mechanism to establish connections between the VRML world and
external applications. These applications might be located on the local host or even on arbitrary external servers. The
communication is realized by a common event interface. Events sent to interface node are forwarded to the application
or server by the VRML browser [Fig. 2]. Events sent to the browser by an application or server are sent to the Interface
node. The communication between the browser and the external application is done by an TCP/IP interface of the
browser. This interface is powerful enough for almost all kinds of applications. For external applications which have to
communicate with a large number of hosts, a multicast connection (see second part of the paper) should rather be
established. Locating an application on a central server which might be accessed from different VRML worlds allows to
create high-level services. The Interface node allows behaviors defined within the scene graph to access such services.
The Interface node may be used for input, output or bidirectional I/O. The external service associated with the interface
node, destinations of incoming events and the name of the external service can be specified by appropriate fields. The
name of the server might be any valid host name or IP address and may include a specification of the port (e.g.
baghira.universe.com:1234 or 134.62.47.11), providing the specified service.
A simple example for the usage of this mechanism is a 3D mail watcher connected to an external daemon by an
Interface node. The daemon watches the user's mailbox and sends appropriate events to the interface. This will than raise
the flag of the user's 3D mailbox within the virtual world.
Distributed Behavior
Our VRML behavior approach as well as any other proposal based on a user-extendable event mechanism, seems to be
very suitable to support distributed virtual worlds. To do this, events influencing the state of a virtual world entity have
to be transmitted over a network connecting the current participants of world. Our proposal [Broll et al. 96] uses Engine
nodes to realize time dependent behaviors such as animations. The Moving Worlds proposal [Mitra et al. 95] uses
TimeSensors instead. However, behaviors depending rather on the elapsed time than on user input allow more
sophisticated ways to reduce the required network traffic [Roehl 95].
Some behaviors are even completely independent on each virtual world, e.g. a waterfall, a blinking light, tree
movements by the wind, etc. These behavior do not need to be synchronized.
Other behavior have a defined starting and ending time, defined in real world time. No synchronization is needed for
this kind of behavior either.
Further more most animations even if not completely independent are well defined. Thus their description can already
be transmitted as part of the virtual world distribution. However, they may be invoked or stopped under certain
conditions or parameters may be modified. This usually requires a single resynchronization. Since the transmission
between the different sites requires a certain time (latency), such updates require a time stamp to guarantee the desired
effects. Time stamps additionally require synchronized clocks, which can be realized using one of the well established
mechanisms such as NTP (Network Time Protocol).
Our approach provides special engines nodes to allow the author of a virtual world to determine the required
synchronization level. By an additional resynchronization field it is possible to determine, under which conditions a
resynchronization is performed. Resynchronization may be deactivated, performed on activation or deactivation of the
engine, or realized when any field value of the engine is changed. In the latter case, modifications are only distributed
immediately if the engine is currently active, otherwise redistribution is postponed until the engine is reactivated.
Multi-User Interactions
In current proposals for VRML 2.0, interactions are executed by the local browser only, since multiple users or shared
virtual worlds are not supported. However, within shared environments, inconsistencies may occur, when several users
at different sites interact with the same virtual world entity. For that reason our approach adds shared trigger components
to the VRML specification. These components either prevent several users to execute a certain behavior at the same time
or detect and resolve concurrent access. Interactions might then be synchronized e.g. by combining them. Shared trigger
components synchronize events, which would actually trigger a certain behavior. Synchronization is achieved by
forwarding the events to the replicated copies of the trigger components. This allows one either to lock certain
interactions already accessed by a another user, or to combine the input events of several users. We realize this kind of