Networked Virtual Environments

8/4/2019 Networked Virtual Environments

1/139

Networked Virtual

Environments

Helmuth Trefftz

[email protected] University - Medelln, Colombia


2/139


3/139

Helmuth Trefftz

Associate Professor at Eafit University,Medelln, Colombia.

Director of Virtual Reality lab at Eafit.

Involved in NVEs since 1996.

Ph.D. in Computer Engineering in 2001

(Rutgers University, NJ). Ph.D. thesis: Heterogeneity in Virtual

Environments.


4/139

Agenda

Introduction (15)

History (10)

Networking Concepts (25)

Architectures (20) Shared State (45)

Scalability and Performance (45)

Research Topics (30) Toy application (30)

Summary and Conclusions (10)


5/139

Introduction

Why Networked Virtual Environments?

1. Technology is here: Powerful commodity 3D graphics accelerators on

every PC. Internet is almost everywhere (wired or wire-less).

2. Need for applications is here: Multiplayer games

Military combat training Design teams across continents


6/139

Introduction

What is a NetworkedVirtual Environment? A Networked Virtual

Environment is asoftware system inwhich multiple usersinteract with eachother in real-time,even though thoseusers may be locatedaround the world[Singhal/Zyda 1999]

http://www.crg.cs.nott.ac.uk/research/systems


7/139

Introduction

Collaborative Virtual Environments

(CVEs) are online digital places andspaces where we can be in touch, play

together and work together, even when weare, geographically speaking, worldsapart In CVEs we can share the

experience of worlds beyond the physical[Churchill/Snowdon/Munro 2001]


8/139

Introduction

Key elements:

A shared sense of space (common virtualspace)

A shared sense of presence (avatars)

A shared sense of time (real-time)

A way to communicate (text, voice,)

A way to interact (among users and with thevirtual world)

TELEPRESENCE


9/139

Introduction

Key components

Graphic engines and displays

Control devices (keyboardtrackers)

Processing Systems

Data Network


10/139

Introduction

CommonVirtual World


11/139

Current challenges

Network Bandwidth/Latency

Heterogeneity

Distributed Interaction (real-time) Resource Management - Scalability


12/139

History - Military

SIMNET (Simulator networking)[Miller/Thorpe95]

Distributed military environment developed forDARPA between 1983 and 1990.

Aimed at:

Building high-quality, low cost simulators

How to network the simulators together.

Created 11 sites with 50 - 100 simulator each.


13/139

History - SIMNET


14/139

History - Military

SIMNET Architecture

Object-event architecture

Autonomous nodes (each entity is responsiblefor informing its state to others)

Dead Reckoning

Average messages:

Slow moving vehicles: 1mess/sec.

Fast moving vehicles: 3mess/sec.


15/139

History - Military

SIMNET Modules

Network Interface

Other-vehicle state table

Controls

Own-vehicle dynamics

Sound generation


16/139

History - Military

SIMNET

Multicast groups: each exercise is assigned amulticast address.

Multiple exercises can co-exist

Scalability

Exercise in March 1990:

850 objects

5 sites

Network: T-1


17/139

History - Military

DIS (Distributed Interactive Simulation) [IEEE93] Started in 1989 as an effort to document the comm.

protocol of SIMNET.

Became an IEEE Standard 1278.

Definition of 27 PDUs (Protocol Data Unit).Examples: Entity State: position, orientation, velocity changes.

Fire

Detonation Collision

Each 5 seconds: a heart-beat state PDU.


18/139

History - Military

DIS - Traffic:

96% Entity State PDUs

Rest:

Fire

Detonation

Collision

Others


19/139

History - Military

DIS - Scalability

Designed for 300-500 users


20/139

History - Military

DIS - Fully distributed and Heterogeneous

Each machine that can read/write DIS PDUSand manages the state, can participate.

Heterogeneity can pose problems.

Slow machines can fall behind processingmessages from fast machines.

Inconsistencies!


21/139

History - Games

SGI Flight

