Virtual Reality systems are really glorified renderers combined with simulations, and some fancy display and pointer technology. The software components typically include the roughly what you would expect, as illustrated in figure 8.10.
The performance requirements for distributing VR are surprising. Once a system is up and running, it transpires that objects are introduced/created and destroyed, with relatively low frequency. If a distributed VR system runs the collision detection and rendering at all receivers, it is only POV and object locations and attitudes that need updating. Here, though, there may be an extremely stringent latency requirement because of multiple interactions with other objects.
We need three main components to a protocol to distribute this functionality:
The virtual world bulk load protocol could be based in a number of existing protocols for large scale information dissemination. We assume that virtual worlds are potentially very large databases (although many VRML examples are not that large, we would anticipate this changing as time progresses and people develop a richer taste in virtual environments). However, it may be possible to use the update protocol that we are devising here too, if it is engineered for high throughput as well as low latency.
The object naming system requires hierarchical naming and wildcarding, as well as a clean mapping from object to multicast group. Such a system has been devised in earlier work, and is partially implemented in the CCCP system[#!cccp!#].
The update protocol is what we will concentrate on here. Essentially, we propose an extension of SRM, together with the congestion avoidance mechanisms taken from Wakeman and McCanne's work. We propose basing the protocol on RTP, as is described in Parnes' work[#!rtpsrm!#], since it is likely that eventually VR worlds may include media such as audio and video, and we see no reason to use a different packet header to support point of view and object motion, and new object upload.
We propose that the constants of repair can be adjusted in favour of fast recovery rather than low numbers of repeated requests and repairs, since the load caused by this (given the size of repairs) is relatively small.
The sender application needs to specify the semantics of the operation, and this is conveyed in single field in the protocol so that receivers can work out whether a repair request is relevant or whether a new update will overwrite the effect anyhow.
Next: Virtual Reality Operations, User
Up: Distributed Virtual Reality
Previous: Distributed Virtual Reality
Jon CROWCROFT
1998-12-03
