On Jan 21, 2008 8:17 AM, Robert Osfield <[EMAIL PROTECTED]> wrote: > HI Glenn, > > I'm currently reviewing this submission and haven't yet come to any > definition conclusions about the best way to tackle this problem, to > help get a bit further could you explain, say via an example of how > you are using archives and the file path list?
Here is an example file: http://pelicanmapping.com/downloads/scene.osga This archive contains one .osg file and two textures. The .osg file references the textures by simple file names like "comm1.jpg". In order to see the textures, you will need the patch. (Side note: when you extract the osg file from the archive, the texture image filename is gone....not sure why.) FYI, the context here is my work on the osgGIS project, in which I am generating archives with huge numbers of buildings that need to share a (relatively) small collection of textures. It sounds like you are > actually specifying it as it is directory, which if a correct > assesement is a interesting way of doing things I haven't thought > about before. The concept of using archive name as directory already existed -- that's the first code block in Registry::read -- PagedLOD uses this by prepending the archive name into something like "file.osga/out.ive". The catch is that only PagedLOD does this, so it only works for paged node refs and not images. My patch just checks the database path list for any archives and searches them for the referenced file. If it's not there, it continues on the normal search procedure. W.r.t readObject and image plugins this is an orthogonal issue to the > archive look up and needs a general decision on - if either need to > add another mechansim to archives to handle image etc. file reads or > to change the image plugins etc all to support readObject(). Either > case we'll need to go further than just the changes you've made. Agreed -- the JPEG patch is just an example, and we would need to apply this to each plugin OR do something smart at a higher level. I will be happy to do this work whatever the decision is. > > Robert. > > On Jan 20, 2008 6:04 PM, Glenn Waldron <[EMAIL PROTECTED]> wrote: > > Robert, > > > > Currently a node file stored in an Archive cannot reference image files > also > > stored in the Archive. This is an attempt to address the issue. > > > > Attached is an updated osgDB/Registry.cpp. I updated the read() method > so > > that given an archive in the database path list, will search that > archive > > for the file to load. It then calls archive->readObject() if it's found. > > > > This works but introduces a secondary issue -- since Archive does not > know > > about the Registry's ReadFunctors, I just call readObject(). But most of > the > > image plugins only respond to readImage(). So I've also attached a > version > > of ReaderWriterJPEG that responds to readObject() ... is this the > correct > > way to approach it? Or should Archive be able to use ReadFunctors? > > > > Thanks for your consideration. Glenn > > > > -- > > 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 > -- 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
