Performance is the key requirement of any VR system. VR applications are "user centered", therefore the physical comfort and experience of the user is of vital importance. As covered in the previous chapter, the experience of the user relies upon presenting an interactive and engaging environment. If the performance of the system is too low, the interactivity of the system becomes erratic and can lead to disengagement from the application that significantly degrades the experience of the user. Poor performance is not merely an inconvenience for the end user; performance problems can cause serious physical side effects including disorientation and motion sickness [#Kalawsky].

Because of these potential problems, VR software requires the utmost in performance [#Zyda networked virtual environments]. Effective immersive environments must maintain a high visual frame rate (15hz or better) and maximize the responsiveness of the system to user inputs [#Rory]. To achieve the best performance, VR systems should take advantage of all available resources on a system, such as processors and special graphics hardware. In addition, the development system itself should have as little application overhead as possible.

Current VR software systems have been successful at achieving good performance. Unfortunately, many of these systems do so while neglecting several fundamental needs of a software system such as: reusability, extensibility, flexibility, portability, and robustness. In some cases, system developers sacrifice these needs in an attempt to increase performance by tying the software system as closely to the hardware as possible. Another reason that current systems may not implement these features is that it is much more difficult to design a system that supports these features. Since the primary focus of VR research to date has been hardware systems and not software systems, these types of features have not received the attention that they deserve in a VR software system. We believe that a high-performance VR software system does not need to sacrifice any of these features in order to maintain high performance. In addition, we believe that these features are vitally important for creating a long lasting standard VR software system.

The next sections discuss some of the software architectural needs that are commonly overlooked.

Extensibility in a VR development environment allows user applications to survive technological changes of the future. Extensibility refers to the ability to add new features and extensions to a current software system. Extensibility is required because the hardware and software tools used for VR development change rapidly. Researchers are constantly creating new VR hardware devices that must be supported by development environments. The development environment should not require a programmer to re-write their application every time support for a new VR hardware device is added.

If a development environment does not allow easy extension, then it becomes difficult for users to write applications that can survive into the future. To avoid rewriting applications for new hardware, application developers need the ability to write an application once and rely upon the VR development environment to support future hardware advances. Although it would be adequate to simply require users to re-compile to get support for new hardware, it is better if the users are not required to even re-compile. In order to avoid the need for re-compilation, a development environment must support dynamic extension.

Extensibility of the software architecture is not enough. The software architecture must also be flexible enough to adapt to new requirements. Flexibility here refers to the ability of the system to adapt to the shifting configurations and changing requirements of a VR system. For example, the development environment must support multiple operating systems in addition to supporting many types of graphics software and hardware.

Development environments should not require developers to rewrite an application for every type of VR system. Instead, the software should adjust itself to the local VR system and facilitate the execution of the user’s application. If the environment cannot adapt to new configurations, applications will be limited in the scope of their usefulness.

In addition, the design of the system itself should not lock developers into writing only one given type of application. For example, the development environment must make it just as easy to write a passive architectural walk-through application as it is to create an interactive scientific visualization application. This requires a development environment that is not only flexible about what hardware it is running on, but is also flexible about what type of applications and toolkits are running within the software system.

Although a VR system is inherently complex, a VR development system does not have to be. The complexity of VR systems has unnecessarily led to the expectation and acceptance of corresponding complexity in development environments. This software complexity limits the ability of on-technical users to develop VR applications.

As more people begin using VR, system designers need to simplify development environments to allow for widespread application development by non-technical users. VR allows users from many fields to gain insight into their problems, but these users are not necessarily expert software developers. Because users may not have software expertise, a VR development environment should be as simple and easy to use as possible. They should not have to worry about the complexities of VR systems, but should instead be able to spend time creating innovative applications.

Before VR applications can completely escape the domain of research, applications will be required to run reliably. Many current VR development environments were developed in research labs that have contributed many innovations and continue to do so. The problem is that in a research lab a "good" program may only be required to be partially stable; crashing one out of five times is commonly considered acceptable. It is research after all, so if the application crashes occasionally, that is to be expected. Outside the research lab, users are not so forgiving.

VR is beginning to enter the mainstream of corporate users. These users will make use of VR applications in their production environments, and will not settle for down time or sporadic behavior in an application. VR development environments need to consider this in order satisfy the rigid demands of corporate users.

The next pages will look at each of these broad requirements of VR development environments in more detail.