Flight simulator demo program used from1984 to 1992.

Created in 1983.

Networked version shown in SIGGRAPH1984.


22/139

History - SGI Flight

http://www.berkelium.com/OpenGL/readme.html

Download source code from:


23/139

History - Games

Doom [idSoftware]

Released in December 1993.

Initial version: no dead-reckoning, messages

at frame-rate.

10s of millions of downloads.

Source code was available.


24/139

History - Doom


25/139

History - Academia

NPSNET [NPSNET]

The longest continuing academic research

effort in networked virtual environments

[Singhal/Zyda 1999] Focus on software technology for

implementing large-scale virtual environments(LSVE).


26/139

History - Academia

Courtesy of Naval Postgraduate School.


27/139

History - Academia

NPSNET

Contracted initially to handle SIMNET terrain.

Afterwards, improvements on protocols:

Protocol for Lans only

Bridges for Lans and Wans

Implementation of IP Multicast for Wans

vrtp proposal.


28/139

History

DIVE (Distributed Interactive VirtualEnvironment) [Hagsand96] [DIVE] Built at the Swedish institute of Computer

Science. World Database:

Distributed

Fully Replicated

New objects can be added/modified in aRELIABLE fashion.

Distributed lock mechanism.


29/139

History - DIVE


30/139

History - DIVE


31/139

History - DIVE


32/139

History - DIVE

Videos


33/139

History

DIVE

Because of the reliable multicastimplementation they use, DIVE does not scale

well beyond 32 participants. DIVE 3 uses a basic communications library

based on IP multicast and Scalable ReliableMulticast (SRM).


34/139

History

MR - TPP Minimal Reality Toolkit PeerPackage [Shaw/Green93]

MR-TTP is based on UDP (unreliable). Lost

packages are ignored.

Instead of heartbeat: sends packages at therate of the input device.

Topology: Complete Graph Connection. Number of users: 4 or less.


35/139

History

MASSIVE-1[MASSIVE][Greenhalgh/Benford9

5]

Developed atNottinhamUniversitys CRG

(Computer Research

Group), led by SteveBendford and ChrisGreenhalgh.


36/139

History

MASSIVE-1 Multi-user distributed V.R. system

Runs on Sun and SGI platforms

Textual, graphical and audio client programs Interaction controlled by aura, focus and

nimbus

Connection oriented networking

Scalability: MASSIVE usually works with upto about 10 users (from Massive-1 homepage).


37/139

History - MASSIVE

Video


38/139

History

MASSIVE 2 and 3

Scalability and Distribution based on Locales

Current networking via TCP client-server style

(to be combined with multicast)

The agent that creates an environment actsas distribution server for that environment

Persistency Management of audio links.


39/139

History

Summary

A number of successful Networked VEs hasbeen created:

Military

Gaming

Research

Differ greatly: What can the users do.

Technological decisions.


40/139

Networking Concepts

Latency

Amount of time to transfer a bit of data fromone point to another.

Latency has a direct impact on interactioninside the virtual world.

The designer cannot really reducelatency. It

is possible to hideit or reduce its impact.


41/139

Networking Concepts

Latency - causes:

Physical limitations: speed of electromagneticwaves in the transmission material (aprox.

8.25 msec per time zone). Delays introduced by the endpoint computers.

Delays introduced by the network itself

(routers).


42/139

Networking Concepts

Bandwidth

Rate at which the network can deliver data tothe destination host.

Examples: Modem: 56Kbits per second.

Ethernet: 10 or 100 Mbits per second.

Fiber-optic: 10 Gbps or more.


43/139

Networking Concepts

Reliability

How much data is lost by the network andhow that loss is handled.

Causes: Routers discard some of the messages (up to 50%

in some cases).

Data gets lost in the communication media.


44/139

Networking Concepts

Reliability - How to handle data that islost?

Detect/Correct: Error-correcting codes.

Detect: ACKS, NACKS.


45/139

Networking Concepts

TCP: Point-to-point connection to anapplication running in another machine.

