1. Distributed VR Mark Green School of Creative Media

2. Distributed VR  Two or more users share the same virtual environment  aware of each other  can interact with each other  all users can interact with and modify the environment  usually at different locations

3. Issues: Technical  Communications bandwidth and latency  where is the environment stored?  What happens when there are no users?  How do we synchronize users?  What happens if two users want to modify the same object?  How do we detect this in a timely manner?

4. Issues: Non-Technical  Representation of users  users interfering with each other  do all users see the same environment?  private information, what should be shared and when?  Social structure and behavior

5. Architectures  If several users share the same environment they must be able to communicate  how do we do this efficiently?  One of the main problems is distance: electrons only move so fast, takes a finite amount of time to travel any distance electrons only move so fast, takes a finite amount of time to travel any distance long distances mean multiple time zones, everyone isn’t awake at the same time long distances mean multiple time zones, everyone isn’t awake at the same time

6. Architectures  What needs to be communicated? The environment (not all of the time) The environment (not all of the time) user state user state changes to the environment changes to the environment ownership and environment state information ownership and environment state information  some of this information is exchanged frequently (several times per second), others are occasional events

7. Communications: User State  Need accurate up to date representations of other users  a time sequence of their actions  requirements: low latency low latency correct order correct order  timely information, missed updates are okay, but can’t have updates out of order

8. Architectures  Main concern is efficient communications  two extremes: centralized: a central server maintains all the information on the environment, coordinates all user communications centralized: a central server maintains all the information on the environment, coordinates all user communications decentralized: each user has their own copy of the environment, users communicate directly with each other decentralized: each user has their own copy of the environment, users communicate directly with each other

9. Centralized Architecture Server VE Client

10. Decentralized Architecture User VE User VE

11. Centralized Architecture  One copy of the environment on the server, all changes to the environment must go through the server  all user actions sent to the server, server then sends them to the other users  this is the simplest architecture to develop, all communications is controlled and centralized

12. Centralized Architecture  When client joins the session the current version of the environment is sent  list of all active users, and their representations is also sent  each user sends position and actions to the server frequently  maybe not every update, but 5 or 10 times per second

13. Centralized Architecture  Server collects user information, then sends all of this information to other users  again this happens 5 or 10 times per second  what happens when a user wants to interact with an object in the environment  user must request “ownership” of the object  by default the server owns all of the objects

14. Centralized Architecture  If server currently owns the object, ownership is transferred to the user  if another user owns the object: user denied access to the object user denied access to the object other user may be requested to release the object, particularly if it hasn’t used it recently other user may be requested to release the object, particularly if it hasn’t used it recently  once the user has ownership, it is free to manipulate it

15. Central Architecture  Each manipulation is sent to the central server, central server sends manipulations to other users  when user is finished manipulating the object it releases ownership  Note: in this model only one user can own an object at a time, no collaboration

16. Central Architecture  This approach has numerous advantages, besides simplicity  one central copy of the environment, we have a consistent representation of the environment  users must register, so we have a charging mechanism, important for commercial applications

17. Central Architecture  Server can package user updates, send as one packet to all users, this can save network bandwidth  need to understand a little bit about how networks work  information isn’t sent as a stream of characters (except in the case of modems), instead packets of bytes are used

18. Central Architecture  All networks have a minimum and maximum packet size – like boxes  minimum is rarely smaller than 64 bytes, maximum rarely more than 1500 bytes  if the information is smaller than the minimum packet size it is padded with extra garbage bytes to reach the minimum size  makes sense to send larger packets

19. Central Architecture  Observation: not just the amount of information that impacts network performance, also how it is packaged  ownership mechanism controls how objects in environment are manipulated  fair sharing of the objects, occurs in a controlled manner  in theory no surprises

20. Central Architecture  The central architecture also has a number of problems  one of the key problems is scalability  as we add more users the central server becomes a bottleneck, it must process an increasing number of messages  at some point it can’t keep up and all users suffer

21. Central Architecture  Another problem is with interaction  user must request ownership, this involves a message transfer to and from the server  this may take several seconds if the server is some distance away, or is busy  users don’t request ownership, the client program does, users aren’t aware of this

22. Central Architecture  User starts manipulating object, at this point client requests ownership  what happens while client waits for a response from server?  Do we let the user continue?  This is okay if we get ownership, but what happens if ownership is refused?  Do we reverse all the user’s actions?

23. Central Architecture  We could stop the user until ownership is received  user doesn’t know why program has stopped, thinks the program has a bad user interface  this is a no win situation, no matter what we do the user will be upset  problems when two users grab the same object at close to the same time

24. Central Architecture  The central architecture works well under the following conditions: the server is close the server is close small number of users, below the point where the server gets overloaded small number of users, below the point where the server gets overloaded relatively simple environments, no complex objects that users might want to share relatively simple environments, no complex objects that users might want to share

25. Decentralized Architecture  Each user has their own copy of the environment  users communicate with each other directly  we remove the server bottleneck, no need to go to the server  this architecture is more complex, since their isn’t a single official copy of the environment

26. Decentralized Architecture  What happens when a new user joins?  New user has a copy of the initial state of the environment, all the objects in their initial positions  this probably isn’t the current state, other users have moved objects  send a “new user” message to one of the existing users

27. Decentralized Architecture  Response is the list of current users and the current state of the environment  new user informs all of the other users that he exists, and they start sending updates to him  not as fast as centralized architecture, may be some time before the new user has up to date copy of the environment

28. Decentralized Architecture  Each user sends updates of its state to all of the other users, again this happens 5 to 10 times per second  receives back the updated information from the other users  all the updates may not arrive at the same time, depends on network and processor speed of other users

29. Decentralized Architecture  Advantage: don’t need to wait for slower client computers  fast computers can exchange information more frequently, smoother motion and interaction  what happens when a user manipulates an object?  There are several possibilities

30. Decentralized Architecture  Can still use an ownership scheme to keep all copies consistent  each object will have an owner, one of the users  need to find the user who owns the object, request ownership from that user  object can store its owner, so we don’t need to search for it

31. Decentralized Architecture  This could be faster than centralized approach, depends on how close the other user is, how busy their computer is  can claim ownership, and see if anyone complains, this is much faster, but could lead to problems  what happens if several users claim ownership, modify object in different ways

32. Decentralized Architecture  End up with multiple versions of the environment, inconsistent in state of this object  Is this a problem?  Depends upon the object and application  if we have a game and the object is important for winning then object ownership is very important

33. Decentralized Architecture  If it is a minor object, this may not be a problem  Example: notepad in a meeting environment  each user can claim their own copy of the notepad and write their own notes  in this case inconsistency in the environment isn’t a big issue, its more of a feature

34. Decentralized Architecture  When a user leaves the environment, he gives up ownership of his objects  what happens when the last person leaves?  Is there a record of the final state of the environment?  If this is important there should be a non- human user whose main responsibility is to save the environment

35. Decentralized Architecture  In many cases we don’t need to save the environment  in an meeting environment, once the meeting is over there is nothing to save  same thing for training simulators, once the training session is over we don’t need to save anything, each session starts with a new scenario

36. Decentralized Architectures  Decentralized architectures have some major advantages  they can scale better, don’t depend on centralized server that can be a bottleneck  more flexible ways of sharing objects, don’t need to have complete consistency, since there are multiple copies of the environment

37. Decentralized Architectures  May or may not have higher bandwidth requirements  this is hard to evaluate, most models are too simplistic  if there are n users, each user will send n- 1 update message and receive n-1 updates  this gives 2n(n-1) messages in total in each update

38. Decentralized Architecture  With a centralized server, each user sends one message to server, and gets one back, the return message is quite large so can be counted as n messages  this gives a total of n+1 messages  its appears that bandwidth requirements grow faster for a decentralized architecture  if using one network segment this is the case

