A multiuser 3D Web browsing system

FEA

TURE

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.

A MULTIUSER3D WEBBROWSINGSYSTEM

JIUNG-YAO HUANG, CHAO-TSOU FANG-TSOU, AND JIA-LIN CHANG

Tamkang University

T he Virtual Reality Modeling Language sets an open-standard file for-mat for designing 3D multimedia and shared virtual worlds on theInternet. VRML was originally designed to support the interaction

of multiple participants in the World Wide Web environment—that is, tonetwork virtual worlds via hyperlinks. However, even version 2.0 of thestandard, published in August 1998, did not fulfill this design goal.

The development of VRML has nevertheless spurred broad research ondistributed multiuser VR systems. Such systems generally provide mecha-nisms for the multiuser server to “remember” the information of registeredparticipants and to process the messages communicated among them (seethe sidebar, “Related Work,” on pp. 72-73). To take advantage of the Webenvironment, however, a distributed multiuser VR system must be seam-lessly integrated with the Web architecture so that users can download virtualscene files from any supporting Web server and navigate transparently toother virtual worlds through other Web servers. Such integration wouldinclude full access to the services provided by the Web environment.

In this article, we describe SharedWeb, a 3D Web browsing system thatwas designed and implemented to support interaction among clients in theexisting Web environment.1 We begin by describing the methodologies andmechanisms used to achieve seamless integration with the Web environ-ment, then we summarize the SharedWeb system implementation. We pre-sent some experimental results that show the effects of different frame ratesand threshold values on system performance, and conclude with discus-sions of two virtual worlds currently supported by the system.

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

70 SEPTEMBER • OCTOBER 1998 h t tp ://computer.org/ in te rne t/ 1089-7801/ 9 8 /$10.00 ©1998 IEEE IEEE INTERNET COMPUTING

.

3 D W E B B R O W S I N G S Y S T E M

71IEEE INTERNET COMPUTING h t tp ://computer.org/ in te rne t/ SEPTEMBER • OCTOBER 1998

server must establish a method to record its clientinformation. Second, a server-to-client callbackmechanism is required. In addition, the networkload must be minimized, and the process of enter-ing a virtual world must be fully integrated into theexisting Web environment.

Client-Information RecordsThe Web server generally does not keep the recordsof the clients that request information from it. Thisinformation is required for multiuser interaction;our system achieves this by having each browsercalculate a sequence number, called a unique iden-tification (UID), to uniquely identify itself to theserver. SharedWeb combines the login name, timestamp, and port number (called LTP, for short) asthe UID to distinguish each client from others.1

With this UID, the SharedWeb server can easi-ly identify a new registered player and assign a UserID to that browser. Moreover, the SharedWeb serv-er records the UID for future reference.

Server-to-Client Callback MechanismThe HTTP link between a server and client isestablished only when a specific request is raised bya client. The Web server cannot establish a con-nection to its clients automatically. If a clientintends to send information to other clients in thesame virtual world, the server does not have theability to forward the information.

To solve this problem, the server has to “remem-ber” the browsers registered to a virtual scene. Inaddition, each browser must give the server infor-mation such as IP address and port number, so thatthe server can automatically send information tothe registered browser. The SharedWeb browseruses the client-information recording method tosend this information to the SharedWeb server aftera user has logged in. When the SharedWeb serverreceives the registration information from a brows-er, it saves the registration message and sends theIP address and port number information to the reg-istered browser. Hence, during the course of multi-user interaction, each registered browser sends itsstatus change to the SharedWeb server. The Shared-Web server then forwards the received message tothe appropriate participants.

Network LoadBecause HTTP establishes links only when arequest is issued, it adds a linking delay on top ofintrinsic network latency. A Web-based multiuserVR system does not necessarily require a multiuser

server to maintain the spatial consistency of a vir-tual world, but it does require a central server tomediate communication among the clients.3 Thus,network bandwidth will overload very quickly asthe number of players increases, and the server willrapidly become an input/output bottleneck as well.

