DIRSIG5 JSON Simulation File

The DIRSIG4 era XML simulation file contained a specific list of input files to describe the single scene to be used, the atmospheric conditions for that scene and the sensor collection description.

To provide backward compatibility with DIRSIG4 era simulations, the DIRSIG5 main executable has an XML input simulation file parser that configures the appropriate plugins that provide DIRSIG4 capabilities. Under the hood, the BasicAtmosphere plugin handles DIRSIG4 atmospheric modeling responsibilities and the BasicPlatform plugin handles the data collection responsibilities.

In addition to using the plugins distributed with DIRSIG5, end users will eventually be able to create their own plugins to use with their simulations. In order to directly configure which plugins are to be used and what inputs should be supplied to them, a new simulation input file was needed. The new simulation input file is a JSON formatted document that contains a list of scenes and a list of plugins to be utilized in the simulation. The example below is the JSON equivalent of the XML simulation file example from the last section:

The top-level components of the file are the "scene list" and "plugin list". These will be described further in the following sections.

For this mode, each entry in the scene_list array utilizes the following variables:

In this mode, each entry in the scene_list array utilizes the following variables:

In order to avoid the headaches of manipulating massive scene geometry models, a common approach to large-area scene construction has been to divide the scene into multiple "parts" or "tiles". This is the approach that has been used at RIT for scenes including MegaScene1. In the case of MegaScene1, each tile of the five tiles were constructed using a shared Scene ENU coordinate system, which means each scene file has the same geographic location for the Scene ENU origin. In DIRSIG4, these scene tiles had to be combined by having either a GLIST or scene file combine the geometry for the desired scenes (e.g. tile_1.scene, tile_1_2.scene, tile_1_2_3.scene, etc.). In DIRSIG5, these scenes can be combined at simulation time by providing the list of scene files that describe each tile.

The user can also utilize this approach to combine scenes that do not share a common Scene ENU coordinate system. In the example below, we combine the Urban scene (downtown Rochester, NY) with MegaScene1 (a suburb just north of Rochester, NY) into a single scene list.

To be clear about what is happening here, the Urban scene uses a geographic location to tie its local Scene ENU coordinate system to the Earth in one location and the MegaScene1 scene has it’s own geographic location that ties its local Scene ENU coordinate system to another location on the Earth. These two scenes are near each other in the real world, but these scenes don’t actually meet at the edges. Hence, there is a gap between them. If a wide-area image of the Rochester region was generated, both scenes would be visible at there respective locations in the simulation output.

Because of the precision required in the geolocation, it can be difficult to align separate scenes to cleanly meet at the edges without gaps. Therefore, when constructing a scene using a tiling method, it is strongly encouraged to use a shared coordinate system and a single geolocation for each tile. However an alternative method is also available, which is discussed next.

It should be noted that you can combin the scene file and scene folder methods:

When relying on the geographic location of the location scene origin in individual scenes to perform relative layouts, the user can quickly get frustrated with precision and projection issues associated with the manipulating geographic locations in order to align scene edges. To simplify that process, individual scenes can be constructed in a single local Scene ENU coordinate system and then offset relative to each other when provided to the simulation. The ModularCity1 demo uses this approach to construct a simple city by quilting together an 11 x 11 set of modular city building blocks that are each 100 x 100 meters. The offset for each scene specifies where that scene is relative to the first scene in the list.

Important Notes:

The previous discussion focused on "tiling" approaches, where individual scenes do not overlap. However, combined scenes can overlap as well. Consider a scenario where the user creates a city and is modeling different traffic patterns through the city. Rather than have a single large scene that combines the baseline city geometry (buildings, roads, etc.) and a specific state of traffic, the user could separate the baseline city from the traffic. The city.scene would contain only the baseline city geometry (buildings, roads, etc.) and separate "traffic" scenes would contain only the vehicles and dynamic instance data describing the path those vehicles follow through the city. Each traffic scene could capture a different traffic pattern scenario and the city and traffic can be combined at simulation time (see below):

Alternatively the user can combine that same city scene with a less busy traffic pattern for the weekend.

Since the cars are driving along roads in the city, it would be easiest to use a shared Scene ENU coordinate system when constructing the scenes.

Some plugins in DIRSIG5 are "combination plugins", which means that a single plugin implements several plugin types. For example, the ChipMaker plugin is a sensor plugin, an atmosphere plugin and an ephemeris plugin.

The plugin list allows the user to configure multiple plugins to be used in the simulation. Some plugin types allow multiple instances of the plugin to be used in the simulation. However, for a subset of plugin types, DIRSIG5 assumes there will only be one plugin supplied. The table below outlines which plugin types support multiple instances.

It is possible that a plugin list will include more than one plugin for a plugin type that only supports a single instance of that plugin. For example, the user might mistakenly configure one or more weather plugins. When this occurs, subsequent plugin requests for that plugin type will override the previous plugin request. For example, if the user requests a weather plugin named WeatherA and then WeatherB, the WeatherB plugin is the one that will be used in the simulation. The simulation startup will communicate this override in the configuration: