[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 [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