SharedWeb adopted the Distributed InteractiveSimulation standard to maintain spatial coherency(see the sidebar, “Distributed Interactive Simula-tion Standard” on p. 73). DIS is a fully distributedsimulation method, and SharedWeb, like DIS,gives each browser the entire virtual world. An enti-ty’s change in status is encapsulated in a self-con-tained data package, called a protocol data unit(PDU), and forwarded to each participating brows-er through the multiuser server.

DIS reduces bandwidth requirements by usinga dead-reckoning algorithm to reduce the frequen-cy with which a change in status must be transmit-ted. As guided by this algorithm, a change in enti-ty status is sent to the multiuser server only whenthe change exceeds a predefined threshold.

Virtual World EntranceIn the request-and-response method of HTTP, theWeb server is not aware of the client that down-loaded a scene file. Consequently, the Web servercannot automatically forward the multiuser serverinformation to that client.One simple solution tothis problem is to embed the information into thedownloaded scene file, but this causes trouble when amultiuser server crashes and a replacement server isactivated. Another possibility is to let the client querythe Web server for multiuser server information, butthis method forces the client to wait to connect untilit receives the reply.

For a networked VR system to integrate seam-lessly with the Web environment, the Web servermust treat the multiuser server as an add-on appli-cation. The Web architecture allows the server tocommunicate with add-on applications through aCGI program. SharedWeb uses this method to for-ward the login information from the Web server tothe multiuser server. Thus, the client does not careif the multiuser server and the Web server reside inthe same host.

In addition, a hierarchy structure of the multi-user servers can be implemented so that the Webserver can pass client login information to a load-monitor program, which will can then forward theclient transparently to another multiuser server. Thisallows load-balancing and fault-tolerance featuresto be implemented for the multiuser server.

.

F E A T U R E

72 SEPTEMBER • OCTOBER 1998 h t tp ://computer.org/ in te rne t/ IEEE INTERNET COMPUTING

SHAREDWEB ARCHITECTUREFigure 1 on page 74 illustrates the SharedWeb archi-tecture. It features two types of nodes. The browsersite is composed of four modules: Multiple Partici-pants Interface, 3D Render Engine, Chat Phase, andWWW Homepage Viewer. The server site is built ontop of the existing Web server with two modules: aCGI program and the SharedWeb server. Commu-nication between server and browser is through theSharedWeb Communication Protocol.

Browser SiteThe Multiple Participant Interface module runs ontop of Winsock to manipulate the interaction

between the browser and other players. This mod-ule is the kernel of a SharedWeb browser. Its mainfunctions are to calculate the browser’s UID, encap-sulate and de-capsulate the PDUs, transmit/receivedata to/from the network, and coordinate messagesamong the other modules.

The 3D Render Engine module provides a visu-al window for the user to explore the virtual world.When a browser retrieves a scene file from the Webserver, it is an ASCII file. The scene file is thentranslated into a virtual world database recognizedby the 3D Render Engine module.

The Chat Phase module is designed to supporttext communication among distributed players.

RELATED WORK

The World Wide Web is a client-server architecture with a com-munication protocol, HTTP, that is intrinsically a “one waystreet.” This makes it impossible to achieve multiuser interac-tivity in the Web environment using HTTP.

The VRML standard attempts to deliver virtual worlds on theWeb. Its original goals included support for the interaction ofmultiple participants, but even version 2.0, which was releasedin August 1996, failed to define a standard to meet it. Hence,different Web–based multiuser systems have developed pro-prietary methods to support multiuser interaction.

Research ProjectsThe Virtual Society is a research project of Sony Computer Sci-ence Laboratory that attempts to define a global architectureand protocol set to realize multiuser 3D Web interaction basedon the VRML standard.1 The VS project was originally based onthe DIVE platform from the Swedish Institute of Computer Sci-ence.2 The project designed the Community Place Browser,which—unlike the DIVE system—is a VRML-standard virtualreality system.

