Adding Multi-User Support to VRML - Semantic Scholar

To appear in the Proceedings of the VRML’95 Symposium (San Diego, Dec. 13-15, 1995), ACM SIGGRAPH, 1995

Bringing Worlds Together: Adding Multi-User Support to VRML Wolfgang Broll, David England GMD — German National Research Center for Information Technology Institute for Applied Information Technology

ABSTRACT In a cooperative, virtual organisation teams of users can be formed at will. They can share and interact with abstract artifacts and communicate with each other through these artifacts. In such a world users can be aware of each others activities, interact with shared objects and have their own 3D representation (or embodiment). The goal of this paper is to show how multiple users can be supported using an architecture based on VRML and HTTP. We describe how VRML can be extended and supported with extended clients and servers to provide mechanisms for awareness, embodiment, consistency and access control. CR Descriptors: C.2.4 [Computer Communication Networks]: Distributed Systems - Distributed applications; I.3.1 [Computer Graphics]: Graphics Systems - Distributed/network graphics; I.3.6 [Computer Graphics]: Methodology and Techniques; [Computer Graphics]: Three-Dimensional Graphics and Realism - Virtual Reality; J.4 [Social and Behavioral Sciences] Sociology.

1

INTRODUCTION

The key distinction between CSCW (Computer Support for Cooperative Work) systems and applications aimed at individual computer users is that CSCW systems allow users to coordinate their activities around a group of tasks. The form of coordination maybe very loose; users might use social protocols, or it might be coordinated according to some model as in Workflow systems. Social protocols are currently the most popular way of supporting user coordination, as they allow users to develop methods of cooperation and coordination that can be tailored to their specific tasks. The goal of our work at GMD is to show how Virtual Reality and VRML can be used to enhance CSCW applications. In this paper we will show how VRML/HTTP based architecture can be used as a basis for this aim by supporting multiple users. In the rest of this GMD—German National Research Center for Information Technology, Institute for Applied Information Technology, D-53754 S a n k t A u g u s t i n , G e r m a n y, e m a i l : { Wo l f g a n g . B r o l l , David.England}@gmd.de Permission to copy without fee all or part of this material is granted provided that the copis are not made or distributed for direct commecial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to publish, requires a fee and/or specific permission

VRML95-12/95 San Diego, California, USA Copyright 1995 ACM

introduction we want to establish the cooperative context in which a multiple user architecture would be used. What are the artifacts that we might wish to model in VRML to support cooperating users? Many CSCW systems attempt to provide analogues of the features of real-world organizations. However to adequately support social and organizational protocols we need to provide some underlying mechanisms with which users can establish their own cooperation environment. We need to provide mechanisms which support important concepts such as:

•Awareness [2, 13] •Access Control [8] •Group membership •Version Control Most existing work on multi-user Virtual Reality has concentrated on visualizing the first two items. In Virtual Reality awareness is more graphic: users are present as visual objects or embodiments, we can actually see who is around, what they are doing and which artifacts they are working on (see figure 1). The Spatial Model [1] takes this further and allows users to control what they see and how they are seen. Users can set a focus on vision and sound and they can also set an aura which defines when they become visible (or audible) to others. In conventional systems access control is usually displayed by either showing that objects or commands are available or not. Commonly unavailable commands are grayed out. The idea of boundaries in VR [8] takes the idea of graying-out further by representing the access state of objects by different graphical properties. So, for example, a completely inaccessible object may be hidden behind a wall, an object that is visible but not accessible may be shown behind a window and when we want a user to be aware of the existence of an object but not its details we may hide it behind frosted glass. The Boundaries idea mixes access control and awareness. This demonstrates one of the benefits of VR for CSCW - we can combine (with careful design) many properties and mechanisms in the visualization of one object and thus give more information to users. VRML provides an additional medium for visualizing awareness and access control.Visualizations can of course be provided in 2 dimensions but they produce greater clutter of limited display space. The third dimension and the dimension of time provide the means for simultaneously viewing more attributes. For example, suppose we have a virtual library where the users are embodied and the query from shared bibliographic searches are visualized (e.g. QPIT [3]). In such a scenario we can spread the results of the query into, for example, a pyramid. We can see users moving about this pyramid and watch them as they choose individual artifacts

To appear in the Proceedings of the VRML’95 Symposium (San Diego, Dec. 13-15, 1995), ACM SIGGRAPH, 1995

