Lancaster University
The implementation of subjective views in Dive utilizes two core features offered by that platform. These are:
The information which defines the state of the subjective views is defined by properties associated with objects in the world. The syntax of properties which define modifiers is:
SV_<identifier> <modifier>
Where <modifier> may be one of:
The subjective view definition of an object is passed down to all its children in the hierarchy. Hence a single definition in the top level object will affect all other objects in the world. However any child object may override the definition given by its parent. For example, in the sample hierarchy of figure 1, if object 'B' has a property stating that it should appear as 'wireframe' for a user then objects 'B', 'D', and 'G' will also appear as wireframe. However if object 'G' has a subjective view property defining that this object should be invisible, this property will override the one inherited from 'B' and the object 'G' will not be displayed.
Figure 1. A sample object hierarchy.
Their are two classes of identifiers:
Both are strings which associate users to the properties within objects. A user name is simply the name of the user, such as 'john'. A user group is an name for an arbitrary role or group of users, such as 'plumbers'. Groups are used to simply specification of subjective view data, as a single definition can affect many users' views. An object may have any number of definitions for users and groups, for example:
…..
SV_john wireframe
SV_plumbers bright
SV_electricians invisible
…..
Which states that, for example, any user who is a member of the plumbers group will be presented with a transparent view of this object. To prevent the use of complex conflict resolution, a user may only be a member of one group at any one time. Without this constraint, policy decisions would have to be made when two definitions are found. Such as when a user is a member of the plumbers and electricians group (see above), here a conflict resolution mechanism must decide whether to make the object bright or invisible.
Given that a user is a member of only one group at any one time there still exists a conflict resolution problem as a user may have a 'named' definition in the same object. For example, in the sample list of properties above, if the user 'john' is also a member of the 'plumbers' group then two modifiers must be resolved. The resolution mechanism used is that user based definitions override those of group based definitions. This permits a group view to be defined, but still allow individual users to configure their display. Hence, continuing the example above, the resultant modifier for John is 'wireframe'.
A user's embodiment within the shared world is utilized to hold the users' identifier definitions. These are held by two properties:
SV_user SV_<user name>
SV_group SV_<user group>
For example:
SV_user SV_john
SV_group SV_plumbers
Normally each user's user-name is unique, allowing them to configure the world independently. However, it is possible for a number of users to assume the same user name. Then the world would be configured identically for all these users (assuming they have the same group definition). This feature may be used as a temporary means of 'seeing the world though someone else's eyes', in cases where two (or more) users are unsure of any inconsistencies in their views of the shared world.
It may also be used to group together tightly associated users, such as a small number of people being taken on a virtual tour. Their views of the world may be taken from a generic 'basic_tourist_view' group definition and refined for the user 'tour_group_A' (which identifies the sub-group).
Representations are controlled in much the same way as modifiers. However such properties exist only within switch type objects, and are not inherited down through the hierarchy. As modifiers may exist within switch objects the properties used to identify representation selections must differ from those used to define modifiers, or orthogonality is lost. Hence selection properties are of the form:
SV_S_<identifier> <choice index>
Identifiers and the conflict resolution mechanism are used as in the case of modifiers. Hence a switch object may have the properties:
…..
SV_john wireframe
SV_S_john 1
SV_S_plumbers 0
…..
Which (if the user john is a member of the plumbers group), will be presented with a wireframe rendering of representation index '1'.
For implementation efficiency the properties:
SV_S_user SV_S_<user name>
SV_S_group SV_S_<group name>
must also exist with the actor along with the SV_user and SV_group definitions used in modifier definitions. For simplicity (although not required) the user and group names defined by both pairs of properties should be consistent. That is, if 'SV_user = SV_john' then 'SV_S_user' must be 'SV_S_john'.
It is often the case that some objects in the virtual world will be invisible for much of the time to all users and only visible to a single or few users on occasion. For example, in an application developed by E. Frécon all users within a large shared world are associated with a large pointer which highlights them from afar. Users may request that a user is highlighted, which will cause the large arrow over them to become visible to that user.
By using only subjective view data to implement this, then for all highlighting arrow objects (over each user) a subjective view property must exist for each user, stating that this object must be invisible. As new users join the world, properties must be created to make the arrows invisible to them.
A much simpler approach is to specify that all the highlighting arrows are invisible by default, using the standard Dive flags. Then as new users join they will not see the highlighting pointers. By specifying the modifier 'Normal', ordinarily invisible objects can be made subjectively visible. Hence to support the application described above, only the users who wish to know the location of other users will require subjective view properties.