To support large–scale shared 3D spaces using VRML, theVS project proposed the Virtual Society Server Client Protocol(VSCP), which extended the functionality of the existing VRMLstandard. In addition, the project designed a scripting archi-tecture for different levels of consistency among the sharedobjects. However, the VS architecture is not seamlessly inte-grated with the Web environment. For example, the VS clientcannot enter a virtual world from the Web server form thatdownloads the scene file. Instead, after a 3D scene file is suc-cessfully downloaded, the VS client must send a URL to the Webserver to query the information on the VS server. The Web serv-er then returns an HTML document to the browser associatedwith that VS client. The answering HTML document contains theaddress and port number of a VS server that will handle that

particular scene. The browser then forwards this informationto the VS client.

The German National Research Center for Information Tech-nology (GMD) proposed another type of Web-based multiusersystem by defining new nodes for the VRML standard.3 TheGMD multiuser system does not require a multiuser server tomaintain the consistency among distributed objects, as the VSproject does. Instead, after a VRML browser has downloadeda VRML scene file from a Web server, the browser will introduceitself as a user to the server. The Web server responds to the userwith embodiment files of all existing players, along with a mul-ticast address and port number. The multicast address refers tothe IP address of the Web server, and the port number denotesan existing virtual world. Hence, during the interaction, eachparticipant sends its status change to the specified port on theWeb server and listens to the update information of other usersfrom another port representing a multicast channel.

Since each individual client sends the update messages tothe specified port and the Web server redistributes the mes-sages through the multicast channel, an extended HTTPD serv-er is designed to receive update information and monitor thestatus of the virtual world. If the HTTPD server does not receivean update message from a client for a designated period oftime, a time-out mechanism on the HPPD server will issue a quitmessage to the multicast channel for that client.

The Scalable Platform for Large Interactive Networked Envi-ronment (Spline) from Mitsubishi Electric Research Lab used adifferent approach to integrate the MVE with the Web.4 Splineis essentially a networked–based multiuser VR system that usesInteractive Sharing Transfer Protocol as its communication pro-tocol.5 ISTP incorporates several simple HTTP protocols to enablethe HTTP server to participate in the multiuser interaction. Withthe help of ISTP, the Spline system provides a Web-like virtualenvironment. However, it is not a Web-based multiuser system.

.



This module enhances the interactions among dis-tributed participants and, hence, broadens theapplicability of the SharedWeb system.

The WWW Homepage Viewer module is a stan-dard HTML browser. By seamlessly integrating thismodule into the SharedWeb browser, a user canenter another virtual world by double-clicking ahyperlink provided on a homepage or inside the vir-tual world. Further, users can exchange informationwith each other by using the Homepage and HTTP.

Server SiteThe Web server is a gateway for a SharedWeb playerto enter a virtual world. The user downloads a scene

Current Commercial ProductsOther commercially available Web-based multi-user systems include Blaxxun CCpro, Venue, OzVirtual, and Pueblo. All of these browsers adaptthe VRML standard as their virtual scene file for-mat, and the multiuser systems use their own tech-niques to provide interactivity among distributedusers. None of them is fully integrated with the tra-ditional HTML browser.

The Active Worlds browser from Worlds Inc. isanother kind of multiuser browser that is not aVRML browser but instead merges the traditionalHTML browser into its own 3D VR browser. ■

REFERENCES1. Y. Honda et al., “Virtual Society: Extending the WWW

to Support a Multiuser Interactive Shared 3D Environ-

ment,” 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 Hon-

nef/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

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.

DISTRIBUTIVE INTERACTIVE SIMULATION

Although VRML brought virtual worlds into the Web environment, theonly standardized communication protocol for multiuser interactionover the Internet is the Distributive Interactive Simulation standard.1

The goal of the DIS standard is to link the activities of multiple partici-pants in an operational exercise that forms a time- and space-coherentsynthetic 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 partici-pating host and defines two important techniques to support its goal:

