Application model

In chapter 6 the distribution architecture was for MASSIVE-1, i.e. based on unicast peer-to-peer communication managed by spatial trading. However this section gener- alises this aspect of the model to include network architectures which make effective use of multicast communication. This is another area in which this model extends the previous one.

The final outputs from the model are predictions of network load in terms of total average network bandwidth and also the average bandwidth received by a single par- ticipant’s machine. The final network traffic model is used to explore:

• the relative impact of state size vs. update or streamed bandwidth;

• the difference between explicit state transfer and the use of heartbeat messages; • the benefits of multicasting compared to unicast;

• the effect of different choices of replication unit;

• the effect of different forms of replication management; • the influence of secondary sourcing and abstraction.

Finally, the MASSIVE-1 and MASSIVE-2 systems are represented in the model to illustrate its use and to indicate the relative scalability of these two systems with respect to network bandwidth requirements.

The specification and modelling of task and application requirements is in some ways the hardest and most significant part of the whole model. This is the area which is dealt with first.

Note that all of the parameters defined in the model are summarised in table 18 on page 157.

10.3.1. Application model

The “application” referred to here is the overall purpose or task for which the system is being used (rather than the individual processes which make up the system). This will determine what kinds of interaction must be supported, what types and quantities of information must be exchanged and may also have a strong influence on actual user behaviour (the next element of the model). The application model defines the relation- ships between a number of key conceptual components of a CVE session. These com- ponents are: worlds, regions, artefacts, participants and scopes of interaction. The nature and number of these components are parameters of the application model which allow a range of tasks and applications to be described. The concepts, overall model and specific parameters are described in turn.

Concepts

The application model is made up of a number of components: worlds, regions, arte- facts, participants and scopes of interest. These are defined in turn below.

• Worlds. All interaction is assumed to occur within a world. Each world is a disjoint space, with its own coordinate system. Most CVEs have some notion of worlds which may also be linked via portals or other mechanisms as in MASSIVE-1 and DIVE [Hagsand, 1996].

• Regions. As described in chapter 2 many multi-user virtual reality systems (espe- cially those which employ multicasting) divide each world into smaller cells or

10.3.1. Application model

zones which play a role in scoping or facilitating communication. Examples include regional third party objects in MASSIVE-2 and hexagonal tiles in NPSNET [Macedonia et al., 1995].

• Artefacts. These are the tangible (visible, audible, etc.) objects which populate the virtual environment. Most or all interaction in the CVE is mediated by artefacts. Examples include the representations (embodiments or avatars) of users, scenery, buildings, useful objects, elements of a visualisation, vehicles, etc.

• Participants. These are the agencies or active processes within the virtual environ- ment and include human user client processes as well as software agents and appli- cations. A participant is typically represented within the virtual environment by one (or more) artefacts. Participant processes also observe surrounding activity in the virtual environment, e.g. to present this information to a human user, or to con- trol an application.

• Scopes of interest. The interests of each participant within the virtual environment are described by a scope of interest. In the original spatial model this was the par- ticipant’s various medium-specific auras. With third party objects this should also take account of third party effects as considered in section 10.1. The same idea is implicit or explicit in most of the systems considered in chapter 2. The participant wishes to know about artefacts within this scope, but need not know about artefacts outside it.

The communication task of a CVE runtime system is to provide all current partici- pants with appropriate and timely information about all artefacts which are within their scope of interest. This information may include graphical geometry, position and orientation, articulations and gestures, audio, video and other forms of interaction and communication. This is in the context of potentially mobile artefacts and normally mobile participants. This is illustrated in figure 39 on page 135.

The following sections formalise the characteristics of artefacts, participants and scopes of interest within the model. These define the model’s key parameters. Consid-

A

simple artefact participant

participant A’s scope of interest

Figure 39: main components of the CVE application model

virtual world

desired information flows to participant A

10.3.1. Application model

eration of worlds and regions is deferred until the distribution architecture is consid- ered since they are intimately related.

Artefact parameters

In this simple model there is one application/task-level parameter concerned with artefacts which is defined below.

• : the total number of non-participant artefacts in the entire system (spread across arbitrary numbers of worlds and regions). One of the key dimensions of scalability is the dependency of communication on this parameter. In this model non-participant artefacts are assumed to be passive, i.e. static and generating negli- gible numbers of updates. Typical values for would be from 1 (the simplest possible non-empty world) to many millions. For example, in the ITW trials it was typically around 10 while for many visualisation applications in would be several hundreds or thousands. Note that all of the parameters defined in the model are summarised in table 18 on page 157.

Participant parameters

Each participant is represented in the system by an active artefact. For simplicity, these participant embodiments are not included in the passive artefact count, , above. If a system or application includes agents or other active artefacts then they should be counted as participants (or participant-equivalents) for the purposes of this model. The parameters relevant to participants are defined below.

• : the total number of participants in the system, which, as with artefacts, may be spread across arbitrary numbers of worlds and regions. The dependency of com- munication on this parameter is the single most important dimension of scalability for many applications. In the ITW trials this way typically 10. The DIS-based STOW program aims to support 100,000 active entities [ARPA, 1994].

• : the length of time for which a participant uses the system in a single session. For example, in the ITW trials the average session duration was 3900 seconds. This parameter would be expected to vary significantly for different applications, ranging from a few seconds to days or weeks.

Scope of interest parameters

Each participant has their own scope of interest. In this model it is characterised by the following parameters.

• : the number of passive artefacts which fall within an average scope of interest. This model assumes a generally consistent density of artefacts. Typical values range from 1 (a minimal meeting space as in some of the ITW meetings) to 106 or more in large visualisation applications.

• : the number of participants which fall within an average scope of interest. Typ- ical values range from 0 (for a single user application!) to tens of thousands (a vir- tual wembley stadium). Example values are 10 for the ITW meetings and 800

N_A N_A N_A N_P T_s I_A I_P