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

Previous | Next | Contents


Section 3: Virtual Reality Methods and Techniques#

3.5 Hardware, testing and maintenance#

3.5.1 Testing for target platform(s)

The hardware and software platforms used to create your world are unlikely to be the same as the platforms used by your target audience. The likely platforms should have been identified during the planning stage of your project (see sub-section 3.3.7). Once the world has been developed, it is important to view it on all of the target platforms, check that it achieves the desired performance and make any modifications. You will need to consider:

  • CPU speed
  • Browser configuration
  • Internet connection (or other delivery options such as CD-ROM)
  • File size
  • Visual quality

The visual quality of the world, together with the sounds and animations that it incorporates, have an impact on both the overall file size and the rate at which the world is delivered on screen.

The frame-rate is the number of times per second that the world is redrawn. For the human eye to perceive a smoothly changing view it must be redrawn at a rate of at least 25 frames per second. A computer's ability to redraw a scene at this speed is determined by the number of facets that have to be displayed at any particular viewpoint and by the textures, animations and other processes being performed. The complexity of information that must be redrawn for a given viewpoint can be minimised by level of detail (LOD) techniques. This involves displaying less detailed versions of objects at greater distances from the user's viewpoint. However, this technique involves creating several versions of each object to be displayed at different viewpoints and thus increases the overall file size (although speeds up the rendering time of individual sections of the model).

File size and the types of Internet connections being used are important considerations if the world is to be downloaded from the web. How long should a user be expected to wait for a world to download? A user in a university may have an Internet connection that allows files to be downloaded up to a rate of 10 megabits a second (although the actual rate depends on the number of users on the university network at the time). However, home users will be able to download files at much slower rates – dial-up modems download files at 28 or 56 kilobits per second while domestic DSL lines achieve rates of up to 512 kilobits per second (1 megabit = 1,024 kilobits). Thus home users will wait much longer than university users for files to download. File size is determined by the number of objects, textures and sounds within the world. It can be reduced by using a compressed format for web delivery, if one is available for the type of virtual reality you are creating. Image files, such as those used for tiling and texturing, can usually be compressed using the normal techniques and experimentation will show the effect that this has on the model.

Another important consideration is that virtual worlds are usually developed on quite fast, powerful computers. Users may not have the same capacity when viewing the worlds, which is one of the reasons why it is important to test on other machines.

During testing it is important to consider the balance between the visual quality of your world, the frame-rate, file size and their impact on the delivery of the world to users. Consider whether realism is more important than speed or if it should be the other way around.

3.5.2 Maintenance and testing

Web-deliverable virtual reality is almost always reliant on a plug-in or viewer running in conjunction with a browser. As new versions of these are released, it is important to test that your worlds continue to run as intended. There may be differences in the way that browsers implement scripting languages (such as Javascript) used in virtual worlds. You will need to test (and continue to test) that worlds perform in the same way within all common browsers.

There is also the general issue of maintenance of the system – who will maintain and update the model after the project ends? Who will be available to deal with any problems when the model is in use? This is one of the reasons that full documentation is necessary (see Section 5).


Previous | Next | Contents