returned by the query. Different users, librarian and readers, may have different styles of embodiment. Readers may find that some artifacts are not accessible to them and their visualization represents the state of their accessibility, e.g. by boundary objects. Another user might make a further refining query which changes the population of the data landscape. Other users may come in and out of the system and become visible to their co-workers.

ments. For example the DIS protocol has been used to support distributed applications with more than 300 participants. However this requires the use of a dedicated network. In further enhancements to NPSNET [15] (based on DIS) it is shown how multicasting can be used to reduce network and computing requirements, and in this paper we shall also use multicasting to support multiuser VRML. NPSNET is limited to military simulations and this limitation is most evident in its restriction to the use of dead-reckoning for propagate changes. For the wider spectrum of VR applications we need to move towards distributing behaviors and we describe one approach to this in a further paper [7].

However before we can provide VRML models that visualize awareness and access features we first need to examine the existing model of distribution. In the current vision of the World Wide Web information is only shared in that multiple users are able to simultaneously view pages put up by many providers.The users are just browsers of the information provided and interaction is limited to following links or completing forms. The control of information remains largely with the information provider. The traditional client-server model of distribution supports this type of information exchange well. However, for truly cooperative work, such as that researched at GMD, we need to support awareness and access control as described above. Some Web products, such as Virtual Places for Windows from Ubique, provide a crude notion of awareness but this is not adequate for our needs. In addition there are requirements for the consistency of views on a virtual world which cannot be met by the current WWW architecture. In this paper we want to examine how VRML could be extended to support cooperative, multi-user worlds on the Internet. We wish to stress cooperative in addition to multi-user worlds. Many systems are multi-user but they are not cooperative, that is, users cannot coordinate their activities through the system. We also wish to examine how cooperation can be supported without radically altering VRML. As an emerging standard radical changes are unacceptable. Ideally we should be able to provide a smooth transition from the existing, isolated-client model to a communicating-clients model, and in the following sections we describe different development paths for achieving this.

Figure 1. Multi-user virtual world

What are the functional requirements for a VRML/HTTP-basis for our Virtual Library world? Firstly we need to be able to create a VRML scene graph of the above query result. This can be done using current WWW technology [5]. Individual users could then view the scene graph. However as VRML objects (currently) have no behavior they could not interact with the objects (unless they were links). The addition of behaviors to VRML would support interaction with the artifacts and the representation of access to artifacts which could be given different behaviors when chosen by different users. As users joined the system we could create a VRML scene graph of their embodiment and add that to the query scene graph. However this updated scene graph would only be visible to the user currently joining and to later users. For existing users to be made aware of the new user would require the server (or other clients in a peer-to peer approach) to notify the connected clients. This is not part of the WWW architecture. However work at GMD by the BSCW project (Basic Support for Cooperative Work) shows how this might be done by modifying servers and clients so that server-to-client notification is possible. Now as users move about the virtual world other users would need to be made aware of their changes in position. Again we would need some form of server-to-client notification of these changes.

In following sections of this paper we will look in more detail at approaches to distributing changes to user representations and how interactions on artifacts may be shared among several virtual worlds. The focus here is on the topology and protocol of communications between server and clients. Finally we will look at some proposals for further extension to VRML in terms of object naming which is base requirement for distributed behavior and multiuser interactions.

2

MULTI-USER REPRESENTATION

In this section we will show two approaches to supporting several users using VRML on the base of slight extensions to the existing HTTP protocol and servers. 2.1 Simple Extensions Our first approach requires only minimal changes to VRML clients/browsers, such as WebSpace or WorldView and slight extension to the HTTPD server. Most of the server extensions might even be realized by CGI scripts. All clients communicate directly with the server. Each user can define his or her own representation within a local VRML file (e.g. myBody.wrl). The browser will use this file or even several files for different user representations (see figure 2). A user might be presented by a human model within an office environment, but using a space ship representation when browsing a

The problem of the distribution of artifacts in virtual worlds can be tackled at two levels. Firstly there are problem of multi-user access to documents and how changes to shared documents might be managed. Secondly there is the question of how the visualization of objects in a shared, space might be kept consistent. Some existing work has looked at the problems of distributed virtual environ-2-

To appear in the Proceedings of the VRML’95 Symposium (San Diego, Dec. 13-15, 1995), ACM SIGGRAPH, 1995

different types of user representations. Thus, either VRML is extended to allow the identification of a sub-tree of the scene graph as a user object (see section 4), or the server distinguishes between the different clients: It will include the user embodiments as parts of the scene graph by default (this can be realized within a simple CGI script), or send them separately on request to multi-user capable clients.

