Networked Virtual Environments

1
Networked Virtual Environments

• Helmuth Trefftz
• htrefftz_at_eafit.edu.co
• Eafit University - Medellín, Colombia

2
Introduction

• Why are you here?

3
Helmuth Trefftz

• Associate Professor at Eafit University,
  Medellín, 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
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
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
Introduction

• What is a Networked Virtual Environment?
• A Networked Virtual Environment is a software
  system in which multiple users interact with each
  other in real-time, even though those users may
  be located around the world Singhal/Zyda 1999

http//www.crg.cs.nott.ac.uk/research/systems
7
Introduction

• Collaborative Virtual Environments (CVEs) are
  online digital places and spaces where we can be
  in touch, play together and work together, even
  when we are, geographically speaking, worlds
  apart In CVEs we can share the experience of
  worlds beyond the physical Churchill/Snowdon/Mun
  ro 2001

8
Introduction

• Key elements
• A shared sense of space (common virtual space)
• 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 the
  virtual world)
• TELEPRESENCE

9
Introduction

• Key components
• Graphic engines and displays
• Control devices (keyboardtrackers)
• Processing Systems
• Data Network

10
Introduction
Common Virtual World
11
Current challenges

• Network Bandwidth/Latency
• Heterogeneity
• Distributed Interaction (real-time)
• Resource Management - Scalability

12
History - Military

• SIMNET (Simulator networking)Miller/Thorpe95
• Distributed military environment developed for
  DARPA 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
History - SIMNET
14
History - Military

• SIMNET Architecture
• Object-event architecture
• Autonomous nodes (each entity is responsible for
  informing its state to others)
• Dead Reckoning
• Average messages
• Slow moving vehicles 1mess/sec.
• Fast moving vehicles 3mess/sec.

15
History - Military

• SIMNET Modules
• Network Interface
• Other-vehicle state table
• Controls
• Own-vehicle dynamics
• Sound generation

16
History - Military

• SIMNET
• Multicast groups each exercise is assigned a
  multicast address.
• Multiple exercises can co-exist
• Scalability
• Exercise in March 1990
• 850 objects
• 5 sites
• Network T-1

17
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
History - Military

• DIS - Traffic
• 96 Entity State PDUs
• Rest
• Fire
• Detonation
• Collision
• Others

19
History - Military

• DIS - Scalability
• Designed for 300-500 users

20
History - Military

• DIS - Fully distributed and Heterogeneous
• Each machine that can read/write DIS PDUS and
  manages the state, can participate.
• Heterogeneity can pose problems.
• Slow machines can fall behind processing messages
  from fast machines.
• Inconsistencies!

21
History - Games

• SGI Flight
• Flight simulator demo program used from 1984 to
  1992.
• Created in 1983.
• Networked version shown in SIGGRAPH 1984.

22
History - SGI Flight
Download source code from
http//www.berkelium.com/OpenGL/readme.html
23
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
History - Doom
25
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
History - Academia
Courtesy of Naval Postgraduate School.
27
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
History

• DIVE (Distributed Interactive Virtual
  Environment) Hagsand96 DIVE
• Built at the Swedish institute of Computer
  Science.
• World Database
• Distributed
• Fully Replicated
• New objects can be added/modified in a RELIABLE
  fashion.
• Distributed lock mechanism.

29
History - DIVE
30
History - DIVE
31
History - DIVE
32
History - DIVE

• Videos

33
History

• DIVE
• Because of the reliable multicast implementation
  they use, DIVE does not scale well beyond 32
  participants.
• DIVE 3 uses a basic communications library based
  on IP multicast and Scalable Reliable Multicast
  (SRM).

34
History

• MR - TPP Minimal Reality Toolkit Peer Package
  Shaw/Green93
• MR-TTP is based on UDP (unreliable). Lost
  packages are ignored.
• Instead of heartbeat sends packages at the rate
  of the input device.
• Topology Complete Graph Connection.
• Number of users 4 or less.

35
History

• MASSIVE-1 MASSIVEGreenhalgh/Benford95
• Developed at Nottinham Universitys CRG (Computer
  Research Group), led by Steve Bendford and Chris
  Greenhalgh.

36
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 up to
  about 10 users (from Massive-1 home page).

37
History - MASSIVE

• Video

38
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 acts as
  distribution server for that environment
• Persistency
• Management of audio links.

39
History

• Summary
• A number of successful Networked VEs has been
  created
• Military
• Gaming
• Research
• Differ greatly
• What can the users do.
• Technological decisions.

40
Networking Concepts

• Latency
• Amount of time to transfer a bit of data from one
  point to another.
• Latency has a direct impact on interaction inside
  the virtual world.
• The designer cannot really reduce latency. It is
  possible to hide it or reduce its impact.

41
Networking Concepts

• Latency - causes
• Physical limitations speed of electromagnetic
  waves 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
Networking Concepts

• Bandwidth
• Rate at which the network can deliver data to the
  destination host.
• Examples
• Modem 56Kbits per second.
• Ethernet 10 or 100 Mbits per second.
• Fiber-optic 10 Gbps or more.

43
Networking Concepts

• Reliability
• How much data is lost by the network and how 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
Networking Concepts

• Reliability - How to handle data that is lost?
• Detect/Correct Error-correcting codes.
• Detect ACKS, NACKS.

45
Networking Concepts

• TCP Point-to-point connection to an application
  running in another machine.
• Data Checksum for integrity.
• Flow-control to avoid flooding of messages,
  including acknowledgements.
• Keeps strict ordering and consistency of
  packages. Is this necessary in NVEs?

46
Networking Concepts

• UDP Lightweight protocol.
• Differences with TCP
• Connectionless transmission. Information about
  the state of the connection is not kept.
• Best-effort delivery. No guarantee of delivery
  or order of messages.
• Each packet is auto-contained.

47
Networking Concepts

• UPD Advantages
• No overhead for connection oriented semantics.
• Packages can be transmitted/received immediately,
  no need for queues.
• It is possible to send information to groups of
  users (multicasting).

48
Networking Concepts

• Unicast
• One computer sends information to only another
  one computer.

49
Networking Concepts

• Broadcast
• One computer sends information to every computer
  in a subnet.

50
Networking Concepts

• Multicast
• Only computers listening to a specific multicast
  group receive the message.

51
Networking Concepts

• Multicast Similar to distribution of newspapers
• Subscribers explicitly request the newspaper.
• Duplicate copies are not sent down the same
  distribution tree.
• The publisher does not need to know the
  subscribers.

52
Networking Concepts

• Mulsticast is emerging as the recommended way to
  build large-scale NVEs.
• BUT many routers do not handle multicast messages
  still.

53
Networking Concepts
54
Networking Concepts

• Summary
• Available networking infrastructure is a very
  important factor when designing a NetVE.
• Networking-related decisions have a big impact
  on
• Complexity of implementation
• Overall performance
• Scalability

55
Architectures

• Client-Server Systems
• logical architecture

Server
Client 1
Client 2
Client n

56
Architectures

• Client-Server Systems
• physical architecture with phone lines

Server
Phone Line
Phone Line
Phone Line
Client 1
Client 2
Client n

57
Architectures

• Client-Server Systems
• physical architecture on a LAN

Server
Client 1
Client 2
Client n

58
Architectures

• Client-Server Systems
• The Server can become a bottleneck.
• What are the advantages? The server can decide
• Which clients should receive a message.
• What protocol to use with different clients.
• Sub-sample messages to slow users.
• Keep statistics.
• ...

59
Architectures

• Multiple-Server Architectures

Client 1
Client 2
Client n

Server 1
Server 2
Client 1
Client 2
Client n

60
Architectures

• Multiple-Server Architectures
• Several servers have the following advantages
• System scales better.
• Communication between clients attached to
  different servers takes longer.
• Key issue how to assign clients to servers?

61
Architectures

• Peer-to-peer

NETWORK
Client n
Client 1
Client 2
62
Architectures

• Peer-to-peer
• Network will be
• Broadcast
• One or multiple multicast groups.
• In the case of multicast groups
• Area of Interest Management assign different
  users to different multicast groups, based on
  some criteria.

63
Architectures

• How many participants can co-exist in a virtual
  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

64
Architectures Dawson98
65
Shared State

• Main idea in a NVE
• Provide users with the illusion that every
  participant is seeing the same things and
  interacting with each other.
• Things in the NVE change.
• Without dynamic shared state, the illusion of
  sharing space and time breaks.

66
Shared State

• Definition of the problem - The
  consistency-throughput tradeoff
• It is impossible to allow dynamic shared state to
  change frequently and guarantee that all host
  simultaneously access identical versions of that
  state. Singha/Zyda 1999

67
Shared State

• Absolute consistency
• Wait until everybody acknowledges before moving
  to a new position.
• Considering latency and available bandwidth, this
  may imply slowing down too much.
• Frequent updates
• Users send the updates and move on.
• But some users will receive the updates quickly
  and others wont.
• Inconsistent views!

68
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
69
Shared State

• Centralized Repositories - File Repository
• Advantage
• absolute consistency.
• Avoids concurrency problems.
• Locks on objects easily implemented (when are
  locks necessary?)
• Problems
• SLOW!

70
Shared State

• Centralized Repositories - Repository in Server
  Memory
• Entry in memory per entity.
• Users need to acquire a lock.

User 1
User 2
User n
71
Shared State

• Centralized Repositories - Repository in Server
  Memory
• Advantages
• Fast!
• Disadvantages
• No persistency.
• What happens if server crashes?

72
Shared State

• Distributed Repositories - Virtual Repository
• Different clients manage different parts of the
  world.
• Clients have a local cache of used objects.

73
Shared State

• Distributed Repositories - Virtual Repository
• Advantages
• No bottleneck
• Disadvantages
• Complex to program.

74
Shared State

• Frequent State Regeneration
• Is absolute consistency always necessary?
• When is it NOT necessary?

75
Shared State

• Frequent State Regeneration
• For instance in a group flight simulator program
• A temporal inaccuracy in the position of another
  plane is not too serious.
• Example if updates are sent every 40
  milliseconds, one lost package is almost
  imperceptible.

76
Shared State

• Frequent State Regeneration
• 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 local
  cache.
• Update the local cache with the remote events.

77
Shared State

• Frequent State Regeneration
• Producers and consumers are decoupled.
• All interactions can be decoupled?
• Independent movements YES.
• Tight-collaborative tasks NO.

Fast cycles
Slow cycles
78
Shared State

• Situation 1
• A slow computer controls a plane moving in a
  straight line.
• A participant in a fast computer perceives a
  jumpy movement.
• Situation 2
• A fast computer floods a slow computer with
  messages of a car moving in a straight line.

79
Shared State

• Issue 1 (slow updates - Fast computer sees
  jumpiness)
• Issue 2 (fast updates - Slow computer overwhelmed)

80
Shared State

• Solution to alleviate both issues
• DEAD RECKONING.
• Instead of sending updates at frame rate,
• Send parameters that describe the trajectory of
  the object (example initial position and
  velocity)
• Each participant displays the trajectory at its
  own rate.

81
Shared State

• Advantages
• Accommodates heterogeneity.
• Bandwidth usage is reduced.
• Cost
• More cycles to compute trajectory at each node.
• Need to re-synchronize.

82
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 move
  the object from the predicted to the actual
  position.

83
Shared State

• Prediction Algorithms
• Derivative Polynomials
• Order one
• Order two
• Part of DIS protocol.

84
Shared State

• Other prediction algorithms
• Circles
• Spirals
• Planes seem to follow many such curves.

85
Shared State

• Other strategy
• Send an update when the actual position is very
  different from the predicted position.
• Advantage the error in the system is kept under
  certain threshold.
• See paper by C. Faistnauer in IEEE VR 2000.

86
Shared State

• Convergence Algorithms

Convergence Position
Predicted Position
Current Position
Last actual position
87
Shared State

• Convergence Algorithms
• Snap Just move the object to the most recent
  actual position.
• Linear Linearly interpolate to a point in the
  new predicted path (convergence point).
• Cubic Spline Create a path in the form of a
  cubic spline from the current position to the
  convergence point.

88
Scalability and Performance

• Improve the size and performance of a Net-VE by
  reducing network bandwidth and processor
  resources.
• Less bandwidth requirements means more users in
  the network.
• Less processor requirements means free cycles for
  other purposes (better graphics,) and more
  heterogeneous participants.

89
Scalability and Performance

• Required resources are a function of
• Number of transmitted messages
• Average number of destination hosts per messsage
• Bandwidth required per message
• Timeliness (minimal delays)
• Processor cycles needed to process each message.

90
Scalability and Performance

• A reduction in any of these items is a gain.
• BUT usually a reduction in one means a penalty in
  another.
• Example
• Dead Reckoning reduces required bandwidth but
  more processor cycles are required.

91
Scalability and Performance

• Compression Aggregation
• Compression
• Aims at reducing bandwidth utilization by
  reducing the size of the messages.
• Internal encode in a more efficient manner.
• External Avoid retransmitting information that
  is identical to previous packages.

92
Scalability and Performance

• Compression
• Example
• Send Snapshots at periodic rates.
• Send updates to the snapshots.
• Snapshots sent over reliable protocol.
• Updates sent over unreliable protocol.

93
Scalability and Performance

• Packet Aggregation
• Aims at reducing the number of packets by merging
  several packets together.
• The saving comes from the headers (25 bytes for
  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
Scalability and Performance

• Which packages to merge?
• Based on a timeout (send a message every timeout
  units of time).
• Based on quorum (send a message only when the
  quorum has been reached).
• Combination of the previous two.

95
Scalability and Performance

• Aggregation Servers
• Define servers that aggregate messages for sets
  of entities having common characteristics
• Virtual World Location.
• Entity type.

96
Scalability and Performance

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

Dest2
Aura
Nimbus 2
Source
Dest1
Nimbus 1
97
Scalability and Performance

• An event is only send from the source to the
  destination if the sources aura intersects the
  destinations nimbus.
• In Massive-1 unicast, peer-to-peer, unreliable
  protocols are used to send events from the sender
  to the destination.
• This does not scale very well.

98
Scalability and Performance

• Multicast
• Key question how to map groups of users to
  multicast groups. Approaches
• Group-per-Entity
• Group-per-Region

99
Scalability and Performance

• 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 server is necessary to inform nodes
  about the position and multicast groups of other
  entities.
• Problem The number of multicast groups grows
  rapidly.

100
Scalability and Performance

• Group-per-region
• The virtual world is partitioned into cells. Each
  cell is assigned a multicast group.
• Users subscribe/unsubscribe from multicast groups
  as they travel.
• As a user approaches a region, it needs to
  subscribe to the neighbor cells. Hexagonal cells
  are an advantage.

101
Scalability and Performance

• 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
Scalability and Performance

• Need for multiple channels.
• Different channels have different resolution
  (update frequencies, spacial granularity, etc)
• Who handles the channels?
• A server
• Each client

103
Research Topics

• Multimedia
• Incorporating audio/video live streams to NVEs
• Questions
• What to display
• Where to display it
• A single rate or multiple rates?

104
Research Topics - Multimedia

• 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 server informs users about positions
  and orientation of other users.
• Actual voice messages and pictures are exchanged
  among users.

105
Research Topics

• FreeWalk

106
Research Topics - Multimedia

• Awareness-Driven Video QOS Reynard 98
• Three different QOS levels are established
• Porthole 1 update every 5 minutes. At the top
  of the virtual office.
• Glance 1 frame/sec. At the front of the office.
• Communications 20 frames/sec. On top of users
  avatar.

107
Research Topics - Multimedia

• Awareness-Driven Video QOS

108
Research Topics - Architectures

• 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
Research Topics - Architectures
Courtesy of T. Funkhouser http//www.cs.princeton.
edu/funk/ring.html
110
Research Topics - Architectures

• 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
Research Topics - Architectures
Courtesy if the Eafit University.
112
Research Topics - Heterogeneity

• How to accommodate heterogeneous nodes in a NetVE
  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 defines
  fidelity levels for each client.

113
Research Topics - Heterogeneity

• Proof-of-concept application

114
Research Topics - Heterogeneity

• The Switchboard architecture

115
Research Topics - Collaborative AR

• Two or more users collaborating in a reality
  augmented with virtual objects.
• See Studio3D by Vienna University.
• What happens if the users are in different
  physical locations?

116
Research Topics

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

117
Research Topics

• Americas Army

From Americas Armys home page.
118
Commercial Systems

• ActiveWorlds
• Commercial system.
• Free sessions for guests.
• Used for
• Education
• Social interaction of groups
• Provide avatars and connected virtual locales
• Communication chat tool.

119
Toy Application (cubes)

• Demonstration
• Will be downloadable from
• http//arcadia.eafit.edu.co/CGIMtutorial/

120
Toy Application

• Packages - Client Application

121
Toy Application

• Packages - Server Application
• Jus the Server Package.

122
(No Transcript)
123
Toy Application - server
124
Toy Application - send
125
Toy Application - receive
126
Toy Application - replicate
127
Toy Application - Documentation

• JavaDoc
• Documentation of classes, methods and atributes.
  Created by Java.
• UML
• Poseidon UML
• SourceCode
• JBuilder Personal Edition project.

128
Toy Application

• 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 in the
  tutorial.
• Use a VRML loader to import prettier geometry.

129
Toy Application

• Test your own ideas!

130
Conferences

• IEEE Virtual Reality (formerly IEEE VRAIS)
• ACM VRST (Virtual Reality Software and
  Technology).
• ACM CVE (Collaborative Virtual Environments).
  (every two years).
• ACM CSCW (Computer Supported Collaborative Work).
• IASTED CGIM.

131
Journals

• PRESENCE. MIT Press.
• In General networking or Human-Computer
  Interaction Journals have more and more articles
  on NVEs.

132
Summary and Conclusions

• New field.
• Technology is here.
• The need interest are growing.
• Many areas to be explored.
• Any idea for your own research? I will be happy
  to discuss.
• Enjoy!

133

• Thank you!

134
Bibliography - BOOKS

• Singhal/Zyda 1999 Singhal, S. and Zyda, M.
  Networked Virtual Environments Design and
  Implementation. Addison-Wesley.1999.
• Churchill/Snowdon/Munro 2001Churchill, E.,
  Snowdon, D. and Munro, A. Collaborative Virtual
  Enironments. Digital Places and Spaces for
  Interaction. Springer Verlag. 2001.

135
Bibliography - Papers and Articles

• Abrams/Wasten/Zyda98 Abrams, H., Waksen, K.
  and Zyda M. Three tiered interest management for
  large-scale virtual environments. In Proceedings
  of VRST 1998. Taipei, Taiwan, November 1998.
• Dawson98 Dawson, F. XDSL market blooming.
  Interactive Week 5(39)28-29. October, 1998.
• Funkhouser96 Funkhouser, T. Network Topologies
  for Scalable Multi-User Environments. In
  Proceedings of IEEE VRAIS. 1996.

136
Bibliography - Papers and Articles

• Greenhalgh/Benford95 Greenhalgh, C., Benford,
  S. Massive a Virtual Reality System for
  Teleconferencing. ACM Transaction on Computer
  Human Interfaces. 2(3)239-261.
• Hagsand96 Hagsand, O. Interactive multiuser
  VEs in the DIVE system. IEEE Multimedia
  3(1)30-39, 1996.
• IEEE93 IEEE standard for information
  technology / protocols for distributed simulation
  applications. IEEE Standard 1278-1993. IEEE
  Computer Society, 1993.
• Macedonia95 Macedonia, M., Zyda, M., Pratt, D.
  and Barham, P. Exploiting reality with multicast
  groups A network architecture for large-scale
  virtual environments. In Proceedings of IEEE
  VRAIS. 1995.

137
Bibliography - Papers and Articles

• Miller/Thorpe95 Miler, D., Thorpe J.A.
  SIMNET The advent of Simulator Networking. In
  Proceedings of the IEEE 83(8)1114-1123, August
  1995.
• Nakanishi96 Nakanishi, H., Yoshida, C.,
  Nishimura, T. and Ishida, T. FreeWalk Supporting
  Casual Meetings in a Network. In Proceedings of
  ACM CSCW. 1996.
• Restrepo03 Restrepo A., Montoya, A. and Trefftz
  H. Dynamic Server Allocation in Virtual
  Environments using QuadTrees for Space
  Partitioning. In Proceedings of IASTED Computer
  Science and Technology, Cancun, Mexico, 2003.
• Reynard98 Reynard, G., Benford, S., Greenhalgh,
  C. Heath, C. Awareness Driven Video Quality of
  Service in Collaborative Virtual Environments. In
  Proceedings of ACM CHI 98.

138
Bibliography - Papers and Articles

• Shaw/Green93 Shaw, C. Green, M. The MR toolkit
  peers package and experiment. In Proceedings of
  the 1993 IEEE Virtual RealityAnnual International
  Symposium, 463/469. Seattle, September 1993.
• Trefftz03 Trefftz, H., Marsic, I. and Zyda M.
  Handling Heterogeneity in Networked Virtual
  Environments. In Presence 12(1) 37. February
  2003.

139
Bibliography - Web Pages

• 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.no
  tt.ac.uk/research/systems/MASSIVE-3/
• NPSNET NPSNET home page http//www.npsnet.org/n
  psnet/
• Toy application
• http//arcadia.eafit.edu.co/CGIMtutorial/