KhronosGroup / KhronosGroup/glTF-Sample-Assets

Draco-compressed version of VirtualCity might be invalid

Open
#264 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.