39. Decentralized Architecture  In centralized architecture, all packets must go through the server, so there is a single network connection that carries all of the traffic  in a decentralized architecture there are multiple network connections carrying all of the traffic, possibly one for each user  since all users don’t update at the same rate, the bandwidth required could be lower

40. Decentralized Architecture  On more closer examination, there could be a separate path for each pair of users  each user will still have a packet coming in from each user and one going out to each user, a total of 2(n-1)  the central server receives a message from every user, and sends a message to every user, sent message is n times as large

41. Decentralized Architecture  Central server total traffic is n + n(n-1)  thus the central server has a much higher bandwidth requirement than any user in a decentralized architecture  as long as the users are evenly distributed over network segments (probably one per segment) decentralized will have better network performance

42. Decentralized Architectures  There are a number of disadvantages  one of the main ones is complexity, the user programs are more complex, they have more things to do  the network protocol is more complex  this requires more programming and there are more things that can go wrong

43. Decentralized Architectures  There is less control  harder to keep all versions of the environment the same  can’t easily update the environment  no easy way to charge people to use the system  harder to enforce the rules

44. Architectures  Rarely use pure centralized or decentralized architectures due to scaling problems  in the case of centralized architectures use multiple servers, each one with part of the users  servers must still communicate, but fewer messages in and out of each server

45. Architectures  If there are a large number of users they will not be able to see each other and communicate with each other  not likely that more than 10 or 20 users will communicate as a group  this means that we don’t need to send all updates to all users, only the ones that we are close to

46. Architectures  This benefits the decentralized architectures the most  need to know the users to send to, this may require some central coordination  some network techniques can be used  for centralized, servers still need to collect all user information, then decide which users get which information

47. User Representation  If we have multiple users in the same VE we need some way of representing them  you need to see where the other users are and what they are doing  this is both a technical and social issue  depends on the application and people involved  Avatar: term used for user representation

48. Avatars  What do we need to represent and how should it be represented?  This partly depends on the application and the available technology  for conference and meeting applications an accurate representation of the users is important  need eye contact and facial expressions

49. Avatars  For other applications a realistic representation isn’t desirable  realistic representations require resources: space: can hide important parts of the application space: can hide important parts of the application display: takes considerable amount of time to display, display resources should be devoted to more important parts of the application display: takes considerable amount of time to display, display resources should be devoted to more important parts of the application

50. Avatars  What is the minimal amount of information we need? Where the other user is located Where the other user is located the direction they are looking the direction they are looking manipulations they are performing manipulations they are performing  minimal representation can use coordinate axis to represent position and direction of sight

51. Avatars: Reo Virus

52. Avatars  Doing more sophisticated avatars is harder since we have a limited amount of information  usually tracking head and hand, only parts of the body we have information for, really can’t move other body parts  the body usually follows the motion of the head, fixed relationship with body

53. Avatars  We have hand position, but not the rest of the arm  must calculate reasonable arm configuration, likely angles between arm segments  may not know arm length, so this could be hard  doing an accurate body is quite hard

54. Avatars  Video can be used for all or part of the body  note: video requires lots of network bandwidth, can only be used with fast connections and few users  easiest is to use a webcam for facial features  take several images per second, convert into texture map and display on avatar’s head

55. Avatars  For full body use one or more cameras to capture full body image, use blue screen or similar technique to just get the body  body is a simple shape, a rectangle or cylinder, body image used as texture map for the avatar  need multiple images if you want to view the body from different directions

56. Avatars  Many applications use low polygon models to represent the user  users can select their avatar and in some cases construct their own from a parts library  bodies are usually rigid and follow the head position and orientation

57. Avatars

58. Avatars

59. Avatar  When user joins the environment they send their avatar to all the other users  in return they get the avatars for the other users  since the geometry is simple, this doesn’t take very long  when user updates are received the corresponding avatar is moved

60. Avatars  The avatars can be anything, which raises interesting social issues  how do you know who you are really dealing with?  In games and entertainment applications this may not be a problem  but in other areas, banking and commerce, this could be very important