■ A protocol data unit, or PDU, defines the information exchangedamong simulation hosts through the network. The PDU containsthe simulated entity status and the type of interaction that tookplace in an exercise; it also defines the data format and protocolfor managing the simulation process. DIS defines 27 types of PDUs,which are organized into six protocol families: entity information/interaction, warfare, logistics, simulation management, distributedemission regeneration, and radio communication.

■ A dead-reckoning algorithm reduces network traffic load by predictingeach entity’s position and orientation based on previous information.A host uses these so-called dead-reckoned values to move distributedsimulated entities before their actual postures arrive from the network.In addition, for the simulated entities in its control, each host calculatesthe dead-reckoned values along with their actual postures, and sendsan Entity State PDU to the network only when the dead-reckonedvalues 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 resumethe dead-reckoning calculation from this new posture.

Although the DIS standard was originally designed for peer-to-peermilitary-training simulations, its has been adapted by other distributedVR systems.2,3 In addition, we have shown in earlier work that the DISstandard can effectively support multiuser interaction over the Webenvironment.4 Based on this work, the SharedWeb system modifies theDIS data format for more general use. ■

REFERENCES1. 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-

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

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

.

F E A T U R E


file from the Web server and logs in a username. Afterthe Web server receives the login information from abrowser, it activates a CGI program and forwards theuser information. The CGI program in turn forwardsthe information to the SharedWeb server.

The SharedWeb server module is the kernel ofthe entire SharedWeb system. This program medi-ates the information exchange among the browsersin the same virtual world: All the client informa-tion is sent to the server, and the server routes it tothe browsers in the same virtual world.

SharedWeb Communication Protocol No standardized communication protocol has yetemerged for Web-based multiuser virtual realitysystems. On the other hand, the DIS standard—even though it was not designed for the Web—hasproved effective in supporting networked multiuservirtual environments on the Internet.4

The SharedWeb Communication Protocol(SWCP) extends the DIS PDUs to support multi-user interaction in the Web environment. Theextensions focus on methods to fully integrate thenetworked VR system into the existing Web archi-tecture. We have so far defined seven PDUs for theSharedWeb system.

Common Portions of SharedWeb PDUs. All PDUsinclude a PDU header field, which allows the Shared-Web system to support more than one scenario at atime by identifying a user in different scenes. The

PDU header has five subfields that identify theSWCP version, the PDU type (Initial, Object State,End, Acknowledge, Chat, HTTP, or Error), the timewhen the PDU was sent, the file name of the down-loaded virtual scene, and a scene ID that uniquelyidentifies the downloaded virtual scene. The Shared-Web server uses the file name and scene ID subfieldsto recognize the virtual world in which the browserissuing the PDU resides. In addition the time stamp-ing is used to validate a user’s message.

The second common portion for most PDUs isthe User Information field, which contains therequired information for a user to identify him-self/herself. The User Information field containsthree subfields: a user ID assigned by the Shared-Web server when the user logs in to a virtual world,the browser’s IP address, and an avatar type (agraphical representation, usually a human figure,inside the virtual world).

In addition to the PDU header and User Infor-mation field, a PDU requires a UID field. Thisfield is calculated by the browser when the browseris activated. The SharedWeb server saves this UIDnumber in its client table and uses it to communi-cate specifically with that browser. Unlike the UserID of the User Information field, the UID mustcontain a unique identification number that dis-tinguishes a user from other players at all times, notjust when they reside in the same virtual world. Inother words, if two players are in two distinct vir-tual worlds, they may have the same User ID num-ber, but they must have different UID numbers.

The UID field contains three subfields, whichwere introduced earlier in the section on clientinformation recording: Login User Name, Time,and Port number.

PDUs for Entering and Exiting a Virtual World. TheInitial PDU allows a browser to submit the infor-mation required to log into a virtual world. Afterthe browser has downloaded a scene file from aWeb server, an Initial PDU is created when the userkeys in a login name. The SharedWeb browsersends the Initial PDU as an HTTP string directlyto the Web server. When the Web server receivesthe HTTP string, it activates a CGI program toforward the Initial PDU to the SharedWeb server.