solar system world. However, multi-user capable browsers should also provide at least one default user representations.

default body files

body file

Time Client

ext. client / browser

request data (virtual world) request and data (client user representation)

HTTPD server

Client body files

HTTPD server

data (user representations)

body files initial transfers and user updates

user representation updates Figure 2. Multi-user support using direct client/server connections

Client user representation updates (all clients)

The protocol extensions used to distribute user representations as well as to update their locations (or even other attributes) will be described below (see figure 3). The browser first sends a request for the world description to the server. The server returns the VRML file. This is the standard mechanism used to transmit VRML files by HTTP. If the browser supports user representations, it sends a request for the representations of the other users along with the location (position/direction) and —if available— local representation of the user. The multiuser capable server will return the current locations of other users in the same world, followed by their individual representation. User representations for a specific world might be provided by the author of the world. The server will send the data received from the browser to all other participants of the world. The local browser then adds the incoming user representations to the local scene graph. It sends any updates on the location of the local user to the server (using some kind of threshold or a dead-reckoning mechanism to reduce network load) and listens for updates on other user locations from the server. As soon as the local browser moves to another virtual world location (VRML file), it sends a quit message to the server. The server eliminates the user from the world and distributes this information among the participants. The server should also realize a time-out mechanism to eliminate users, which have not updated their position for a certain time. Additionally the server may limit the total number of displayed user embodiments or the number of users participating the world. Caching might be used to reduce the amount of transmitted data. Servers (or even browsers) may keep user representations for a certain time to reduce re-transmission, when the user returns to a previous page. Servers might also use the transmitted user representation, if the browser switches to another document on the same server. The approach allows arbitrary user representations of a theoretically unlimited number of users for each world. However, servers of popular sites will very quickly become a bottleneck, since they have to handle the communication of all participants of all provided multi-user worlds. It would be preferable, if the server could also add user representations to pages requested by clients not capable of multi-user support. Currently, the user description cannot be included within the virtual world description, since the naming mechanism used in VRML is not general enough to identify different users as well as

exit message Client user exit (all clients)

HTTPD server

HTTPD server

initialization

ext. client / browser

HTTPD server (extended)

updates

body files

ext. client / browser

exit

ext. client / browser

Figure 3. Extended protocol for multi-user support 2.2 Multicast Approach Our second approach is very different from the first one, since it moves many tasks from the server to decentralized components. Central servers as used in the first approach can very quickly become a bottleneck of a distributed system. Especially when adding further enhancements such as interactions within shared worlds, the central server approach is no longer suitable, since it is not scalable. Our second approach uses the multi-cast mechanism, which has already proven to be suitable for large scale interactive multi-user virtual environments, such as NPSNET [15, 18] and DIVE [9]. However, even this approach does not require really new or additional servers, it can be realized by extending existing HTTPD servers. This is different to other approaches, such as VSCP (Virtual Society Server Client Protocol) used by the Virtual Society project [14], which realize multi-user extensions by additional servers. The initial setup of the connections is the same as in the first approach: The browser contacts the server to receive the VRML page. Afterwards the client will introduce itself as a user to the server and the server will respond by sending the user embodiment files of the current users. Along with this, the client receives a multi-cast address and port number. The multi-cast address will usually refer to the server, while the port number will refer to the individual world. However, in large virtual worlds, or when separating groups of users by replicated worlds, different relations might be used. The browser now sends its current user description, including the location, to the mutlicast address. All participants, as well as the server, get the new user information from the multicast address. The browser now listens to the multicast address for updates of other user representations, for new users and for quit messages of existing users. A time-out mechanism can be provided by -3-

To appear in the Proceedings of the VRML’95 Symposium (San Diego, Dec. 13-15, 1995), ACM SIGGRAPH, 1995

Other users should realize, who is participating in the shared world and what the participants are doing. We referred to this earlier as awareness. One problem, well known from distributed databases as well as from existing distributed VR systems [4, 9, 10, 15], is the problem of providing consistency among the different sites. Another problem, specific to VRML is the implementation of user movement between different worlds. User should be able to move easily between different worlds. Portals [9] seem to be a more adequate metaphor for that purpose than simple links. This issue was discussed very controversially during the specification of VRML 1.x [1], but was not finally resolved. Moving objects or entities (currently parts of the scene graph) from one world to another is an important issue, which has to be addressed within this topic. We will now show our approach to handle sharing of objects and interactions, and allow users to exchange objects as well as their own representations between several worlds. The approach is an extension of the multicast approach.

the server as in the first approach. In this case, the server sends the quit message to the multicast address instead of the client.

ext. client / browser

HTTPD server (extended)

multicast address

ext. client / browser

ext. client / browser

3.1 Realizing Consistency of Virtual Worlds Before we present some possible solutions to keep distributed virtual worlds consistent and to manage access in distributed VRML based systems, we will try to answer the question, 'Why do we need access control at all?'. There are several examples of multiuser applications, —not only in the VR context, but rather in the CSCW context— which show, that access management can be solved on social than on technical mechanisms. Imagine a group of users standing in front of a virtual white board (see figure 1). only one user writes at the whiteboard at any time, while other users will wait until he or she has finished. Thus no access control is necessary, since consistency among the local views of the world is achieved by a social protocol. If you extend this to a large virtual world (or even a MUD), this world will be completely anarchistic but even it might still work.

initial transfers user updates Figure 4. Multi-user support using multicast groups This approach reduces server communication dramatically, since the update messages are sent by clients. Thus they are reduced to necessary updates only. Additionally, sending the messages directly via the multicast address, increases the average update time significantly, since the messages need not be re-distributed by the server (see figure 4). 2.3 Conclusions Compared to the average network load based on browsing through VRML pages, or even HTML pages, the number of messages in a multi-user virtual world will be significantly higher. Instead of loading a new page every few minutes, updates will be necessary at least every few seconds. Using traditional client/server connections, already a small number of participants in a multi-user virtual world, would it make impossible for the server to realize realistic (almost real-time) updates of user representations. Multicast has been proven to be suitable for this task. In contrast to symmetrical (none-server based systems without any central components) distributed multi-user VR systems, our second approach still includes a central server. But this server is used rather to provide a uniform address to 'dial in' the world (to get the multi-cast address) and to provide all participants with the same set of virtual world contents. These services cannot be provided by frequently changing (connecting, disconnecting) hosts. Within specialized systems, such as NPSNET, such problems do not occur, since they are limited to a certain kind of application. Within its limited world (military simulation), all entities are well defined, so each participating site can use a fixed database to set up the world. But this approach is not to be suitable for general purpose virtual environments, especially when sites participate at worlds for a rather short period.

3

Time

client #1

client #2

Figure 5. Consistency problems in distributed copies However, we can find other situations where social protocols will not be sufficient to guarantee the required level of consistency. We will demonstrate this by another example: Imagine a user who wants to drive a virtual car. While one user enters the car and drives into one directions, another user within another local copy of the same world might drive the car into another direction. When the position changes are distributed among all sites, they might arrive at the individual client at arbitrary orders. Thus, different clients will have different views of the same world. Even the car of one of the driving users may suddenly be relocated (see figure 5). This will not only distort the user’s view but also will make the results even of simple interactions unpredictable. So it is sometimes very important to guarantee consistency by restricting access to certain objects. This is in particular very important for user representations or avatars, to use a more popular term, but also for many

SHARING AND DISTRIBUTED INTERACTIONS

Real distributed, multi-user, virtual environments require not only to share a static world and dynamic user representations, but also sharing of interactions. So users should be able to change the virtual world or parts of it and have these modifications distributed among all current and future participants of the specific world. -4-

To appear in the Proceedings of the VRML’95 Symposium (San Diego, Dec. 13-15, 1995), ACM SIGGRAPH, 1995

However, this scheme may lead to rejections of locking requests. Thus an appropriate message can be sent to the client to reset its lock. Additionally the client might send a request to the server to restore the object. The server will also distribute the current lock status to all new clients, joining the world. Again the server will be responsible to release a lock after a certain time-out and to achieve consistency.

basic interactions. We will present some possible solutions and review their advantages and disadvantages for a VRML/HTTP based virtual environment. No Access Management If no access management is provided, each client is allowed to change the scene graph independently. All modifications are posted to the multicast address and distributed among the other clients and the server. This method is very fast since no additional information other than the modifications of the scene graph itself has to be distributed. For that reason, it might be used for the modification of worlds, where reliability of modifications and consistency among the worlds is not a major requirement. Consistency cannot be guaranteed, since concurrent access is not detected. Additionally, modifications of the virtual world may arrive at the individual client sites in different orders1 as shown in the example above. In large worlds with several interacting users this may lead to different local copies at each client site.

