Hi Glenn, I have been reviewing the code and I'm not happy with the way this code is drifting - being reused to do this it wasn't designed to do. Some places in the OSG can cope with this type of repurposing, others are better solved another way and my current get feeling this is one of the later cases.
The crux of what you are trying to do is use a archive to store files and have osgDB automatically load these archives implicitly from a list of archives rather than explicitly. Doing it implicitly does mean that that more archives could be loaded than are required, or worse the wrong might be loaded first and you end up with a file that you didn't mean too. Setting the DataFilePathList up in a strict way will help the issue of picking up the file from the wrong archive, but it still won't be as good as being explicit about it. The http/.net plugin management also makes more wonder if things need to all be done a bit more structured in this area. I'm inclined to think that perhaps we should have preloading of archives and have file search checks done against these already loaded archives. I do need to think more about this issue, unfortunately right now isn't a great time for me to while away the hours pondering this type of stuff. On the topic of adding readObject to the image plugins, I feel this is an appropriate thing to do regardless of whether we add other methods to archive support, and is something we need to roll out to all plugins Robert. On Jan 21, 2008 4:09 PM, Glenn Waldron <[EMAIL PROTECTED]> wrote: > > Hi Glenn, > > > > > > On Jan 21, 2008 3:05 PM, Glenn Waldron < [EMAIL PROTECTED]> wrote: > > > > Yes, correct. Although that example does not seem to work with the > patch. > > > I'm investigating why that is.. > > > > Glenn > > > > > > oops..the example in this case would be: > > > > > > export OSG_FILE_PATH=scene.osga > > > osgviewer --image comm1.jpg > > > > Does this still fail even with your patch? This does seem like a > > reasonable scheme so it'd be nice to get working. > > Now it works. I was checking the Options database path but not the > Registry's dataFilePath. Here is a new Registry.cpp that works with the > above test case. It actually searches the archive for the file to load, > created a "pathname" version of the file, and re-calls read(). Instead of > creating a new ReadFunctor I am just replacing the _filename in the old one > (with a de-consting cast), but it looks safe. > > The only thing left is the issue of readObject() support in the > plugins...but like you said this is an orthogonal issue. > > Glenn > > > > > > > > > I'm about to make a 2.3.3 dev release this afternoon so given there is > > still stuff we need to get working and decide upon I'll leave your > > changes to after the dev release. > > > > > > > > > > Robert. > > > > _______________________________________________ > > osg-submissions mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > > > > > -- > Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
