Poor assumptions about file protocol lead to failure.

Some environments allow local file access from JavaScript. In particular, Electron-based environments, such as the HTML preview window in Visual Studio Code, allow this.

There are at least two different places in Babylon where a poor assumption about the presence of file: in a string leads to local file access failure. One is on line 460 of Babylon.Tools.LoadImage and another is on line 540 of Babylon.Tools.LoadFile.

The presence of file: leads Babylon to look in FilesInput.FilesToLoad, which is not correct for this case. The intended behavior in this use case is to send the full XHR request to the file-protocol URL as-is.

For Windows-based local-drive filenames, this problem can be worked around: The Windows drive letter is enough of a clue to Chromium to load from the local file, even without the file protocol being specifically named on the front of the URL. But on Mac/Linux/Unix systems, or even on Windows network shares, there is no drive letter on the front of the URL, and the URL ends up looking like a host-relative root path, not a file-protocol path. Adding an explicit file: protocol to the front of such URLs is the only available fix, but Babylon sees that and refuses to issue an XHR request at all.

/cc @bghgary @sbtron This is deeply related to the issue blocking the glTF Extension for VSCode from working on other platforms, see https://github.com/AnalyticalGraphicsInc/gltf-vscode/issues/58#issuecomment-345111944

[deltakosh]

Or even better : We could try first to load from filesInput and if not found then simply issue an xhr Thoughts?

[deltakosh]

Ok better now!