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