Data Checksum for integrity.

Flow-control: to avoid flooding ofmessages, including acknowledgements.

Keeps strict ordering and consistency ofpackages. Is this necessary in NVEs?


46/139

Networking Concepts

UDP: Lightweight protocol.

Differences with TCP:

Connectionless transmission. Informationabout the state of the connection is not kept.

Best-effort delivery. No guarantee of deliveryor order of messages.

Each packet is auto-contained.


47/139

Networking Concepts

UPD Advantages:

No overhead for connection orientedsemantics.

Packages can be transmitted/receivedimmediately, no need for queues.

It is possible to send information to groupsof

users (multicasting).


48/139

Networking Concepts

Unicast

One computer sends information to onlyanother one computer.


49/139

Networking Concepts

Broadcast

One computer sends information to everycomputer in a subnet.


50/139

Networking Concepts

Multicast

Only computers listening to a specificmulticast groupreceive the message.


51/139

Networking Concepts

Multicast: Similar to distribution ofnewspapers:

Subscribers explicitly request the newspaper.

Duplicate copies are not sent down the samedistribution tree.

The publisher does not need to know the

subscribers.


52/139

Networking Concepts

Mulsticast is emerging as therecommended way to build large-scaleNVEs.

BUT many routers do not handle multicastmessages still.


53/139

Networking Concepts

TCPSmall number of users

Limited data requirements

Typically client-serverconfiguration

UDP Higher data requirementsUsed both in client-server andpeer-to-peer configurations.

IP Broadcasting Small peer-to-peer Net VEs with

high data requirements and timesensitive delivery.

IP Multicasting Large peer-to-peer NetVEs, becareful with routers.


54/139

Networking Concepts

Summary

Available networking infrastructure is a veryimportant factor when designing a NetVE.

Networking-related decisions have a bigimpact on:

Complexity of implementation

Overall performance

Scalability


55/139

Architectures

Client-Server Systems

logical architecture

Server

Client 1 Client 2 Client n

A hi


56/139

Architectures


physical architecture with phone lines

Server


Phone Line Phone Line Phone Line

A hi


57/139

Architectures


physical architecture on a LAN


Server

A hi


58/139

Architectures


The Server can become a bottleneck.

What are the advantages? The servercan decide::

Which clients should receive a message.

What protocol to use with different clients.

Sub-sample messages to slow users.

Keep statistics.

...

A hi


59/139

Architectures

Multiple-Server Architectures

Server 1



Server 2

A hit t


60/139

Architectures

Multiple-Server Architectures

Several servers have the followingadvantages:

System scales better. Communication between clients attached to

different servers takes longer.

Key issue: how to assign clients to servers?

A hit t


61/139

Architectures

Peer-to-peer

NETWORK

Client 1

Client 2

Client n

A hit t


62/139

Architectures

Peer-to-peer

Network will be:

Broadcast

One or multiple multicast groups.

In the case of multicast groups:

Area of Interest Management: assign differentusers to different multicast groups, based on some

criteria.

A hit t


63/139

Architectures

How many participants can co-exist in avirtual world?

From a Network infrastructure point of

view: Infinite compute power at each node

Network does not saturate

Packet size: 144 bytes

PDUs per second: 5 - 30

A hit t


64/139

Architectures [Dawson98]

Technology Speed(Kbps)

Min #players

Max #players

Modem 56 1 6

DSL 1500 39 163

T-1 1500 39 163

10BT 10,000 263 1085

100BT 100,000 2630 10851

Sh d St t


65/139

Shared State

Main idea in a NVE:

Provide users with the illusion that everyparticipant is seeing the same things and

interacting with each other.

Things in the NVE change.

Without dynamic shared state, the illusionof sharing space and time breaks.

Sh d St t


66/139

Shared State

Definition of the problem - Theconsistency-throughput tradeoff

It is impossible to allow dynamic

shared state to change frequentlyand guarantee that all hostsimultaneously access identicalversions of that state. [Singha/Zyda1999]

Shared State


67/139

