Re: [osg-users] custom search paths...
HI Neil, We already have a Registry::ReadFileCallback, how is this not sufficient? Robert. On Fri, May 1, 2009 at 1:01 PM, 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 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, 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 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, 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,
Re: [osg-users] custom search paths...
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 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, 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 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, 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
Re: [osg-users] custom search paths...
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, 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 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, 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-use
Re: [osg-users] custom search paths...
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 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, 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-use
Re: [osg-users] custom search paths...
Hi Robert, Thanks for the reply, I'll look into this approach. Neil. Robert Osfield 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, 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
Re: [osg-users] custom search paths...
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, 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
