Each driver provides the same set of capabilities, with minor exceptions based upon the protocol. These drivers visualize entities and interaction effects such as detonations. They also handle advanced visualization features such as track histories. You can have multiple simulation drivers added to the display engine, each with a different configuration. Each instance of a simulation driver is referred to as a simulation connection. You can save exercise configurations and easily switch between connections.

6.2.1 Stopping and Starting Simulation Drivers

A simulation driver's state is controlled by its connection state. When a simulation driver is not connected to a simulation, it is in the stopped state. A simulation driver enters the running state (starts) when it successfully connects to a distributed exercise. While the simulation driver is connected to the exercise it continues to run. Disconnecting from the exercise causes the driver to stop.

6.2.2 Using Shared Source Files for Simulation Drivers

VR-Forces simulation drivers use VR-Link, which provides a single interface for multiple simulation protocols. Because the interface is largely the same for both DIS and HLA, almost all protocol-specific classes are written once and compiled multiple times (for each simulation protocol). Each class is compiled into a separate namespace to eliminate duplicate symbols. Shared source classes are written in header (.h) files and inline (.inl) files. However, the inline files are not included by the header files. All shared source inline files are included in a single source (.cxx) file to be compiled for the particular library that defines the namespace.

6.2.3 Simulation Driver Classes and Namespaces

The functionality of the distributed simulation drivers is implemented in a small number of associated classes and patterns in addition to the primary driver class.

To distinguish between classes with the same name, a different namespace is used under the main makVrv namespace. For example the DtVrlinkConnection class represents the simulation connection. The DIS protocol library is call vrvDis. The complete name of this class is makVrv::vrvDis::DtVrlinkConnection. In the header and inline files the namespace is defined using a macro, DT_PROTOCOL_NAMESPACE, which is redefined for each library that recompiles the code.

6.2.4 Connections

Each driver class has a connection class called DtVrlinkConnection, which manages the VR-Link exercise connection and registers listener classes. The connection class manages DtVirtualBaseClass instances. It deletes all instances before disconnecting by deleting the exercise connection at the appropriate time.

A connection registers listeners.

6.2.5 Listeners

A listener class provides signals for a particular type of data. The templated class DtInteractionListener can listen to any VR-Link interaction class. The DtFireInteractionListener is an example of a specialization that listens for instances of the DtFireInteraction class to be received. Stateful objects such as entities have two levels of listeners. The main instance listener class DtEntityExistenceListener listens for newly discovered entity instances and signals when existing instances are deleted. For each entity that is discovered, there is a DtEntityStateListener, which listens for changes to a particular entity's state and signals when attributes change. Listeners are created lazily on demand from a visualizer or a processor. Listener classes inherit the DtVirtualBaseClass and should be registered with the connection to ensure that they are destroyed before the exercise connection is destroyed.

Note: Typically there is only one instance of a listener, because instances are registered with the connection instance of a driver. Individual state listeners are an exception. They are owned by the instance listener, which follows this rule.

6.2.6 Visualizers and Processors

Visualizer classes and processor classes use listeners to make visualization calls or data processing calls. Visualizer classes do not follow any pattern or class hierarchy other than that they connect to the signals of a particular listener and create scene object and model agents, which interact with the scene. An example of a visualizer is the DtFireInteractionVisualizer, which creates a muzzle flash effect in the scene for each DtFireInteraction that is received. A processor class is similar to a visualizer, but it does not make agents. An example of a processor is the DtViewControlProcessor, which receives custom Stealth Control messages and makes calls that control observers.

Usually there is only one instance of a particular type of visualizer or processor. While not required, it is useful to register the instance of the visualizer or processor with the connection to ensure proper memory management. Visualizers and processors can be dynamically added and removed from a connection. The Driver Accessories pattern lets you add visualizers to existing driver instances, thereby extending the functionality without modifying the existing capabilities.

[<< The Input Driver] [Home] [Top of Page] [Adding Functionality to a Driver (Accessories) >>]