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