61. Avatar  An animal avatar is clearing hiding a true identity, but what about a human one?  Studies have shown that a significant number of online game players choose avatars of a different gender  in social circumstances this could be very misleading  changing age is also common

62. Avatars  Choosing misleading avatars can be a real problem when people meet outside of the virtual world  the hot blonde you’ve been chatting up for the past month is really a fat old truck driver  the boy you thought was your age is really a dirty old man  both true stories

63. Social Behavior  What is correct social behavior in a VE?  We built one of the earliest distributed VE and showed it at Cyberconf 1993  it was a shared breakout game where players took turns hitting the ball  one of the best winning strategies was to put your hand in the other player’s head, they couldn’t see the ball

64. Social Behavior  Since we have more freedom of movement we can do things we can’t in the real world  we can invade people’s private space  do we need laws or codes of social behavior?  These issues are only being investigated in a few places

65. Environment Consistency  Should everyone have the same copy of the environment?  This is both a technical and a social issue  maintaining exact consistency is expensive, both in terms of usability and network resources  must carefully manage ownership of all objects

66. Environment Consistency  User wanting to manipulate object must obtain ownership  this may take several seconds, and possibly several messages if several servers are involved  this is extra network bandwidth and slows the user down  but is all of this worth while?

67. Environment Consistency  Users don’t have a consistent view of the environment, even with strict ownership  it takes time for object update messages to reach users, this time will vary from user to user  at any real point in time, different users may see the same object in different states, depending upon the updates they receive

68. Environment Consistency  Makes a difference if more than one object is manipulated  sequence of actions may be different for different users  some users may see A move first, while others will see B move first  different versions of events or cause and effect

69. Environment Consistency  This problem could be solved by a central server, but this could introduce large delays  central server collects updates, send to other users in a common sequence  need to wait for all updates, introduces delay  hard for users to synchronize their actions  Users manipulating objects will still have different view

70. Environment Consistency  What happens if things aren’t consistent?  start by looking at object ownership, what happens if we don’t worry about this?  Two or more users could interact with the same object at the same time  is this really a problem?  Depends on the application, but it could also be a problem if it was not allowed

71. Environment Consistency  What if two or more users must work together?  They both need to manipulate the object, this isn’t possible if ownership is enforced  if another user starts manipulating the same object is this really a surprise??  They must be in the same area, it must be possible to see their actions, talk to them

72. Environment Consistency  If two users want to manipulate the same object, they must be able to see each other, see the other user reach for the object  if only one can manipulate the object, they know a problem is about to occur  this happens in real life, we have social conventions to deal with it  maybe this is the best solution

73. Environment Consistency  What about private space?  If all copies of the environment are completely consistent there is no private information  Users may want to customize their environment, position lights so they can get a better view, change visual representations, this may be of no interest to other users

74. Environment Consistency  Users in a virtual meeting may want private notes, don’t want to tell competitors what your strategy is!  This suggests that the environment should be divided into two parts: common: shared by all common: shared by all private: restricted to current user, may be shared with other users, based on permission private: restricted to current user, may be shared with other users, based on permission

75. More Technical Details  There are a number of technical details that need to be dealt with  one issues involves different types of computers: different internal representations different internal representations different processor speeds different processor speeds different network connections different network connections

76. More Technical Details  Why are these differences important?  Need to send information between different computers, need a common representation in order to do this  want to keep environments synchronized, with different CPU speeds we need to be careful how we program behaviors

77. Technical Details  Binary representation more compact than ASCII, faster to transmit  but different binary representations makes this difficult  ASCII is readable by all computers, so often the representation of choice  need standard binary representation and conversions for all computers

78. Technical Details  ASCII representations used for the environment, only sent once per user at beginning, can afford to wait  binary representation used for updates, this needs to be quick and has a significant influence on bandwidth

