A multiuser 3D Web browsing system

.

FEATURE

A MULTIUSER 3D WEB BROWSING SYSTEM SharedWeb integrates multiuser VR technology into a 3D browsing system by extending the ANSI/IEEE Distributed Interactive Simulation, or DIS, standard to existing Web servers.

J IUNG -YAO H UANG , C HAO -T SOU FANG -T SOU , AND J IA -L IN C HANG Tamkang University

T

he Virtual Reality Modeling Language sets an open-standard file format for designing 3D multimedia and shared virtual worlds on the Internet. VRML was originally designed to support the interaction of multiple participants in the World Wide Web environment—that is, to network virtual worlds via hyperlinks. However, even version 2.0 of the standard, published in August 1998, did not fulfill this design goal. The development of VRML has nevertheless spurred broad research on distributed multiuser VR systems. Such systems generally provide mechanisms for the multiuser server to “remember” the information of registered participants and to process the messages communicated among them (see the sidebar, “Related Work,” on pp. 72-73). To take advantage of the Web environment, however, a distributed multiuser VR system must be seamlessly integrated with the Web architecture so that users can download virtual scene files from any supporting Web server and navigate transparently to other virtual worlds through other Web servers. Such integration would include full access to the services provided by the Web environment. In this article, we describe SharedWeb, a 3D Web browsing system that was designed and implemented to support interaction among clients in the existing Web environment.1 We begin by describing the methodologies and mechanisms used to achieve seamless integration with the Web environment, then we summarize the SharedWeb system implementation. We present some experimental results that show the effects of different frame rates and threshold values on system performance, and conclude with discussions of two virtual worlds currently supported by the system.

MULTIUSER INTERACTIVITY OVER THE WEB The Hypertext Transfer Protocol designed for the Web environment forces the server to use a request-and-response technique with its clients: The link between the server and client is established only when a client issues a request to the server. Further, the link is broken and immediately “forgotten” by the server after the requested information is sent.2 Thus, the Web environment poses intrinsic problems to the support of multiuser interaction. First, a

70

SEPTEMBER • OCTOBER 1998

http://computer.org/internet/

1089 -7801/ 9 8 /$10.00 ©1998 IEEE

IEEE INTERNET COMPUTING

.

3

server must establish a method to record its client information. Second, a server-to-client callback mechanism is required. In addition, the network load must be minimized, and the process of entering a virtual world must be fully integrated into the existing Web environment. Client-Information Records The Web server generally does not keep the records of the clients that request information from it. This information is required for multiuser interaction; our system achieves this by having each browser calculate a sequence number, called a unique identification (UID), to uniquely identify itself to the server. SharedWeb combines the login name, time stamp, and port number (called LTP, for short) as the UID to distinguish each client from others.1 With this UID, the SharedWeb server can easily identify a new registered player and assign a User ID to that browser. Moreover, the SharedWeb server records the UID for future reference. Server-to-Client Callback Mechanism The HTTP link between a server and client is established only when a specific request is raised by a client. The Web server cannot establish a connection to its clients automatically. If a client intends to send information to other clients in the same virtual world, the server does not have the ability to forward the information. To solve this problem, the server has to “remember” the browsers registered to a virtual scene. In addition, each browser must give the server information such as IP address and port number, so that the server can automatically send information to the registered browser. The SharedWeb browser uses the client-information recording method to send this information to the SharedWeb server after a user has logged in. When the SharedWeb server receives the registration information from a browser, it saves the registration message and sends the IP address and port number information to the registered browser. Hence, during the course of multiuser interaction, each registered browser sends its status change to the SharedWeb server. The SharedWeb server then forwards the received message to the appropriate participants. Network Load Because HTTP establishes links only when a request is issued, it adds a linking delay on top of intrinsic network latency. A Web-based multiuser VR system does not necessarily require a multiuser

IEEE INTERNET COMPUTING

D

W

E

B

B

R

O

W

S

I

N

G

S

Y

S

T

E

M

