The transition from DIRSIG 3 to DIRSIG 4 was a major shift towards a more modern code architecture and a more flexible simulation design. The goal was to address the development challenges faced at that time and to be ready for the new features and capabilities that would come.
During the past few years, we have added new modalities (particularly LiDAR), new platform support (Windows), an entirely new GUI interface, native 3D radiative transfer code, extensive sensor and platform modeling, support for more complex scene radiometry, and many other features to support user needs. Every new piece of code has expanded, and in some cases, stressed, the underlying DIRSIG 4 framework and its original design. While this evolution has been successful functionally, we have made sacrifices to execution speed and our agility adapting to new challenges and projects well beyond the scope of what was imagined, or even possible, when that framework was constructed.
DIRSIG 5 (D5) represents another major shift in architecture, moving to a more modular design to support faster, isolated turnaround of new or improved features and allowing plugin functionality. We are also vigorously addressing simulation speed -- from the load time of scene properties and geometry, to the computation of radiometry -- exploiting hardware (GPU, multiple cores, etc..) wherever possible. We also recognize that the field of computer graphics has advanced significantly since the early days of DIRSIG when most of what is now considered to be fundamental technique had to be homegrown. In addition to having these ideas influence our design and tools, we are also attempting to use optimized and mature libraries to fulfill fundamental needs in the code (when licenses allow) -- giving us more time to focus on our fundamental goal of being a premier remote sensing simulation tool.
Development of D5 is still in its infancy, though we have made some significant headway during the past month. The architecture design is goal-oriented and we are letting it evolve as we attempt to find the best way to meet those goals (the following is not exhaustive):
A Short List of Specific Goals:
• Stable core with fewer major revision cycles
• Modular non-core design for platform/scene development and external plugins
• Shorter development cycles for new and improved, modular functionality
• Faster geometry intersections and rad solver solutions with GPU exploitation
• Better handling of large data files (property maps, dems, geometry/image files)
• Improved modeling of multiple, independent instruments and platforms
• Top-level scheduling of complex tasking and temporal interactions
• Optimized, universal matrix math library
• Top level, scriptable data model for all simulation component properties
• Improved extensibility of the GUI for advanced simulation interfaces
• Geocentric atmosphere, scene, and space models.
• Support for multiple scenes, atmospheric objects, and a background planet DEM
As D5 progresses, we will be posting occasional status messages here with performance statistics and demonstrations of new features and interfaces. We'd also like to use this space as a place for users to provide comments about the direction we are going in. Are we meeting your needs? Is there something you'd like to see in D5 that we aren't addressing? Keep in mind that we are mostly interested in the big picture goals right now -- we'll care more about new, specific functionality later on.
During the past few years, we have added new modalities (particularly LiDAR), new platform support (Windows), an entirely new GUI interface, native 3D radiative transfer code, extensive sensor and platform modeling, support for more complex scene radiometry, and many other features to support user needs. Every new piece of code has expanded, and in some cases, stressed, the underlying DIRSIG 4 framework and its original design. While this evolution has been successful functionally, we have made sacrifices to execution speed and our agility adapting to new challenges and projects well beyond the scope of what was imagined, or even possible, when that framework was constructed.
DIRSIG 5 (D5) represents another major shift in architecture, moving to a more modular design to support faster, isolated turnaround of new or improved features and allowing plugin functionality. We are also vigorously addressing simulation speed -- from the load time of scene properties and geometry, to the computation of radiometry -- exploiting hardware (GPU, multiple cores, etc..) wherever possible. We also recognize that the field of computer graphics has advanced significantly since the early days of DIRSIG when most of what is now considered to be fundamental technique had to be homegrown. In addition to having these ideas influence our design and tools, we are also attempting to use optimized and mature libraries to fulfill fundamental needs in the code (when licenses allow) -- giving us more time to focus on our fundamental goal of being a premier remote sensing simulation tool.
Development of D5 is still in its infancy, though we have made some significant headway during the past month. The architecture design is goal-oriented and we are letting it evolve as we attempt to find the best way to meet those goals (the following is not exhaustive):
A Short List of Specific Goals:
• Stable core with fewer major revision cycles
• Modular non-core design for platform/scene development and external plugins
• Shorter development cycles for new and improved, modular functionality
• Faster geometry intersections and rad solver solutions with GPU exploitation
• Better handling of large data files (property maps, dems, geometry/image files)
• Improved modeling of multiple, independent instruments and platforms
• Top-level scheduling of complex tasking and temporal interactions
• Optimized, universal matrix math library
• Top level, scriptable data model for all simulation component properties
• Improved extensibility of the GUI for advanced simulation interfaces
• Geocentric atmosphere, scene, and space models.
• Support for multiple scenes, atmospheric objects, and a background planet DEM
As D5 progresses, we will be posting occasional status messages here with performance statistics and demonstrations of new features and interfaces. We'd also like to use this space as a place for users to provide comments about the direction we are going in. Are we meeting your needs? Is there something you'd like to see in D5 that we aren't addressing? Keep in mind that we are mostly interested in the big picture goals right now -- we'll care more about new, specific functionality later on.
Comments
-- "Yes" to the idea of better handling of large data sets, in particular large texture maps, in particular large texture maps that happen to depict desert-like regions of Southern California, that may or may not contain the town of Trona. Loading those maps always killed the runtime.
-- Multi threaded! Any way you can auto-magically take advantage of multiple cores and/or multiple nodes on a network would rock. Manually keeping track of 12+ sime on 12+ computers is taxing.
The handling of large data sets is what I'm working on right now -- for large texture maps and large DEM-based geometry. All of these files will be used on demand, with only a minimal amount of data loaded into memory at any given time. You should see improvements in both load time and memory usage.
Wherever possible, we're trying to take advantage of multiple cores and GPU processing. I hadn't thought about managing multiple sims on multiple nodes yet, but I will keep that in mind going forward.
@Dave A.:
GPU rendering and general processing is one of our top priorities. I've done some preliminary prototyping with OpenCL (which works with CUDA GPUs and multiple CPU cores) with some pretty promising results.
This is one of those components of D5 that will be a "module." As we continue to develop new approaches to computation, you will hopefully get better turnaround of specific new code, without dealing with an entire new version of DIRSIG.
Thanks for your comments!