Hi Robert, I think your osgDB::Options idea is mostly working for finding references in the same archive as the parent. I find that this works when the reference is just a filename, but it fails if the filename comes with a path, such as the absolute path that an exporter might give you. This should probably be fixed regardless of whatever else we do on this subject.
This could probably be made to work if a call to getSimpleFileName() was inserted somewhere along the way, but I don't see a good place to put it yet. Somewhere in Registry::read()? Or in the archive plugin? Any suggestions on this one? -- Terry Welsh mogumbo 'at' gmail.com www.reallyslick.com On Sat, Mar 10, 2012 at 5:09 PM, Terry Welsh <[email protected]> wrote: >>> >>> Hi Terry, >>> >>> I've been wondering about archive functionality, in particular about >>> the reading of file internal references such as reading the imagery >>> referenced by a scene graph where both are stored in the same archive. >>> The intent of the osgDB::Options support in ReaderWriter's is that >>> nested references should by handled by prepending of the path to the >>> parent file to a locally cloned osgDB::Options object that is then >>> passed on when doing the readImage(..) etc call. I haven't done the >>> testing yet to confirm the behaviour in the context of Archives yet >>> but what in theory should be happening is that the archive should be >>> added to the Options object on access to it, and suspect this isn't >>> happening for all usage models. >>> > Upon reading this email of yours a second time I think I have a better > answer to your question: What you're saying about nested references > makes perfect sense if the reference is in the same archive as the > parent. But adding the parent's path to a local osgDB::Options will > not allow the reference to be found in a different archive, which is > what my solution provides. Other archives can only be supplied by > OSG_FILE_PATH or some other environment variable that we haven't > invented yet. > > I'm going to stare at the code a little more now and see if I can > think of more alternatives.... > - Terry > >>> Could it be that the problems you are seeing a related to this issue? >>> I'm hopeful that if we sort out the proper prepending of the archive >>> path to the Options object we won't need to intrusive changes to >>> osgDB::Registry that you've had to make. >>> >>> Robert. >>> _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
