[osg-users] PagedLOD/ProxyNode design discussion

Chris 'Xenon' Hanson xenon at alphapixel.com
Wed Nov 25 11:57:33 PST 2009

Robert Osfield wrote:
> I can't help but feel that you are trying to making this more complex
> than it needs to be.

  Well, not _trying_. ;) Sometimes I am through ignorance. I did not know you could force
preload that way without

> First up pre-loading a plugin to handle extensions is easy, as it's
>   osgconv -e ModifyTerrain model-in.ive model-out.ive
> Another aspect of the way the plugin mechanism works is that if you
> just added the extension directly to the osgconv line the
> ModifyTerrain plugin would be loaded first automatically anyway,

  Ok, that definitely addresses one of the major issues. I can perhaps just rely on
MODIFYTERRAIN intercepting all loads, and selecting which ones it wants to apply to.

> Finally, changing osgconv's to add support recursion and adding your
> optional extension on to internal should be trivial.  I really can't
> see a need or great value in adding the extra complexity of a
> getCombinedFilename() or a osgDB::ModifyFilenameCallback. 

  I'm not sure we're talking on exactly the same wavelength, but I was pretty sure that
any approach I came up involving osgconv and suffixes would be frowned upon as adding
extraneous application-specific functionality to osgconv. Which, obviously we both wish to
avoid. Let me clarify what the issue really is, as I see it (since by necessity, you're
not as immersed in the problems and requirements of this design as I have to be).

  The part that is still left unspecified is this. the pseudoloader has to "mark" the
PagedLOD nodes (or their child filenames, either one works) to indicate which ones should
be modified by MODIFYTERRAIN. If MT intercepts all load requests, it needs to know which
ones it should actually modify, and skip the others (both for performance reasons, and you
might want some data loaded unmodified).

  Additionally, in order for this flagging to work (and then disappear) during an osgconv
conversion where the modifyterrain is being applied via the loader, the "marking" has to
disappear and not be present in the re-saved PagedLOD nodes or their child filenames.
Otherwise MT would RE-applied when the converted (and already modified) database was
reloaded, which is undesirable. The point of conversion is to apply the modification and
then be rid of the runtime modification overhead.

  This is why the original suffix was designed not to be saved as part of the PagedLOD,
and why I am avoiding tinkering with the actual child filename in the PerRangeData. Those
changes would "stick" with the converted database. One might think I could manually stick
the suffix on the child filename, and strip it off once the child loaded. However, if the
child unloaded and then reloaded during one osgViewer run, the modifyterrain effect would
disappear on subsequent loads after the first.

  However, I think I have a solution that can work without modifying any core OSG code,
and still meet all the transparency requirements.

  I'll use the plugin pre-loading technique to allow MODIFYTERRAIN to intercept all loads.
When MT loads a subgraph, it will (at your suggestion, and similar to how it does now
setting the database suffix) go through the subgraph and mark each candidate PagedLOD by
attaching a custom osgDB::Options. It is my understanding from a brief review of the .osg
saver (PagedLOD_writeLocalData) that the osgDB::Options field is not stored when the .osg
file format is written, and this is by intention.

  So, I will use the osgDB::Options to indicate which PagedLODs should receive MT
treatment. I plan to do this by adding a plugin string data to the Options object via
setPluginStringData with a key/value of "PSEUDOLOADERSUFFIX", ".modifyterrain". I believe
this is within the intended use of the plugin string data.

  When modifyterrain intercepts the load call, it appears to be provided the
osgDB::Options object (from the PagedLOD object), so the pseudoloader can check for the
presence of the PSEUDOLOADERSUFFIX=modifyterrain key/value on the Options, and decide
whether to post-load-process the subgraph or not.

  (The alternative to not tracking the pseudoloader-marking state directly on the PagedLOD
via the Options is to keep a list of child filenames needing the treatment as a singleton
within the MT pseudoloader, but then ModifyTerrain would have to search that list for each
load, which could have dire performance on large filename collections, depending on which
container type was used.)

  I think this is practical. Do you have any comments or suggestions on this method before
I code it? It should allow osgconv and osgviewer to be completely naive and oblivious to
the presence of a pseudoloader using this technique, which is my goal.

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 mailing list