Shared State

Absolute consistency:

Wait until everybody acknowledges before moving toa new position.

Considering latency and available bandwidth, thismay imply slowing down too much.

Frequent updates:

Users send the updates and move on.

But: some users will receive the updates quickly andothers wont.

Inconsistent views!

Shared State


68/139

Shared State

Centralized Repositories - File Repository

For pedagogical purpose:

One file per entity

Each update:

Open File

Read/Updat

Close File

User 1

User 2

User n

Shared State


69/139

Shared State

Centralized Repositories - File Repository

Advantage:

absolute consistency.

Avoids concurrency problems. Locks on objects easily implemented (when are

locks necessary?)

Problems:

SLOW!

Shared State


70/139

Shared State

Centralized Repositories - Repository inServer Memory

Entry in memory per entity.

Users need to acquire a lock.

User 1

User 2

User n

Shared State


71/139

Shared State

Centralized Repositories - Repository inServer Memory

Advantages

Fast!

Disadvantages

No persistency.

What happens if server crashes?

Shared State


72/139

Shared State

Distributed Repositories - VirtualRepository

Different clients manage different parts of the

world. Clients have a local cache of used objects.

Shared State


73/139

Shared State

Distributed Repositories - VirtualRepository

Advantages:

No bottleneck

Disadvantages:

Complex to program.

Shared State


74/139

Shared State

Frequent State Regeneration

Is absolute consistency alwaysnecessary?

When is it NOT necessary?

Shared State


75/139

Shared State


For instance in a group flight simulatorprogram:

A temporal inaccuracy in the position ofanother plane is not too serious.

Example: if updates are sent every 40milliseconds, one lost package is almostimperceptible.

Shared State


76/139

Shared State


Producer

Broadcast location of local objects

Either when they move or at a fixed rate.

Consumers (other participants)

Draw the scene using the locations in the localcache.

Update the local cache with the remote events.

Shared State


77/139

Shared State


Producers and consumers are decoupled.

All interactions can be decoupled?

Independent movements: YES.

Tight-collaborative tasks: NO.

Slow cycles Fast cycles

Shared State


78/139

Shared State

Situation 1:

A slow computer controls a plane moving in astraight line.

A participant in a fast computer perceives ajumpy movement.

Situation 2:

A fast computer floods a slow computer withmessages of a car moving in a straight line.

Shared State


79/139

Shared State

Issue 1 (slow updates - Fast computer sees jumpiness)

Issue 2 (fast updates - Slow computer overwhelmed)

Shared State


80/139

Shared State

Solution to alleviate both issues:

DEAD RECKONING.

Instead of sending updates at frame rate,

Send parameters that describe the trajectory ofthe object (example: initial position and velocity)

Each participant displays the trajectory at its ownrate.

Shared State


81/139

Shared State

Advantages:

Accommodates heterogeneity.

Bandwidth usage is reduced.

Cost:

More cycles to compute trajectory at eachnode.

Need to re-synchronize.

Shared State


82/139

Shared State

Dead Reckoning - Two parts:

Prediction

Predict where the object is based on the received

parameters. Convergence

Once an actual position is received: how to movethe object from the predicted to the actual position.

Shared State


83/139

Shared State

Prediction Algorithms

Derivative Polynomials:

Order one:

Order two:

Part of DIS protocol.

tvelpospos *01

2

01 *2

1

* tacctvelpospos

Shared State


84/139

Shared State

Other predictionalgorithms:

Circles

Spirals

Planes seem to followmany such curves.

Shared State


85/139

Shared State

Other strategy: Send an update when the actual position is

verydifferent from the predicted position.

Advantage: the errorin the system is keptunder certain threshold.

See paper by C. Faistnauer in IEEE VR 2000.

Shared State


86/139

Shared State

Convergence Algorithms

Predicted Position

Current Position

Last actual position

ConvergencePosition

Shared State


87/139

Shared State

Convergence Algorithms

Snap: Just move the object to the mostrecent actual position.

