Practically I don’t want to modify the gltf but intercept his loading and eventually look in some fallback folder for textures…How can I do this?
I do not know enough the API , so I’m struggling a little bit
thanks
Reading at the source code, it seems there’s no way to easily intercept the loading path of textures.
The code in _loadTextureAsync is:
if (image.uri) {
if (Tools.IsBase64(image.uri)) {
url = image.uri;
}
else if (this._babylonScene.getEngine().textureFormatInUse) {
// If an image uri and a texture format is set like (eg. KTX) load from url instead of blob to support texture format and fallback
url = this._rootUrl + image.uri;
}
}
As you can see, the image.uri is concatened with this._rootUrl.
You could write a GLTF extension and override _loadTextureAsync, but it may not work because you need to access private members of the GLTF loader (at least I tried and it didn’t work because of that)…
the error I have is with the babylon engine in vscode
this is what he say
/images/0/uri: ‘…/texture/checker-map_tho.png’ is invalid
with tree.js engine the texture is visible without problem.
seems like babylon is not able to navigate on top of the gltf itself
babylon engine does not allow any of this
neither an absolute path neither a relative path that go up in folder hierarchy
is there any way to avoid override this?
Also I do not understand why a gltf with a broken texture path should not be visible at all .
it should fallback in a default texture or something similar
Is this a missing feature or it is like this by design?
The first is the result of only implementing support for relative paths. The second resulted from a security review. Both of these are security risks if the glTF is from untrusted sources.
As for your scenario, I’m assuming your glTF are from trusted sources, I think we can add a flag to turn off the .. check and possibly another flag for allowing additional url schemes (like http://). If you want either of these, please file issue(s) on GitHub.
Another related feature of the loader is the preprocessUrlAsync callback on the glTF loader that allows you to modify the url before the loader loads it. This currently happens after the .. check though.
I agree and I understand the security issues.
And of course leave this security check optional is the best solution in my opinion
Thanks, I will raise the issues on github
I’m doing the exact same thing for loading varying-texture GLTFs into Unity (where the additional textures are not predefined in the .gltf). I’ve tried injecting reference to new image at several places in the unity importer, and it always comes out fail in some way or other. Better to just change the JSON and reload from scratch. Good to see the method confirmed here.
FWIW, I just tried this, and it doesn’t work, because the URI needs to be relative.
So if your asset was loaded from https://mywebsite/assets/model.gltf this would update the uri of the image to https://mywebsite/assets/http://example.com/myimage.png
It also doesn’t let you use ../ in the relative path, so right now I can’t see anyway to share textures between multiple gltf files if those textures are in a higher directory path than the models.
For example if I have two models that share the same texture: /models/category1/model1.gltf /models/category2/model2.gltf
They can’t share a texture in a “global” pool of textures at something like: /textures/texture.png
Because there is no way to relatively get that texture path without using ../. Is that correct? Is there any way around this, or is it basically a limitation of the gltf spec?
Hi Tim, this definitely works and we’re using it in production. I’m not sure what’s different, but we are only loading in a single GLTF file and each texture path is updated to point to a service instead of the relative path. You can pass in params to the GLTF extensions, so you could include a prop that tells your various GLTF files which path to use based on some criteria. In my experience, the GLTF extension is very flexible and we’re using several of them to do various transformations to the data.