When the SharedWeb server receives the InitialPDU, it responds with an Acknowledge PDU to thebrowser. This Acknowledge PDU has the same fieldsand contents as the Initial PDU; only the PDU typeand time stamp subfields differ. This AcknowledgePDU is used by the SharedWeb server to verify that

3D render engine Chat

phase

Multiple participants interface

Homepageviewer

WAN

SharedWeb browser

SWCP

(HTTP)

CGI SharedWebserver

SWCP(TCP or UDP)

Figure 1. An architecture for the SharedWeb system.

.



an Initial PDU has been received and to send theassigned unique User ID back to the browser.

When the user wants to exit a virtual world, thebrowser sends an End PDU to notify the SharedWebserver. When the SharedWeb server receives the EndPDU, it will first remove the corresponding avatarinformation from its client table and respond to thisevent by issuing an Acknowledge PDU to thatbrowser. The SharedWeb server will also forward theEnd PDU to other browsers so they can remove itsrepresented avatars from their virtual worlds.

PDUs for Exchanging Status Information. The mostimportant PDU in the DIS protocol is the EntityState PDU, because it is used to exchange the statuschange information among the distributed entities.SharedWeb uses an Object State PDU to mirrorthe Entity State PDU. However, the SharedWebsystem design goals do not require the Object StatePDU to be as complicated as the Entity StatePDU. In addition to the header and User Infor-mation fields, the Object State PDU contains foursubfields:

■ Location, Linear Velocity, and Orientation sub-fields define the postures of the avatar repre-senting the player inside a virtual world.

■ DR Parameter is set by the browser to specifythe type of dead-reckoning algorithm used bythe avatar.

After successfully logging into the virtual world,the browser uses the Object State PDU to send anavatar’s status-change information to the Shared-Web server. Inside the virtual world, the ObjectState PDU is issued only when the actual positionof the avatar exceeds its dead-reckoned value by apredefined threshold. This mechanism reduces thenumber of messages flowing on the network andthus the bandwidth requirements. When theSharedWeb server receives an Object State PDUfrom a browser, it forwards this PDU to all theother browsers residing in the same virtual world.

PDU for the SharedWeb Chat Phase. We adaptedthe Internet Relay Protocol5 to design the ChatPDU. Since the IRP is a peer-to-peer communica-tion, the Chat PDU contains two subfields in addi-tion to the PDU Header: Sender ID subfield forthe User ID of the sender and Text Message sub-field for the chat information.

Although a chat server can be designed to sup-port group chatting, it can generate a bottleneck

on the SharedWeb server site as the number ofplayers increases. Hence, SharedWeb supports onlythe peer-to-peer chatting protocol at this time.

PDU for Web Resource Integration. The SharedWebsystem is designed not only to support multiple par-ticipants over the Web but also to integrate Webresources into the virtual world. We have imple-mented an HTTP PDU to achieve this goal. TheHTTP PDU allows the user to send a URL addressof a network resource, such as an HTML documentor sound, to other users.

After a browser receives an HTTP PDU, itdownloads the specific network resource from thespecified URL. Particularly, the HTTP PDU letsusers control the objects in the virtual world froman HTML document. Data is sent to the Web serv-er via an HTML form provided by the SharedWebbrowser. The Web server forwards the informationto the SharedWeb server, and the SharedWeb serv-er then packs the information into an HTTP PDU,which is forwarded to other browsers.

With this PDU, a user can easily send HTMLdocuments or other resource to the other players inthe same virtual world.

SHAREDWEB SYSTEMIMPLEMENTATION We implemented the SharedWeb system inMicrosoft Visual C++ version 4.0. The server runson a Windows NT machine with an embeddedWeb server. The browser currently operates as astand-alone browser, though we plan to implementit as a plug-in application for Netscape Communi-cator or the Internet Explorer.

Figure 2 illustrates the current browser interface.It uses Superscape’s Viscape software to render the3D world (see the upper right window in Figure 2).The lower-right window is the chat output windowthat displays the text messages communicated