server to maintain the spatial consistency of a virtual world, but it does require a central server to mediate communication among the clients.3 Thus, network bandwidth will overload very quickly as the number of players increases, and the server will rapidly become an input/output bottleneck as well. SharedWeb adopted the Distributed Interactive Simulation standard to maintain spatial coherency (see the sidebar, “Distributed Interactive Simulation Standard” on p. 73). DIS is a fully distributed simulation method, and SharedWeb, like DIS, gives each browser the entire virtual world. An entity’s change in status is encapsulated in a self-contained data package, called a protocol data unit (PDU), and forwarded to each participating browser through the multiuser server. DIS reduces bandwidth requirements by using a dead-reckoning algorithm to reduce the frequency with which a change in status must be transmitted. As guided by this algorithm, a change in entity status is sent to the multiuser server only when the change exceeds a predefined threshold. Virtual World Entrance In the request-and-response method of HTTP, the Web server is not aware of the client that downloaded a scene file. Consequently, the Web server cannot automatically forward the multiuser server information to that client.One simple solution to this problem is to embed the information into the downloaded scene file, but this causes trouble when a multiuser server crashes and a replacement server is activated. Another possibility is to let the client query the Web server for multiuser server information, but this method forces the client to wait to connect until it receives the reply. For a networked VR system to integrate seamlessly with the Web environment, the Web server must treat the multiuser server as an add-on application. The Web architecture allows the server to communicate with add-on applications through a CGI program. SharedWeb uses this method to forward the login information from the Web server to the multiuser server. Thus, the client does not care if the multiuser server and the Web server reside in the same host. In addition, a hierarchy structure of the multiuser servers can be implemented so that the Web server can pass client login information to a loadmonitor program, which will can then forward the client transparently to another multiuser server. This allows load-balancing and fault-tolerance features to be implemented for the multiuser server.

http://computer.org/internet/ SEPTEMBER • OCTOBER 1998

71

.

F

E

A

T

U

R

E

RELATED WORK

The World Wide Web is a client-server architecture with a communication protocol, HTTP, that is intrinsically a “one way street.” This makes it impossible to achieve multiuser interactivity in the Web environment using HTTP. The VRML standard attempts to deliver virtual worlds on the Web. Its original goals included support for the interaction of multiple participants, but even version 2.0, which was released in August 1996, failed to define a standard to meet it. Hence, different Web–based multiuser systems have developed proprietary methods to support multiuser interaction.

Research Projects The Virtual Society is a research project of Sony Computer Science Laboratory that attempts to define a global architecture and protocol set to realize multiuser 3D Web interaction based on the VRML standard.1 The VS project was originally based on the DIVE platform from the Swedish Institute of Computer Science.2 The project designed the Community Place Browser, which—unlike the DIVE system—is a VRML-standard virtual reality system. To support large–scale shared 3D spaces using VRML, the VS project proposed the Virtual Society Server Client Protocol (VSCP), which extended the functionality of the existing VRML standard. In addition, the project designed a scripting architecture for different levels of consistency among the shared objects. However, the VS architecture is not seamlessly integrated with the Web environment. For example, the VS client cannot enter a virtual world from the Web server form that downloads the scene file. Instead, after a 3D scene file is successfully downloaded, the VS client must send a URL to the Web server to query the information on the VS server. The Web server then returns an HTML document to the browser associated with that VS client. The answering HTML document contains the address and port number of a VS server that will handle that

particular scene. The browser then forwards this information to the VS client. The German National Research Center for Information Technology (GMD) proposed another type of Web-based multiuser system by defining new nodes for the VRML standard.3 The GMD multiuser system does not require a multiuser server to maintain the consistency among distributed objects, as the VS project does. Instead, after a VRML browser has downloaded a VRML scene file from a Web server, the browser will introduce itself as a user to the server. The Web server responds to the user with embodiment files of all existing players, along with a multicast address and port number. The multicast address refers to the IP address of the Web server, and the port number denotes an existing virtual world. Hence, during the interaction, each participant sends its status change to the specified port on the Web server and listens to the update information of other users from another port representing a multicast channel. Since each individual client sends the update messages to the specified port and the Web server redistributes the messages through the multicast channel, an extended HTTPD server is designed to receive update information and monitor the status of the virtual world. If the HTTPD server does not receive an update message from a client for a designated period of time, a time-out mechanism on the HPPD server will issue a quit message to the multicast channel for that client. The Scalable Platform for Large Interactive Networked Environment (Spline) from Mitsubishi Electric Research Lab used a different approach to integrate the MVE with the Web.4 Spline is essentially a networked–based multiuser VR system that uses Interactive Sharing Transfer Protocol as its communication protocol.5 ISTP incorporates several simple HTTP protocols to enable the HTTP server to participate in the multiuser interaction. With the help of ISTP, the Spline system provides a Web-like virtual environment. However, it is not a Web-based multiuser system.

SHAREDWEB ARCHITECTURE Figure 1 on page 74 illustrates the SharedWeb architecture. It features two types of nodes. The browser site is composed of four modules: Multiple Participants Interface, 3D Render Engine, Chat Phase, and WWW Homepage Viewer. The server site is built on top of the existing Web server with two modules: a CGI program and the SharedWeb server. Communication between server and browser is through the SharedWeb Communication Protocol. Browser Site The Multiple Participant Interface module runs on top of Winsock to manipulate the interaction

72

SEPTEMBER • OCTOBER 1998

http://computer.org/internet/

between the browser and other players. This module is the kernel of a SharedWeb browser. Its main functions are to calculate the browser’s UID, encapsulate and de-capsulate the PDUs, transmit/receive data to/from the network, and coordinate messages among the other modules. The 3D Render Engine module provides a visual window for the user to explore the virtual world. When a browser retrieves a scene file from the Web server, it is an ASCII file. The scene file is then translated into a virtual world database recognized by the 3D Render Engine module. The Chat Phase module is designed to support text communication among distributed players.

IEEE INTERNET COMPUTING

.

3

D

W

E

B

B

R

O

W

S

I

N

G

S

Y

S

T

E

M

DISTRIBUTIVE INTERACTIVE SIMULATION Current Commercial Products Other commercially available Web-based multiuser systems include Blaxxun CCpro, Venue, Oz Virtual, and Pueblo. All of these browsers adapt the VRML standard as their virtual scene file format, and the multiuser systems use their own techniques to provide interactivity among distributed users. None of them is fully integrated with the traditional HTML browser. The Active Worlds browser from Worlds Inc. is another kind of multiuser browser that is not a VRML browser but instead merges the traditional ■ HTML browser into its own 3D VR browser.

Although VRML brought virtual worlds into the Web environment, the only standardized communication protocol for multiuser interaction over the Internet is the Distributive Interactive Simulation standard.1 The goal of the DIS standard is to link the activities of multiple participants in an operational exercise that forms a time- and space-coherent synthetic world. DIS creates this synthetic world through the low latency (100 to 300 milliseconds) exchange of data units between distributed, computationally autonomous simulation applications. The DIS standard deploys the virtual world scene on each participating host and defines two important techniques to support its goal: ■

REFERENCES 1. Y. Honda et al., “Virtual Society: Extending the WWW to Support a Multiuser Interactive Shared 3D Environment,” Proc. VRML’95, San Diego, Calif., Aug. 1995; available

online

at

http://www.csl.sony.co.jp/

person/rodger.html. 2. O. Hagsand, “Interactive Multiuser VEs in the DIVE System,”

IEEE Multimedia, Vol. 3, No. 1, Spring 1996, pp. 30–39. 3. W. Broll, “VRML: From the Web to Interactive Multiuser Virtual Reality,” Proc. Int’l Workshop MVD’95, Bad Honnef/Bonn, Germany, Nov. 1995; available online at http://orgwis.gmd.de/~broll/papers/MVD95.ps.gz. 4. R.C. Waters, et al., “Diamond Part and Spline: Social Virtual Reality with 3D Animation, Spoken Interaction, and Runtime Extendability,” Presence, Vol. 6, No. 4, Aug. 1997, pp. 461–481. 5. R.C. Waters, D.B. Anderson, and D.L. Schwenke, “The

■

A protocol data unit, or PDU, defines the information exchanged among simulation hosts through the network. The PDU contains the simulated entity status and the type of interaction that took place in an exercise; it also defines the data format and protocol for managing the simulation process. DIS defines 27 types of PDUs, which are organized into six protocol families: entity information/ interaction, warfare, logistics, simulation management, distributed emission regeneration, and radio communication. A dead-reckoning algorithm reduces network traffic load by predicting each entity’s position and orientation based on previous information. A host uses these so-called dead-reckoned values to move distributed simulated entities before their actual postures arrive from the network. In addition, for the simulated entities in its control, each host calculates the dead-reckoned values along with their actual postures, and sends an Entity State PDU to the network only when the dead-reckoned values differ from the actual postures by a predetermined threshold. When other hosts in the same simulation receive the Entity State PDU, they correct the posture of this entity to the updated value and resume the dead-reckoning calculation from this new posture.

Interactive Sharing Transfer Protocol Version 1.0,” tech. report, Mitsubishi Electric Research Lab, Cambridge, Mass., 1997; available online at http://www.merl.com/reports/ index.html/TR97–10.

