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
