Networked VR Environments: Architectures and Consistency

1. Virtual Environments: Networked VR Anthony Steed Department of Computer Science University College London http://www.cs.ucl.ac.uk/teaching/VE

2. Content • Networked scenarios • Architectures • Peer-to-peer • Consistency • Full • Partial • Predicted • Conclusion

3. The Diamond park • Cycling around the park • Multiple users • Voice support

4. The Oil Platform • Multi-user simulation exercise • Use of haptic device + HMD

5. Multiplayer Game

6. Nature of a Networked Virtual Environment • Multiple user – geographically distributed • More types of interactions • Passive navigation • Single object/multiple user • Multiple objects/multiple users • Voice link between participants • Heterogeneous immersion devices

7. Demands • Provide up-to-date info to all participants • Users location • Support Interactions • Minimal delay update • Support multiple message type • Simple state • Voice/video • Consistency is Very important

8. Architectures • Peer-to-Peer • Client/Server • Hybrid

9. DB DB Simple Peer-to-Peer • Total Replicated Database • Simple Extension to Single Users • Initial Multi-Participant VE

10. Multiple Peer-to-Peer

11. Client-Server Architecture DB Client Server • Database on Server with Shadow Copy on Clients • Current Online Games • Some VE (MASSIVE,Deva)

12. Client-Server Architecture Server Client Client Client Client

13. Hybrid Architectures DB Server pool • Multiple servers serving different regions • Multiple service types & service layers

14. How do these architecture measure up? • Up-to-date information • Synchronisation in peer-to-peer impossible – no absolute reality! • Interaction • Client/Server provides central locus of control – constraint resolution • Consistency!

15. It is not possible for EVERY user to share the EXACT same state at EVERY instance Consistency : Reality • GOLDEN RULE • Information propagation IS NOT instantaneous

16. State Consistency: Case 1 (Total Sync) Client A Client B T = t Acknowledge every update Propagation delay is 100ms Updates on clients every 100ms

17. State Consistency: Case 1 Client B Client A T = t + 50ms 50ms because this it time taken for system to respond and be ready to send update

18. State Consistency: Case 1 Delta T Client B Client A T = t + 50 ms + 100 ms DeltaT is 100ms

19. State Consistency: Case 1 Client B Client A T = t + 50ms + 100ms + 50ms Local compute on Client B

20. State Consistency: Case 1 Delta T Client B Client A T = t + 50ms + 100ms + 50ms + 100ms T = t + 300ms After 300ms Client A may move again!!!

21. State Consistency: Case 2 (Async) Client B Client A T = t Again local update every 100ms Propagation delay is 100ms

22. State Consistency: Case 1 Client B Client A T = t + 50ms

23. State Consistency: Case 2 Client B Client A T = t + 150ms

24. State Consistency: Case 2 Client B Client A T = t + 200ms Both clients do a local compute A moves, B shoots

25. State Consistency: Case 2 Delta T Delta T Client B Client A T = t + 300ms

26. State Consistency: Case 2 Client A Client B T = t + 350ms Inconsistency!!!

27. State Consistency: Problem • Network propagation > 100ms • Network is congested -> retransmission • Players >> 2 Consistency Update Frequency

28. State Consistency: Total Consistency Provided by Client/Server Architecture • Server controls total consistency of database • Communication is reliable • Each Client reads from Server • Client sends updates to Server (dirty cache) • Events are totally ordered

29. State Consistency: Total Consistency Pros • Guaranteed ordered event processing • Implicit ownership Cons • Latency penalty: 2 Round Trip Time • Reliability not always compatible with real-time (msg + ack) • Poor scalability • Server is bottleneck • Server is single point of failure

30. State Consistency: Eventual Consistency • Clients just send periodic updates • Discrepancy is tolerated if: • Does not exceed a given time threshold • Does not dramatically a perceptual error threshold • Clients do not need acknowledgements • A client is unawares of other clients • Inconsistency inversely proportional update frequency

31. State Consistency: Eventual Consistency • Pros: • Minimum latency • No infrastructure -> reduced processing overhead • Simple to upgrade a single user system to multi users • No bottleneck • Fault tolerant (no packets -> remove entity) • Cons: • Explicit ownership • Bandwidth hungry (high frequency for low inconsistency) • Better scalability but still poor

32. State Consistency: Predicted Consistency Facts: • Users are not aware of other users • Total consistency is not a requirement • But eventual consistency has problems • Possible solution: • Dead reckoning • High level behaviours

33. State Consistency: Predicted Consistency • Dead reckoning I Ghost A Client B Ghost B Movement Model: P(t) = P(t0) + v*t P(t) = P(t0) + v*t + 0.5 * a * t2 Client A

34. If new pos does not exceed error threshold then do nothing If new pos does exceed error threshold then send new position State Consistency: Predicted Consistency • Dead reckoning II Simulation Client A

35. OR T = t T = t+1 T = t+2 State Consistency: Predicted Consistency • Dead reckoning III - convergence T = t

36. State Consistency: Predicted Consistency • High level behaviours (Games) Position B Position A • At each game interval send current position packet • If path takes 30 seconds and game tick is 10 per second • You have 300 packets being sent

37. State Consistency: Predicted Consistency • High level behaviours (Games) Position B Position A • Just send Destination Position B • Use path finding to compute best path • Not all users will see same path • But all will see final result • Send 1 packet only with parameters

38. Summary • Networked VR • allows new possibilities for interaction • Poses new challenges to VR designers • Three types of architectures exist and their suitability depends on the target application • Consistency is at the heart of networked VR