Friday, May 16, 2008
Application Model Initially, we are making the big assumption here
Application Model Initially, we are making the big assumption here, that the model run at each site/host is the same, and that the only differences are POVs and the user at each host. However, it is not necessary for all users at all sites to ``see'' all objects. In fact, real estate probably precludes this. This means that certain (large) optimisations are possible in terms of delivering operation/messages to each host.
The set of typical operations between a VR application and the underlying system range from moving point of view to moving objects themselves and altering the attitudes.
A more advanced approach, one could consider sending trajectories around, and having receivers apply the model world to the object. (eg. gravity, wind, friction, etc etc).
Messages may be idempotent (describe an absolute position for an object, or position and velocity, and so on), or not (maybe they just say how far the object has moved).
Interactions between users of a distributed VR application are complex. An object must in some senses have an "owner". This may be the user at a site (e.g. if the object is the POV itself, or the glove/pointer, etc), or an object currently under the control of a user.
Thus we should associate a set of objects (and users) with a portion of the multicast address space - the idea is that a user is in some locale and that only operations relative to that locale need be delivered to their system.
Furthermore, there most be some notion of ``real'' virtual world distance. The set of objects in VR in a locale that are ``near'' a user are subject to interactions which can reasonably be modeled without having to worry about propagation delay across the net. Beyond some distance, and the time to get a message from the originator of the action to the hosts that a set of POVs that include this locale may simply be too high to consider. For example, imagine playing catch in a virtual world simulated between two machines on the net. The time for the ball to reach the ground is less than the time for the message to cross a terrestrial line more than a few thousand miles.
However, it may be possible to introduce some element of representation of distance into the user interface - two approaches suggest themselves based on physics models of the real world:
1.
Uncertainty - as an object gets further away, we can introduce less certainty about its position (note that the SRM protocol above gives us enough information to do this accurately!).
2.
Relativity - we could warp spacetime in the virtual environment to produce a similar effect to gravity - action at a distance could become much slower.
Given this, different VR applications may need to relax a different one of the four constraints, possibly at different times. In fact, we can envisage single applications that need to relax different constraints for different objects at different times.
Credit Link: http://www.cs.odu.edu/~cs778/crowcroft/book/node270.html
The set of typical operations between a VR application and the underlying system range from moving point of view to moving objects themselves and altering the attitudes.
A more advanced approach, one could consider sending trajectories around, and having receivers apply the model world to the object. (eg. gravity, wind, friction, etc etc).
Messages may be idempotent (describe an absolute position for an object, or position and velocity, and so on), or not (maybe they just say how far the object has moved).
Interactions between users of a distributed VR application are complex. An object must in some senses have an "owner". This may be the user at a site (e.g. if the object is the POV itself, or the glove/pointer, etc), or an object currently under the control of a user.
Thus we should associate a set of objects (and users) with a portion of the multicast address space - the idea is that a user is in some locale and that only operations relative to that locale need be delivered to their system.
Furthermore, there most be some notion of ``real'' virtual world distance. The set of objects in VR in a locale that are ``near'' a user are subject to interactions which can reasonably be modeled without having to worry about propagation delay across the net. Beyond some distance, and the time to get a message from the originator of the action to the hosts that a set of POVs that include this locale may simply be too high to consider. For example, imagine playing catch in a virtual world simulated between two machines on the net. The time for the ball to reach the ground is less than the time for the message to cross a terrestrial line more than a few thousand miles.
However, it may be possible to introduce some element of representation of distance into the user interface - two approaches suggest themselves based on physics models of the real world:
1.
Uncertainty - as an object gets further away, we can introduce less certainty about its position (note that the SRM protocol above gives us enough information to do this accurately!).
2.
Relativity - we could warp spacetime in the virtual environment to produce a similar effect to gravity - action at a distance could become much slower.
Given this, different VR applications may need to relax a different one of the four constraints, possibly at different times. In fact, we can envisage single applications that need to relax different constraints for different objects at different times.
Credit Link: http://www.cs.odu.edu/~cs778/crowcroft/book/node270.html