Robert Osfield wrote: > I can't help but feel that you are trying to making this more complex > than it needs to be.
Well, not _trying_. ;) Sometimes I am through ignorance. I did not know you could force preload that way without > First up pre-loading a plugin to handle extensions is easy, as it's > osgconv -e ModifyTerrain model-in.ive model-out.ive > 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, Ok, that definitely addresses one of the major issues. I can perhaps just rely on MODIFYTERRAIN intercepting all loads, and selecting which ones it wants to apply to. > 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. I'm not sure we're talking on exactly the same wavelength, but I was pretty sure that any approach I came up involving osgconv and suffixes would be frowned upon as adding extraneous application-specific functionality to osgconv. Which, obviously we both wish to avoid. Let me clarify what the issue really is, as I see it (since by necessity, you're not as immersed in the problems and requirements of this design as I have to be). The part that is still left unspecified is this. the pseudoloader has to "mark" the PagedLOD nodes (or their child filenames, either one works) to indicate which ones should be modified by MODIFYTERRAIN. If MT intercepts all load requests, it needs to know which ones it should actually modify, and skip the others (both for performance reasons, and you might want some data loaded unmodified). Additionally, in order for this flagging to work (and then disappear) during an osgconv conversion where the modifyterrain is being applied via the loader, the "marking" has to disappear and not be present in the re-saved PagedLOD nodes or their child filenames. Otherwise MT would RE-applied when the converted (and already modified) database was reloaded, which is undesirable. The point of conversion is to apply the modification and then be rid of the runtime modification overhead. This is why the original suffix was designed not to be saved as part of the PagedLOD, and why I am avoiding tinkering with the actual child filename in the PerRangeData. Those changes would "stick" with the converted database. One might think I could manually stick the suffix on the child filename, and strip it off once the child loaded. However, if the child unloaded and then reloaded during one osgViewer run, the modifyterrain effect would disappear on subsequent loads after the first. However, I think I have a solution that can work without modifying any core OSG code, and still meet all the transparency requirements. I'll use the plugin pre-loading technique to allow MODIFYTERRAIN to intercept all loads. When MT loads a subgraph, it will (at your suggestion, and similar to how it does now setting the database suffix) go through the subgraph and mark each candidate PagedLOD by attaching a custom osgDB::Options. It is my understanding from a brief review of the .osg saver (PagedLOD_writeLocalData) that the osgDB::Options field is not stored when the .osg file format is written, and this is by intention. So, I will use the osgDB::Options to indicate which PagedLODs should receive MT treatment. I plan to do this by adding a plugin string data to the Options object via setPluginStringData with a key/value of "PSEUDOLOADERSUFFIX", ".modifyterrain". I believe this is within the intended use of the plugin string data. When modifyterrain intercepts the load call, it appears to be provided the osgDB::Options object (from the PagedLOD object), so the pseudoloader can check for the presence of the PSEUDOLOADERSUFFIX=modifyterrain key/value on the Options, and decide whether to post-load-process the subgraph or not. (The alternative to not tracking the pseudoloader-marking state directly on the PagedLOD via the Options is to keep a list of child filenames needing the treatment as a singleton within the MT pseudoloader, but then ModifyTerrain would have to search that list for each load, which could have dire performance on large filename collections, depending on which container type was used.) I think this is practical. Do you have any comments or suggestions on this method before I code it? It should allow osgconv and osgviewer to be completely naive and oblivious to the presence of a pseudoloader using this technique, which is my goal. -- 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
