Chris 'Xenon' Hanson
xenon at alphapixel.com
Thu Nov 19 11:42:50 PST 2009
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
More information about the osg-users