RING: A Client-Server System for Multi-User Virtual Environments Thomas A. Funkhomer .4T&T Bell Laboratories i Abstract This paper describes the client-server design, implementation ant1 experimental results for a system t.hat supp0rt.s real-time visual interaction between a large number of users in a shared 3D virtual environment. The key feature of the system is that server-based visibility algorithms compute potential visual in- teractions between entit.ics representing users in order to re- duce the number of messages required to maintain consistent state among many workstations distributed across a wide-area network. When an entity changes state, updat,e messages are sent ouly to workstations with entities that can potentially perceive the change - i.e., ones to which the update is visi- ble. Initial experiments show a 40x decrease in the number of messages processed by client workstations during tests with 1024 cntit.ics interacting in a large densely occluded virtual environment. CR Categories and Subject [Computer Graphics]: 1.3.7 and Realism - Virtual Renlity. Descriptors: Three-Dimensional Graphics Additional Key Words and Phrases: Visual simulation, multi-user systems, virtual reality, 3D virtual environments, real-time graphics, client.-scrvcr design, distributed systems. 1 Introduction In a multi-user visual simulation system, users rmi an interac- tive interface pr0gra.m 011 (usually distinct) workstations con- nected to each other via a net.work. The interface program simulates the experience of immersion in a virtua.1 environ- ment by rendering images of the environment as perceived from the user’s simulated viewpoint. Each user is represented in the shared virtual environment by an entity rendered on every other user’s workstation, and multi-user interaction is supported by matching user actions to entity updates in the Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial 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 of Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. 1995 Symposium on Interactive 3D Graphics, Monterey CA USA 0 1995 ACM O-89791 -736-7/95/0004...$3.50 shared virtual environment. -4pplications for these systems include distributed training simulations, collaborative design, virtual meetings, and multiplayer games. A difficult challenge in multi-user visual simulation is main- taining consistent state anion, c a large number of worksta- tions distributed over a wide-area network. Since three di- mensional rendering at. imeractive rates requires fast access to the geometric database, shared portions of the virtual en vironment (including dynamic entity states) are replicated on every participating workstation. As a result, whenever any entity changes state (e.g., moves) or modifies the shared cn- vironment, an appropriate update must be applied to cvcry copy of the database in order to maintain consistent state (see Figure 1). Virtual Environment Figure 1: Multi-user systems must maintain consistency be- tween entities (A, B, C, and D) replicated on multiple work- stations. Implementing visual simulation systems for large numbers of users is especially challenging because updates can occur at cxt.remely high rates. If N entit.ies move through a shared vir- tual environment simultaneously, each modifying its position and/or orientat.ion M times per second, then M * h’ updates are generated to a shared database per second. Moreover, updates must be propa.gatccl to participating workstations in near real-time since large variances or delays in updat.cs can result in visually perceptible jerky or latent motion and thus may be disturbing to users. As a result, general-purpose dis- tributed database systems are not adequate for use in multi- user visual simulat.ion applications, and special-purpose mes- saging protocols are typically used to maintain consistent state in multi-user visual siniulat~ion systems [9. 131. 85
`
`BUNGIE - EXHIBIT 1005
`
`01
`
`

`

`2 Previous work Numerous experimental virtual reality systems and multi- player ga.m.es have been developed for real time interaction iu shared virtual environments. Unfortunately, most existing systems do not. scale well to large numbers of simultaneous I1scrs. R.eality 13uilt For Two [a]! VEOS [4], and MR Toolkit [Id] are multi-user virt.ual rea1it.y systems that maintain consis- tent, statr among N workstations by sending a point-to-point message to each of N-l workst.ations whenever any entity in the distribut.ed simulation changes state. This approach yields 0( IV?) update messages during every simulation step (see Fig- ure 2), and thus does not scale to many simultaneous users before t.he ::ietwork gets saturated. Figure 3: Systems using broadcast, messages pass only O(X) updates each simulation step. But, every workst,at,ion still must process every update message. Figure 2: Systems using point-to-point connections pass O(N’) update messages (labeled arrows) during each simu- lation step. SIMNET [s], NPSNET [17], and VERN [3] use broadcast messages to send updat,es to all other workstations participat- ing in a virtual environment. at once. Although, this approach cuts down on the total number of messages transmitted to O(N), every workst.ation still must process a message when- ever any entity in the distributed simulation changes state (see Figure 3). Since every workstation must st.ore data and process updat.e messages and/or simulate behavior for all N entities during every simulation step, these systems do not scale beyond the capabilities of t.he least powerful participat- ing workstation. Experiences with SIMNET and NPSNET show that a significant percentage of every workstation’s pro- cessing capability is used just, to read update messages from other workstations during large simulations; and, therefore, broadcast protocols are not practical for more than a few hun- dred users on incxpcnsivc workstations [17] In order 1:o support very large numbers of users (> 1000) in tcracting simultaneously in a distributed virtual environment it is necessary t,o develop a system design and communicabion protocol that does not require sending update messages to all participating hosts for every entit,y st.ate change. Kaaman has proposed a. system design, called W.4VES, in which mes- sage managers mediate communication between hosts, possi- bly culling irrelevant messages [lo, 111. His approach is very similar to the lone presented in this paper. One difference is that this paper presents algorithms and experimental results for visibility-based message culling during large simulations. 3 Overview of Approach This paper describes a system (called RING) that supports interaction bctwecn large numbers of users in virt.ual envi- ronments with dense occlusion (e.g., buildings, cities, etc.). RING takes advantage of the fact that state changes must be propagated only to hosts containing entities that can possibly perceive the change - i.e., the ones that can see it.. Object- space visibility algorithms are used to compute the region of influence for each state change, and then update messages are sent only to the small subset of workstations to which the update is relevant. The key idea is illustrated in Figure 4. Alt,hough entities A, B, C, and D (filled circles) all inhabit the same virtual environment, very little visual interaction (hat.chcd polygons) is possible due to the occlusion of walls (solid lines). In -fact, in this example, only one visual interaction is possible - entity .4 can see entity B. Therefore, only one update message must be sent for each update to entity B’s position in real-time (to the workst.abion wibh entity A). All other emities need not distribute any update messages in real-time since they are uot visible to any other entity. From this cxamplc, we see t.ll.at it is possible to greatly reduce the number of messages passed in real-time to maintain consistent state among multiple f?ntities in a densely occludecl cnvironmrnt using line-of-sight visibility to determine the region of influence for each update. Only visibk ser C sibilil:y Figure 4: A system that culls messages based on entity-cnt.ity visibility may be able to reduce t,he number of messages pro- cessed by each workstation in densely occluded environments. 86
`
`02
`
`

`

`The following section describes the RING system design. Results of experiments with the system are presented in Sec- tion 5, while a discussion of alternate approaches and possible future work appears in Section 6. Finally, Section 7 contains a brief summary and conclusion. 4 RING System Design RING represents a virtual environment as a set of indepen- dent entities each of which has a geometric description and a behavior. Some entities arc static (e.g.. terrain, buildings, etc.), whereas others have dynamic behavior that can be tither autonomous (e.g., robots) or controlled by a user via input devices (e.g., vehicles). Dist.ributed simulation occurs when multiple entities interact in a shared virtual environment by sencling messages to one another to announce updates t.o their own geometry or behavior? modifications to the shared envi- ronment, or impact on other entities. Every RING entity is ma.naged by exactly one client work- station. Clients execute the programs necessary to generate behavior for their entities. They may map user input to con- trol of particular entities and may include viewing capabilities in which the virtual environment is displayed on the client workstation screen from the point of view of one or more of its entities. In addition to managing their own entities (local en- tities), clients maintain surrogates for some cntit.ies managed by other clients (remote cntit.ics). Surrogates contain (often simplified) representations for the entity’s geometry and be- havior. When a client receives an update message for an en- tity managed by another client, it updates the geometric and behavioral models for the entity’s local surrogate. Between updat.es, surrogate behavior is simulated by every client. Communication between clients is managed by servers. C1ient.s clo not send messages directly to other c1ient.q but in- st.cad send them to servers which forward them to other client and server workstations participating in the same distributed simulation (see Figure 5). 4 key feature of this client-server design is that servers can process messages before propagating them to other workst.ations, culling, augmenting, or altering them. For instance, a server may determine that a particular update message is relevant only to a small subset of clients and then propagate the message only to those clients or their servers. In addition, a server may send clients auxiliary mes- sages that contain sta.tus information helpful for fut.ure client processing. Finally, a server may replace some set of mes- sages intended for a client with anot,her (possibly simpler) set of messages better suited to the client’s performance capabil- itics. The aim of this client-server design is to shift some of the processing burden away from the client workstations and into servers so t.hat larger, more affordable, multi-user visual simulation systems can be built using primarily low-cost client workstations. In the current implcmcntation, RIKG servers forward up- date messages in real-time only to other servers and clients managing entities that can possibly “see” the effects of the update. Server-based message culling is implemented using precomputccl line-of-sight visibi1it.y information. Prior to the multi-user simulation, the shared virtual environment is par- t.itioncd into a spatial subdivision of cells whose boundaries are coniprisccl of the static, axis-aligned polygons of the vir- tual environment [l: 151. A visibility precomputation is per- Client Client ,+ rl Figure 5: RING servers manage communication bet.ween clients, possibly culling, augmenting, or altering messages. formed in which the set of cells potentially visible to each cell is det.ermined by tracing beams of possible sight-lines through transparent cell boundaries [15, 161 (see Figure 6). During the muhi-user simulation, servers keep track of which cells contain which entities by exchanging “periodic” update mcs- sages when entities cross cell boundaries. Real-time update messages arc propagated only to servers and c1icnt.s contain- ing entities inside some cell visible to the one containing the updated entity. Since an entity’s visibility is conservatively over-estimated by the precomputccl visibility of its cont.aining ~11, this algorithm allows servers to process update messages quickly using cell visibility “look-ups” rather than more exact real-time entit.y visibility computations which would bc too expensive on currently available workstations. Figure 6: Cell-to-cell visibilit,y (stipple) is the set of cells reached by some sight-line from anywhere in the source cell (dark box) passing only through transparent portals (dash Snes) and no opaque walls (black lines). It is a useful, pre- computed overestimate of the visibility of any entity resident in the source cell. As an example of RING server operation, consider the flow of messages between clients A, B, C, and D for the entities shown in Figure 4 connected to servers in the topology sho~vn in Figure 5. Figure 7 shows the surrogates (small squares labeled by entity) and flow of update messages (arrows labeled by entity) for each of the four entities in this example. 87
`
`03
`
`

`

`. If entity A is m.odijied: client A sends an update message to server X. Server X propagates that message to server Y: but not to server Z because entities C and D are not iuside cells in the cell-to-cell visibility of the cell contain- ing entity A. Server Y forwards the message to Client B which updates its local surrogate for entity A. . Zf entity L3 is modified: client B sends an update message to server Y. Server Y then propagates that message to servers X and Z, which forward it to clients A a.nd C. Server Z does not send the update message to client D because the ccl1 containing entity D is not in the cell-to- cell visibility of the cell containing entity B. . If entity C is modified: client C sends an update message to server Z. Server Z propagates that message to server Y, which then forwards the mcssagc to Client B. Server Z does not send the message to either server X or client D because neither is managing entities in the visibility set for entity C. . If entity D is modified: client D sends an update message to server Z. Server Z does not forward the message to any other server or client because no other entiby can potentially see entity D. Client D h 1 Client A Figure 7: Flow of update messages (labeled arrows) for up- dates to entities A, B, C, and D &ranged in a virtual.cnviron- ment, as shown in Figure 4. RING servers allow each client workstation to maintain sur- rogates for only the subset of remote entities visible to at least one entity local to the client. All other remote entities are ir- relevant to the client so there is no need to waste storage space or behavioral simulation processing for them. To sup- port this feature, servers send their clients an “Add” message each time ;a remote entity enters a cell potentially visible to one of the c:lieKt’s local entities for the first time. A “Remove” message is sent. when the server determines that t.he entity has left the client’s visible region. As entities move through the environment, servers augment update messages with “Add” and “Remove” messages notifying clients that, remote entities have become relevant or irrelevant to the client’s local enti- ties. Since the system uses an unreliable network protocol, the “Add” and “Remove” messages are considered hints and need not necessarily be proccsscd by clieuts. However: t.hey al- low a client to store and simulate a small subset of the entities with little ad.ditional processing or message t.raffic. The primary advantage of the RING system design is t.hat the storage, processing, and network bandwidth rcquircments of the client workstations are not dependent on the numl:er of entities in the ent.ire distributed simulation. Client wor.ksta- tions must store, simulate, and process update messages only for the subset of entities visible to one of t.he client’s local cn- tities. In densely occluded virtual environments, visible sets tend to be constant size (e.g., how many rooms you can see looking into the hallway from your office usually does not dc- pend on the size of your building or whether your building is surrounded by a large city) ~ so the burden on individual client workstations does not grow as the entire system does. Another advantage is that high-level management of the virtual environment may be performed by servers without the involvement ,of every client. For instance, adding or removing an cntit.y to or from the virtual environment requires noti- fication of only one server. That server handles notification of ot.her servers and c1ient.s. Also, the client-server design al- lows use of e%cient networks and protocols available bet.ween server workst,ations, but not universally available t.o all client workstations. For instance, clients may connect to servers via low-bandwidth networks, while servers communicate with each other via high-bandwidth networks. The storage and processing requirements of RING servers are within practical limits. Unlike clients, servers do not have to store display data (e.g., polygons, textures, etc.). But, they must maintain spatial subdivision and visibility informa- tion for the virtual environment (typically < 20MB for large environments) and a surrogate representation for every ent,ity in the cnvironmcnt (currently 48 bytes per entity). As server storage requirements grow linearly with the total number of entibies, the size of scrvcr workstation memory may theoreti- cally limit the numbcr of entities that are able to share a. vir- tual environment, simultaneously. However, this is not likely to bc a probl,sm in pract,ice since a workstation with 6451:B of memory can accommodate nearly one million entities. Server workstation processing is also within reasonable bounds. Servers must process messages in real-time onl:y for entities visible to some entity managed by one of their cli,snts; they are not required to simulate entity behavior bct.ween up- dates; and, they do not render images of the virtual envirou- ment. As a result, the memory capacity and processing power of standard CNIX workst.ations are adequate for RING servers in densely occluded virtual environments with very large num- bers of simultaneous users. The disaclvanta.ge of the RING system design is that; ex- tra latency is, introcluccd when messages are routed through servers. Rather than sending messages directly between clients, RING routes each one through at least oue server, and possibly two. Computations arc performed in the servers before messages are propagated further adding to latency. So far, the extra latency due 60 server processing has not been noticeable during experiments. Additional work will have to be done to quantify the latency cost.s and to determine which types of entity interact,ions are sensitive to latency issues. 88
`
`04
`
`

`

`5 Experimental Results A prototype multi-user simulation system has been imple- mented with the client-server design described in the previous section. The system runs on Silicon Graphics workstations and uses UDP/IP datagrams for message passing. This sec- tion presents results of experin1ent.s with this system manag- ing many entities interacting in large densely occluded virtual environments. The virtual environments used in these ex- periments were mazes of “rooms” connected by “hallways.” They were constructed by instancing a simple floor-plan 1, 2, 4, 8, lG, and 32 times in a square tiling pattern. Each tile contained 25 rooms (counting hallways) and had 724 poly- gons (see Figure 8). The largest environment used in these tests had 23,168 polygons which formed 2,219 cells. The spa- tial subdivision and visibility information for this environment took 99 seconds to compute and required 11.2MB of storage. Figure 8: One tile of virtual environment used in tests. Experiments were run with several environment sizes and various numbers of entities, clients, and servers to charac- terize the scalabi1it.y of the system design. During these experiments, entities navigated through the virtual environ- ment “randomly” following piecewise linear paths in random- ized directions for randomized distances. Clients sent update messages only for changes in derivatives of entity position aud/or orientation (i.e., dead-reckoning) while other clients simulated intermediate positions with linear “smooth-back.” Update messages containing 40 bytes (message-type[4], entity- ID(4], target-position[12], target-orientation[12], positional- velocity[4], and rotational-velocity[4]) were generated for each entity once every 2.3 seconds on average with this “random” navigational behavior. To investigate the message processing requirements of a sin- gle client in RING, we performed tests measuring the rates of messages received by clients managing one entity navigating through virtual environments containing 64, 128, 2513, 512, and 1024 entities managed by other clients. Each test was repeated iu virtual environments containing 25, 50, 100, 200, 400, and 800 rooms. Plates I and II contain images captured during tests with 512 entities in a 400 room environment. Ta- ble 1 and Figure 9 show average rates of messages received by individual clients in each test. In Figure 9, points represent- ing the same number of total entities are conuected by lines, while points representing the same density of entities are at the same horizontal position in the plot. Ent.ities Per Room 10.24 10.24 10.24 5.12 5.12 5.12 5.12 2.56 2.56 2.56 2.56 2.56 1.28 1.28 1.28 1.28 1.28 0.64 0.64 0.64 0.64 0.32 0.32 0.32 0.16 0.16 0.08 - I - # Entities - 1024 512 256 1024 512 256 128 1024 512 256 128 64 1024 512 256 128 64 512 256 128 64 256 128 64 128 64 64 L T # II ClientWServer Rooms Ontput 100 0.44 50 0.43 25 0.47 f 200 0.55 100 0.45 50 0.44 Input - 61.37 70.43 53.68 55.93 37.37 33.20 27.26 24.56 19.88 23.19 17.42 13.65 11.35 14.18 13.28 12.08 8.39 4.62 6.57 6.41 5.37 3.18 3.20 3.35 1.91 1.68 0.52 Table 1: Average message processing rates (messa.ges per sec- ond) measured in a single client (managing one entity) during experiments with 64, 128, 256, 512, and 1024 entities in virtual environments with 25, 50, 100, 200, 400, and 800 “rooms.” 80 , I u 7o g 60 cz 50 2 4 6 8 10 Entities per Room Figure 9: Average rat.c of messages sent to a single client (managing one entit,y) during tests with 64, 128, 256, 512, and 1024 entities interacting in virtual environments with 25, 50, 100, 200, 400, and 800 “rooms.” Horizontal axis represents the density of entities in the environment. 89
`
`05
`
`

`

`From the grouping of points in the plot, WC see that the rate of messages received by a single client is dependent more on the density of entit,ies in t.hc virtual environment than the t.otal number of entities. This is because each client has a relatively constant sized region of interest (its visible region) which is independent of the total size of the environment or the total number of entities inhabiting it. During the test with 1024 ‘entities simultaneously navigating through an 800 room environment each client processed only 11.35 messages (4360 bits) per second on average (row 13 of Table 1). This was approximately 2.5% of the 450 messages per second that would have been processed by each client in a system without visibility-based culling - a 40x decrease. To characterize the message processing requirements of a single server in RING, we performed tests with various num- bers of server:: managing communication for 16 clients and 256 eutities distributed evenly across the clients and servers in a virtua! environment. with 800 rooms. Table 2 lists aver- age server-+client, serverttservcr, and total message rates for a single server during t.ests with 1, 2, 4, 8, and 16 servers. Fig- ure 10 shows a plot of total message rates per server measured during each of these tests. Server+tServer Total Input 1 output Input 1 output 0.0 I 0.0 107.1 1 634.1 u 16 /I 6.7 1 81.5 11 85.6 1 120.9 39.4 11 78.9 1 Table 2: .4..rerage message processing rates (messages per sec- ond) measured in a single server during tests with 1, 2, 4, 8, and 16 servers managing communication for 16 clients and 256 entities distributed evenly across the clients and servers in a virt.ual environment with 800 rooms. -0 600 ‘\ s x / ” ,, Output Messages 500 !: 8 3 0 0 . ~‘-y 2 ‘~ ‘...__ ii 200 . -...._ -..___ r” 100 . - Input Messages -------~---.-. . ..__._...__..__.___~~~~~ 01 I 0 2 4 6 8 10 12 14 16 Number of Servers Figure 10: .Average rates of messages sent to (input) and from (out,put) a single server during tests with 1, 2, 4, 8, and 16 servers managing communication for 16 clients and 256 en- tities distributed evenly across the clients and servers in a virtual environment with 800 rooms. As the number of servers increases, the total number of messages input and output by a single server decreases. This phenomenon is aided by the fa.ct that update messages are propa.ga.ted ouly to servers attached to clients with ent:.ties that can potentially see the updated enbity. In the t,est with 16 servers, 74% of the real-time serverHserver messages are cullccl due to visibility (i.e., the 16 entities managed by each of the 16 servers cumulatively see 26% of the environment). These results are encouraging since visibility-b,ased message culling becomes more effective as the number of servers in- creases and less of the model becomes relevant to each server. From these results, we conclude that it is possible to build large multi-user visual simulation systems using a client-server design. We have found that server-based message processing algorithms which cull messages based on the three dimensional geometry of the virtual environment can be effective at reduc- ing the network traffic into client workstations. As a result, for sufficiently occluded virtual environment.s, it is possible to build la.rge, affordable multi-user virtual environments using inexpensive client workstations with low-bandwidt,h network connections, while higher performance workstations are re- quired only for the relatively few servers. 6 Discussion Several alternate approaches and future extensions are possi- ble for this system. Multicast In our first experiments with multi-user virtual environments, we used IF’ multicast. to send upda.tc messages directly be- tween clients. The general iclea is to map entity properties into multicast groups, and seud update messages only to relevant groups [6]. F,or instance, Macedonia [12] partitions a virt.ual world into a 2D grid of hexagonal shaped cells each of which is represented by a separate multicast group. Entities localize their visual interactions by sending updates only to the muhi- cast group representing the cell in which they reside, and .;hey listen only to multicast groups representing cells within some radius. The multicast approach is similar to the RING client-server approach for wide-area networks. In both cases, intermediate machines may cull messages rather than propagating them to a.11 participating workst.ations. However, using multicast, mcs- sage culling is done by routers at the network layer? whereas, in RING, me.ssage culling is done by server machines at the applicat.ion layer (see Figure 11). The advantages of the ~nul- ticast approach are that: 1) fewer messages must be passed if clients are connected directly to a multicnst-capable LAN (e.g., ethernet), and 2) latency is reduced due to faster mes- sage routing. The disadvantages are that: 1) delays associated with joining and leaving multicast groups make it impractical to use highly dynamic entity properties for multicast. group mappings, 2) the number of unique multicast groups accessi- ble to any one application may not be sufficient for complex virtual environments, and 3) multicast is not generally avail- able across wide-area networks to many t,ypes of networked computers (e.g., PCs with modems). The advamage of the RING client-server approach is that very dynamic and complex message processing may be per- 90
`
`06
`
`

`

`Figure 11: RING servers process messages in the application layer using 3D model and semamic information. Multicast routers use only IP addressing in the network layer. formed by servers. In contrast to multicast routers, which can only cull messages based on a relatively small, static set of multicnst groups, RING servers can cull messages using high- level geometric algorithms and knowledge regarding a multi- plicit,y of highly dynamic entity at,tributes (e.g., location, ori- entation, velocity, etc.) and interaction types (e.g., visibility, sound, collision, etc.). Since RING servers can take advantage of knowledge regarding message semantics and the 3D geome- try of the virtual environment directly, they can execute more effective and flexible culling algorithms than would be possi- ble using only IP address and port ma.ppings. Furthermore, unlike multicast routers, RING servers may process, augment, and alter messages in addition to culling them. For instance, RING servers already augment update messages with “Add” and “R.emove” messages to inform clients that entities are en- tering or leaving their potentially visible sets. Server Topology We have experimented with a variety of topologies for con- necting RING clients and servers. For practical reasons, we have focused mainly on arrangements in which clients com- municate with a single server. However, depending on the ca- pabilities of available workstations and networks, clients can send messages to server(s) via unicast or multicast. Clients can choose server(s) to manage their messages statically (i.e., all of a client’s messages are sent to the same server(s)) or dynamically (e.g., based on the position of the updated en- tity). Servers have similar choices for distribution of messages among themselves, but can also be arranged in a hierarchy in which some servers manage communication between others. Perhaps the most promising topologies are those in which servers manage communication between entities in separate regions of the virtual environment. For instance, we have im- plemented protocols with which entities migrate to a server managing the region of the environment containing the cen- troid of its enclosing cell. The advantage of this approach is that server-server communication is greatly reduced if there is relatively little inter-visibility between regions. Ill such cases, most real-time updates affect only entities managed by the same server, and periodic updates must be passed only to servers whose region is visible to the updated ent.ity. In early experiments, more than 95% of server-server messages are eliminated with regional servers. Further work is requirccl to fully investigate the trade-offs between regional and other types of client-server t.opologies. Multiresolution Simulation An extension to RING currently being investigated is to use multiresolution simulation to reduce network traffic and client behavioral simulation processing. One idea is to allow RING servers to process sequences of messages and eliclc updates based on the perceptible importance t.o each client’s entit.ies. For example, consider the situation shown iu Figure 12. Al- though A can see bot.11 B and E, B is closer to A. Thus~ up- dates to B may be more important to A than updates to E, and could be sent to A at a finer resolution. 111 fact, E may be far enough away that small updates are impercept.ible to A, so they can bc elided completely. More geuerally, RING servers can alter any sequence of update messages for any en- tity dynamically to meet the perceptible quality required by each client. Finally, time critical computing algorithms can bc used to determine an “optimal” set of messages t,o send to each client based on network connection bandwidths, workst,ation processing capabilities, and many other real-time performance factors (i.e., in a manner similar to that used iu [8]). Update B in A fine resolutio Update E in A coarse resoluti Figure 13: RING Servers may propagate sequences of update messages to client A at finer