Hi Chris,
I can't help but feel that you are trying to making this more complex
than it needs to be.
First up pre-loading a plugin to handle extensions is easy, as it's
already built into the core OSG. Try -e ext which preload the plugin
of the given extension.
osgconv -e ModifyTerrain model-in.ive model-out.ive
This would preload your ModifyTerrain plugin and it then can handle
all file loads and decide what to do with them. osgviewer supports
the same option. Programmatically it's just a single line call to:
osgDB::Registry::instance()->loadLibrary(osgDB::Registry::instance()->createLibraryNameForExtension("ModifyTerrain");
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, so
there after can handle all filenames as it'll be the first plugin in
the list.
osgconv model-in.ive.ModifyTerrain model-out.ive
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. The later
really seems like a silly leave of embedding extra callbacks to modify
narrow features. There are already plenty of ways of overriding the
read file, adding more isn't going to make the code any less
extensible or flexible, it's just going to complicate things.
Robert.
On Tue, Nov 24, 2009 at 10:28 PM, Chris 'Xenon' Hanson
<xe...@alphapixel.com> wrote:
> 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
> suffixes.
>
> 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
> ModifyFilenameCallback changes.
>
>
> (Note: Everything I've written above applies to ProxyNode as well, but I
> wrote only of
> PagedLOD for simplicity.)
>
>
>> 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@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
