I just submitted this code over on submissions for Robert to consider, but since there's some opportunity for discussion of the future of this, I'm reposting the accompanying description here for discussion.
This pseudo-loader permits on-the-fly modifications of a PagedLOD database's terrain heightfield's elevation values during load or save operations by simply appending the .modifyterrain suffix to the database filename and setting some ReaderWriter Options like "MODIFYTERRAIN_ELEV_ADD". These can be specified through the command-line osgViewer like: osgviewer -O "MODIFYTERRAIN_ELEV_ADD 5" terrain.osg.modifyterrain Currently the sample code permits adding a positive or negative constant value, scaling, enforcing a maximum or minimum clamp (ceiling/floor), replacement of a known constant value with another known constant value, as well as replacing all values below a constant with a potentially different constant. The underlying code is equipped to do non-spatially uniform terrain elevation modification (similar to osg::TDS) through the use of generalized visitors and functors offering point-elevation-evaluation callbacks. The callback provides the current spatial point location and elevation and allows user code to return a new elevation value that will replace the heightfield's existing elevation at that point. No spatial-feature-deformation library (for raising/lowering regional features like lakes, building sites, roads, ordinance craters, etc) is included at this point. My client isn't able to release this work yet, but may be able to in the future. This framework is designed so that any API capable of answering "what elevation should be in effect at this X/Y position" can be plugged in by deriving from the ModifyTerrainFunctor class, constructing a ModifyTerrainVisitor with it, and apply()ing it to a scenegraph. A CMakeLists.txt is included. ReaderWriterMODIFYTERRAIN.cpp replies on some of the PagedLOD/ProxyNode suffix enhancements I have already submitted in order to propagate the psuedoloader suffix through child PagedLODs and ProxyNodes so that deeper levels of the scenegraph get the modify treatment as they are loaded. While this code is finished and working, it could use a bit of cut & paste before being checked in as-is. Much of the code within the ReaderWriterMODIFYTERRAIN.cpp file should be (I feel, without arrogance) incorporated into the broader osg/osgTerrain architecture. The three classes/APIs: ModifyTerrainFunctor, ModifyTerrainHeightField and ModifyTerrainVisitor are applicable to in-scenegraph modification of VPB/PagedLOD terrain whether it is done through the .modifyterrain pseudoloader or through user-application-invoked code. Additionally the ModifyDatabaseSuffixVisitor is generally applicable to any application of the pseudoloader technique in a database containing PagedLOD or ProxyNode entities -- this class could be placed into any convenient library/namespace -- osgDB suggests itself to me. The code for each of these is marked in the comments with a <<<>>> token and an explanation of where it might go in the osg Core code if it were broken out of .modifyterrain. This is just the tip of what I'm working on as far as terrain tools, but it's all I can release right now. It has already been tested pretty thoroughly, and can do some great things. The pseudoloader technique means that you can apply these terrain modifications at numerous different stages: During loading of a scenegraph in osgViewer, using -O to pass the modification parameters. While building the scenegraph within OSGDEM/VPB. While converting a scenegraph using osgconv (see my recent recursive-conversion submissions). The pseudoloader also abstracts away any file-format dependency -- you can use the pseudoloader atop any format plugin that can load and save PagedLOD databases made of osgTerrain/heightfield geometry. Currently this is just .osg and .IVE. Moving the ModifyTerrainFunctor, ModifyTerrainHeightField and ModifyTerrainVisitor classes out of .modifyterrain should allow any osg program to perform on-the-fly elevation modifications to the terrain even after it is loaded. I have some additional work in progress that would facilitate selectively requesting PagedLOD nodes to reload their already-loaded-and-displayed children (presumably through the pseudoloader layer) so that runtime dynamic terrain alterations (think, explosion craters) can easily be performed on the database without affecting the pristine on-disk copy. Alternately, this could be used to load permanently-updated copies of the terrain model that had been built by VPB (patching the database to include newly-incorporated but permanent modifications such as data updated from UAVs, etc). I intend to submit as much of this as I can as time and client allows. Essentially, there's an enormous amount of terrain technology I can provide to OSG in the near future, as my client allows me to release it. I'd love to hear feedback from others about where you'd like to see this go. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ "There is no Truth. There is only Perception. To Perceive is to Exist." - Xen _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
