Powered by
JSPWiki v2.8.2
g2gp 17-01-2009
View PDF

Previous | Next | Contents


Section 6: Archiving Virtual Reality Projects#

6.3 Archiving particular virtual reality formats#

As virtual reality worlds are multi-media applications and standards are still evolving, archiving is more complex than with other forms of digital data. VR developers will need to consider carefully which aspects of a world should be preserved in the long term and the best way to go about this. If the look and feel of a virtual world is important, does preservation mean attempting to keep the world running on its original hardware and software (with the risks inherent in this strategy, see Section 6.2)? Or is it sufficient to preserve the original source files with screen shots of the world and detailed documentation of how the world was created?

The approach that is taken to archiving VR will depend on both the technology that has been used and the nature of the project. Where standard VR formats have been used, such as VRML and X3D, worlds can be migrated as computer hardware and software evolves. For projects such as archaeological reconstructions, archiving the original source files (the original images, CAD models and so on) used to create the world will be important. For many projects an acceptable alternative to archiving the VR world itself, which may be both difficult and uncertain for proprietary or non-standard formats, might be to break down the VR into its original source files. With this approach, the source files would be deposited in standard formats together with screen-shots of the world and a detailed description of how to put the elements back together to recreate the application. In other cases, archiving the look and feel of the world may involve emulation of the VR on future platforms.

Archiving virtual reality in any format involves depositing the data files that make up the application with the project documentation (see Section 5) and metadata records (see Section 7.2). Particular VR formats require the additional data and documentation listed below to allow for either emulation or re-creation of the application.

6.3.1 Bubble worlds and QTVR

For panoramas and bubble worlds, it is recommended that the following should be deposited as part of the project archive:

  • Original image files with documentation of any 'hot-spots'
  • The specification, version number and date of the format used. Use of industry standard formats (e.g. QTVR) is recommended
  • A list identifying the name and version number of plug-ins or viewers which can be used to view the application
  • A copy of at least one plug-in/viewer that can be used to view the application
  • Installation instructions.

6.3.2 VRML

For virtual reality applications developed in VRML, it is recommended that the following should be deposited as part of the project archive:

  • The VRML specification, version number and date should be identified. For versions other than the ISO standard, VRML 97, a copy of the specification is recommended
  • A list identifying the name and version number of all VRML plug-ins or viewers which have been tested for use with the application
  • A copy of at least one plug-in/viewer that can be used to view the application
  • Installation instructions.

6.3.3 Java3D

Virtual reality applications developed in Java3D are not suitable for archiving by a data migration strategy except when archived as the original files. It is recommended that the following should be deposited with the project archive:

  • The original 3-D models in archival formats
  • Documentation describing how the world was constructed
  • A report which illustrates the world and describes how it was used
  • A copy of the correct version of the Java Developer's Kit (JDK) with the appropriate Java3D plug-in
  • A copy of the appropriate versions of the Java and Java3D specifications
  • A copy of the correct version of the Java Run-time Environment (JRE) and the appropriate Java3D plug-in
  • Installation instructions.

6.3.4 Collaborative Virtual Environments

Collaborative Virtual Environments may not be suitable for archiving by a migration strategy except when archived as original data files. The following should be provided with the project archive for the purposes of migration:

  • The original 3-D models (including worlds and avatars) in archival formats
  • Documentation describing how the models were incorporated into the CVE and the interactivity
  • Where appropriate, the 'chat-log' for an exhibition or event
  • A report illustrating the CVE and describing how it was used
  • Both client-side and server-side application software with specifications, documentation and installation instructions.

Previous | Next | Contents