Linear: Linearly interpolate to a point in thenew predicted path (convergence point).

Cubic Spline: Create a path in the form of

a cubic spline from the current position tothe convergence point.

Scalability and Performance


88/139


Improve the size and performance of aNet-VE by reducing network bandwidthand processor resources.

Less bandwidthrequirements means moreusers in the network.

Less processorrequirements means freecycles for other purposes (bettergraphics,) and more heterogeneousparticipants.



89/139


Required resources are a function of: Number of transmittedmessages

Average number of destinationhosts per

messsage Bandwidthrequired per message

Timeliness(minimal delays)

Processor cyclesneeded to process eachmessage.



90/139


A reduction in any of these items is a gain.

BUTusually a reduction in one means apenalty in another.

Example:

Dead Reckoningreduces required bandwidthbut more processor cycles are required.



91/139


Compression & Aggregation

Compression:

Aims at reducing bandwidth utilization byreducing the size of the messages.

Internal: encode in a more efficient manner.

External: Avoid retransmitting information thatis identical to previous packages.



92/139


Compression Example:

Send Snapshots at periodic rates.

Send updates to the snapshots.

Snapshots sent over reliable protocol.

Updates sent over unreliable protocol.



93/139


Packet Aggregation Aims at reducing the numberof packets by

merging several packets together.

The saving comes from the headers (25 bytesfor UDP and 40 bytes for TCP).

Which packets can be merged?

Packages from all entities managed by the node(at the client).

Packages from several clients (at the host).



94/139


Which packages to merge? Based on a timeout(send a message every

timeoutunits of time).

Based on quorum(send a message onlywhen the quorum has been reached).

Combination of the previous two.



95/139


Aggregation Servers Define servers that aggregate messages for

sets of entities having common

characteristics: Virtual World Location.

Entity type.



96/139


General model: Each node has an Aura, or area of influence.

Each node has a Nimbus, or a type of entities

from which to receive data.

Source

Dest1

Dest2Aura

Nimbus 1

Nimbus 2



97/139


An event is only send from the source tothe destination if the sources aura

intersects the destinations nimbus.

In Massive-1 unicast, peer-to-peer,unreliable protocols are used to sendevents from the sender to the destination.

This does not scale very well.



98/139


Multicast Key question: how to map groups of users to

multicast groups. Approaches:

Group-per-Entity Group-per-Region



99/139


Group-per-Entity [Abrams/Watsen/Zyda98].

There is a multicast group per entity.

Each node subscribes to multicast groups of

entities in its nimbus. A directory serveris necessary to inform nodes

about the position and multicast groups of otherentities.

Problem: The number of multicast groups growsrapidly.



100/139


Group-per-region The virtual world is partitioned into cells. Each

cell is assigned a multicast group.

Users subscribe/unsubscribe from multicastgroups as they travel.

As a user approaches a region, it needs tosubscribe to the neighbor cells. Hexagonalcells are an advantage.



101/139


Level of Detail perception

Objects that are very far away will:

Appear smaller

Probably not be the focus of attention.

Therefore:

Can be updated less frequently.



102/139


Need for multiple channels.

Different channels have differentresolution (update frequencies, spacial

granularity, etc) Who handles the channels?

A server

Each client

Research Topics


103/139

esea c op cs

Multimedia Incorporating audio/video live streams to

NVEs

Questions: What to display

Where to display it

A single rate or multiple rates?

Research Topics - Multimedia


104/139

s a p s a

FreeWalk [Nakanishi96]. Mapped a picture of the user in the front face of a

pyramid (avatar).

Users can move freely and establish voice

conversations. The volume depends on the distance and mutual

orientation.

A community serverinforms users about positionsand orientation of other users.

Actual voice messages and pictures are exchangedamong users.

Research Topics


105/139

p

FreeWalk



106/139

p

Awareness-Driven Video QOS [Reynard98]

Three different QOS levels are established:

Porthole: 1 update every 5 minutes. At the top ofthe virtual office.

Glance: 1 frame/sec. At the front of the office.

