Image init_from bug ?

Hi,

I’m using COLLADA DOM to parse DAE files and I’ve encountered the following problem. While loading some of the sample files taken from collada.org (example: seymourplane.dae) and parsing the images (from library_images) the getFilepath on init_from returns the complete path with the last directory missing. This is caused by the fact that the image path is relative to the dae file location:

<library_images>
<image id=“file1” name=“file1” depth=“1”>
<init_from>./planeDiffuse.tga</init_from>
</image>
</library_images>

Now if I’m using the following code:

domImage *image;

domImage::domInit_from *init_from = image->getInit_from().cast();
if(init_from)
{
myString = init_from->getValue().getFilepath();

And I have the dae file in the following location on the disk: c:\collada_samples\Seymour.

myString contains /c:\collada_samples/ instead of the entire path (Seymour directory is left out).

Is it ./planeDiffuse.tga a valid path URI? For me it seems that ./planeDiffuse.tga is not a valid format for an external image file inside init_from and getFilepath doesn’t work correctly in this case.

Hey Licu,
Are you using the last released DOM or a svn checkout? (just for my info)

Either way, the URI is a well formatted relative path. Here are three things to try though.

  1. The DOM “normalizes” (expands out) every URI. The rules for expanding these relative URIs are pretty much like, if URI is in a document use Document URI + what is given. If URI is not in a document use cwd + what is given. Since you are seeing this from in a document then the first is what is going on. The document you are loading needs to be in the Seymour folder too. (obviously for the relative path to work correctly) I don’t think this is your problem.

  2. instead of calling getFilepath use getPath( daeString buffer, int buflength ). This will get you the whole path, filepath+docname. That might work better for you. If there is a problem with the daeURI normalization this may work around it.

  3. URIs don’t use \ characters ever. It actually screws up the DOM’s URI processing (because the DOM does it correctly and doesn’t do any win32 specific hacks). When the daeURI sees \something\something\file it treats it as a single path segment. So if you have a … it will back all the way to the root. Since you say your output string you are getting is “/c:\collada_samples/” I see you are mixing slashes. Thats a big no no.

My bet is on #3. #2 might be useful for you anyways, its how I always get file paths in the aps I write with the DOM. Just remember that a URI returns a / as a root. in windows systems you will need to skip that first character.

-Andy

First, the last check out was at 12/28/2006.

And, yes, I’ve suspected that was using the current working directory and it seems that it is using it but in an incorrect way. For example, if I have Seymour in the following location: c:\collada_samples\official\Seymour, the returned path for its image file is /c:\collada_samples/official when the current working directory is c:\collada_samples. The image file is in Seymour directory, but the function left out that last directory and appended /official (and the beginning /) to the current working directory. This also answer your question about mixing / and . I don’t do that, the COLLADA DOM is doing it. Basically is letting the current path in its current OS dependent form (with ) and append folders with the correct / separator (but lefts out the last folder).

Also getPath doesn’t work either, it returns /c:\collada_samples/official/boy_10.tga in the above example (instead of /c:/collada_samples/official/Seymour/boy_10.tga).

Hope this helps. The Seymour file you have already (since is from official examples) and the DOM code I use is above, in the first post.

Regards,
Licu

PS: in case of Seymour the init_from is in the following format: <init_from>boy_10.tga</init_from>