DIRSIG

We often want the ability to add clouds to a large scale scene in order to see the reflective, transmissive and shadowing effects on the scene. In these cases we are not so much concerned with the absolute radiometry of the clouds (true multiple scattering, exact modeling of limb regions, etc..), as we are with capturing bulk effects (single-scattering contributions, transmission effects, realistic spatial distributions, etc..). With these cases in mind, and to support modeling of the next generation Landsat sensor, we are developing a simplistic and very fast large-scale cloud model based on using the USAF Cloud Scene Simulation Model ( CSSM ) and OPAC data to generate voxelized representations of inherent optical properties. DIRSIG uses this data to drive a simple radiative transfer model that captures the bulk of the radiometric effects on the scene with very little additional computation overhead. The process is currently going through a period of validation and refinement and sh

Three weeks ago we announced a "release candidate" for DIRSIG 4.4.0. In the time since, we had quite a few early adopters try out 4.4.0 and provide us with feedback. Those improvements and bug fixes have now been incorporated into the official release of DIRSIG 4.4.0, which is now ready for download on myDIRSIG for registered users. Like we said at the time of the release candidate, we are very excited about this release as it packs in a bunch of new features and performance improvements: New User Interface Tools Graphical simulation preview Basic image viewer Component browser SGP 4 Orbiting Platform Motion Wizard Geometry Improvements Added affine transform INFO option to ODB Ray-trace optimization for dynamic (moving) scene geometry Support for vertex normals (normal "shading") on OBJ input geometry Atmosphere Added the GUI for the built-in "uniform" atmosphere model User-defined MODTRAN profile support (make_ adb config

Over the past few years we have been doing more simulations of video systems. Perhaps you have seen the video simulation of MegaScene1 with the cars driving down the streets as would be acquired from a circling UAV: So how do we make these videos? It is really a simple tool chain involving a tool that is distributed with DIRSIG and another tool that can be downloaded from the web. For this example, we are going to deal with a 2D framing array type system and that has a red, green and blue (RGB) channel set being captured (read out) on a regular interval: DIRSIG itself doesn't generate video files directly, but you can employ DIRSIG to generate the individual frames for a video and them combine them. This workflow breaks down into a three (3) step process: Instruct DIRSIG to output each capture (or "frame") of the focal plane to an individual file. Convert each floating-point radiance image file to a 24-bit (8-bits per channel) RGB image file. Encode the RGB image files

When we first started on the DIRSIG model in the late 1980s, 3D computer graphics was still in its infancy. At the time, standard file formats for 3D geometry were still being established. In addition, the DIRSIG model had the need for a specific set of per-facet attributes (material ID, thickness, override temperature, etc.) that are still somewhat unique in the 3D modeling community. As a result, the DIRSIG specific Geometric Database (GDB) format was created and is still used to this day. In the mean time, a variety of 3D geometry file formats have become widely used. Although the GDB format serves our needs well, it requires the user to translate the 3D geometry assets from other formats in order to use them with DIRSIG. Lately we have been experimenting with using the Alias/Wavefront OBJ file format as a possible replacement for GDB. The important features of the OBJ format are: It is widely supported by 3D geometry authoring tools (Rhino, SketchUp, Blender, etc.). It supports per

In the DIRSIG 4.4.0 release users will find that we made some modest improvements to the classic Urban and Forest scenes. Primarily, we improved the scene geometry by replacing the decade old, low facet count trees with the high fidelity trees we have been using in other scenes. We have also cleaned out a bunch of unused files and tried to improve the organization of the respective scene directories. The first thing you will notice in the updated Urban scene (seen above) is the new trees and the fact that there is more than one tree species. The scene also has some new textures for the grass and asphalt areas. This scene now has both day/night and summer/winter configurations. The "night" .scene files have the streetlights automatically enabled. The "winter" .scene files use defoliated trees. You might ask why the river running down the middle of the scene is so green in color. The river is modeled as a flat surface with an effective reflectance measured from s

One of the ways we try to teach users about specific features is by making a "bare bones" simulation as a demonstration of that feature. These "demos" don't usually generate a very exciting output data product, but they are fully self-contained (no external data required) simulations that focus on how to configure a specific feature. We have been distributing our growing set of demos with DIRSIG releases for some time. In DIRSIG-4.4.0, we tried to make demos easier to use. The "demos" folder now includes a top-level HTML index file. On a Windows installation, this HTML index is can be opened by clicking the "Demonstrations" item in the "DIRSIG 4" sub-menu of the Start menu. On Mac and Unix/Linux, just open $DIRSIG_HOME/demos/index.html in your browser. This shows a thumbnail image for each demo and gives a brief description of what the example demonstrates. Note the "Download this demo" link under each description. Whe

Here is a look at the input files that go in to a DIRSIG simulation. Each icon in the dirsig_edit tool corresponds to an XML file: Behind the scenes, these files are given the following extensions: .scene .atm .platform .ppd .tasks .options The options file is, by happenstance, optional. So what goes in to the ".sim" manifest file? It's simply a list of the files assigned to each component. A typical sim file looks as follows: <simulation> <scene externalfile="../../warehouse.scene" /> <atmosphericconditions externalfile="./warehouse.atm" /> <platform externalfile="./warehouse.platform" /> <platformmotion externalfile="./warehouse.ppd" /> <tasklist externalfile="./warehouse.tasks" /> </simulation> See? Nothing more than a list of files. You can also see the relationship between files and components from within dirsig_edit. Jus