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

Fix noncomformant behavior by not requiring the source field to be present in textures. #413

Closed
wants to merge 1 commit into from

Commits on Feb 18, 2024

  1. Fix noncomformant behavior by not requiring the source field to be

    present in textures.
    
    It's perfectly legal for `source` to not be present. Typically, this
    will happen when an extension such as `KHR_texture_basisu` provides the
    actual source.
    
    The glTF spec § 5.29 states unambiguously that `source` is an optional
    field [1]. The validator backs this up (see the `blank_texture.gltf`
    test case, which validates). Furthermore, the `KHR_texture_basisu`
    extension provides the following example in "Using without a fallback"
    [2]:
    
    ```json
    "textures": [
    {
        "extensions": {
    	"KHR_texture_basisu": {
    	    "source": 0
    	}
        }
    }
    ],
    ```
    
    This doesn't contain a `source` field. Parsing this today with the
    `gltf` crate causes a panic in `serde`.
    
    I ran into this with the `gltf-transform` [3] tool, which follows the
    standard when compressing textures and therefore produces valid glTF
    files that the `gltf` crate panics when attempting to load.
    
    [1]: https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#reference-texture
    
    [2]: https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Khronos/KHR_texture_basisu/README.md#using-without-a-fallback
    
    [3]: https://github.com/donmccurdy/glTF-Transform
    pcwalton committed Feb 18, 2024
    Configuration menu
    Copy the full SHA
    359a89b View commit details
    Browse the repository at this point in the history