Beruflich Dokumente
Kultur Dokumente
Helmuth Trefftz
htrefftz@eafit.edu.co Eafit University - Medelln, Colombia
Introduction
Why are you here?
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.
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)
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).
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
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/Munro 2001]
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
Introduction
Key components
Graphic engines and displays Control devices (keyboardtrackers) Processing Systems Data Network
Introduction
Current challenges
Network Bandwidth/Latency Heterogeneity Distributed Interaction (real-time) Resource Management - Scalability
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.
History - SIMNET
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.
History - Military
SIMNET Modules
Network Interface Other-vehicle state table Controls Own-vehicle dynamics Sound generation
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
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.
History - Military
DIS - Traffic:
96% Entity State PDUs Rest:
Fire Detonation Collision Others
History - Military
DIS - Scalability
Designed for 300-500 users
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!
History - Games
SGI Flight
Flight simulator demo program used from 1984 to 1992. Created in 1983. Networked version shown in SIGGRAPH 1984.
http://www.berkelium.com/OpenGL/readme.html
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.
History - Doom
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).
History - Academia
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.
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.
History - DIVE
History - DIVE
History - DIVE
History - DIVE
Videos
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).
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.
History
MASSIVE-1
[MASSIVE][Greenhalgh/Benford9
5]
Developed at Nottinham Universitys CRG (Computer Research Group), led by Steve Bendford and Chris Greenhalgh.
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).
History - MASSIVE
Video
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.
History
Summary
A number of successful Networked VEs has been created:
Military Gaming Research
Differ greatly:
What can the users do. Technological decisions.
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.
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).
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.
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.
Networking Concepts
Reliability - How to handle data that is lost?
Detect/Correct: Error-correcting codes. Detect: ACKS, NACKS.
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?
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.
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).
Networking Concepts
Unicast
One computer sends information to only another one computer.
Networking Concepts
Broadcast
One computer sends information to every computer in a subnet.
Networking Concepts
Multicast
Only computers listening to a specific multicast group receive the message.
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.
Networking Concepts
Mulsticast is emerging as the recommended way to build large-scale NVEs. BUT many routers do not handle multicast messages still.
Networking Concepts
TCP
Small number of users Limited data requirements Typically client-server configuration Higher data requirements Used both in client-server and peer-to-peer configurations. Small peer-to-peer Net VEs with high data requirements and time sensitive delivery. Large peer-to-peer NetVEs, be careful with routers.
UDP
IP Broadcasting IP Multicasting
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
Architectures
Client-Server Systems
logical architecture
Server
Client 1
Client 2
Client n
Architectures
Client-Server Systems
physical architecture with phone lines
Server
Phone Line
Phone Line
Phone Line
Client 1
Client 2
Client n
Architectures
Client-Server Systems
physical architecture on a LAN
Server
Client 1
Client 2
Client n
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. ...
Architectures
Multiple-Server Architectures
Client 1 Client 2 Client n
Server 1
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?
Architectures
Peer-to-peer
Client 2
Architectures
Peer-to-peer
Network will be:
Broadcast One or multiple multicast groups.
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
Architectures [Dawson98]
Technology Speed (Kbps) Min # players Max # players
1 39 39 263
100BT
100,000
2630
10851
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.
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]
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!
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
Centralized Repositories - File Repository
Advantage:
absolute consistency. Avoids concurrency problems. Locks on objects easily implemented (when are locks necessary?)
Problems:
SLOW!
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
Shared State
Centralized Repositories - Repository in Server Memory Advantages
Fast!
Disadvantages
No persistency. What happens if server crashes?
Shared State
Distributed Repositories - Virtual Repository
Different clients manage different parts of the world. Clients have a local cache of used objects.
Shared State
Distributed Repositories - Virtual Repository Advantages:
No bottleneck
Disadvantages:
Complex to program.
Shared State
Frequent State Regeneration Is absolute consistency always necessary? When is it NOT necessary?
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.
Shared State
Frequent State Regeneration
Producer
Broadcast location of local objects Either when they move or at a fixed rate.
Shared State
Frequent State Regeneration
Producers and consumers are decoupled.
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.
Shared State
Issue 1 (slow updates - Fast computer sees jumpiness)
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.
Shared State
Advantages:
Accommodates heterogeneity. Bandwidth usage is reduced.
Cost:
More cycles to compute trajectory at each node. Need to re-synchronize.
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.
Shared State
Prediction Algorithms
Derivative Polynomials: Order one:
Shared State
Other prediction algorithms:
Circles Spirals
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.
Shared State
Convergence Algorithms
Predicted Position
Convergence Position
Current Position
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.
Dest2
Nimbus 2
Therefore:
Can be updated less frequently.
Research Topics
Multimedia
Incorporating audio/video live streams to NVEs Questions:
What to display Where to display it A single rate or multiple rates?
Research Topics
FreeWalk
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.
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.
Research Topics
Americas Army
Commercial Systems
ActiveWorlds
Commercial system. Free sessions for guests. Used for:
Education Social interaction of groups
Toy Application
Packages - Client Application
Toy Application
Packages - Server Application
Jus the Server Package.
UML
Poseidon UML
SourceCode
JBuilder Personal Edition project.
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.
Toy Application
Test your own ideas!
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.
Journals
PRESENCE. MIT Press. In General networking or HumanComputer Interaction Journals have more and more articles on NVEs.
Thank you!
Bibliography - BOOKS
[Singhal/Zyda 1999] Singhal, S. and Zyda, M. Networked Virtual Environments: Design and Implementation. AddisonWesley.1999. [Churchill/Snowdon/Munro 2001]Churchill, E., Snowdon, D. and Munro, A. Collaborative Virtual Enironments. Digital Places and Spaces for Interaction. Springer Verlag. 2001.
VRAIS. 1996.
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.