From 2e99d0b26f8b50ec52cd16e029bd0133242036c8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=C3=A9mi=20Verschelde?= Date: Fri, 2 Oct 2020 14:13:32 +0200 Subject: glTF: Fix parsing image data with `mimeType` undefined The glTF 2.0 spec only makes `mimeType` mandatory for `bufferView` image data, so the previous logic to handle URIs with base64-encoded images could fail if `mimeType` is undefined. The logic was documented and refactored to better handle the spec, notably: - `uri` and `bufferView` are now mutually exclusive, and only the latter fails if `mimeType` is undefined. - `uri` with a file path will now respect the `mimeType` if defined, and thus attempt loading the file with the specified format (even if its extension is not the one expected for this format). So we can support bad extensions (PNG data with `.jpg` extension) or custom ones (PNG data in `.img` file for example). - `uri` with base64 encoded data will infer MIME type from `data:image/png` or `data:image/jpeg` if it was not documented in `mimeType` initially. - `uri` with base64 encoded data, no `mimeType` and `application/octet-stream` or `application/gltf-buffer` will fall back to trying both PNG and JPEG loaders. Fully fixes #33796 (and fixes up #42501). --- scene/resources/mesh.cpp | 1 - 1 file changed, 1 deletion(-) (limited to 'scene/resources') diff --git a/scene/resources/mesh.cpp b/scene/resources/mesh.cpp index 10f0a040d0..e9606e03e6 100644 --- a/scene/resources/mesh.cpp +++ b/scene/resources/mesh.cpp @@ -872,7 +872,6 @@ Array ArrayMesh::_get_surfaces() const { ret.push_back(data); } - print_line("Saving surfaces: " + itos(ret.size())); return ret; } -- cgit v1.2.3