DIRSIG Model Introduction

The DIRSIG model has been under development since the late 1980s. However, the software has undergone multiple, ground-up rewrites since it’s inception. The brief timeline outline below summarizes the history of code development.

Since DIRSIG5 does not support some features that DIRISG4 did (and vice-versa) the following comparison can be useful.

The DIRSIG radiometry engine is driven by a ray tracer which finds intersections with geometric elements within the scene. A ray is defined by a direction vector, an origin that it emanates from and (optionally) a length. The geometry of the scene can be described by planes (infinite extent), facets or polygons (planes with finite extent), and other mathematical primitives including spheres, boxes, cylinders, etc. An intersection calculation is simply finding the mathematical solution to where the ray equation and the equation for the geometric object intersect (for example, the point where the equation for a line and a plane intersect). In it’s most primitive form, a ray tracer works by identifying objects that intersect a given ray through a brute-force search. However, once the number of scene objects becomes large, this approach becomes computationally inefficient. The DIRSIG ray tracer employs a variety of spatial sorting optimizations that minimize the number of geometric objects that must be checked for intersection.

In most cases DIRSIG employs "reverse ray tracing", where rays are traced into the scene from the sensor looking at the scene. In this approach, the ray tracer quickly finds objects that can be seen by the sensor, but strategies must be employed to figure out the illumination onto those objects. DIRSIG also employs "forward ray tracing", where rays are traced into the scene from the "sources" (e.g. the sun, the moon, the sky, user-defined sources, etc.). In this approach, strategies must be employed to figure out which objects can be seen by the sensor. Finally, DIRSIG utilizes some hybrid approaches that employ both forward and reverse ray tracing.

The DIRSIG5 software is constructed and deployed differently than DIRSIG4 was. DIRSIG5 is constructed around a arelatively stable "radometry core" and most features are provided via a series of plugins rather than features to a monolithic compiled code. This helps provide feature modularity and allows the radiometry core to establish stable and well tested APIs through which these plugins communicate to the radiometry engine. The current DIRSIG5 software includes a set of plugins that provide backward compatibility with existing DIRSIG4 simulation configurations. The list of the documented plugins employed by DIRSIG5 can be found in the plugins manual.

In DIRSIG4, the speed and fidelity of the simulation could be controlled through a series of configuration choices and settings spread across the material configurations and sensor modeling parameters. The two primary mechanisms utilized by users were:

In general, users were often observed dialing down the fidelity of a DIRSIG4 simulation (using these two mechanisms) in order to meet compute time targets. Furthermore, there wasn’t an easy "single knob" interface to DIRSIG4 to control the fidelity vs. time trade off.

In DIRSIG5 there are no radiometry solvers because it utilizes a new, unified numerical radiometry calculation. DIRSIG5 uses path tracing, which follows a single ray path from the pixel to either a source of energy (sun, moon, sky, light, etc.) or a termination (absorbed). Since this approach is emulating a Monte-Carlo integral of all the light paths reaching a pixel, the fidelity of the solution is proportional to how many samples (paths) are used. This "number of paths" parameter provides the sought after single knob interface controlling fidelity vs. time for the model. When a small number of paths are used, the resulting radiance estimate will be noisy. As more paths are used, the estimate improves. Controlling the number of paths per pixel is discussed in the DIRSIG5 Command-Line Guide.

Unlike DIRSIG4, the DIRSIG5 code is multi-threaded. That means more compute resources can be utilized for micro-scale parallelization on a multi-core computer. Controlling how many threads are used by the model is discussed in the DIRSIG5 Command-Line Guide.

DIRSIG5 releases include a Message Passing Interface (MPI) enabled executable that will allow the software to distribute computations on clustered computing resources. Details about using the MPI-enabled version of DIRSIG is described in a supplementary manual.

Future releases of DIRSIG5 may utilize NVIDIAs CUDA and OptiX frameworks for GPU-accelerated ray tracing, which currently accounts for approximately 60% of the execution time. Numerous prototypes have been created but none of them have yielded a viable solution. Hence, DIRSIG5 is not GPU accelerated at this time.

One of the key features of the DIRSIG model is that all modalities are simulated from a common scene description. The synthetic world that is employed is composed of 3-D geometric constructs (polygon geometry, mathematical objects and voxelized geometry) that are assigned a material description (see Figure 1). Users can create 3-D polygon models with a variety of 3-D asset creation tools including AutoCAD, 3ds Max, Rhinoceros, Blender3D, SketchUp, etc. This material description includes thermodynamic properties to enable temperature prediction and optical properties to drive the radiometric prediction. Instead of a discrete suite of modality specific models, the currently supported modalities all share the same geometric and radiometric core, which insures phenomenological agreement across modalities. For example, the same specular paint BRDF for a car hood would be used when simulating both a passive RGB camera and an active LIDAR system. If a vehicle is painted black, it will be warmer than a lighter colored material in the thermal infrared because of the differences in solar absorption. The scene database also supports dynamic object positioning, which allows objects like vehicles to be linked to external traffic simulators (for example, the Simulation of Urban MObility (SUMO) model) or collection scenario planning and management tools including System Toolkit (STK).

The DIRSIG sensor module was designed to provide a framework upon which a myriad of multi-modal sensors could be implemented. Passive imaging systems can range in complexity from single-pixel scanning architectures, to modular pushbroom arrays to 2-D imaging arrays. The geometry (pixel sizes and locations) of an imaging array is separated from the "capture" of incident energy by that device. This allows a 2-D array to be combined with either an array wide filter or a color-filter array (for example, a Bayer pattern) to capture multi-spectral imagery. To model a hyper-spectral system, the same 2-D array can be combined with a dispersive or refractive element to create the spatial separation of the incident spectral flux. A LIDAR receiver array analyzes the incident temporal flux to determine when a return is detected. However, a real or synthetic aperture radar system employs an entirely different family of radiation measurement technologies. In these systems, the user is describing an antenna array and the radial gain function.

The DIRSIG model also features an advanced data acquisition model that centers on the concept of a "platform" that can have one of more imaging or non-imaging sensors attached to it. The platform model allows sensors to be positioned relative to one another and synchronized by central clocking mechanisms. This platform can represent a variety of data acquisition platforms ranging from a fixed tripod, to a driving van, to a flying aircraft to an orbiting satellite (Brown 2011). The platform model also supports flexible command data interfaces to control the position and orientation of the platform as a function of time (e.g. vehicle route, aircraft flight line, etc.) as well as dynamic platform relative pointing interfaces (scan patterns, camera ball pointing, etc.). The images in Figure 2 and Figure 3 are simulated data products for the same scene, but were collected by separate airborne LIDAR and color image systems. In addition to employing different sensor modalities, these two sensors were imaged from different platforms at different times of day.

The primary sensor and platform model in DIRSIG5 is provided by the BasicPlatform sensor plugin.

This level represents the highest level of readiness on the scale. That does not mean that there is no room for improvement, but it does indicate that the application area has been well exercised by the team at RIT and the user community as a whole. Documentation and examples for this level are usually abundant.

This level corresponds to features that are becoming finalized. Documentation and demonstrations (examples) at this level are well established but (perhaps) not complete. End users should utilize features at this level with caution and expect minor bugs and well documented limitations.

This level represents a capability that has achieved the most basic form of usability. Documentation for capabilities at this level are usually non-existent or ad-hoc. Interfaces to the model may change as the capability is refined and matured. End users should utilize features at this level with extreme caution and expect bugs and undocumented limitations.

This level is associated with new research areas that are being researched by the team at RIT, but which is not currently available to the end-user in any form. Some research in this area may never make it out of this state.