This module enhances the interactions among distributed participants and, hence, broadens the applicability of the SharedWeb system. The WWW Homepage Viewer module is a standard HTML browser. By seamlessly integrating this module into the SharedWeb browser, a user can enter another virtual world by double-clicking a hyperlink provided on a homepage or inside the virtual world. Further, users can exchange information with each other by using the Homepage and HTTP.

Although the DIS standard was originally designed for peer-to-peer military-training simulations, its has been adapted by other distributed VR systems.2,3 In addition, we have shown in earlier work that the DIS standard can effectively support multiuser interaction over the Web environment.4 Based on this work, the SharedWeb system modifies the ■ DIS data format for more general use. REFERENCES 1. ANSI/IEEE Std. 1278-1993, Standard for Information Technology, Protocols for

Distributed Interactive Simulation, Mar. 1993. 2. O. Hagsand, “Interactive Multiuser VEs in the DIVE System,” IEEE Multimedia, Vol. 3, No. 1, Spring 1996, pp. 30–39. 3. C. Greenhalgh and S. Benford, “Massive, A Collaborative Virtual Environment for Teleconference,” ACM Trans. Computer-Human Interaction, Vol. 2, No. 3, 1995, pp. 239–261. 4. J.Y. Huang et al., “Usage of DIS Technique to Create an Interactive WWW Envi-

Server Site The Web server is a gateway for a SharedWeb player to enter a virtual world. The user downloads a scene

IEEE INTERNET COMPUTING

ronment,” Proc. 14th Workshop on Standard for the Interoperability of Distrib-

uted Simulations, Orlando, Florida, 1996, pp. 201–210.

http://computer.org/internet/ SEPTEMBER • OCTOBER 1998

73

.

F

E

A

T

U

R

E

3D render engine

Chat phase

Homepage viewer

Multiple participants interface SharedWeb browser

WAN

(TC SWC Po P rU DP )