79. Environment Representation  Two ways of getting the initial version of the environment: transmission from central sever or peer transmission from central sever or peer part of application code part of application code  Another related issue: produce a separate program for each environment produce a separate program for each environment general purpose program, like SE, used for several environments general purpose program, like SE, used for several environments

80. Environment Representation  If we use a special purpose program the environment can be stored locally or transmitted from another computer  with a more general purpose program the environment is usually sent from another computer  need to look carefully at how both of these work

81. Environment Representation  Producing a special purpose program for each environment is more work, need to do more programming  advantage is you can provide special purpose program code for the environment  distribute initial version of environment with the program, save some transmission time

82. Environment Representation  Reo Virus is a good example  most of the environment is in a 3DS file that is local to the server  at run time most of the environment is converted into OpenGL objects and sent to client using GLX, a binary protocol for OpenGL, very efficient

83. Environment Representation  During interaction, transformations sent to client, geometry already cached at client  this gives very good interactive response  only works if client has OpenGL running on top of X  doesn’t work for a standard PC, need special software

84. Environment Representation  The general purpose approach allows us to use the same program for several environments  saves some programming time  opens up opportunity for browser plugins and distribution over the Internet  this is very attractive, but there are some problems

85. Environment Representation  Usually have ASCII representation of environment, this is often slow to transmit  temptation to use text editor to produce geometry, main problem with VRML  have the problem of behavior, need to have a language for describing behavior, since it can’t be built into the program that runs the environment

86. Environment Representation  Many of the web based systems suffer from this problem  can do static environments, some can do canned animation, but few allow real interaction  restricted to mouse and keyboard for interaction, lowest common denominator

87. Environment Representation  Can we change the environment after it starts running - add new geometry?  very few systems support this  problem: geometry can be quite large, particularly if ASCII representation is used  requires considerable network bandwidth, interferes with normal running of the environment

88. Environment Representation  Need to be able to add new objects when the program is running, software may not be structured for this  possible solution: use separate network connection and program thread to transmit new geometry use separate network connection and program thread to transmit new geometry add it as separate scene graph add it as separate scene graph  should work, but haven’t tried it

89. Time Issues  If we have behaviors, they must all run at the same rate, regardless of CPU speed  we don’t want to send update messages for all of the objects with behaviors: use a lot of network bandwidth use a lot of network bandwidth problems of network delay makes it hard to synchronize all the environments problems of network delay makes it hard to synchronize all the environments

90. Time Issues  How do we get reasonably consistent environments?  Program all behaviors in terms of time not updates  if all behaviors start at the same time they will evolve at the same rate, so the environments will be consistent

91. Time Issues  Still need to synchronize at one point in time, maybe at regular intervals as well  all behaviors don’t start at the same time, depends upon when program starts  several types of time: simulation time: time since the start of the simulation, time in our environment simulation time: time since the start of the simulation, time in our environment clock on the wall time: real time clock on the wall time: real time

92. Time  If all behaviors are in terms of time, they should be synchronized to simulation time  there could be drift, but this is a good starting point  need to match simulation time to real time  network protocols for synchronizing clocks on computers, so can assume that all computers have the same real time

93. Time  First step, synchronize simulation time to real time  several possible schemes  assign one computer as the time source  it sends packets with real time and its simulation time  other computers adjust their simulation time to match it

94. Time  Next step: synchronize behaviors to simulation time  behaviors associated with objects, each object has an owner  periodically each client broadcasts the state of all the objects it owns  packet with simulation time and state of the object at that time

95. Time  When these packets are received by other objects they will have gone beyond the simulation time  need to compare object states at the simulation time in the packet, not the current time  we have probably lost that state information so how do we do comparison?

96. Time  One solution is to set the object’s state to the state in the packet  then run the behavior from the time in the packet to the current simulation time  this should give us the state in the object owner at the current simulation time  this only works if the behaviors can be performed quickly

97. Dead Reckoning  This leads us to an interesting bandwidth reduction technique  we send our current position and orientation to all the other users in the environment  they receive this information some time in the future, so by the time they get it it’s no longer accurate!  Dead reckoning can help solve this problem

