[osg-users] PagedLOD/ProxyNode pseudoloader suffix techniques

Robert Osfield robert.osfield at gmail.com
Sat Nov 21 08:05:35 PST 2009

Hi Chris,

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.

So that's now five ways of tackling the problem without needing to
modify anything in the core OSG... and all of this approaches are more
flexible than your original submission.


On Fri, Nov 20, 2009 at 6:04 PM, Chris 'Xenon' Hanson
<xenon at alphapixel.com> wrote:
>  [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
>> Registry::ReadFileCallback.
>  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
> loader plugin.
>> 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.
>> Cheers,
>> Robert.
> --
> 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 at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

More information about the osg-users mailing list