17.2 - The Physical World

Table of Contents

• 17.2.1 Terrain Database
• 17.2.2 Environmental State Manager
• 17.2.3 Spatial Organization of Simulation Objects
• 17.2.4 Sensor Propagation

The VR-Forces simulation engine has a single central class that contains all aspects of the world that simulation objects may want to interact with as they are simulated.

This class is called DtPhysicalWorld (physicalWorld.h), and is accessible from the DtCgf and the DtSimManager.

The primary aspects of DtPhysicalWorld are:

• The terrain database, including both polygon mesh of the terrain and the terrain feature data.
• The Environment Manager.
• Spatial organization of all simulation objects in the exercise.
• Sensor propagation though the environment.

DtPhysicalWorld contains methods for accessing all of these. It also has methods that combine various aspects of these parts of the world together to answer a single query, such as a line of sight query between two positions, which will take multiple aspects of the world into account.

17.2.1 Terrain Database

The DtPhysicalWorld class gives access to the terrain database to all other parts of the simulation. This can be done through direct access to the DtTerrainInterface class using the method terrainInterface(). There are also many terrain query methods on the DtPhysicalWorld class directly, such as closestTerrainLocation() and groundClamp(). Please see DtPhysicalWorld for the complete list and explanations of what these methods do. vrfTheTerrainAPI also has information about querying terrain databases.

DtPhysicalWorld also has a set of methods for doing coordinate transforms. These methods transform coordinates between the terrain database coordinate system (often referred to as the local coordinate system) and various other coordinate systems, such as geocentric and geodetic.

17.2.2 Environmental State Manager

The DtEnvironmentalStateManager is a sub-object of DtPhyicalWorld. You can access it through the method environmentalStateManager(). DtEnvironmentalStateManager maintains the current state of the dynamic environment, such as time of day, illumination, and various aspects of the weather. All access to this data from any behavior or dynamics model should be made to this class.

The environmental state data is distributed over the network. DtEnvironmentalStateManager maintains the current state of whatever the conditions are in the current VR-Forces scenario, even if they are being simulated and maintained by a different simulation engine.

The DtEnvironmentalStateManager also has methods for changing the environmental state parameters. When any of these methods are called, this class locates the simulation engine in the exercise that is simulating the environmental state, and sends commands to that simulation engine to change the state. As a result, any calls to these modification methods will result in the environmental state changing for all simulation engines in the exercise, not just the local application.

17.2.3 Spatial Organization of Simulation Objects

DtPhysicalWorld is also responsible for maintaining a spatial organization of simulation objects in the scenario. This differs slightly from the list of objects maintained by the DtVrfObjectManager in that the main purpose of this list is to be fast and easy to search using spatial searches. For example, searching to determine if a particular sight line is blocked by any simulation objects in the scenario, is done by querying the DtPhysicalWorld. Internally, a spatially organized structure is used and updated each simulation frame, to optimize the searching of simulation objects based on physical location.

All of these searches are done using the methods such as getVrfObjects() and visitVrfObjects(). There are various versions of these methods that take different spatial structures, such as DtExtent objects, DtChord objects, and others.

Note

The various spatial organization methods in DtPhysicalWorld typically return lists of simulation objects that may overlap with the specified geometry, but do not necessarily overlap. The list returned is guaranteed to contain all the items that overlap, but may contain additional items that do not. This is done for performance reasons, and additional checks need to be calculated by the client code if that level of accuracy is desired.

17.2.4 Sensor Propagation

DtPhysicalWorld also contains the sensor propagation models. Please see 7.1.1 Signature Sensor Concepts, for a description of how sensor propagation models are used by the sensor.

DtPhysicalWorld has a class called DtSensorSignatureManager that is accessible though the sensorSignatureManager() method. This manager contains DtSignaturePropagator subclasses that implement algorithms that determine how sensor signatures are altered by the environment. Sensor ranges and how sensors are blocked by terrain, environment state, and other factors are determined by these propagators.

The signature propagation model is used by calling one of the apparentObjectSignature() methods on the DtSensorSignatureManager. The string name of the sensor domain is passed in, as well as the target object and the viewer location. These propagators make use of the rest of the physical world class to determine the result.

[<< The Simulation Manager] [Home] [Top of Page] [The Settings Manager >>]