gltfpack: Replace images that can't be found or encoded with invalid URI #676
Conversation
Instead of printing to stderr manually whenever we have a case when an image can't be saved, call writeImageError; this unifies the error reporting and allows us to produce JSON content that indicates an error.
This prevents errors around missing images in case we can't find the source image or can't encode it. Loading the resulting glTF file will result in a PNG decode error. Unfortunately, files like this are still treated as invalid by glTF spec/validator.
|
Removal of image/texture references is possible in theory. I think right now nothing prevents this from keeping the file valid. In addition to that change being much more invasive, I'm also worried about future extensions where you can't simply omit an image/texture reference, eg |
|
The effect of this change is that files that had invalid or missing images previously failed to parse when using three.js GLTFLoader, and now cleanly load with the following error in the console: 
gltf.report also loads the file but has some odd error handling for cases like this: 
|
|
I asked for clarifications on the official GLTF repo about GLTF asset file validity in these cases, and the result is that an invalid URI indeed makes the GLTF asset file invalid but a valid URI pointing to a missing/corrupted file is valid usage, so the produced GLTF asset file must still be valid in this case. |
|
Sure; I think semantically really all of these are invalid in the same sense; glTF spec may consider some subset of these invalid cases "valid", and glTF validator may or may not disagree (for example, glTF validator will parse JPEG/PNG headers and as such a file that isn't a valid PNG can be treated as invalid by the validator). I'm going to merge this for now as it's better than status quo; it might be better to remove image references completely after all in cases like this but this can be done separately. |
This change consolidates error handling for images that can't be read, written, or encoded, and uniformly emits an invalid embedded Base64 URI in these cases.
This keeps the file invalid as per glTF spec, but allows various loaders to load it. The source file in cases like this was semantically invalid so maybe this is fine.
Ideally we would probably want to remove references to the image. Unfortunately, to preserve glTF file validity, this requires transitive removal of texture references from all materials as well as image/texture array compaction...
Fixes #675