3D displaywindow

Chat outputwindow

User listwindow

Chat inputbox

Figure 2. Interface of the SharedWeb browser.

.

F E A T U R E


among distributed players; the user types in a mes-sage from the chat input box. When the browser isinitiated, the chat input box is labeled “Input UserName.” The user types his or her name to log intothe downloaded virtual world.

Before the user logs into a virtual world, the chatfunction and the multiuser interaction feature are dis-abled. After the user has successfully logged in, thechat input box is activated automatically, and all ofthe players’ names inside the world are listed in theuser list window (see Figure 2). At the same time, a“Send URL” button will appear above the chat inputbox, as shown in Figure 3. This button lets the usersend a hyperlinked resource, such as an HTML doc-ument or audio clip, to other players.

After the “Send URL” button is pressed, it willdisappear again and a highlighted message will dis-play in the chat output window. Meanwhile, asshown in Figure 4, the label of the chat input boxchanges to “URL:” so the user can input the addressof a network resource, such as an HTML documentor audio clip. Moreover, the sender selects the recip-ients by clicking one or more names from the userlist window. Clicking the OK button automaticallyforwards the network resource to the recipients.

SYSTEM PERFORMANCEAccording to the mechanisms designed for theSharedWeb system, four factors will affect the inter-action among the distributed players:

■ The bandwidth required by the SharedWebbrowser to reflect the status change of an avatar.

■ The network latency between the SharedWebserver and browser.

■ The network bandwidth provided by the net-work structure, such as the Internet.

■ The computational load of the SharedWebserver in forwarding the received PDUs.

The second and third factors depend completelyon the network structure, and the fourth factor isa constant time since the SharedWeb server simplyrecords and forwards the received PDUs accordingto the information saved in its client table.

The first factor depends on the size of the ObjectState PDU and how often it is sent by the Shared-Web browser. By multiplying the size of the ObjectState PDU by the number of PDUs sent by abrowser per second, we can easily calculate thebandwidth required by a single user. In addition,we can use this factor to determine the number ofplayers that can be interacting simultaneously.

PDUs Per SecondThe dead-reckoning algorithm minimizes the num-ber of Object State PDUs sent to the network. Theequation for the algorithm used by the SharedWebsystem is linear:

P = P0 + V * t

where P stands for dead-reckoning value, P0 is thelast updated actual position, V is the velocity of anavatar, and t is the logical time of the virtual world.

This definition ensures that avatar movementsamong the distributed players will not be affected byeach host’s computational power. It also greatly sim-plifies computation of the dead-reckoning algorithm.Since the target frame rate for a VR system is 30frames per second, we can project a logical time unitas 1/30 of a second of local clock on the host.

Dead-Reckoning Threshold ValueSetting the optimal dead-reckoning threshold valueis critical: if the value is too high, the motion willbe too jerky; if it is too small, the system will loadthe network with more PDUs than necessary.Hence, we conducted experiments to determine

Button toforwardHTML

document

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

Notificationmessage

URLinput box

Receiverselected

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

.



appropriate threshold valuesunder different frame rates. Ourexperiments were based on thefollowing assumptions:

■ The pace, or single step, ofeach avatar equals its width.This approach allows virtualworld designers to scale theirown worlds without coordi-nating with other designers.

■ The threshold value is mea-sured by the number of pacesbetween the actual positionand the dead-reckoned value.Therefore, if the thresholdvalue is 3, an Object StatePDU is sent out wheneverthe difference between theactual position and dead-reckoned value is greater than3.

■ The worst case of bandwidthrequirement is assumed. Wefound that a circular move-ment will make an avatar’sactual position different fromits dead-reckoned value atevery movement.

■ Finally, the velocity V is aconstant value. Although theSharedWeb system allowseach avatar to move at different velocities, thisassumption simplified our simulation and pro-duce a result that is close to the real case.

