Hi Robert,
The usage case I am solving here is allowing users to treat archives
just like directories when loading files into OSG. This provides
convenience when organizing your data files or packaging software.
For example, you could have OpenSceneGraph-Data.zip instead of a
directory called OpenSceneGraph-Data full of files. Archives are
simply added to OSG_FILE_PATH just like path names.
The simple case I used for most of my testing was to create a
model.osg which referenced a texture.png. Put model.osg into
model.zip and put texture.png into texture.zip. Then do:
export OSG_FILE_PATH=path/to/model.zip:other/path/to/texture.zip
osgviewer model.osg
To make this work I also needed to add this to main() in osgviewer:
osgDB::Registry::instance()->loadLibrary(osgDB::Registry::instance()->createLibraryNameForExtension("zip"));
So automatic plugin loading based on finding an archive extension in
OSG_FILE_PATH might be something worth adding.
findFileInPath() was modified so that after it does its normal search
for a file in every possible path, it looks at each path again to see
if any contain a possible archive name based on the archive extensions
known to the Registry. If an archive name is found, then it tries to
locate the file inside of it. If the file is found then the full path
is returned, treating the archive just like a directory name. Most of
the code required for this addition was already built into OSG: the
list of archive extensions, the ability for Registry to open archives,
and Archive::fileExists().
Registry::read() starts out by reading a specified data file in a
specified archive, such as model.zip/model.osg. Then I added a
section that will also find and read model.osg in archives specified
in OSG_FILE_PATH. These two code blocks are very similar and could
probably be combined pretty easily.
You're right that this is invasive code that risks accidentally
changing existing behavior, and I would only want to add it if there
is plenty of time before a big OSG version update. I have been using
it for weeks now in a game I am programming. I have gone through
packaging it for Windows and Linux with all the data in a data.zip
file. It also uses osgDB routines for locating files in data.zip
that are not loaded by OSG. That's a pretty thorough test, and so far
everything is working.
I have not tested for a while with .osga. As I recall, .zip and .osga
behaved differently before I added any code. I couldn't store a .png
file inside a .osga file and maybe some other things. But I don't
know what .osga was intended for in the first place.
--
Terry Welsh
mogumbo 'at' gmail.com
www.reallyslick.com
>
> Hi Terry,
>
> I have now started reviewing your submission. The changes to
> src/osgWrappers/deprecated-dotosg/osg/Shader.cpp and
> src/osgPlugins/glsl/ReaderWriterGLSL.cpp all look uncontroversial so
> have merged these and once we are a bit further along with the review
> will check this in. The changes to FileUtils.cpp's
> osgDB::findFileInPath(const std::string& filename, const FilePathList&
> filepath,CaseSensitivity caseSensitivity) and Regisytry.cpp's
> ReaderWriter::ReadResult Registry::read(const ReadFunctor&
> readFunctor) feel a bit awkward to me.
>
> Could you explain the changes you've made and what usage case you were
> working to solve with these changes. I need to get my head around
> that changes before I merge. I'm may well decide to refactor the
> changes, but can't decide upon this until I know what you are
> attempting to do. I also need to have a good think about the
> potential consequences of the changes on other usage models as these
> bits of code and heavily used by many users.
>
> Could you also give me some pointers of how to recreate the usage you
> using so I can recreate this at my end.
>
> Cheers,
> Robert.
>
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
