-
Notifications
You must be signed in to change notification settings - Fork 508
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
gltfpack: Output GLTF is invalid if input scene has missing image files #675
Comments
I'm not sure if copying the URI unconditionally is always a good idea: if the output is a GLB file, I'd expect no external references and there might be issues if the target application doesn't expect that any URIs are preserved (eg maybe it's a URI that can be used maliciously somehow). Maybe in that case an empty URI would suffice... |
This might cause some issues when the final program tries to recompose the absolute path of the file. Example: std::filesystem::path absolutePath = gltfParentPath / imageUri;
if (std::filesystem::exists(absolutePath))
{
// Read and process image
// No need to check for error since the path exists, what could go wrong?
} I think the best way is to remove the image entry altogether (along with texture entries referencing it) and unlink those textures from materials, as if the material's texture slot was empty from the start. |
@zeux i was able to get a model with this problem ( looks like it from the hubs exporter) |
Yeah I didn't include a sample (probably should have, sorry). |
One other potential cause here is that when using |
When optimizing a GLTF file which has image entries referencing missing files, the exported image entries have neither their
uri
property nor theirbufferView
property defined.According to this JSON schema in the specs, such entries are invalid.
When optimizing, gltfpack logs warnings about skipping these missing images entries to the console, which means it already is aware of this possibility.
As such, I would expect it to produce a valid GLTF file by simply copying these entries to the output file without any processing.
(related to KhronosGroup/glTF#2377)
The text was updated successfully, but these errors were encountered: