Hi Robert,
(sorry about the other mail, I pressed Ctrl-Enter accidentally)
On 4/6/09 5:44 PM, Robert Osfield wrote:
I'm aware of this issue but re-order the call to the CURL plugin so it
goes before other plugins will break other NodeKits such as osgEarth
as they rely upon their own plugins catching http calls.
Good point, I thought they only look at filenames like .earth
Could we iterate over all plugins that support the protocol in question, with the CURL
plugin being the last resort?
A full solution has to be changing the search mechanism so that it
doesn't strip the full path from the front of the file when doing it's
searching of the OSG_FILE_PATH list, however, such a change would
break apps that rely upon this for searching for files. For instance
if you have a texture with filename subdirectory/image.jpg but on
disk the file is in MyDirectory/image.jpg, then unless the is the
option to strip the path you won't ever be able to find the file even
if your point OSG_FILE_PATH at the directory.
Yeah, the joys of file path searches...
I agree that we have to check the basename of the filename, but probably only after
testing the full filename.
So for "sub1/sub2/image.jpg" and a filepath of "aaa:bbb" we could check
sub1/sub2/image.jpg
sub2/image.jpg
aaa/sub1/sub2/image.jpg
bbb/sub1/sub2/image.jpg
aaa/sub2/image.jpg
bbb/sub2/image.jpg
aaa/image.jpg
bbb/image.jpg
image.jpg (maybe, or maybe only if the current directory is in the path)
The last part I only mentioned because I believe the search path should have preference
over the local directory. If there's a file "image.jpg" and one in "media/image.jpg" and
I set the search path to "media" then I don't want the local file to be used.
To get round this problem I though perhaps we could add an exception to the
file path
search scheme that makes it reject trying to search for files that have a
server path in them.
I think that makes sense. If the filename is not local it doesn't make sense to check
plugins that only understand local files.
imagine the following situation:
- there is a file earth.ive somewhere in the search path
- run "osgviewer http://www.openscenegraph.org/data/earth_bayarea/earth.ive";
What will happen is that the local file earth.ive is loaded instead of the
URL.
IMHO this is a bug.
The bug is caused by the behaviour of osgDB::Registry::read(const
ReadFunctor& readFunctor).
What this does is (at each step returning if successful):
- check if the filename is an archive; if yes, load it
- check if the filename can be loaded with one of the existing plugins
- load the proper library for filename and try that
- if that fails and the filename is a URL, try the CURL plugin
What it *should* do to work properly is the following:
- (check if the filename is an archive; if yes, load it)
- if the filename is a URL, try the CURL plugin
- find (load if necessary) the proper library for filename and try that
About the archives I'm not sure. Strictly speaking they too should be
checked after the URL check but I'm not sure to what extent they support
being streamed.
Attached is a patch that implements the outlined behaviour.
I've checked it with the earth.ive online database (with and without local
'earth.ive' file present), a local .osga paged database, and various other
models, also in combination (for example with the online database and the
local database side-by-side).
Please have a look and tell me what you think.
Cheers,
/ulrich
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