Figure 5 presents the results of our experiment intabular and graph formats. During this experi-ment, we set the radius of the trajectory to be 10times an avatar’s pace. In addition, the trajectoryis simulated by rotating the avatar 10 degrees perframe while it is moving forward. The first columnin the table (Figure 5a) represents the differentthreshold values used, and the first row representsthe frame rates tested. The table shows that, at thethreshold value 10, a PDU is generated every1.98727 frames (that is, frame rate 8 divided by4.02562 PDUs per second). Similarly, a PDU isgenerated every 2.977165 frames when the thresh-old value is 20 and so on.

The graph in Figure 5b compares the numberof PDUs generated per second versus the differentframe rates for the threshold values.

Optimal Value for SharedWebBased on these results, we chose a threshold value of30 for the SharedWeb system. Thus, for each virtualworld, the dead-reckoning threshold value is threetimes an avatar’s width. With this threshold value, anObject State PDU will be sent every four frames inthe worst case (4 =~ 8/2.024588 and so on).

Since the size of the Object State PDU is 528bits in the worst case, the network bandwidthrequired by a SharedWeb browser is 528 * 6.32563=̃ 3,340 bits per second at a 24-Hz display rate withthreshold value 30. Hence, the SharedWeb systemcan theoretically support more than 300 simulta-neous players (that is, 314 roughly equal to 1 Mbitsdivided by 3,340 bits person) in the network envi-ronment with 1 Mbit of bandwidth.

VIRTUAL SCENE DEMOSTo explore the SharedWeb features, we constructedseveral virtual worlds. For example, the Virtual Cam-pus duplicates the main campus of Tamkang Uni-

Threshold

Frame rate

10

20

30

40

50

8

4.02562

2.68712

2.02458

1.62442

1.34774

12

6.21677

4.16112

3.15029

2.50606

2.09612

24

12.4024

8.49192

6.32563

5.02114

4.17452

36

18.2287

11.8745

9.12651

7.29393

5.98301

52

26.1428

17.6048

12.9869

10.3976

8.62408

(a)

30

25

20

15

10

5

08 12 24

Frames/sec

36 52

PDU

s/se

c

10 threshold20 threshold30 threshold40 threshold50 threshold

(b)

Figure 5. The number of PDUs generated per second at different frame rates anddead-reckoning threshold values: (a) table format and (b) graphical format.

.

F E A T U R E


versity, Taiwan. Its purpose is to investigate the pos-sibility of a virtual university over the Web. It opensto a view of the campus. Before the user logs in, heor she is alone in the scene. When the user logs in,the names of all users already inside the world are dis-played in the User List window. Each user can navi-gate the virtual campus by clicking and dragging thecontrol panel provided by the Viscape 3D RenderEngine software, and the other users will observe themovement of the user’s avatar (see Figures 2 and 3for parallel views in the Virtual Office application).

Each building in the downloaded scene file has ahyperlink to another virtual world of the building’s

interior, which can in turn contain other hyper-links. For example, the Virtual Office is a hyper-linked virtual world from inside the Virtual Cam-pus’ Administrative Building. The Virtual Office ispart of an effort to study performing some of theuniversity’s administrative tasks online. Since theSharedWeb system integrates the VR system withthe HTML browser, a user can fill out an HTMLform, say, for a new student ID.

In Figure 6, various application forms are hyper-linked by pictures on the wall. When the studentdownloads an application form, fills it out, and clicksthe “Send” button on the HTML form, the infor-mation is sent to the Web server for processing. Afterthe server has successfully received the information,it sends an acknowledgement to the client.

We also developed a 3D tank wargaming simula-tion that prototypes a wargaming system in the Webenvironment. This application is a 3D version of arole-playing game (RPG) simulation, where the play-er can choose a role inside the game. The game iscontrolled by a user’s command rather than by directmanipulation through an input device such as a joy-stick. For example, if you are playing the captain of awarship, you can issue a command to move the war-ship to a new location. Whether the ship reaches thatlocation will depend on whether an enemy attackoccurs enroute. If an enemy attacks, the system willprompt you for a defense. Thus, RPG systems trainfor strategic thinking, not motor skills.

RPG traditionally uses a 2D graphical layout. Inaddition, it requires an interactive dialog box, or com-mand sheet, for the player to control his or her char-acter inside the game. The SharedWeb system caneasily implement the command sheet through anHTML document. A game master is also requiredfor an RPG to control the game rules. We imple-mented the game master in the SharedWeb server.

The prototype system allows three users to entera virtual battlefield. One user plays the blue tankcommander by logging in as “Bluetank,” anotherplays the red tank commander by logging in as“Redtank,” and the third player is the “referee” ofthe combat exercise. Bluetank and Redtank can useforms and check boxes available in an HTML doc-ument to control two tanks each inside the virtualbattlefield. Figure 7 shows the viewpoint of the redtank commander after all three users have enteredthis virtual battlefield. The user command sheet hasautomatically downloaded into the HTML brows-er. The user can input data to control tank move-ments. In addition, check buttons let the user knowwhether or not to fire tank missiles.

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

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

.



After the user inputs a command and presses the“Confirm” button, the commands are sent to theSharedWeb server. The server forwards them to allparticipants and the status of each tank is modifiedaccordingly.

FUTURE WORKThe SharedWeb system sits on top of existing Webservers. It is transparent to users, who only need todownload a scene file from a Web server and log in.The Web server then gracefully transfers the userto an appropriate SharedWeb server. Although thecurrent SharedWeb implementation successfullydemonstrates the concept of seamless integrationwith the Web, more research is required to improvethe multiuser interaction. For example, consisten-cy control of shared objects is an important func-tion for computer-supported cooperative work(CSCW) applications.

Moreover, in a virtual environment with Navatars, the current SharedWeb server must “broad-cast” a change in any avatar’s state to N – 1browsers. Thus, in the worst case, the server mustsend N 2 – N PDUs to the network. This approachyields O(N 2) complexity for updating messagesand could exhaust the computation power of a hosteven before it saturates the network.

To overcome this problem, we are currentlyinvestigating the concept of spatial culling for theSharedWeb server.6 This would allow the server tosend out PDUs selectively during the course ofinteraction. For example, it could forward thereceived PDU only to the browsers residing in thesame virtual room as the browser issuing the PDU.

We are also investing a multiserver function thatwould organize the world databases into a client-server architecture and thus scale up the number ofparticipants. This function would also provide faulttolerance on the server site. ■

REFERENCES1. J.Y. Huang et al., “SharedWeb—A Shared Virtual Envi-

ronment 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 Con-

trol, SPIE, Bellingham, Wash., USA, 1998, pp 303-312.

4. D. Rogers, “STOW-E Lessons Learned, Focus on the 3 Pri-

mary Army STOW-E Sites,” Proc. 12th Workshop on Stan-

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 Vir-

tual Environment for Teleconference,” ACM Trans. Computer-

Human 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 Univer-

sity'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 Univer-

sity 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 Depart-

ment 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. Fangt-

sou 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 Com-

puter Science and Information Engineering at Tamkang

University, Taiwan, ROC. Chang graduated from the

Department of Applied Mathematics at the Tatung Insti-

tute of Technology, Taiwan, in 1995, and received his MS

from the Department of Computer Science and Informa-

tion Engineering at Tamkang University in 1997.

Readers may contact Huang and Fangtsou at {jhuang,

ctfang}@mail.tku.edu.tw.

URLs for this ArticleActive Worlds • www.activeworlds.com/Blaxxun CCpro • ww3.blacksun.com/download/index.htmlCommuni ty P lace Browser • vs . sp iw.com/vs/OZ Virtual • www.oz.com/Pueblo • www.chaco.com/ Superscape’s V iscape • www.superscape.com/produc t s/vr t/ index.h tmVenue• home.mira.net/~reality/venue.htmlVRML • www.vrml .org/

.

Documents

A multiuser 3D Web browsing system