Active Locking with Acknowledge Active locking with acknowledgment requires only small extensions to the previous method. The main difference is, that the server always sends an acknowledge message of the lock to the client (see figure 7). This is an improvement over sending an acknowledge message to every client. The latter would either cause an unnecessary heavy load on the multicast address or require that each client is able to communicate with all other clients directly (peer-to-peer).

ext. client / browser

Active Locking Without Acknowledge Active locking without acknowledge requires at least three times as many messages as without any access management (see figure 6). Object modifications or a block of them have to be preceded by a locking message on the specific objects. After the distribution of the modifications, a release message has to be distributed. Locks are not acknowledged by the individual clients nor by the server. But the server will manage multiple locks on the same object. Different kinds of locks might be used to support various kinds of reliability requirements. Locks should not be understood to guarantee absolute access to an object—this kind of locks has failed in most cooperative environments. We see locks rather as a guarantee of achievable consistency, based on a prediction of the client’s future activities [11]. This mechanism provides a kind of soft locks, which may be broken for the price of a certain loss of consistency.

HTTPD server (extended)

multicast address

ext. client / browser

ext. client / browser

modifying client

locking message modifications release message acknowledge message

ext. client / browser

HTTPD server (extended)

multicast address

ext. client / browser locking message

Figure 7. Active locking with acknowledge This would then require the distribution of all client addresses and heavily increase the load on the locking client. Additionally the locking phase would be extended to an unacceptable length and clients not capable of locking, or with slow network connections, would slow down the whole process.

ext. client / browser

Decentralized Access Management The mechanisms shown above are based on a central access management provided by the server. In a large scale virtual environment, including a large number of participants, the server will again become a bottleneck. System performance will decrease, even when using the multicast distribution mechanism, since access control is performed entirely on the server. Decentralized mechanisms to manage access control include migration and master entities [6]. Migration does not seem to be very useful in the VRML context, since the graphical representation of all virtual world contents has be locally available and VRML does not provide any additional object representation besides this. Nevertheless, migration has proven to be suitable even for distributed VR, e.g. in the AVIARY system [16]. It might be a solution, as soon as object identification and naming is solved within VRML in

modifying client

modifications release message Figure 6. Active locking without acknowledge 1. This may change when the reliable order-conserving multicast protocol RMP [17] will be available. -5-

To appear in the Proceedings of the VRML’95 Symposium (San Diego, Dec. 13-15, 1995), ACM SIGGRAPH, 1995

an appropriate way, and objects may hold more information than just a graphical representation. Master entities provide a mechanism for flexible access in a distributed system. Access control for each part of the virtual world (objects, artifacts or just subtrees of the scene graph) is located at potentially different sites. The object copy at the managing site is called master entity This site is also called the owner of the object. When changes to certain objects are closely related to their owners, this method provides a very fast mechanism, even in distributed systems. If access has to be provided for different sites (clients), but is concentrated at each time to one of them, master entities (object ownerships) can be migrated. In a central server system, pure master entity mechanisms are not appropriate. As there might not be any clients at all, the server has to be the owner of all master entities, at least at start up time. Clients can request ownerships from the server. The server keeps track of the current owner and gets the master entity back by migration, disconnection of the client or after a time-out. So far there is almost no difference to the locking schemes described before. But master entities might also be transferred directly from one client to another. This can be done using the multicast connection, since all clients and the server always have to know the current owner of the object. When supporting multiple locks for each object, migration cannot be used as a general mechanism to provide access for other sites than the current owner. For that reason, the owner has to provide server functionality for access management. This can either be achieved by direct (peer-to-peer) connections between the two sites or via the multicast address. Both solutions raise some problems: direct connections require the distribution of all participants’ addressees and may cause a heavy load on some participating sites (especially when they own several master entities). Using the multicast address will increase the load of all participants, even those, for which the access for this particular object is not of any interest. The main problem when using this kind of decentralized access management is to find an appropriate algorithms to decide, under which conditions master entities (rights) are relocated to achieve a good performance.

should be possible to manage access on a soft lock mechanism if required. 3.2 Moving Objects and Users Through Multiple Worlds Another important issue to the realization of multiple users and interactions is the question ‘How can users and objects move between several worlds?’. Currently VRML uses hyperlinks realized by WWWAnchor nodes to switch to other virtual worlds. With some late extensions of the specification 1.0 it is possible to specify the destination location in the new world, if it is another VRML page. The term portal was used to specify a special kind of link, potentially bidirectional, and also capable of connecting points within the same world. However, a portal can be realized by a pair of hyperlinks, specifying the world and the position in the appropriate counterpart. It has to be part of the client realization to provide mechanisms to avoid unnecessary reloading of pages. Since portals and links connect different worlds, or parts of them, they are closely related to the movement of user representations and objects between such worlds. In our approach, user embodiments are provided by the client and sent to the server for each page separately. However, as mentioned above, user movements between several worlds on the same server should be cached to reduce network transfers. Moving objects can be realized by the same mechanism. The object, or even several objects, become parts of the user representation. They are distributed along with it, but have to be identified as independent objects. The user needs to be able to drop objects in a world, so they can be manipulated or modified by other users. However, picking, grabbing and dropping objects will require further extensions to VRML to realize interaction and behavior. This is not part of this paper, although we realize this in our prototype. Additionally some extensions are necessary, to specify whether objects can be removed or just copied and if it is possible to add objects to a world. Authors of virtual worlds might also want to specify objects, or parts of their worlds, so they can neither be removed nor copied. But since all transferred VRML data is accessible, restrictions could only be applied to the unexpected copying or removing of objects. This would not allow an author to restrict access to his virtual world data (although this might be useful for some commercial use of VRML in the future).

Conclusions Beyond the access mechanisms show above, there exist several more [12], which could be applied to support multi-user virtual worlds, but which did not seem to be suitable to us for smooth VRML/ HTTP extensions. We will now try to review the different approaches to get an idea of the final approach, which may be used for future multi-user VRML worlds. On the one hand, many virtual worlds will not need any kind of access control, since consistency is not a major problem if users use social protocols. This allows the server to stay almost passive after the initialization phase and for that reason reduces server and network load. On the other hand, at least for some objects of the world (including avatars) or for certain kinds of interactions (grabbing, moving) consistency is important. Thus it should be possible to specify consistency either on an object (subgraph) level or on an interaction level. This will require extensions to the VRML specification, or will have to be included in the interaction and behavior specification respectively. As long as we distinguish between servers and clients, i.e. a more or less centralized system, decentralized access mechanisms do not seem to be advantageous, since all virtual world contents are originally located at the server. However, this may change, if all users will have a basic common library of objects on their local system. Thus a participating site (server/client) would only have to supply some special objects. For the central server architecture a rather simple approach should be used. We think access should not be restricted by default, but it

4

FURTHER EXTENSIONS