98. Dead Reckoning  We make the assumption that people travel in a straight line over short periods of time, a few seconds  our update packet contains the following information: current simulation time current simulation time current position current position current velocity current velocity

99. Dead Reckoning  When we receive an update packet from another user we do the following  compute the difference between current simulation time and the time in the packet  multiply the velocity by this time difference and then add it to the position in the packet  this should give a close approximation to the user’s current position

100. Dead Reckoning  If the user’s velocity is relatively constant we don’t need to send as many updates  several times per second we compute the user’s velocity  if the velocity is significantly different from the last update packet we send a new update packet, otherwise no update packet is sent

101. Dead Reckoning  If we don’t receive a new update packet from another user, we assume the velocity is the same  we just keep adding the user’s previous velocity to their position to get their new position  a simple computation that can be performed quite quickly

102. Dead Reckoning  If the user stays still or moves with a constant velocity this work very well  may send a packet every few seconds so other users know we are still alive  if the user changes direction a lot bandwidth requirements could go up, since each packet is larger

103. Example Systems  Look at some of the historically significant systems  most of these systems are relatively old, but they form the basis for a lot of what we see now  really not a lot of progress in the last few, maybe 5, years

104. SIMNET and DIS  The US military version of distributed VR  work started on SIMNET in 1983, two goals: build low cost simulators ($300,000 range) so many of them can be build, say hundreds build low cost simulators ($300,000 range) so many of them can be build, say hundreds network the simulators so multiple units can train together network the simulators so multiple units can train together  model object is the tank

105. SIMNET  Why a tank? Limited visibility, don’t need to have sophisticated display systems, just small out the window displays Limited visibility, don’t need to have sophisticated display systems, just small out the window displays don’t move very fast, very limited rules of engagement don’t move very fast, very limited rules of engagement often work in groups, so group training makes sense often work in groups, so group training makes sense

106. SIMNET  Based on objects and events  each computer is responsible for one or more objects: a tank is an object a tank is an object a shell fired from a tank is also an object a shell fired from a tank is also an object  computer owns the objects that it simulates  there is no central server, a completely distributed system

107. SIMNET  Client sends out state packets for all the objects it owns  makes use of dead reckoning, so typically one packet every second or so for each object  clients receive packets for all objects, tracks the state of the objects that are close to it  may have inconsistencies if packets are lost, quickly fixed on next update

108. SIMNET  Tank fires a shell: computes the progress of the shell computes the progress of the shell when it strikes ground an explosion is generated when it strikes ground an explosion is generated other units close to explosion are told to compute damage due to shell other units close to explosion are told to compute damage due to shell rely on other units to honestly determine their death rely on other units to honestly determine their death

109. SIMNET  First test around 1986, system delivered in 1990  a success, 100s of units could be trained at the same time  some simulated units (no people)  used in training exercises with improvement in real performance

110. SIMNET  Very advanced for its time, motivated a lot of research  a number of limitations  really good with tanks, but not so good with other vehicles, used with helicopters and some other land vehicles  no interaction with the terrain: couldn’t blow up bridges, etc

111. SIMNET  Coarse grain simulation  really don’t consider the individual actions of each of the users  only look at gross movements, like tank direction and speed, direction of shell, etc  couldn’t simulate an individual person  fast moving objects tended to flood the network

112. DIS  Distributed Interaction Simulation protocol, developed from SIMNET, first version in 1993  became an IEEE standard  an attempt to generalize the SIMNET protocol, only partially successful  a more general packet structure and a number of new commands

113. DIS  Can handle a wider range of vehicles, more situations, but still the same basic model  some network optimizations so it can now handle 1000s of objects  still has limitations of coarse grain and no modification of the terrain  mainly for military training systems

114. DIS  Really ran its course by around 1996  they had conferences, held twice a year (may still be running)  also freely distributed implementation of the protocol  some attempts at non-military applications, but not particularly successful

