donmccurdy / donmccurdy/glTF-Transform
Missing 'normalized' flag in Draco encoder calls
- Dominant language
- TypeScript
- Stars
- 2k
- Forks
- 206
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 16
Description
When compressing glTF assets with Draco, some data about each attribute is encoded _both_ in the glTF accessor, and in the Draco-encoded buffer. Currently there's no way to tell the Draco encoder that a vertex attribute is normalized, so the normalized flag will be missing from the encoded buffer.
Client implementations may read vertex attribute data from either the accessor or the buffer — they're supposed to match — and so clients reading from the buffer may not know the attribute is normalized. three.js currently uses only the accessor data, so this is not an issue for .gltf/.glb files in three.js.
The babylon.js devs tracked the issue down to the Draco library itself, so the problem likely occurs in all current Draco encoders — glTF Transform, glTF Pipeline, Blender, and perhaps others. Once the upstream issue in Draco is resolved, we should be sure to mark normalized attributes in the Draco encoder here.
Context:
- https://github.com/google/draco/issues/1023
- https://github.com/KhronosGroup/glTF-Blender-IO/issues/2013
Contributor guide
Research direction
Start by locating the Draco encoder call sites in this TypeScript repository and review google/draco#1023 for the upstream normalized-attribute support. Once that issue is resolved, pass normalized attributes to the encoder and verify that the Draco buffer metadata matches the glTF accessor.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- computer-graphics
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100