In this section we will present some extensions to the VRML specification necessary to realize multi-user support as well as to our approaches presented in the previous sections. The VRML extensions can simplify the management of users and artifacts and enforce the possibilities to distribute multi-user world descriptions to standard (not multi-user capable) browsers. User and Artifact Naming and Identification As already mentioned above, users or user representations and objects or artifacts should be identified within a scene graph to support the described functionality. Currently there are two methods of doing this within the VRML specification: 1. Info nodes 2. the DEF keyword Although Info nodes are already widely used by browsers, such as WebSpace, to set up browser parameters, they should not be used to identify structures of the scene graph (otherwise we could repre-6-

To appear in the Proceedings of the VRML’95 Symposium (San Diego, Dec. 13-15, 1995), ACM SIGGRAPH, 1995

group decisions, which are rather based on social factors than on engineering considerations. We will demonstrate this in a short example: In a MUD-like virtual world, people would like to create their own home (building), etc. Nevertheless, some ‘official’ buildings would be necessary, e.g. for meetings, shopping, etc. A decision has to be made, where to locate these buildings (objects) and whether other buildings have to be relocated (this is very similar to the real world, except that buildings can be moved easily). On the one hand, a single user should not be able to change common areas, or to place his or her own ‘home’ there. On the other hand, nobody wants to hold elections for such things (neither the users, who want to make modifications immediately (and interactively), nor the page (world) administrator, who does not want to evaluate hundreds of change requests for such a world. A simple but powerful solution for such problems, is to support multi-user interactions. In this example, a number of users, e.g., five or ten, would have to grab the object and move it to the new location. However, even when the conditions to relocate the object are satisfied, there remains a high number of possible ways to realize the movement. Since the different movement of the individual users have to be combined, this approach has to include the resolution of concurrent interactions [6]. Multi-user interaction support can be added easily to our approaches for access control. Multi-user interaction will be performed on objects or subtrees of the scene graph of the virtual world. The server will have to handle the multiple interaction requests and post the resulting interaction to the multicast address (see figure 8). This might be done using the proposed soft lock mechanism. The mechanism can also be used within decentralized systems. In our model, resolution of multi-user interactions is only a special case of achieving consistency in a distributed system.

sent almost every node as an Info node). They should be used to include safe comments on nodes into the scene graph. The DEF keyword, currently used to name nodes, could be used to identify a single user: DEF User Separator {...} But with multiple users (as in the server) the naming convention has to be extended (e.g. User1, User2, etc.) and when providing several user representations for the same user, names can become unreadable (User1Car, User2b, etc.); especially as there is no way of identifying a user, or set a user type, which can be used by the server to select the appropriate user representation for the current scene. In a cooperative world, users will need to get more information on the individual user or its organisation. Since we support individual user representations, WWWAnchor nodes might be used as parts of the user embodiment to point to the user’s personal home page, or his or her organisation. The DEF keyword could also be used to identify parts of the scene graph as objects or artifacts which might be modified. As a general mechanism to support user representations as well as objects (artifacts) in VRML, we would prefer a more general naming convention. Although we do not want to propose a new syntax or give examples of syntax here, we wish to represent a user embodiment by a new node. This node should contain a user’s name, his or her identification, e.g. user@host or the email-address of the user and an entry to specify the type of representation. This type could either specify the type of environment for the specific user representation (e.g., OFFICE, SPACE, GAME, etc.) or the type of object the user is representing (HUMAN, CAR, SPACESHIP, BEATLE). The node should be inherited from Separator nodes. So it may have several sub-nodes to realize the geometry, as well as sound, behavior, etc. For rendering as well as for sizing issues, a method for specifying bounding boxes might be included. Objects the user is carrying and which have not become (identifiable) parts of his representation, i.e. they are not visible and have no location, might also be included in a separate component of a user node. It would also be preferable to include camera settings and navigation specification (currently part of the browser configuration) within a user representation. This seems to be very useful in combination with the specification of different user representations (types), since the requirements for viewing and navigating will change according to this type.

ext. client / browser

server (multi-user interaction capable)

To specify and identify artifacts a similar approach can be used. However we can think of other more general naming conventions to support objects or aggregate objects in VRML. One important issue is availability of type information, which would allow to bind interaction and object behavior to artifacts, dependent of their object type. For that reason a new general naming convention for VRML should allow to specify objects by several criteria, e.g. •names •classes (including super classes) •types •groups This scheme should not only support simple but also qualified names, e.g. to specify all shape nodes of an object ‘wind mill’.

participating client

multicast address

ext. client / browser passive client

ext. client / browser

participating client

locking message (joining multi-user interaction) access (potentially concurrent) release message (leaving multi-user interaction) consistency updates Figure 8. Multi-user interactions

Multi-User Interactions—Group Decisions When interacting with a high number of users in a shared work space, i.e. a distributed virtual world, concurrent access by user interaction is very common. Existing systems reduce the problem either by realizing access control so that multi-user interactions cannot be performed, or they do not guarantee consistency. Thus multi-user interactions are sequencialised, rejected or may lead to arbitrary results. However, this might not be a suitable solution for all kinds of interaction. Especially when realizing support for

5

SUMMARY AND CONCLUSIONS

The key requirements for working together in shared virtual worlds are awareness and consistency control. Without these coworkers have great difficulties coordinating their activities. They need to be aware of the presence and actions of others. They need -7-

To appear in the Proceedings of the VRML’95 Symposium (San Diego, Dec. 13-15, 1995), ACM SIGGRAPH, 1995

11. Dourish, P. Consistency Gurantees: Exploiting Application Semantics for Consitency Management in a Collaboration Toolkit. Rank Xerox Technical Report EPC-1995-106, Cambridge, 1995. 12. Ellis, C. A., S. J. Gibbs, and G. L. Rein, Groupware - Some Issues and Experiences. Communications of the ACM, Vol. 34, No. 1, (January 1991), pp. 38–58. 13. Fuchs, Ludwin, Uta Pankoke-Babatz, and Wolfgang Prinz, Supporting Cooperative Awareness with Local Event Mechanisms, to appear in Proceedings of the Conference on Computer Supported Cooperative Work 1995 (ECSCW‘95), (Sep. 1995, Stockholm, Sweden). 14. Honda, Yasuaki, Kouichi Matsuda, Jun Rekimoto, and Rodger Lea, Virtual Society: Extending the WWW to support a Multi-user Interactive Shared 3D Environment. In Proceedings of the VRML’95 Symposium, (San Diego, Ca., Dec. 13-15, 1995) ACM, 1995. 15. Macedonia, M.R., Michael J. Zyda, David R. Pratt, et al. (1995). Exploiting Reality with Multicast Groups: A Network Architecture for Large-Scale Virtual Environments. In Proceedings of the Virtual Reality Annual International Symposium. VRAIS ‘95. IEEE Computer Society Press, Los Alamitos, CA, (March 1995), pp. 2-10. 16. Snowdon, Dave. N., Adrian J. West,, and Toby L. J. Howard, Towards the Next Generation of Human Computer Interface. Informatique’93: Interface to Real & Virtual Worlds, (March 1993), pp. 399-408. 17. Whetten, Brean, Todd Montgomery, Simon Kaplan, “A High Performance Totally Ordered Multicast Protocol”. [www] http://research.ivv.nasa.gov/projects/RMP/RMP.html 18. Zyda, Michael J., David R. Pratt, J. S. Falby, C. Lombardo, and K.M. Kelleher, The Software Required for the Computer Generation of Virtual Environments, Presence 2, 2 (1994).

to be aware of the state of shared artifacts and interactions on those artifacts. Authors (who are also co-workers) need to be able to restrict access according to the demands of the shared tasks. This will allow users to participate in an shared virtual world at the required consistency level. We can use VR models within the VRML/HTTP framework to support these requirements. In this paper we have outlined how users can be made aware of each other through multi-user VRML representations. A multicasting approach allows servers and clients to show VRML representations of users attached to a shared virtual world. We have also shown various methods by which interactions, causing up-dates to shared artifacts, may be distributed. Then we have seen how objects and user might migrate through multiple worlds. To support the foregoing we need better naming conventions for VRML artifacts. Finally our approach can also handle multi-user interaction but we can take a step further by providing peer-to-peer communication.

ACKNOWLEDGEMENTS We wish to thank Dik Bentley for his valuable comments and remarks during the development of this paper.

REFERENCES 1.

Bell, Gavin, Anthony Parisi, and Mark Pesce, “The Virtual Reality Modeling Languange, Version 1.0 Specification”. [www] http://vrml/wired.com/vrml.tech/ 2. Benford, Steve D., and Lennart E. Fahlén. A Spatial Model of Interaction in Large Virtual Environments. Proceedings of the Third European Conference on CSCW (ECSCW’93), Kluwer, Milano, Italy, 1993. 3. Benford, Steve, and John Mariani, “Virtual Environments for Data Sharing and Visualisation—Populated Information Terrains”. Research report CSCW/5/1994, Lancaster University (1994). Also in [www] http://www.comp.lancs.ac.uk/computing/research/cseg/projects/qpit/ 4. Blau, B., C. E. Hughes, J. M. Moshell, and C. Lisle, Networked virtual environments. In Computer Graphics (1992 Symposium on Interactive 3D Graphics), Zeltzer, D. (Ed), 25, 2 (1992), pp. 157-160. 5. Bremers-Lee, T., R. Fielding, H. Nielsen, “Hypertext Transfer Protocol HTTP 1.0”, HTTP Working Group. [www] http://www.w3.org/hypertext/WWW/Protocols/Overview.html 6. Broll, Wolfgang, Interacting in Distributed Collaborative Virtual Environments. Proceedings of the IEEE VRAIS’95 Conference, IEEE Computer Society Press, Las Alamitos, Ca. (March 1995), pp. 148-155. 7. Broll, Wolfgang, “Interaction and Behavior Support for Multi-User Virtual Environments”. Proceedings of the ACM SIVE 95, First Workshop on Simulation and Interaction in Virtual Environments (Iowa City, Iowa, July 13-15, 1995), 256-263. 8. Bulock, Adrian and Benford, Steve, An Approach to Access Control for Spatial Systems, Esprit COMIC Document 4.2, October 1994. 9. Carlsson, Chister and Olof Hagsand, DIVE–A Platform for Multi-User Virtual Environments. Computer & Graphics, Vol.17, No. 6 (1993), pp. 663–669. See also [www] http:// www.sics.se/dce/dive/dive.html 10. Codella, Christopher .F., Reza Jalili, Lawrence Koved, J. Bryan Lewis, D. T. Ling, J. S.Lipscomb, D. A. Rabenhorst, C. P. Wang, A. Norton, P. Sweeney, and G. Turk, Interactive simulation in a multi-person virtual world. Human Factors in Computing Systems CHI‘92 Conference Proceedings, ACM, (May 1992), pp. 329-334. -8-