3.1 - The Object Manager and Simulated Objects

Table of Contents

• 3.1.1 Creating the Object Manager
• 3.1.2 Simulated Objects
• 3.1.3 Local and Remote Objects
• 3.1.4 Spatial Organization of Objects

All VR-Forces applications have an instance of a DtVrfObjectManager (vrfObjMgr.h).

It is one of the top-level managers maintained by the DtCgf class. The Object Manager creates and maintains local objects. It also instantiates local instances of remotely simulated objects. Generally speaking, a simulated object is an individual entity, a unit, or a control object. The Object Manager maintains lists of each object type. It provides a callback mechanism to notify applications when objects are added or deleted. If you need to know about an object, you go to the Object Manager.

The Object Manager reads the object parameter database and uses this information when objects are created. It is also responsible for reading and writing the order of battle file. The Object Manager registers with the Simulation Manager’s message executive to receive all DtDeliverRadioMessageType messages, and directs them to the appropriate radio channel.

The Object Manager monitors the network for state updates from remote objects in an exercise and for VR-Forces-specific state information. When it detects the presence of a new remote object, it creates a new remote DtVrfObject to represent it and adds it to list of objects to be managed.

The Object Manager is responsible for saving and restoring the state of locally simulated simulation objects as part of a scenario or checkpoint. It reads and writes the order of battle file. It uses the DtReaderWriter mechanism to save/restore itself to file. (For details, please see 16 - Reading and Writing Files.) Almost all of the data members in the state repositories can read and write their data, and therefore are saved as part of an object’s entry in the order of battle file.

3.1.1 Creating the Object Manager

The Object Manager is one of the manager objects created by the DtCgf object. The DtCgf object takes responsibility for deleting the Object Manager at the end of the simulation. You can create your own derived Object Manager. For a description of the process, please see 2.4.2 The VR-Forces Creator.

3.1.2 Simulated Objects

All simulated objects are instances of DtVrfObject (vrfObject.h). The different types of simulated objects (entities, units, and control objects) are not distinguished by the classes used to instantiate them. For example, there is no control object class or ground vehicle class. Instead, object types are distinguished by the managers, interfaces, and state repository that they have.

Note

In this manual, we use the following terms as indicated:

• Object. Unless the context clearly indicates otherwise, we are referring to simulated objects (DtVrfObjects).
• Entity. An individual vehicle, human, or other lifeform.
• Unit. A simulation object that represents multiple entities, units, or both. A unit whose subordinates are also modeled is called a disaggregated unit. A unit whose subordinates are not modeled is an aggregated unit.
• Simulation object. A generic term that refers to entities and units collectively.
• Tactical graphics. Point, line, areal, and text objects that can be drawn on the VR-Forces window. Simulation objects may be able to interact with them, such as following a route or moving to a waypoint.
• Simulation graphics. Linear and areal objects that can be drawn on the VR-Forces window that automatically affect simulation object behavior. For example, simulation objects avoid obstacles as part of innate behavior. You do not have to explicitly tell a simulation object to avoid them.

Note

When we refer to an object’s subcomponents in this page, we do so in a highly generic sense of the term. We are not referring to the component architecture used to model behavior. For details about the component architecture, please see vrfComponent Concepts.

All objects have:

• An object type - an 8-digit superset of the DIS/RPR FOM object type enumerations. For example, the object type for an M1A2 tank is 1 (1 1 225 1 1 3 -1).
• Parameters - values that a user can configure, and which are stored in an object parameter database.

DtVrfObjects contain instances of the following items through a has-a relationship:

• Identifiers:
  • Object name (DtString) - a unique string used to identify the object within the exercise, and which can persist from session to session.
  • Object identifier (DtObjectId).
  • Global object designator (DtGlobalObjectDesignator).
• Object Label (DtString)- a text string that can persist beyond a particular run of an exercise and does not have to be unique. (For details, please see 3.2.7 The Object Label.)
• A configurable set of the following subcomponents:
  • State repository (DtVrfObjectStateRepository).
  • Network interface (DtSimObjectNetInterface).
  • Organization Manager (DtOrganizationManager).
  • Task Manager (DtSimTaskManager).
  • Plan Manager (DtVrfObjectPlanManager).

  • Component Manager (DtSimComponentManager).

All objects have a state repository and network interface. Control objects have only these two subcomponents. Only simulation objects (entities and units) use the other subcomponents. State repositories and network interfaces are described in this chapter. The other subcomponents are described in 4 - Simulation Objects.

3.1.3 Local and Remote Objects

From the point of view of a particular VR-Forces application, a local object is any object that it simulates. A remote object is an object that is received over the network from another application. A VR-Forces application participating in an exercise may know about both local and remote objects.

There are two categories of remote objects - objects simulated by VR-Forces applications, and objects simulated by applications other than VR-Forces, such as the VR-Link F18. When VR-Forces learns about a non-VR-Forces remote object, it knows only what is transmitted in the standard DIS or HLA message. By contrast, VR-Forces objects share additional state information over the network, such as echelon ID and label.

The figure illustrates how objects simulated by different VR-Forces applications and a non-VR-Forces application appear to VR-Forces applications. In this figure, application 1:3001 simulates a waypoint and a fixed-wing entity. Application 1:3002 simulates a tracked entity. A non-VR-Forces application is also running on the network.

Local and Remote Objects as Seen by VR-Forces

3.1.4 Spatial Organization of Objects

The DtVrfObjectManager class contains a DtSpatialVrfObjectManager, which it uses to spatially organize specified DtVrfObjects. A filter function predicate determines which DtVrfObjects are spatially sorted, to let you easily change the sorting in a derived class. Additionally, the creation, initialization, and use of the DtSpatialVrfObjectManager class is all performed in the appropriate functions, allowing for user modification.

A simple algorithm is used to determine the spatial organization configuration (number of subdivisions in each dimension). Also, all DtVrfObjects are stored in the Spatial Manager, including routes, waypoints, and so on.

To access the spatially sorted vrfObjects, the getVrfObjects() functions are provided to get all vrfObjects that may intersect the specified primitive (currently only DtChord or DtExtent). The resulting set contains all objects that may intersect the chord or extent. Not all are guaranteed to do so, but the set will not be missing any that actually do. If the exact intersection is required, as for line-of-sight testing in the vrfObjectStateRepository, then further refinement is required.

[Home] [Top of Page] [How the Object Manager Creates an Object >>]