[osg-users] PagedLOD/ProxyNode design discussion
Chris 'Xenon' Hanson
xenon at alphapixel.com
Tue Nov 24 14:28:28 PST 2009
Robert Osfield wrote:
> Another possibility of how to tackle adding the proxy node would be to
> use the new support (in svn/trunk) in osgDB::Options for providing a
> custom ReadFileCallback. Using this you can override the way that
> objects are loaded. PagedLOD has now has a _databaseOptions field
> that you can use for this.
This seems like the most likely to succeed, so I've been investigating how this would
interact with the recursion code for osgconv.
The problem I see is that hooking into the ReadFileCallback would work for normal
scenegraph cull traversal loading (like osgViewer or any other app who is just loading via
the pseudoloader). However, recursive osgconv can't just let the scenegraph do the loading
for it in pagedLOD::traverse(). For one, it has to load all LODs. It also has to load each
external file individually so that it can configure the loading and saving context
properly (to preserve relative paths and such that are specific to each external child).
But ReadFileCallback does the actual loading itself, rather than just providing the
pathname of the file that the node in question (PagedLOD or ProxyNode) intends to load
(which is what the too-specific getCombinedFileNameWithSuffix() method I made did).
I feel that irrespective of anything to do with modifyterrain, pseudoloaders or
suffixes, the idea of a getCombinedFilename() method (note, without "WithSuffix") has
merit. It simply decomposes the conglomerated merge-path-with-filename and
load-merged-path methods into two discrete methods. In this way, the
merge-path-with-filename operation doesn't have to be re-created elsewhere (in osgconv),
which would be poor design. This issue arises even if we completely ignore pseudoloader
As an alternative, I investigated the potential of FindFileCallback. It is more along
the lines of the more-minimal operation this calls for, but it too is called only from
within the actual load operation, and so it's not what osgconv needs. There doesn't appear
to be a way for osgconv to ask what-file-should-the-PagedLOD-try-to-load without actually
calling for that file to be loaded. Altering FindFileCallback seems like taking it farther
afield from its intended purpose, and therefore a bad idea.
I'm sure you understand that I'm trying to keep application-specific implementations out
of osgconv. The goal is to permit osgconv to do a bulk, recursive convert of a database
while allowing a transparent pseudoloader to function during load. I'm trying to avoid
messing with the persistent stored data attributes of the PagedLOD (like child names, and
database path) so that when the modified database (which no longer needs the pseudoloader,
because the modifications have been incorporated) is resaved, no trace of the pseudoloader
remains. This can be used to freeze terrain modifications into a database so that they no
longer need to be applied at runtime.
I understand your wish to avoid domain-specific changes like the PagedLOD suffix. Would
it be acceptable to instead devise an osgDB::ModifyFilenameCallback class, with an entry
for it basically everywhere that FindFileCallback is available. PagedLOD's
getCombinedFilename() would utilize this to expose load-time-filename-alteration without
disrupting the stored child filename. In this way, PagedLOD::traverse can "see" the
filename modifications and osgconv can manually request the modified filename, and still
avoid putting anything pseudo-loader or suffix-specific into either one.
I suspect you may feel I'm trying to re-argue the same point over and over, but I really
am trying to find a design that is amenable to your criteria of programmable rather than
configurable, while not junking up the core code with something that will only ever get
used by one application.
While it may seem to you that I'm summarily rejecting some of the other options you've
proposed, rest assured that I have thought them through pretty seriously, and each has a
side-effect that manifests when you consider the shape of the whole problem. For example,
the foreign-extension-grabbing technique that osgTDS apparently uses would be incompatible
with unmodified osgViewer, because you have to alter the source to jam the TDS loader in
before any other plugin is registered. I am omitting a full discussion of why each
technique fails because I don't want to bore everyone to tears, but I really have spent
most of the summer trying to make this technique as minimally-invasive and
widely-applicable so that others can benefit from the engineering that my client had me do
for their purposes (recursive osgconv, for one example). I'd prefer to be able to pull all
of this off with no modifications to core OSG at all, but I simply haven't found a way to
achieve all the requirements without a little extra smarts and refactoring inside PagedLOD
to hook into currently black-box functionality.
If you feel this is appropriate, I'll happily write and submit the
(Note: Everything I've written above applies to ProxyNode as well, but I wrote only of
PagedLOD for simplicity.)
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