HI Neil, We already have a Registry::ReadFileCallback, how is this not sufficient?
Robert. On Fri, May 1, 2009 at 1:01 PM, <neil.hug...@tesco.net> wrote: > Hi Robert, > > I suspect we may be saying the same thing, and perhaps I haven't explained > myself clearly. All I'm suggesting is a slight amendment to the search > functions to delegate to an application supplied readfilecallback the role of > searching when the default search has failed to locate the file. OSG would be > agnostic as far as the actual alternative search algorithm is concerned. It > merely invokes it and returns the result. > > Neil. > > > ---- Robert Osfield <robert.osfi...@gmail.com> wrote: >> Hi Neil, >> >> This type of customization is exactly what ReadFileCallback is for. I >> don't feel it's appropriate for search routines to do anything other >> than search, having them remap file names is inappropriate. >> >> Robert. >> >> On Fri, May 1, 2009 at 11:32 AM, <neil.hug...@tesco.net> wrote: >> > Hi Robert, >> > >> > I've had a look at this, and whilst it will address the specific scenario >> > I described, I left out a little "top spin" to the scenario that has some >> > bearing on the issue. Not only do I want to specify the directory where >> > the search looks, but I also wish to amend the file extension. Essentially >> > the issue is that when we originally started out modelling - circa 10 >> > years ago now - we only used TGA files. Now we tend to prefer to load jpg >> > files, unless there is an alpha channel in which case we'll load TGA's. >> > For space reasons, and speed of load/download we therefore want to say >> > that if a tga file is referenced, try loading, but if not found, try the >> > jpg equivalent. >> > >> > I can handle this at the load image time within my supplied >> > readfilecallback, if I circumvent the search results. However, I'd like >> > the search routines to be able to handle this type of functionality as >> > well. i.e. I request Pear.TGA, the search try's to locate it, but if it >> > fails it tries some alternative extensions. >> > >> > Now I recognise that this is somewhat specific to myself, but rather than >> > have customised 3DS readers, I was hoping to extend the search routines in >> > a general way to permit an application to supply its own search algorithm, >> > that could be used in the event that the file was not found with the >> > current search implementations. I recognise that for the majority of >> > people either the standard search path, or the options route you describe, >> > is sufficient. Its just that I can't see a way to amend the extension/path >> > according to some application defined rules using this approach. >> > >> > Robert, I think I'll code up a solution, and perhaps submit it for >> > consideration if that's ok with you, and then we'll have a framework to >> > bat about. >> > >> > Kind regards >> > >> > Neil. >> > >> > >> > >> > >> > >> > a jpgour models were producedmodelled, >> > >> > >> > >> > >> > >> > >> > ---- neil.hug...@tesco.net wrote: >> >> Hi Robert, >> >> >> >> Thanks for the reply, I'll look into this approach. >> >> >> >> Neil. >> >> >> >> >> >> ---- Robert Osfield <robert.osfi...@gmail.com> wrote: >> >> > Hi Neil, >> >> > >> >> > The ReaderWriter::Options structure has a data file path list built >> >> > into it, this is checked before the main data file path list stored in >> >> > the Registry is checked. So if you want a certainly directory >> >> > checked just put it on your path, either via the ReaderWriter::Options >> >> > or via the Registry using osgDB::s/getDataFilePathList. You'd >> >> > typically use Options when you only want to locally set the search >> >> > path. >> >> > >> >> > Robert. >> >> > >> >> > On Thu, Apr 30, 2009 at 5:29 PM, <neil.hug...@tesco.net> wrote: >> >> > > Hi All, >> >> > > >> >> > > I'd like to pick your collective brains for a moment in regards to >> >> > > search paths for files within OSG. I'm currently working on the 3DS >> >> > > plugin for OSG, looking at a little problem. The scenario is as >> >> > > follows. >> >> > > >> >> > > I have a 3DS file whose material table references a texture. When >> >> > > this model was created the texture resided in the same directory as >> >> > > the model, and hence no path information was stored - at least I >> >> > > guess that's why there is no path information for the texture >> >> > > referenced. Now when I want to load this model, the 3DS loader tries >> >> > > to locate the texture in the directory that the model resides in - >> >> > > using the findfileindirectory function - but as the texture is no >> >> > > longer in this directory, the function fails to find the file, and >> >> > > the 3DS reader decides not to put a texture on the geometry. >> >> > > >> >> > > Now, the thing is, I do know where the texture is relative to the >> >> > > model. Its in a parallel directory. In fact, if I ignore the result >> >> > > of the find file, and merely just try and load the image, my >> >> > > readfilecallback handler amends the path to the file, and the image >> >> > > loads. >> >> > > >> >> > > So, what I was wondering was whether there already exists a way by >> >> > > which I can "direct" the findfileindirectory function to take account >> >> > > of a custom search algorithm? I've had a look and I can't spot one, >> >> > > but wondered if others might know differently? >> >> > > >> >> > > On the assumption that no such methodology exists, my thoughts were >> >> > > that I could amend the existing function to call a custom defined >> >> > > function on the user supplied readfilecallback - if one has been >> >> > > supplied - in the event where the readfileindirectory function has >> >> > > failed. >> >> > > >> >> > > Any thoughts ? >> >> > > >> >> > > Thanks for any assistance/comments. >> >> > > >> >> > > Kind regards, >> >> > > >> >> > > Neil. >> >> > > _______________________________________________ >> >> > > osg-users mailing list >> >> > > osg-users@lists.openscenegraph.org >> >> > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > > >> >> > _______________________________________________ >> >> > osg-users mailing list >> >> > osg-users@lists.openscenegraph.org >> >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> >> >> _______________________________________________ >> >> osg-users mailing list >> >> osg-users@lists.openscenegraph.org >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > >> > _______________________________________________ >> > osg-users mailing list >> > osg-users@lists.openscenegraph.org >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