115. Games  Some early history here too  rumors that there were networked versions of Spacewar, but no reliable evidence  need to have multiple graphics workstations for this to happen, so not much until the 1980s  one of the best early example are Flight and Dogfight

116. Games  Flight was developed around 1984 at SGI as a demo of their graphics workstations  a very realistic flight simulator  goal is to take off, fly around and then attempt to land  several different plane models  in 1984 Flight was networked so you could see people flying on other workstations

117. Games  Dogfight appeared around 1985, modification of Flight that allowed you to shoot down other players  not a very good network protocol, tended to overload networks quickly  another SGI networked game, bz, was a tank simulation that was a bit easier to play

118. Games  Doom was one of the first networked games that was widely available  didn’t use very efficient network protocols, overloaded many networks  created the initial demand for networked games  this will probably be one of the major markets in the future

119. NPSNET  Developed at the Naval Postgraduate School starting around 1986  aim was to produce low cost military simulators, but in a research and public environment  in many ways similar to SIMNET/DIS at first, but quickly developed to be more general

120. NPSNET  Have been able to build a wide range of simulators, including some fine grain ones  research results in network protocols and performance  group is still active, longest lasting research group in the field

121. DIVE  DIVE : Distributed Interactive Virtual Environment had a completely different set of motivations  came out of the collaborative work area, evolved from meeting environments and similar tools, not simulation  produce a shared space where people can have meetings, work together

122. DIVE  This produces a different structure  being able to share objects is important, share a white board where you can write notes, etc  have better control over communications, may not want everyone to know what you are discussing

123. DIVE  Introduced the notions of aura and nimbus: aura: range covered by the user’s information, objects in this area can potentially receive this information aura: range covered by the user’s information, objects in this area can potentially receive this information nimbus: area that the user is sensitive to, can perceive things in this area nimbus: area that the user is sensitive to, can perceive things in this area  when the aura of one user intersects the nimbus of another they can communicate

124. DIVE  The aura and nimbus don’t need to be the same size and shape  can be different for different kinds of media  DIVE concentrated less on graphics and simulation and more on communications and interaction  used a somewhat primitive interface, based on mouse and keyboard

125. DIVE  The DIVE project started around 1990 at SICS in Sweden  since then its has grown to include a number of other researchers, mainly in Europe  a wealth of experience in developing systems and good technical evaluation of the work they have done

126. MR and Friends  MR Toolkit was developed around 1990 at the University of Alberta  network capabilities were added around 1992, motivated by the Placeholder piece developed by Laural and Strickland at Banff  peers package developed by Shaw and Green in a few nights of coding

127. MR and Friends  Peers was based on a shared data model, the easiest of the early systems to program  also totally based on Internet protocols, means it can run anywhere  Ball: a breakout like game developed to demonstrate Peers  up to four players could play together, take turns hitting the ball

128. MR and Friends  First public demonstration 1993 CyberConf in Austin Texas  four players: Austin, Stanford, Banff, and Edmonton running over a standard Internet connection  demo ran for 2 hours, covered by both ABC and CNN!

129. MR and Friends  EM: 1994 first fine grained distributed VR system, built on top of Peers  based on objects and ownership  ownership of an object can be split, based on object’s parts  several users can manipulate the same object  ownership can be transferred between users

130. MR and Friends  Reo Virus was the last of the line at UofA  the first central server system that we built  again relies on standard Internet protocols and the GLX protocol  store most of the environment on local client, only transmit updates

131. The Future  Where are we headed??  Not a lot of progress over the past few years, incremental growth  what about the web?  Nothing has really worked on the web, interaction has been too restricted, rely on mouse and keyboard, limited protocols

132. The Future  What problems do we need to solve now?  The first is to get interesting behavior that can be distributed and communicated  next we need to think more about interaction, don’t want to just look at the other users  much better authoring tools

133. The Future  What we really need to think about is why we are really doing this?  The best systems have been highly application driven  we need to have a vision of what we want to communicate  maybe games and entertainment and the way to go