As stated in the section about the microkernel, internal managers are responsible for system tasks that are beyond the scope of the kernel. The internal managers capture the commonality of tasks such as managing the current input devices or tracking the current state of the configuration system. The remainder of this section describes the major internal managers.
The Input Manager controls all manner of input devices for the kernel. The input devices are divided into distinct categories, including position devices (such as trackers), digital devices (such as a wand or mouse button), analog devices (such as a steering wheel or joystick), and glove devices (such as a CyberGlove™). VR Juggler defines a class hierarchy for the all of these types of input devices (see Figure 4). There is base class for all input devices that specifies the methods that must be implemented to start, stop, and update the device (see vjInput Figure 4). There is also a base class defined for each distinct category that specifies the generic interface that any device of that category must support. For example all positional devices must derive from vjPosition support a getPosData() member function that returns a position matrix.
To add support for new devices, developers create a new class for the specific device. The new class must be derived from the base classes of the input types that the new device can return (Figure 4). For example, a device that can return analog and positional data is derived from vjAnalog and vjPosition. The new class has to implement the member functions of the base input device interface as well as the methods for returning the input type of each of the parent classes.
The application uses device proxies [#Design patterns] to interface with all devices. Before an application gets data from a device, it must first get a proxy to the device. The application requests the device using the name given to it in the current configuration. The input manager looks up the requested device name, and returns a proxy to the corresponding physical device.
The main advantage of device proxies is that they allow the application to be decoupled from the physical device being used. The device referred to by a proxy can change at run-time. For example, a proxy may initially be linked to a hardware tracker in the system. If the user wants to change tracking systems, then the user points the proxy to a different tracker. The next frame, the application still uses the same proxy but the data returned is now coming from a different device. The proxy abstraction allows the configuration of the virtual platform to change during execution without disturbing the application.
VR Juggler uses a device store [#Object store] to allow the system to keep all device drivers separate from the main library and to dynamically load device drivers at run-time (see vjDeviceFactory in Figure 5). The device store is a factory object [#GOF] that keeps track of device drivers and associated device constructors that have registered with the system. A device constructor is a proxy that hides the exact type of a device driver and the method used to create new instances of the device. There is no coupling between the library and the device drivers, so the set of device drivers can vary independently.
When the input manager receives a configuration request to add a new device, it asks the store if it has a constructor that knows about the device name given. The store queries all the registered device constructors and if one of them knows how to instantiate a driver for the named device, then an instance of the new class is created and the configuration information is passed to it. A handle to the new device is then added to the input manager’s list of active devices.
The device store supports the addition of new devices at run-time or at link time by registering a new device constructor object with the device store. This allows a developer to add new device drivers without having to recompile an application. The application only has to be compiled with the associated device library or load the device library at run-time to have access to the new devices.
The environment manager allows vjControl to connect to a running VR Juggler application. VjControl, communicates with the environment manager via a network connection. The environment manager supplies data to the GUI and passes on instructions from the GUI to the kernel. From the vjControl user interface, it is possible to view and dynamically control every aspect the running virtual platform.
The display manager (see Figure 6) encapsulates all the information about the display windows' settings. This includes information such as size, location, graphics pipeline, and the viewing parameters being used. In addition to holding the display parameters, the display manager is also responsible for performing all viewing calculations for the windows it controls. This is done as part of the main kernel control loop.
The display manager is also used for communicating configuration requests to the draw managers in the system. When a new window is created in the system, the display manager handles the configuration request by adding the window to its internal state information. Then it triggers an update notification that notifies the draw manager of the new display window.