 |
VR-Forces Development_Version Class Documentation
|
All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Groups Pages
|
VR-Forces Development_Version Class Documentation
|
Entities are represented in the scene by scene objects, to which models are attached.
The GUI APIprovides some common kinds of entity primitives. These are called facades and show how models and model instances are added to a scene object.
Although you can place individual entities in a scene using the DtEntityFacade, it is common to use a DtVrlinkConnection (which is created by one of the drivers based on the DtVrlinkDriver) to populate a scene. This section describes how entities are created within a connection.
Individual entities are handled by the DtEntityElementProcessor. The DtEntityElementProcessor is registered as a singleton instance with the DtVrlinkConnection. The DtEntityElementProcessor uses (or creates if it does not exist) a singleton instance of a DtEntityExistenceListener registered with the connection as "DtEntityListener" at construction; a different (derived) existence listener may be registered, but this must occur before the creation of the DtEntityElementProcessor. The DtEntityElementProcessor also looks up the DtVisualizerCreationSettings instance registered with the connection, which will be used to determine which visualizers need to be created when an entity is discovered (as described in 7.7.1.2 The Visualizer Creation Settings Manager). It also connects to the signal_visualizerCreationEnabled and signal_visualizerCreationDisabled signals of the DtVisualizerCreationSettingsSignaler, which tells the DtEntityElementProcessor when visualizers need to be created or deleted for entities, as well as allowing it to keep the DtVisualizerCreationSettings up-to-date.
When the DtEntityExistenceListener discovers a new entity, it allocates a DtVrlinkEntityStateListener for use with the entity, which in turn allocates a unique ID for that entity. The DtEntityExistenceListener sends a signal to the DtEntityElementProcessor informing it about the new entity, and includes the new DtVrlinkEntityStateListener as part of that signal. The DtEntityElementProcessor then creates and initializes a DtEntityElement, using the unique ID allocated by the DtVrlinkEntityStateListener as the entity's DtElementID. The DtElementID can be used to look up the DtVrlinkEntityStateListener or the DtEntityElement for that entity. The new DtElementID is registered with the DtEntityElementProcessor's DtAggregateEchelonManager, and finally, the DtEntityElementProcessor raises its signal_elementCreated signal (which includes both the new DtEntityElement and its associated DtVrlinkEntityStateListener).
When constructed, the DtEntityElement looks up the name of the element definition for its entity type. When it is initialized by the DtEntityElementProcessor (by calling DtEntityElement::visualize()), it looks up the DtEntityElementProcessor instance (in the connection) and, for each model set that can be visualized (please see 7.6 - Scene Objects for a discussion of model sets), creates a DtEntityVisualizerSet. Each DtEntityVisualizerSet is in turn initialized by calling DtEntityVisualizerSet::visualize() with the name of the element definition to use and the DtVisualizerCreationSettings from the DtEntityElementProcessor.
DtEntityVisualizerSet::visualize() looks up the DtElementDefinitionTypeManager instance (also in the connection), and then looks up the DtElementDefinitionNew for the element definition argument in the DtElementDefinitionTypeManager. It then calls its base class DtVisualizerSet::visualize() method with the element definition name, the DtElementDefinitionNew that was looked up, and the DtVisualizerCreationSettings from the DtEntityElementProcessor.
DtElementDefinitionNew contains a DtVisualizerDefinitionSet for every model set defined. Since the DtVisualizerSet was initialized with its model set specified, it can find the DtVisualDefinitionSet for the model set it needs to visualize. The DtVisualizerDefinitionSet is a list of DtVisualizerDefinitions, that describe the visualizers that exist for the entity in this model set. The DtVisualizerSet iterates through the DtVisualizerDefinitionSet, and if the DtVisualizerCreationSettings indicates that visualizers with the visual type of a DtVisualizerDefinition, that DtVisualDefinition will be realized into some type of DtStateVisualizer, using the DtStateVisualizerFactory.
DtVisualizerCreationSettings indicate that a visualizer should not be created for a given model set only if that visualizer has a visual type that has been specified in the DtVisualizerCreationSettingsManager::VisualTypeVisualizerCreationStrategyMap(see) as being 'create-as-needed' and that visual type is not currently being displayed for any observer using that model set. Note that many visualizers have no real defined visual type (and so have their visual type set to 0). These visualizers will always be created. The defined visual types are:
By default, these all have the 'create-as-needed' strategy. The visual type is assigned to a visualizer definition (and on the DtStateVisualizer that realizes it) in the Visual Definition Editor.
The DtVisualizerCreationSettingsManager maintains a map of visualizer creation strategy (either create-always or create-as needed) by visual type. It can also provide, on request, a map of which visualizers, based on visual type and model set, should be created given that visual type's creation strategy and the current observer settings in use. That map is wrapped in a DtVirtualBaseClass called DtVisualizerCreationSettings. So if, for example, the creation strategy for visual type "track_histories" is create-as-needed and none of the observers that are currently using an observer mode that both uses model set 0 and has track histories enabled, then visualizers with the "track_histories" visual type do not need to be created for model set 0.
When a new connection is created, it will ask the DtVisualizerCreationSettingsManager to create and initialize a DtVisualizerCreationSettings object and register it with the connection. It will then be available for the DtEntityElementProcessor that the connection will subsequently create, providing it with an up-to-date initial state. The DtVisualizerCreationSettingsManager also listens to changes to observer mode selections and observer mode model set and settings changes, and generates signals whenever it becomes appropriate to enable or disable the creation of a specific visual type for a given model set. The DtEntityElementProcessor listens for these signals and updates its DtVisualizerCreationSettings, as well as creating or destroying visualizers as needed for entities that already exist.
To visualize aggregates, you must first be connected to a communications protocol. This can be DIS, HLA13, HLA1516 or HLA Evolved and occurs in the respective simulation driver. Once connected, there must be traffic on that network that VR-Vantage can identify as an aggregate. This happens when an application publishes an Aggregate State PDU on the network. When VR-Forces recognizes this PDU, it internally maps the entity type of the aggregate to an aggregate element definition.
A visual definition is a series of visual components that are used to visualize an object on the 2D overlay or as 3D geometry. An aggregate visual definition will usually contain the following visualizers:
The DtVrlinkAggregateExistenceListener listens to the network. For each aggregate, it communicates with the DtAggregateElementProcessor to create new aggregate visuals. The DtAggregateElementProcessor, when notified of a new aggregate, creates a DtAggregateElement. For each visualized model set, the DtAggregateElement creates a DtAggregateVisualizerSet. This DtAggregateVisualizerSet uses the supplied visual definition set (as discovered from the aggregate type mapping) to visualize the elements contained within.
The DtAggregateElementProcessor also uses the DtAggregateEchelonManager class to manage the echelon hierarchy. The DtAggregateEchelonManager manipulates a DtElementIDHierarchy in order to keep parent/child relationships of elements that are created in the system. The DtAggregateElementProcessor is also responsible for hiding and showing aggregate elements based on the DtAggregateSettingsRecord as well as the expanded/collapsed state of the aggregate. This expanded/collapsed state is communicated from the UI thread to the simulation driver thread via element attributes, specifically the DtElementIDHierarchyDisplayStateAttribute attribute.
As the entities are placed in the scene, the ones that support emitter systems are created with emitter volume visualizers (DtVrlinkEntitySensorVolumeVisualizer for 3D model sets, and DtVrlink2DEntitySensorVolumeVisualizer for 2D model sets). These visualizers listen for the creation and destruction of emitter systems by connecting to the signals emitted by the emitter system existence listener (DtEmitterSystemExistenceListener).
When an emitter system (DtEmitterSystemRepository) is created, a custom implementation is used (DtVrlinkEmitterStateInterceptor) to intercept calls that change the state of the emitter system and signals the emitter system's state listener (DtVrlinkEmitterStateListener). Visualizers now connect to the additional signals provided by the state listener (for more detailed information about the syste's emitter beams and overall configuration), and creates a visual representation for all emitter beams already attached to the discovered emitter system. As new emitter beams are discovered, or when existing emitter beams change, the visualizer updates the emitter volume visualization accordingly.
[<< Scene Objects] [Home] [Top of Page] [Props >>]