Papers in PDF format

2.3 Geometric and visual ‘continuity’ across Rooms
A completely new approach is the concept of visual continuity across (adjacent) rooms. If the user selects a WWW
anchor, MRTSpace starts a child process that retrieves the description of the new location. When the child returns
and the WWW link led to a HTML page the viewer starts an external browser. But if the web link led to another
VRML scene MRTSpace tries to find a door between the new and the old scene. A door is an object that has
web anchors leading from one scene to another and vice versa. If a door is found MRTSpace tries to match both
scenes by matching the doors of each file. In the trivial case the 3D representations of both doors are identical, so
the match can be done in an exact way. If the shapes of the doors differ, the bounding volumes are used instead
and some heuristics try to figure out the direction of the doors. In both cases the current and the new scene are
merged, the door object becomes penetrable and the user can walk from one scene to the other without any visual
interruption. This greatly enhances the perception of the overall VR environment as a place to wander around.
Comfort of navigation can further be improved by two additional features: load ahead and keep rooms. Load
ahead means that MRTSpace tries to load all WWW anchors that lead to a URL matching something like *.wrl,
searches for doors, and adds these rooms to the current scene whenever possible. So if the user enters a room with
several doors, these doors will ‘open’ as soon as the representation of their web anchors have been loaded. The
Keep Rooms option controls when to discard the geometric description of rooms. In the simplest case this is done
immediately after the user leaves, but if the resources of the machine that runs the browser aren’t too limited is
very convenient to keep at least the last room visible.
3 Adding Multi User Support
Recent proposals on behavior all try to bring VRML worlds closer to the notion of cyberspace as a means of
communication [Bro95, BE95]. Most proposals, however, follow the route of defining a new server architecture to
take care of the exchange and interaction aspects involved in multi-user virtual reality. Others like [MZP 95] are
based on the multicast backbone approach MBone [MB94].
In contrast, our approach builds on existing server technologies merging IRC as a medium to communicate and
VRML as a interface to a virtual reality. IRC was originally developed to allow people all over the world to chat
with each other. It has been used to develop a network of servers which form the backbone of a very effective and
fault tolerant multi user medium. Using the HTTP client/server protocol for sharing the static data of a room where
people can meet and using the IRC protocol to exchange information between these users avoids several start up
problems that arise when introducing new specialized servers.
3.1 A new Node for VRML
For our solution we need a simple extension to the VRML standard of the following form:
SharedRoom {
width 2 # SFFloat
height 2 # SFFloat
depth 2 # SFFloat
name "" # SFString
}
The first three fields describe a bounding volume. The VRML browser will check each time the user moves (and
on start up), whether the user enters one of these bounding volumes. In this case the VRML browser opens a
connection to the next IRC server and uses the IRC command JOIN to open a channel with the name given in the
fourth field. This name must be unique for this shared room. One obvious way to build such a name is to choose
the URL of this VRML script and append some extension to identify SharedRoom within the script. The channel
with this name is then shared among people all over the world who have loaded this particular script and entered
this particular room. If the channel did not already exist the IRC server will create it automatically.