diff options
author | Rémi Verschelde <rverschelde@gmail.com> | 2020-10-02 14:13:32 +0200 |
---|---|---|
committer | Rémi Verschelde <rverschelde@gmail.com> | 2020-10-05 13:06:50 +0200 |
commit | 2e99d0b26f8b50ec52cd16e029bd0133242036c8 (patch) | |
tree | 098d333e53274a03c1e6231cebacf51ed31dc1b5 /icon.svg | |
parent | 3556bc48a1d357ff0109e2677c2e02b925a3e46b (diff) |
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).
Diffstat (limited to 'icon.svg')
0 files changed, 0 insertions, 0 deletions