Communications: 20 frames/sec. On top of users

avatar.



107/139

p

Awareness-DrivenVideo QOS

Research Topics - Architectures


108/139

p

Hierarchy of Servers [Funkhouser95] Compared Static Allocation of clients to

servers vs. Dynamic Allocation (a server per

room). The number of server-to-server messages

was reduced.



109/139

p

Courtesy of T. Funkhouserhttp://www.cs.princeton.edu/funk/ring.html



110/139

p

Dynamic partitioning of space[Restrepo03]

Partition the space dynamically as the

users move in the world. Assign one partition to each server.

If a space becomes to crowded, split in a

quadtree fashion.

Load among servers was better balanced.



111/139

p

Courtesy if the Eafit University.

Research Topics -


112/139

pHeterogeneity

How to accommodate heterogeneous nodes in aNetVE [Trefftz03] The system handles multiple variables:

Display Rate

Frequency of remote updates Frequency of video updates

The user can specify her preferences. The System Administrator can define minimum

levels The system optimizes the function and definesfidelity levels for each client.

Research Topics - Heterogeneity


113/139

Proof-of-conceptapplication:

Research Topics - Heterogeneity


114/139

The Switchboardarchitecture

Research Topics - Collaborative


115/139

AR

Two or more users collaborating in areality augmented with virtual objects.

See Studio3D by Vienna University.

What happens if the users are in differentphysical locations?

Research Topics


116/139

p

What are the big players doing? Mike Zyda (NPS):

Very successful army game.

Agents in VEs.

Defense-Entertainment cooperation for Training.

Greenhalgh/Benford (Nottingham)

Heterogeneity

Wireless

Steve Feiner IEEE VR 2003: Merge of VR and wireless technologies.

Research Topics


117/139

Americas Army

From Americas Armys home page.

Commercial Systems


118/139

ActiveWorlds Commercial system.

Free sessions for guests.

Used for: Education

Social interaction of groups

Provide avatars and connected virtual locales Communication: chat tool.

Toy Application (cubes)


119/139

Demonstration Will be downloadable from:

http://arcadia.eafit.edu.co/CGIMtutorial/

Toy Application
http://arcadia.eafit.edu.co/CGIMtutorial/http://arcadia.eafit.edu.co/CGIMtutorial/


120/139

Packages - Client Application

Toy Application


121/139

Packages - Server Application Jus the Server Package.


122/139

Toy Application - server


123/139

Toy Application - send


124/139

Toy Application - receive


125/139

Toy Application - replicate


126/139

Toy Application - Documentation


127/139

JavaDoc Documentation of classes, methods and

atributes. Created by Java.

UML Poseidon UML

SourceCode

JBuilder Personal Edition project.

Toy Application


128/139

Changes you can do: Use UDP instead of TCP - Compare

performance.

Add audio-video streaming (JMF) Make it peer-to-peer - Compare performance.

Try the techniques for scalability defined inthe tutorial.

Use a VRML loader to import prettiergeometry.

Toy Application


129/139

Test your own ideas!

Conferences


130/139

IEEE Virtual Reality (formerly IEEEVRAIS)

ACM VRST (Virtual Reality Software and

Technology). ACM CVE (Collaborative VirtualEnvironments). (every two years).

ACM CSCW (Computer SupportedCollaborative Work).

IASTED CGIM.

Journals


131/139

PRESENCE. MIT Press. In General networking or Human-

Computer Interaction Journals have more

and more articles on NVEs.

Summary and Conclusions


132/139

New field. Technology is here.

The need & interest are growing.

Many areas to be explored.

Any idea for your own research? I will behappy to discuss.

Enjoy!


133/139

Thank you!

Bibliography - BOOKS


134/139

[Singhal/Zyda 1999] Singhal, S. and Zyda,M. Networked Virtual Environments:Design and Implementation. Addison-Wesley.1999.

[Churchill/Snowdon/Munro 2001]Churchill,E., Snowdon, D. and Munro, A.Collaborative Virtual Enironments. Digital

Places and Spaces for Interaction.Springer Verlag. 2001.

Bibliography - Papers and Articles


135/139

[Abrams/Wasten/Zyda98] Abrams, H., Waksen, K. andZyda M. Three tiered interest management for large-scale virtual environments. In Proceedings of VRST1998. Taipei, Taiwan, November 1998.

[Dawson98] Dawson, F. XDSL market blooming.Interactive Week5(39):28-29. October, 1998.

[Funkhouser96] Funkhouser, T. Network Topologies forScalable Multi-User Environments. In Proceedings of

IEEEVRAIS. 1996.



136/139

[Greenhalgh/Benford95] Greenhalgh, C.,Benford, S. Massive: a Virtual Reality Systemfor Teleconferencing. ACM Transaction onComputer Human Interfaces. 2(3):239-261.

[Hagsand96] Hagsand, O. Interactive multiuser VEs inthe DIVE system. IEEE Multimedia3(1):30-39, 1996.

[IEEE93] IEEE standard for information technology /protocols for distributed simulation applications. IEEEStandard 1278-1993. IEEE Computer Society, 1993.

[Macedonia95] Macedonia, M., Zyda, M., Pratt, D. and Barham, P.Exploiting reality with multicast groups: A network architecture forlarge-scale virtual environments. In Proceedings of IEEE VRAIS.1995.



137/139

[Miller/Thorpe95] Miler, D., Thorpe J.A. SIMNET: The advent of SimulatorNetworking. In Proceedings of the IEEE83(8):1114-1123, August 1995.

[Nakanishi96] Nakanishi, H., Yoshida, C., Nishimura, T. and Ishida, T.FreeWalk: Supporting Casual Meetings in a Network. InProceedings of ACM CSCW. 1996.

[Restrepo03] Restrepo A., Montoya, A. and Trefftz H. Dynamic

Server Allocation in Virtual Environments using QuadTrees forSpace Partitioning. In Proceedings of IASTED Computer Scienceand Technology, Cancun, Mexico, 2003.

[Reynard98] Reynard, G., Benford, S., Greenhalgh, C. & Heath, C.Awareness Driven Video Quality of Service in Collaborative VirtualEnvironments. In Proceedings of ACM CHI98.



138/139

[Shaw/Green93] Shaw, C. Green, M. TheMR toolkit peers package and experiment.In Proceedings of the 1993 IEEE VirtualRealityAnnual International Symposium,463/469. Seattle, September 1993.

[Trefftz03] Trefftz, H., Marsic, I. and ZydaM. Handling Heterogeneity in Networked

Virtual Environments. In Presence12(1)37. February 2003.

Bibliography - Web Pages


139/139

[DIVE] DIVE home page http://www.sics.se/dce/dive/ [idSoftware] idSoftware home page

http://www.idsoftware.com/

[MASSIVE-3] MASSIVE home page

http://www.crg.cs.nott.ac.uk/research/systems/MASSIVE-3/

[NPSNET] NPSNET home pagehttp://www.npsnet.org/~npsnet/

Toy application: http://arcadia.eafit.edu.co/CGIMtutorial/
http://www.sics.se/dce/dive/http://www.idsoftware.com/http://www.crg.cs.nott.ac.uk/research/systems/MASSIVE-3/http://www.crg.cs.nott.ac.uk/research/systems/MASSIVE-3/http://www.npsnet.org/~npsnet/http://arcadia.eafit.edu.co/CGIMtutorial/http://arcadia.eafit.edu.co/CGIMtutorial/http://www.npsnet.org/~npsnet/http://www.crg.cs.nott.ac.uk/research/systems/MASSIVE-3/http://www.crg.cs.nott.ac.uk/research/systems/MASSIVE-3/http://www.crg.cs.nott.ac.uk/research/systems/MASSIVE-3/http://www.idsoftware.com/http://www.sics.se/dce/dive/

Networked Virtual Environments

Documents

Transcript of Networked Virtual Environments