CP SW TP) (HT CGI

SharedWeb server

Figure 1. An architecture for the SharedWeb system.

file from the Web server and logs in a username. After the Web server receives the login information from a browser, it activates a CGI program and forwards the user information. The CGI program in turn forwards the information to the SharedWeb server. The SharedWeb server module is the kernel of the entire SharedWeb system. This program mediates the information exchange among the browsers in the same virtual world: All the client information is sent to the server, and the server routes it to the browsers in the same virtual world. SharedWeb Communication Protocol No standardized communication protocol has yet emerged for Web-based multiuser virtual reality systems. On the other hand, the DIS standard— even though it was not designed for the Web—has proved effective in supporting networked multiuser virtual environments on the Internet.4 The SharedWeb Communication Protocol (SWCP) extends the DIS PDUs to support multiuser interaction in the Web environment. The extensions focus on methods to fully integrate the networked VR system into the existing Web architecture. We have so far defined seven PDUs for the SharedWeb system. Common Portions of SharedWeb PDUs. All PDUs

include a PDU header field, which allows the SharedWeb system to support more than one scenario at a time by identifying a user in different scenes. The

74

SEPTEMBER • OCTOBER 1998

http://computer.org/internet/

PDU header has five subfields that identify the SWCP version, the PDU type (Initial, Object State, End, Acknowledge, Chat, HTTP, or Error), the time when the PDU was sent, the file name of the downloaded virtual scene, and a scene ID that uniquely identifies the downloaded virtual scene. The SharedWeb server uses the file name and scene ID subfields to recognize the virtual world in which the browser issuing the PDU resides. In addition the time stamping is used to validate a user’s message. The second common portion for most PDUs is the User Information field, which contains the required information for a user to identify himself/herself. The User Information field contains three subfields: a user ID assigned by the SharedWeb server when the user logs in to a virtual world, the browser’s IP address, and an avatar type (a graphical representation, usually a human figure, inside the virtual world). In addition to the PDU header and User Information field, a PDU requires a UID field. This field is calculated by the browser when the browser is activated. The SharedWeb server saves this UID number in its client table and uses it to communicate specifically with that browser. Unlike the User ID of the User Information field, the UID must contain a unique identification number that distinguishes a user from other players at all times, not just when they reside in the same virtual world. In other words, if two players are in two distinct virtual worlds, they may have the same User ID number, but they must have different UID numbers. The UID field contains three subfields, which were introduced earlier in the section on client information recording: Login User Name, Time, and Port number. PDUs for Entering and Exiting a Virtual World. The Initial PDU allows a browser to submit the information required to log into a virtual world. After the browser has downloaded a scene file from a Web server, an Initial PDU is created when the user keys in a login name. The SharedWeb browser sends the Initial PDU as an HTTP string directly to the Web server. When the Web server receives the HTTP string, it activates a CGI program to forward the Initial PDU to the SharedWeb server. When the SharedWeb server receives the Initial PDU, it responds with an Acknowledge PDU to the browser. This Acknowledge PDU has the same fields and contents as the Initial PDU; only the PDU type and time stamp subfields differ. This Acknowledge PDU is used by the SharedWeb server to verify that

IEEE INTERNET COMPUTING

.

3

an Initial PDU has been received and to send the assigned unique User ID back to the browser. When the user wants to exit a virtual world, the browser sends an End PDU to notify the SharedWeb server. When the SharedWeb server receives the End PDU, it will first remove the corresponding avatar information from its client table and respond to this event by issuing an Acknowledge PDU to that browser. The SharedWeb server will also forward the End PDU to other browsers so they can remove its represented avatars from their virtual worlds.

D

W

E

B

B

R

O

W

S

I

N

G

S

Y

S

T

E

M

3D display window Chat output window User list window Chat input box

Figure 2. Interface of the SharedWeb browser.

PDUs for Exchanging Status Information. The most

important PDU in the DIS protocol is the Entity State PDU, because it is used to exchange the status change information among the distributed entities. SharedWeb uses an Object State PDU to mirror the Entity State PDU. However, the SharedWeb system design goals do not require the Object State PDU to be as complicated as the Entity State PDU. In addition to the header and User Information fields, the Object State PDU contains four subfields: ■

■

Location, Linear Velocity, and Orientation subfields define the postures of the avatar representing the player inside a virtual world. DR Parameter is set by the browser to specify the type of dead-reckoning algorithm used by the avatar.

After successfully logging into the virtual world, the browser uses the Object State PDU to send an avatar’s status-change information to the SharedWeb server. Inside the virtual world, the Object State PDU is issued only when the actual position of the avatar exceeds its dead-reckoned value by a predefined threshold. This mechanism reduces the number of messages flowing on the network and thus the bandwidth requirements. When the SharedWeb server receives an Object State PDU from a browser, it forwards this PDU to all the other browsers residing in the same virtual world. PDU for the SharedWeb Chat Phase. We adapted the Internet Relay Protocol5 to design the Chat PDU. Since the IRP is a peer-to-peer communication, the Chat PDU contains two subfields in addition to the PDU Header: Sender ID subfield for the User ID of the sender and Text Message subfield for the chat information. Although a chat server can be designed to support group chatting, it can generate a bottleneck

IEEE INTERNET COMPUTING

on the SharedWeb server site as the number of players increases. Hence, SharedWeb supports only the peer-to-peer chatting protocol at this time. PDU for Web Resource Integration. The SharedWeb system is designed not only to support multiple participants over the Web but also to integrate Web resources into the virtual world. We have implemented an HTTP PDU to achieve this goal. The HTTP PDU allows the user to send a URL address of a network resource, such as an HTML document or sound, to other users. After a browser receives an HTTP PDU, it downloads the specific network resource from the specified URL. Particularly, the HTTP PDU lets users control the objects in the virtual world from an HTML document. Data is sent to the Web server via an HTML form provided by the SharedWeb browser. The Web server forwards the information to the SharedWeb server, and the SharedWeb server then packs the information into an HTTP PDU, which is forwarded to other browsers. With this PDU, a user can easily send HTML documents or other resource to the other players in the same virtual world.

SHAREDWEB SYSTEM IMPLEMENTATION We implemented the SharedWeb system in Microsoft Visual C++ version 4.0. The server runs on a Windows NT machine with an embedded Web server. The browser currently operates as a stand-alone browser, though we plan to implement it as a plug-in application for Netscape Communicator or the Internet Explorer. Figure 2 illustrates the current browser interface. It uses Superscape’s Viscape software to render the 3D world (see the upper right window in Figure 2). The lower-right window is the chat output window that displays the text messages communicated

http://computer.org/internet/ SEPTEMBER • OCTOBER 1998

75

.

F

E

A

T

U

R

E

SYSTEM PERFORMANCE Button to forward HTML document

According to the mechanisms designed for the SharedWeb system, four factors will affect the interaction among the distributed players: ■ ■ ■

Figure 3. The SharedWeb browser after a user logs into the virtual world. Note when the URL button emerges, a user can forward a Web resource to other players.

Notification message

Receiver selected URL input box

Figure 4. Snapshot after the “Send URL” button is pressed.

among distributed players; the user types in a message from the chat input box. When the browser is initiated, the chat input box is labeled “Input User Name.” The user types his or her name to log into the downloaded virtual world. Before the user logs into a virtual world, the chat function and the multiuser interaction feature are disabled. After the user has successfully logged in, the chat input box is activated automatically, and all of the players’ names inside the world are listed in the user list window (see Figure 2). At the same time, a “Send URL” button will appear above the chat input box, as shown in Figure 3. This button lets the user send a hyperlinked resource, such as an HTML document or audio clip, to other players. After the “Send URL” button is pressed, it will disappear again and a highlighted message will display in the chat output window. Meanwhile, as shown in Figure 4, the label of the chat input box changes to “URL:” so the user can input the address of a network resource, such as an HTML document or audio clip. Moreover, the sender selects the recipients by clicking one or more names from the user list window. Clicking the OK button automatically forwards the network resource to the recipients.

76

SEPTEMBER • OCTOBER 1998

http://computer.org/internet/

■

The bandwidth required by the SharedWeb browser to reflect the status change of an avatar. The network latency between the SharedWeb server and browser. The network bandwidth provided by the network structure, such as the Internet. The computational load of the SharedWeb server in forwarding the received PDUs.

The second and third factors depend completely on the network structure, and the fourth factor is a constant time since the SharedWeb server simply records and forwards the received PDUs according to the information saved in its client table. The first factor depends on the size of the Object State PDU and how often it is sent by the SharedWeb browser. By multiplying the size of the Object State PDU by the number of PDUs sent by a browser per second, we can easily calculate the bandwidth required by a single user. In addition, we can use this factor to determine the number of players that can be interacting simultaneously. PDUs Per Second The dead-reckoning algorithm minimizes the number of Object State PDUs sent to the network. The equation for the algorithm used by the SharedWeb system is linear: P = P0 + V * t where P stands for dead-reckoning value, P0 is the last updated actual position, V is the velocity of an avatar, and t is the logical time of the virtual world. This definition ensures that avatar movements among the distributed players will not be affected by each host’s computational power. It also greatly simplifies computation of the dead-reckoning algorithm. Since the target frame rate for a VR system is 30 frames per second, we can project a logical time unit as 1/30 of a second of local clock on the host. Dead-Reckoning Threshold Value Setting the optimal dead-reckoning threshold value is critical: if the value is too high, the motion will be too jerky; if it is too small, the system will load the network with more PDUs than necessary. Hence, we conducted experiments to determine

IEEE INTERNET COMPUTING

.

3

appropriate threshold values under different frame rates. Our experiments were based on the following assumptions:

D

W

E

B

B

R

O

W

S

I

N

G

S

Y

S

T

E

M

Frame rate 8

12

24

36

52

10

4.02562

6.21677

12.4024

18.2287

26.1428

20

2.68712

4.16112

8.49192

11.8745

17.6048

Threshold

The pace, or single step, of 30 2.02458 3.15029 6.32563 9.12651 12.9869 each avatar equals its width. This approach allows virtual 40 1.62442 2.50606 5.02114 7.29393 10.3976 world designers to scale their 50 1.34774 2.09612 4.17452 5.98301 8.62408 own worlds without coordinating with other designers. (a) ■ The threshold value is measured by the number of paces 30 between the actual position and the dead-reckoned value. 10 threshold 25 20 threshold Therefore, if the threshold 30 threshold value is 3, an Object State 40 threshold 20 PDU is sent out whenever 50 threshold the difference between the 15 actual position and deadreckoned value is greater than 10 3. ■ The worst case of bandwidth 5 requirement is assumed. We found that a circular move0 ment will make an avatar’s 8 12 24 36 52 actual position different from Frames/sec (b) its dead-reckoned value at every movement. Figure 5. The number of PDUs generated per second at different frame rates and dead-reckoning threshold values: (a) table format and (b) graphical format. ■ Finally, the velocity V is a constant value. Although the SharedWeb system allows each avatar to move at different velocities, this Optimal Value for SharedWeb assumption simplified our simulation and pro- Based on these results, we chose a threshold value of 30 for the SharedWeb system. Thus, for each virtual duce a result that is close to the real case. world, the dead-reckoning threshold value is three Figure 5 presents the results of our experiment in times an avatar’s width. With this threshold value, an tabular and graph formats. During this experi- Object State PDU will be sent every four frames in ment, we set the radius of the trajectory to be 10 the worst case (4 =~ 8/2.024588 and so on). Since the size of the Object State PDU is 528 times an avatar’s pace. In addition, the trajectory bits in the worst case, the network bandwidth is simulated by rotating the avatar 10 degrees per required by a SharedWeb browser is 528 * 6.32563 frame while it is moving forward. The first column = ˜ 3,340 bits per second at a 24-Hz display rate with in the table (Figure 5a) represents the different threshold value 30. Hence, the SharedWeb system threshold values used, and the first row represents can theoretically support more than 300 simultathe frame rates tested. The table shows that, at the neous players (that is, 314 roughly equal to 1 Mbits threshold value 10, a PDU is generated every divided by 3,340 bits person) in the network envi1.98727 frames (that is, frame rate 8 divided by ronment with 1 Mbit of bandwidth. 4.02562 PDUs per second). Similarly, a PDU is generated every 2.977165 frames when the threshold value is 20 and so on. VIRTUAL SCENE DEMOS The graph in Figure 5b compares the number To explore the SharedWeb features, we constructed of PDUs generated per second versus the different several virtual worlds. For example, the Virtual Camframe rates for the threshold values. pus duplicates the main campus of Tamkang UniPDUs/sec

■

IEEE INTERNET COMPUTING

http://computer.org/internet/ SEPTEMBER • OCTOBER 1998

77

.

F

E

A

T

U

R

E

Figure 6. In the Virtual Office, pictures on the wall hyperlink to various HTML forms. The user has downloaded an application form for a student ID and filled it in.

Figure 7. Snapshot of the “redtank” user’s view after entering the virtual battlefield.

versity, Taiwan. Its purpose is to investigate the possibility of a virtual university over the Web. It opens to a view of the campus. Before the user logs in, he or she is alone in the scene. When the user logs in, the names of all users already inside the world are displayed in the User List window. Each user can navigate the virtual campus by clicking and dragging the control panel provided by the Viscape 3D Render Engine software, and the other users will observe the movement of the user’s avatar (see Figures 2 and 3 for parallel views in the Virtual Office application). Each building in the downloaded scene file has a hyperlink to another virtual world of the building’s

78

SEPTEMBER • OCTOBER 1998

http://computer.org/internet/

interior, which can in turn contain other hyperlinks. For example, the Virtual Office is a hyperlinked virtual world from inside the Virtual Campus’ Administrative Building. The Virtual Office is part of an effort to study performing some of the university’s administrative tasks online. Since the SharedWeb system integrates the VR system with the HTML browser, a user can fill out an HTML form, say, for a new student ID. In Figure 6, various application forms are hyperlinked by pictures on the wall. When the student downloads an application form, fills it out, and clicks the “Send” button on the HTML form, the information is sent to the Web server for processing. After the server has successfully received the information, it sends an acknowledgement to the client. We also developed a 3D tank wargaming simulation that prototypes a wargaming system in the Web environment. This application is a 3D version of a role-playing game (RPG) simulation, where the player can choose a role inside the game. The game is controlled by a user’s command rather than by direct manipulation through an input device such as a joystick. For example, if you are playing the captain of a warship, you can issue a command to move the warship to a new location. Whether the ship reaches that location will depend on whether an enemy attack occurs enroute. If an enemy attacks, the system will prompt you for a defense. Thus, RPG systems train for strategic thinking, not motor skills. RPG traditionally uses a 2D graphical layout. In addition, it requires an interactive dialog box, or command sheet, for the player to control his or her character inside the game. The SharedWeb system can easily implement the command sheet through an HTML document. A game master is also required for an RPG to control the game rules. We implemented the game master in the SharedWeb server. The prototype system allows three users to enter a virtual battlefield. One user plays the blue tank commander by logging in as “Bluetank,” another plays the red tank commander by logging in as “Redtank,” and the third player is the “referee” of the combat exercise. Bluetank and Redtank can use forms and check boxes available in an HTML document to control two tanks each inside the virtual battlefield. Figure 7 shows the viewpoint of the red tank commander after all three users have entered this virtual battlefield. The user command sheet has automatically downloaded into the HTML browser. The user can input data to control tank movements. In addition, check buttons let the user know whether or not to fire tank missiles.

IEEE INTERNET COMPUTING

.

3

After the user inputs a command and presses the “Confirm” button, the commands are sent to the SharedWeb server. The server forwards them to all participants and the status of each tank is modified accordingly.

FUTURE WORK The SharedWeb system sits on top of existing Web servers. It is transparent to users, who only need to download a scene file from a Web server and log in. The Web server then gracefully transfers the user to an appropriate SharedWeb server. Although the current SharedWeb implementation successfully demonstrates the concept of seamless integration with the Web, more research is required to improve the multiuser interaction. For example, consistency control of shared objects is an important function for computer-supported cooperative work (CSCW) applications. Moreover, in a virtual environment with N avatars, the current SharedWeb server must “broadcast” a change in any avatar’s state to N – 1 browsers. Thus, in the worst case, the server must send N 2 – N PDUs to the network. This approach yields O(N 2) complexity for updating messages and could exhaust the computation power of a host even before it saturates the network. To overcome this problem, we are currently investigating the concept of spatial culling for the SharedWeb server.6 This would allow the server to send out PDUs selectively during the course of interaction. For example, it could forward the received PDU only to the browsers residing in the same virtual room as the browser issuing the PDU. We are also investing a multiserver function that would organize the world databases into a clientserver architecture and thus scale up the number of participants. This function would also provide fault tolerance on the server site. ■ REFERENCES 1. J.Y. Huang et al., “SharedWeb—A Shared Virtual Environment Over World Wide Web,” Proc. IEEE Pacific Graphics 97, IEEE Computer Society, Los Alamitos, Calif., 1997, pp.178–189. 2. T. Berners-Lee et al., “The World-Wide Web,” Comm. ACM, Vol. 37, No. 8, Aug. 1994, pp.76–82. 3. J.Y. Huang et al., “Design of a Multiple Participant 3D War Game Environment over WWW,” SPIE 12th Annual Int’l Symp. on Aerospace/Defense Sensing, Simulation, and Control, SPIE, Bellingham, Wash., USA, 1998, pp 303-312. 4. D. Rogers, “STOW-E Lessons Learned, Focus on the 3 Primary Army STOW-E Sites,” Proc. 12th Workshop on Stan-

IEEE INTERNET COMPUTING

D

W

E

B

B

R

O

W

S

I

N

G

S

Y

S

T

E

M

URLs for this Article Active Worlds • www.activeworlds.com/ Blaxxun CCpro • ww3.blacksun.com/download/index.html C o m m u n i t y P l a c e B r o w s e r • v s . s p i w. c o m / v s / OZ Virtual • www.oz.com/ Pueblo • www.chaco.com/ S u p e r s c a p e ’s V i s c a p e • w w w. s u p e r s c a p e . c o m /

products/vrt/index.htm Venue • home.mira.net/~reality/venue.html V R M L • w w w. v r m l . o r g /

dards for the Interoperability of Distributive Simulation, Vol. I: Position Papers, IST-CF-95-01.1, 1995; available online at ftp://ftp.sc.ist.ucf.edu/public/STDS/workshop/12th/papers/0 26.doc. 5. J. Oikarinen and D. Reed, “Internet Relay Chat Protocol,” Internet RFC No. 1459, May 1993. 6. C. Greenhalgh and S. Benford, “Massive, A Collaborative Virtual Environment for Teleconference,” ACM Trans. ComputerHuman Interaction, Vol. 2, No. 3, 1995, pp. 239–261. Jiung-yao Huang is an associate professor in the Department of Computer Science and Information Engineering at Tamkang University, Taiwan, ROC. He is also director of the University's Cham-Pion Incubator Center. Huang received a degree in applied mathematics from Chung-Hsing University in 1983, an MS in computer science from Tsing-Hua University in 1988, and a PhD in electrical engineering from the University of Massachusetts in 1993. He is a member of IEEE, ACM, and the Society for Computer Simulation. Chao-Tsong Fangtsou is an associate professor in the Department of Computer Science and Information Engineering at Tamkang University, Taiwan, ROC. He is also the leader of the Network and the Information Management Sections of the University's Information Processing Center. Fangtsou graduated from the Department of Computer Science in 1981, received his MS in computer science in 1983 and his PhD in management science in 1992, all from Tamkang University. Jia-Lin Chang is a PhD student in the Department of Computer Science and Information Engineering at Tamkang University, Taiwan, ROC. Chang graduated from the Department of Applied Mathematics at the Tatung Institute of Technology, Taiwan, in 1995, and received his MS from the Department of Computer Science and Information Engineering at Tamkang University in 1997. Readers may contact Huang and Fangtsou at {jhuang, ctfang}@mail.tku.edu.tw.

http://computer.org/internet/ SEPTEMBER • OCTOBER 1998

79