As stated earlier, the most common approach for VR application
development is one where the application defines the
main() function. That main()
function in turn calls library functions when needed. (This is the
model followed by software packages such as the
CAVElibs™ and the Diverse Toolkit.) The
library in this model only executes code when directed to do so by the
application. As a result, the application developer is responsible for
coordinating the execution of the different VR system components. This
can lead to complex applications.
As a virtual platform, VR Juggler does not use the model described above because VR Juggler needs to maintain control of the system components. This control is necessary to make changes to the virtual platform at run time. As the controller of the execution, the kernel always knows the current state of the applications, and therefore, it can manage the run-time reconfigurations of the virtual environment safely. With run-time reconfiguration, it is possible to switch applications, start new devices, reconfigure running devices, and send reconfiguration information to the application object.
Application objects lead to a robust architecture as a result of low coupling and well-defined inter-object dependencies. The application interface defines the only communication path between the application and the virtual platform, and this allows restriction of inter-object dependencies. This decreased coupling allows changes in the system to be localized, and thus, changes to one object will not affect another unless the interface itself is changed. The result is code that is more robust and more extensible.
Because the application is simply an object, it is possibly to load and unload applications dynamically. When the virtual platform initializes, it waits for an application to be passed to it. When the application is given to the VR Juggler kernel at run time, the kernel performs a few initialization steps and then executes the application.
Since applications use a distinct interface to communicate with the virtual platform, changes to the implementation of the virtual platform do not affect the application. Changes could include bug fixes, performance tuning, or new device support.
By treating applications as objects, we can mix programming
languages in the VR Juggler kernel. For example, an application
object could be written in Python, C#, or even VB.NET, but the VR
Juggler kernel (written in standard C++) will still see it as an
instance of the abstract interface
vrj::App. The use of application objects has allowed such
extensions to VR Juggler to be written without requiring any changes
to VR Juggler.