On Jan 21, 2008 12:14 PM, Robert Osfield <[EMAIL PROTECTED]> wrote:

> 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.


OK understood - I agree that it's not the most elegant solution - in any
case I think I can work around it n the meantime by referencing the full
archive path in the texture def (e.g. archive.osga/texture.jpg).


> 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


I will work on this and submit it separately. Thanks -gw


>
>
> 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
>



-- 
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

Reply via email to