New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

relative and absolute paths on Android #3179

Closed
snovak opened this Issue May 29, 2015 · 2 comments

Comments

Projects
None yet
2 participants
@snovak

snovak commented May 29, 2015

Hey All,

I'm having an issue with loading a g3dj with relative links to texture files. It seems that android, specifically wants texture files in the same directory as the model. Desktop accepts relative links without issue.

For example, the following works on Desktop (OSX), not on Android.

// snippet from g3dj file
"textures": [
                      {
                           "id": "Texture.005",
                           "filename": "../materials/miami-hurricanes-tiled.jpg",
                           "type": "DIFFUSE"
                      }
                 ]

I have tried both relative and absolute path format
Relative: "../materials/miami-hurricanes-tiled.jpg" // should navigate one up from current directory
Absolute: "/materials/miami-hurricanes-tiled.jpg" // should navigate from top level of assets folder

Here is my assets directory hierarchy:

screen shot 2015-05-28 at 2 51 09 pm

The error from LogCat reports:
05-28 15:16:45.243: E/AndroidRuntime(2681): com.badlogic.gdx.utils.GdxRuntimeException: com.badlogic.gdx.utils.GdxRuntimeException: Couldn't load dependencies of asset: models/../materials/miami-hurricanes-tiled.jpg

What DOES work, is having the texture file in the same directory as the g3dj file.

@FyiurAmron

This comment has been minimized.

Show comment
Hide comment
@FyiurAmron

FyiurAmron May 29, 2015

Contributor

AFAIK (I might be wrong), this is directly related to
#2617
with workaround (needed due to no path normalization routines currently in libGDX and the fact that Java core library had path normalization added in version 1.7, making it mostly unavailable on Android) being to use

public String normalize( String filenameWithDots ) {
    return new URI( filenameWithDots  ).normalize().getPath();
}

e.g. in the g3dj loader (https://github.com/libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/graphics/g3d/loader/G3dModelLoader.java#L216), i.e. by doing a copy of the loader class and, in your copy, adding

...
jsonTexture.fileName = materialDir + (materialDir.length() == 0 || materialDir.endsWith("/") ? "" : "/")
                            + fileName; // existing L216/217
jsonTexture.fileName = normalize(jsonTexture.fileName); // workaround for this problem
...

- and then using that loader instead.

Could you verifiy if that workaround works for you?

Note that creating new URIs and using URI#normalize() is quite inefficient for this, especially in loops or for large amounts of paths - and that's the exact reason why there is https://commons.apache.org/proper/commons-io/apidocs/org/apache/commons/io/FilenameUtils.html#normalize%28java.lang.String%29 .

As I recall, the exact issue appeared the same way - I tried loading OBJs with .. in paths on desktop, everything was fine, tried that on Andy, didn't work at all - probably due to the way those OSes handle dotted paths.

(note that I might be wrong on this, I never used g3dj myself, I'm basing this on my similar experiences with working with OBJs)

Contributor

FyiurAmron commented May 29, 2015

AFAIK (I might be wrong), this is directly related to
#2617
with workaround (needed due to no path normalization routines currently in libGDX and the fact that Java core library had path normalization added in version 1.7, making it mostly unavailable on Android) being to use

public String normalize( String filenameWithDots ) {
    return new URI( filenameWithDots  ).normalize().getPath();
}

e.g. in the g3dj loader (https://github.com/libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/graphics/g3d/loader/G3dModelLoader.java#L216), i.e. by doing a copy of the loader class and, in your copy, adding

...
jsonTexture.fileName = materialDir + (materialDir.length() == 0 || materialDir.endsWith("/") ? "" : "/")
                            + fileName; // existing L216/217
jsonTexture.fileName = normalize(jsonTexture.fileName); // workaround for this problem
...

- and then using that loader instead.

Could you verifiy if that workaround works for you?

Note that creating new URIs and using URI#normalize() is quite inefficient for this, especially in loops or for large amounts of paths - and that's the exact reason why there is https://commons.apache.org/proper/commons-io/apidocs/org/apache/commons/io/FilenameUtils.html#normalize%28java.lang.String%29 .

As I recall, the exact issue appeared the same way - I tried loading OBJs with .. in paths on desktop, everything was fine, tried that on Andy, didn't work at all - probably due to the way those OSes handle dotted paths.

(note that I might be wrong on this, I never used g3dj myself, I'm basing this on my similar experiences with working with OBJs)

@snovak

This comment has been minimized.

Show comment
Hide comment
@snovak

snovak Jun 1, 2015

I ended up working around the problem for the time being. My models and materials are in different directories. So, I load geometric data from /models with a simple material.
After the model loads, I'm loading more complex materials with linked maps from the same directory. That works for now. I'll backtrack and try the fix if I have some time left.

Let's call this a duplicate and close for now. Thanks for the link!

snovak commented Jun 1, 2015

I ended up working around the problem for the time being. My models and materials are in different directories. So, I load geometric data from /models with a simple material.
After the model loads, I'm loading more complex materials with linked maps from the same directory. That works for now. I'll backtrack and try the fix if I have some time left.

Let's call this a duplicate and close for now. Thanks for the link!

@snovak snovak closed this Jun 1, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment