KhronosGroup / KhronosGroup/glTF-Sample-Assets
Draco-compressed version of VirtualCity might be invalid
- Dominant language
- TypeScript
- Stars
- 1.1k
- Forks
- 107
- Avg merge
- 9h 39m
- Merged PRs (30d)
- 4
Description
The Draco-compressed version of the [`VirtualCity`](https://github.com/KhronosGroup/glTF-Sample-Assets/tree/main/Models/VirtualCity) may be invalid:
- The [mesh with index `15`](https://github.com/KhronosGroup/glTF-Sample-Assets/blob/6eb233d158f79f1fbc9648910d8a1f71235d14b1/Models/VirtualCity/glTF-Draco/VirtualCity.gltf#L5819) refers to accessor `202` as its `indices`
- The [accessor with index `202`](https://github.com/KhronosGroup/glTF-Sample-Assets/blob/6eb233d158f79f1fbc9648910d8a1f71235d14b1/Models/VirtualCity/glTF-Draco/VirtualCity.gltf#L13159) contains a `max: [ 228 ]`
- The mesh refers to the accessor with index `203` as its `NORMAL`
- The accessor with index `203` (just below the indices) claims a `count` of `140` - meaning that some indices will be out of bounds for that
For comparison: In the `glTF` version (default, uncompressed):
- The [mesh with index 15](https://github.com/KhronosGroup/glTF-Sample-Assets/blob/6eb233d158f79f1fbc9648910d8a1f71235d14b1/Models/VirtualCity/glTF/VirtualCity.gltf#L5464) refers to accessor `88` as its `indices`
- The [accessor with index `88`](https://github.com/KhronosGroup/glTF-Sample-Assets/blob/6eb233d158f79f1fbc9648910d8a1f71235d14b1/Models/VirtualCity/glTF/VirtualCity.gltf#L9744) contains the same `max: [ 228 ]`
- The mesh refers to the accessor with index `89` as its `NORMAL`
- **But** the accessor with index `89` (just below the indices) has a `count` of `229` - just right for the maximum index of `228`
Maybe I'm overlooking something in the Draco spec - something that claims that the `count` may be that of the compressed/reordered data or something. The [Conformance section](https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Khronos/KHR_draco_mesh_compression/README.md#conformance) claims that a loader must ignore the data of the accessor, and use the Draco-decoded data instead - but I think that this does not imply that the `count` of these accessors may be wrong.
There probably aren't many people who can quickly give a 👍 or 👎 on whether this is really invalid. But I hope that it's OK to tag @lexaknyazev here...
---
EDIT: Mistyped "accessor" as "buffer view" in some places...
Contributor guide
Research direction
Compare Models/VirtualCity/glTF-Draco/VirtualCity.gltf with Models/VirtualCity/glTF/VirtualCity.gltf, focusing on mesh 15 and accessors 202, 203, 88, and 89. Read the KHR_draco_mesh_compression Conformance section to determine whether the Draco asset's accessor metadata is valid and whether any asset correction is required.
Written by the indexing model from the issue text.
Assessment
- Domain
- computer-graphics, testing-qa
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100