Jonathan C.Roberts and Nick Ryan

A paper to accompany a poster to be displayed at the VRSIG97 Conference in which we describe and compare four models of operation that allow the publisher to generate views, with the client manipulating and affecting specific objects in the world. We demonstrate these approaches through a problem in archaeological visualization.

Many existing VR models enable the user to pick up and manipulate virtual portable objects within a fixed virtual environment. Here, we apply similar techniques to permit the user to manipulate the virtual environment itself. We provide an example based on the need for effective presentation of the uncertainty inherent in archaeological interpretation, but the approach may also prove valuable in many other fields such as geology, civil engineering and architecture.

Examples of the four model categories:

1. Require new: the publisher generates multiple images or virtual world models, linking them together using HTML. Each image or world is requested and downloaded separately. This describes a typical Web page with linked images or worlds.
2. Switch Change: a single file is published containing multiple versions of a virtual world. The user requests and downloads the single file, then switches between the available models.
3. Functional Change: the publisher generates a world with objects and characteristics that may be easily changed, typically through a user interface embedded in the world model. In our example of a Roman theatre, this allows the height of the building, the number of seats, and the presence of other features to be altered interactively.
4. Program Run: (example not yet available) a version of the data and program is published, for example as a Java applet. The user runs the program on their local machine to generate different views and modes of the displayed world

The image below shows an example of our Functional Change category. The user interface is generated in a Head Up Display (HUD) configuration. The HUD nodes maintain the position of the user interface on the browser screen, independent on the viewing angle or position, thus keeping the controls at the users finger tips. The output data streams are ROUTE'd to a Calculator prototype. The calculator prototype allows the calculations of the model dimensions to be grouped in one place, reducing the number of routes in the model and allowing changes to the dependencies to be altered in one place in the code.