basePath doesn't seem to work when loading glTF content

[HowardWolosky]

new Cesium.Model lets you specify basePath to indicate the base path that any relative paths in the glTF JSON are referring to. Unfortunately, it doesn't seem to work.

I attempted to use the glTF 1.0 boxTextured sample model. I copied the files to c:\sample\ and did something like this:
var gltfContent = ""; // insert the full content of the .glTF file here. model = scene.primitives.add(new Cesium.Model({ gltf: gltfContent, basePath: "c:\\sample" // I also tried "c:\\sample\\" and had same result }));
Nothing ends up rendering.

Now, if I modify the uris within gltfContent and make all of those paths absolute, it all renders just fine. So, it appears that basePath functionality has an issue.

[emackey]

I presume you were trying this within the context of gltf-vscode where there is a need to load these files off the local filesystem. Cesium is of course designed and tested for loading the files from a remote server, and I'm sure basePath is meant to be a URL, not a filesystem path.

I plan to investigate this issue as part of the review of AnalyticalGraphicsInc/gltf-vscode#6.

[HowardWolosky]

Precisely. I found a workaround, but I think it makes sense to support local rootpaths as well since you might want to implement an app/game that can run off Cesium locally.

[mramato]

I presume you were trying this within the context of gltf-vscode where there is a need to load these files off the local filesystem. Cesium is of course designed and tested for loading the files from a remote server, and I'm sure basePath is meant to be a URL, not a filesystem path.

This is most likely to loadWithXhr usage under Node and related to #5138, @emackey if you are interested in finishing that up, I'd be happy to help point you in the right direction (should actually be pretty straightforward if you read that PR.).

[emackey]

@mramato This is kind of the opposite problem. In this particular case, Cesium is executing inside an HTML preview sandbox with relaxed security that allows reading arbitrary files off the local filesystem.

Actually I wonder if just slapping file:/// on the front of the value passed to basePath would fix this. basePath is handed off to new Uri(...), so I would expect that putting the file protocol on it would work so long as the file security isn't in play.

[mramato]

Ahh, that makes perfect sense, and I expect making sure you use a file:// uri should make things work as expected.

[HowardWolosky]

Great catch. That does indeed fix it. I missed this because Babylon doesn't want the file://. I'll need to have that as logic handling when switching between the two renderers. Feel free to close this. I'd recommend just updating the documentation to reflect the need for the file:// protocol when referencing local files.

[emackey]

Great, thanks!