Loaders: Inconsistent implementations of .setPath()

Hey dear guys,

since you urged + forced me (me, just a innocent threejs user), see #12903
I bravely followed you to use GLTF, and tried …

It looks, as if GLTFLoader.setPath() doesn’nt work …

The default “Blender Cube” should appear like this:
https://rawgit.com/wolfgangvonludwigsburg/three.js/dev/examples/_webgl_loader_gltf_cube_PR.html

Compare to current “90dev” state:
https://rawgit.com/wolfgangvonludwigsburg/three.js/dev/examples/_webgl_loader_gltf_cube_fail.html
Console.log: Failed to load resource: the server responded with a status of 404 (Not Found)

To verify the loading path, I’ve put in an additionally FileLoader request (which succeeds).

The fix could be, in GLTFLoader.js,
line 27, after

    var path = this.path !== undefined ? this.path : THREE.LoaderUtils.extractUrlBase( url );

insert

    if ( this.path !== undefined )
        url = this.path + url;

If you verify the fault, should I do a PR, or the author of GLTFLoader.js ?

BTW: Additionally I tried JSONLoader.setPath() which fails (member method not available) …

  • maybe all loaders should behave accordingly in the same manner … ?

90dev, Chrome, Windows

Author: Fantashit

1 thought on “Loaders: Inconsistent implementations of .setPath()

  1. I also prefer setResourcePath over setTexturePath and the plural alternatives. Since resource is a generic term, I do not think we need an additional setTexturePath method for loaders where all of the resources happen to be textures, like MTLLoader. If we’re agreed on that, the tasks are updating (all?) loaders such that:

    • .setPath() affects original file (or multiple original files forCubeTextureLoader)
    • .setResourcePath() affects dependencies of original file, where applicable

Comments are closed.