[osg-users] PagedLOD/ProxyNode pseudoloader suffix techniques
Chris 'Xenon' Hanson
xenon at alphapixel.com
Fri Nov 20 10:04:11 PST 2009
[Moving to osg-users for discussion.]
Robert Osfield wrote:
> Hi Chris,
> There are other better ways to add the alias.
Ok, well, if I'm going to need to rewrite this, let's work out what the best engineering
approach is first so it gets done right the (second) time.
> Paul's suggestion of
> utilising the OSG's use of the "Chain of Responsibility" pattern to
> check for ability to load files from plugin is another approach you
> could use, an approach that is similar to use a custom
This does avert the only-one-ReadfileCallback issue I raised earlier. But, I have to be
honest, this approach seems fairly obscure and not-obvious. I personally was never aware
that you could have one plugin 'intercept' loads directed towards another plugin, and the
mechanism behind this seems cryptic at best to most users. I would personally like a
solution where the typical user can actually easily tell what happened and why the
pseudoloader got invoked to load the external file that had the extension for a different
> Another approach would be to use a custom CullCallback on the PagedLOD
> node, and override the way that the plugin chooses it's children and
> dispatches the file requests.
To me, this seems the most attractive. However, as I recall, custom CullCallbacks are
also singular -- if the pseudoloader uses this method, then it excludes the possibility
that the user would want to use a Custom CullCallback themselves. I was trying to deploy
the pseudoloader as a "system" that could seamlessly be used in any application without
disrupting any existing (or future) use of scenegraph technologies. I'm not just trying to
make a quick kludge that works for my current app, I want something that becomes part of
the whole OSG technology suite so others can utilize and build on it.
> Another approach would be to use a custom DatabaseRequestHandler
> attached to the CullVisitor that intercepts all the file requests done
> by PagedLOD then passes these on to the DatabasePager with the
> filename appropriately modified.
If I understand correctly, this one seems like it has the most code associated with it,
and the least simplicity and obviousness. It means that to employ this method, a user
needs to be concerned with messing with the DatabaseRequestHandler and the CullVisitor,
which puts the "action" as it were, a long way from where the magic happens -- in the
PagedLOD and ProxyNode. It also means the user has to modify their calling code, they
can't just slap .modifyterrain onto the end of a file they're loading into osgViewer.
> All of these approaches are both more flexible and less intrusive than
> embedded the filename suffix into PagedLOD/ProxyNode.
If you look at the scope of the submission I made, it is changes to a few concise lines
of code, and it stores the necessary suffix-override state right where it is needed. It's
self-contained in that no changes to user-code are required, and it's non-intrusive in
that it doesn't interfere with any existing usage of the scene graph. Granted, it's not as
flexible as some other approaches, but I thought the cleanliness and simplicity of it made
up for it.
I'm all in favor of using callbacks or functors to make enhancements extensible and not
single-purpose (you'll see that in the .modifyterrain code which is highly customizable
and extensible, especially if three of the utility APIs are put into core OSG somewhere).
I felt the suffix member variable was isometric to the databaseprefix, and so the downside
of it being special-purpose and not generalized was excusable.
I have an idea for mitigating the generalization issues of a custom CullCallback. What
if the external-reference node types (PagedLOD, ProxyNode and anything else in the future)
supported a custom LoadCallback? This would allow interception of the load operation
without having to take over the already-oft-utilized custom CullCallback. The
modifyterrain pseudoloader could store the suffix information in an existing state
variable, like using a Description string in the Node's DescriptionList. The LoadCallback
could rely on searching for a KEY=VALUE description of the form of
PSEUDOLOADER_LOAD_SUFFIX=.modifyterrain, and extract the suffix from there to employ it.
Would this satisfy your objections to generality? From my perspective, it would satisfy
the desired qualities of obviousness/transparency, not requiring setting up scenegraph
magic outside the PagedLOD/ProxyNode nodes (like custom CullVisitors and
DatabaseRequestHandlers), as well as not interfering with existing use of current
scenegraph techniques like CullCallback.
> I'll dive into
> your other submissions today and if there are points that you rely on
> your added PagedLOD functionality I'll review which of the above
> approach is most appropriate/easist to implement/less intrusive.
I can't recall if the osgconv work is dependent on this, or not. I think it was intended
to be transparent, since the modifyterrain pseudoloader is self-contained and doesn't need
any fancy changes to the context in order to work.
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