Skip to content
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

[Merged by Bors] - Fix MIME type support for glTF buffer Data URIs #3101

Closed
wants to merge 1 commit into from

Conversation

parasyte
Copy link
Contributor

Objective

Buffer data MAY alternatively be embedded in the glTF file via data: URI with base64 encoding. When data: URI is used for buffer storage, its mediatype field MUST be set to application/octet-stream or application/gltf-buffer.

(Emphasis in original.)

Solution

  • Check for both MIME types.

@github-actions github-actions bot added the S-Needs-Triage This issue needs to be labelled label Nov 10, 2021
@alice-i-cecile alice-i-cecile added A-Assets Load files from disk to use for things like images, models, and sounds C-Bug An unexpected or incorrect behavior S-Needs-Review and removed S-Needs-Triage This issue needs to be labelled labels Nov 10, 2021
Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks for the clear explanation!

@parasyte
Copy link
Contributor Author

parasyte commented Nov 10, 2021

I hit this issue when attempting to load some of the Khronos glTF sample models.

@cart
Copy link
Member

cart commented Nov 11, 2021

Can you also create a pr with these changes on top of the pipelined-rendering branch (in the pipelined/bevy_gltf2 folder)?

@cart
Copy link
Member

cart commented Nov 11, 2021

bors r+

bors bot pushed a commit that referenced this pull request Nov 11, 2021
# Objective

- The glTF 2.0 spec requires that Data URIs use one of two valid MIME types. `bevy_gltf` only supports one of these.
- See:
  - https://www.khronos.org/registry/glTF/specs/2.0/glTF-2.0.html#_media_type_registrations
  - https://www.khronos.org/registry/glTF/specs/2.0/glTF-2.0.html#file-extensions-and-media-types
  - https://www.khronos.org/registry/glTF/specs/2.0/glTF-2.0.html#binary-data-storage

> Buffer data **MAY** alternatively be embedded in the glTF file via `data:` URI with base64 encoding. When `data:` URI is used for buffer storage, its mediatype field **MUST** be set to `application/octet-stream` or `application/gltf-buffer`.

(Emphasis in original.)

## Solution

- Check for both MIME types.
@bors bors bot changed the title Fix MIME type support for glTF buffer Data URIs [Merged by Bors] - Fix MIME type support for glTF buffer Data URIs Nov 11, 2021
@bors bors bot closed this Nov 11, 2021
@parasyte parasyte deleted the fix/gltf-loader-mimetype branch November 11, 2021 03:25
bors bot pushed a commit that referenced this pull request Nov 11, 2021
Apply #3101 on top of the `pipelined-rendering` branch, as requested by @cart in #3101 (comment)

# Objective

- The glTF 2.0 spec requires that Data URIs use one of two valid MIME types. `bevy_gltf2` only supports one of these.
- See:
  - https://www.khronos.org/registry/glTF/specs/2.0/glTF-2.0.html#_media_type_registrations
  - https://www.khronos.org/registry/glTF/specs/2.0/glTF-2.0.html#file-extensions-and-media-types
  - https://www.khronos.org/registry/glTF/specs/2.0/glTF-2.0.html#binary-data-storage

> Buffer data **MAY** alternatively be embedded in the glTF file via `data:` URI with base64 encoding. When `data:` URI is used for buffer storage, its mediatype field **MUST** be set to `application/octet-stream` or `application/gltf-buffer`.

(Emphasis in original.)

## Solution

- Check for both MIME types.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Assets Load files from disk to use for things like images, models, and sounds C-Bug An unexpected or incorrect behavior
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants