Networked VR Ashweeni Beeharee Ashweeni Beeharee VE Course - - - PDF document

networked vr
SMART_READER_LITE
LIVE PREVIEW

Networked VR Ashweeni Beeharee Ashweeni Beeharee VE Course - - - PDF document

Networked VR Ashweeni Beeharee Ashweeni Beeharee VE Course - Networked VR 1 Content Networked VR scenarios Architectures Peer-to-peer Consistency Full Partial Predicted Conclusion Ashweeni Beeharee VE Course -


slide-1
SLIDE 1

1

Ashweeni Beeharee VE Course - Networked VR 1

Networked VR

Ashweeni Beeharee

Ashweeni Beeharee VE Course - Networked VR 2

Content

Networked VR scenarios Architectures

Peer-to-peer

Consistency

Full Partial Predicted

Conclusion

slide-2
SLIDE 2

2

Ashweeni Beeharee VE Course - Networked VR 3

Helicopter Maintenance

Assembly of a helicopter engine Participant across continents

Ashweeni Beeharee VE Course - Networked VR 4

The Diamond park

Cycling around the park Multiple users Voice support

slide-3
SLIDE 3

3

Ashweeni Beeharee VE Course - Networked VR 5

The Oil Platform

Multi-user simulation exercise Use of haptic device + HMD

Ashweeni Beeharee VE Course - Networked VR 6

Multiplayer Game

slide-4
SLIDE 4

4

Ashweeni Beeharee VE Course - Networked VR 7

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

Ashweeni Beeharee VE Course - Networked VR 8

Concerns for designers

Immersion and embodiment

In-body vs out-body

Presence and shared presence User expectation

Things should look natural

Adaptation

slide-5
SLIDE 5

5

Ashweeni Beeharee VE Course - Networked VR 9

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

Ashweeni Beeharee VE Course - Networked VR 10

Architecture

You already know about networking! Peer-to-Peer Client/Server Distributed

slide-6
SLIDE 6

6

Ashweeni Beeharee VE Course - Networked VR 11

  • Total Replicated Database
  • Simple Extension to Single Users
  • Initial Multi-Participant VE

Simple Peer-to-Peer

DB DB

Ashweeni Beeharee VE Course - Networked VR 12

Multiple Peer-to-Peer

slide-7
SLIDE 7

7

Ashweeni Beeharee VE Course - Networked VR 13

Client-Server Architecture

Client Server

  • Database on Server with Shadow Copy on Clients
  • Current Online Games
  • Some VE (MASSIVE,Deva)

DB

Ashweeni Beeharee VE Course - Networked VR 14

Client-Server Architecture

Server Client Client Client Client

slide-8
SLIDE 8

8

Ashweeni Beeharee VE Course - Networked VR 15

Distributed Architecture

  • Total Replicated or Partial Database
  • Most Virtual Environments (DIVE, NPSNET)

DB

Ashweeni Beeharee VE Course - Networked VR 16

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!

slide-9
SLIDE 9

9

Ashweeni Beeharee VE Course - Networked VR 17

Consistency : Reality

GOLDEN RULE Information propagation IS NOT instantaneous

It is not possible for It is not possible for EVERY EVERY user to share the user to share the EXACT EXACT same state at same state at EVERY EVERY instance instance

Ashweeni Beeharee VE Course - Networked VR 18

State Consistency: Case 1 (Total Sync) State Consistency: Case 1 (Total Sync)

T = t Acknowledge every update Propagation delay is 100ms Client A Client B

slide-10
SLIDE 10

10

Ashweeni Beeharee VE Course - Networked VR 19

State Consistency: Case 1 State Consistency: Case 1

Client A Client B T = t + 50ms

Ashweeni Beeharee VE Course - Networked VR 20

State Consistency: Case 1 State Consistency: Case 1

Delta T Client A Client B T = t + 50 ms + 100 ms

slide-11
SLIDE 11

11

Ashweeni Beeharee VE Course - Networked VR 21

State Consistency: Case 1 State Consistency: Case 1

T = t + 50ms + 100ms + 50ms + 100ms T = t + 300ms After 300ms Client A may move again!!! Client A Client B Delta T

Ashweeni Beeharee VE Course - Networked VR 22

State Consistency: Case 2 (Async) State Consistency: Case 2 (Async)

T = t Local update every 150ms Propagation delay is 100ms Client A Client B

slide-12
SLIDE 12

12

Ashweeni Beeharee VE Course - Networked VR 23

State Consistency: Case 2 State Consistency: Case 2

T = t + 100ms Client A Client B

Ashweeni Beeharee VE Course - Networked VR 24

State Consistency: Case 2 State Consistency: Case 2

T = t + 150ms Client A Client B

slide-13
SLIDE 13

13

Ashweeni Beeharee VE Course - Networked VR 25

State Consistency: Case 2 State Consistency: Case 2

T = t + 250ms Client A Client B Delta T

Ashweeni Beeharee VE Course - Networked VR 26

State Consistency: Case 2 State Consistency: Case 2

T = t + 300ms Client A Client B

slide-14
SLIDE 14

14

Ashweeni Beeharee VE Course - Networked VR 27

State Consistency: Case 2 State Consistency: Case 2

T = t + 400ms Inconsistency!!! Client A Client B Delta T Delta T

Ashweeni Beeharee VE Course - Networked VR 28

State Consistency: Problem State Consistency: Problem

Network propagation > 100ms Network is congested -> retransmission Players >> 2

Consistency Update Frequency

slide-15
SLIDE 15

15

Ashweeni Beeharee VE Course - Networked VR 29

State Consistency: Total Consistency 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

Ashweeni Beeharee VE Course - Networked VR 30

State Consistency: Total Consistency 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

slide-16
SLIDE 16

16

Ashweeni Beeharee VE Course - Networked VR 31

State Consistency: Eventual Consistency 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

Ashweeni Beeharee VE Course - Networked VR 32

State Consistency: Eventual Consistency 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

slide-17
SLIDE 17

17

Ashweeni Beeharee VE Course - Networked VR 33

State Consistency: Predicted Consistency 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: Possible solution:

  • Dead reckoning

Dead reckoning

  • High level behaviours

High level behaviours

Ashweeni Beeharee VE Course - Networked VR 34

State Consistency: Predicted Consistency State Consistency: Predicted Consistency

Dead reckoning I

Client A Client B Ghost A Ghost B Movement Model: P(t) = P(t0) + v*t P(t) = P(t0) + v*t + 0.5 * a * t2

slide-18
SLIDE 18

18

Ashweeni Beeharee VE Course - Networked VR 35

State Consistency: Predicted Consistency State Consistency: Predicted Consistency

Dead reckoning II

Client A Simulation If new pos does not exceed error threshold then do nothing If new pos does exceed error threshold then send new position

Ashweeni Beeharee VE Course - Networked VR 36

State Consistency: Predicted Consistency State Consistency: Predicted Consistency

Dead reckoning III - convergence

T = t

OR

T = t T = t+1 T = t+2

slide-19
SLIDE 19

19

Ashweeni Beeharee VE Course - Networked VR 37

State Consistency: Predicted Consistency State Consistency: Predicted Consistency

High level behaviours (Games)

Position A Position B

  • 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

Ashweeni Beeharee VE Course - Networked VR 38

State Consistency: Predicted Consistency State Consistency: Predicted Consistency

High level behaviours (Games)

Position A Position B

  • 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
slide-20
SLIDE 20

20

Ashweeni Beeharee VE Course - Networked VR 39

Twines

Derive function which represents complex

path

Send the function over in a single message

Twine

Ashweeni Beeharee VE Course - Networked VR 40

Interaction

Passive navigation

Consistency requirement minimal Delays

User/User – gesture Point and Shoot Collaboration

Single object/multiple user Multiple objects/multiple users

What is the impact of network problems on these?

slide-21
SLIDE 21

21

Ashweeni Beeharee VE Course - Networked VR 41

Constraint resolution

Collaborative manipulation

Where is the resolver? – local/remote Impact of Round-trip time Object ownership

But how about finite lag?

Minimising decoupling by using spring paradigm

Ashweeni Beeharee VE Course - Networked VR 42

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 Perfect system not always possible

slide-22
SLIDE 22

22

Ashweeni Beeharee VE Course - Networked VR 43

The ultimate application?