Christoph Fünfzig wrote:
[snip]
> Sorry, a bit intricate.
> I give an example for an OBJ scene
>
> [karl.obj] references [karl.mtl]
> [karl.mtl] references textures
> [textures/karlbacknr1.tif][textures/karlbacknr2.tif][textures/karlbacknr3.tif]
>
> Now, you publish the scene on a webserver http://home.dummy.net in
> directory /models, /models/textures
> You can identify the scene file with URL
> http://home.dummy.net/models/karl.obj, but the
> contained references are still relative paths. So the OBJSceneFileType
> has to generate the URLs
> http://home.dummy.net/models/karl.mtl and
> http://home.dummy.net/models/textures/karlbacknr1.tif from them!
>
> What are the possible cases (e.g. all in one ZIP file karl.zip on the
> webserver) here and where should the resolution of absolute/relative
> paths (into URLs, layered URLs)
> happen?
Simplified, the plan is:
- User calls SFH.read("http://home.dummy.net/models/karl.obj";);
- SFH calls ContentProviderFacotory to invoke HTTPContentProvider and
get an iostream.
- SFH calls OBJSceneFileType::read(url, iostream) with above URL & iostream.
- OBJSFT reads mtl-file relative path, combines it with base url. (See
boost::filesystem::path.) The call would be something like:
URL mtlURL = url.branch() / mtl_path;
(url.branch() returns the directory of the url, i.e. everything but
the file name).
- OBJSFT calls ContentProviderFactory to get an iostream for the MTL-file.
- OBJSFT reads the MTL-file. It encounters textures. It again combines
the base url and the image relative paths, calling
ImageFileHandler::read(tex_url) to get each texture.
Note that the root URL will be handled transparently here, it doesn't
matter where it is.
If you notice my latest wiki edit (5 minutes ago) I have read the holy
standard and come to favour the fragment feature of url for zip-files,
i.e. http://server/archive.zip#file.obj). (Several zips/archives would
then just be several # in a row.)
To clarify, the cases we could have are:
* Local relative file: 'data\karl.obj' will be resolved via something
like the current PathHanddler into an URL such as
'file:///c:/myapp/data/karl.xml' depending on current directory and setup.
* Local absolute file: 'c:\data\karl.obj' is converted to
'file:///c:/data/karl.obj'.
* Remote http file: 'http://server/karl.obj' is simple.
* Remove http zip file: 'http://server/data.zip#dir/karl.obj'. This
would still work, since karl.obj would be stripped and
'textures/tex.tga' would be added, i.e.
'http://server/data.zip#dir/textures/tex.tga'.
All that combining is from calling "url.branch() / relatíve_path". If
you don't like the / operator call it append() or something. We could of
course combine that call into a function that would take the relative
path and return a new URL straight away, i.e. makeRelative(). Then, that
is all that would be required for loaders that need to load referenced
files. (That function could also check if the relative_path is a
absolute URL and then just return the URL.)
Does it make sense? I think it ought to work out pretty well, although I
am not sure how much 'non-uri-standard' behaviour we need to add to make
this work. (I think we ought to make it as standards-conforming as possible)
If you want to do layered urls, one could imagine a URL then actually
being a 'stack' of URLs. So you would do url.push(relative_path) etc, to
add relative paths to it. However, I don't think that has much merit if
any, over combined URLs.
I wish I knew more about URI/URLs to know how they are intended to be
used, rather than just provide suggestions on how to pervert them into
doing our wicked biddings. ;)
Cheers,
/Marcus
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
