[BUG] Accessors with sparse storage but without bufferView fail validation

[seberoth]

Describe the bug
If a accessor uses sparse storage but hasn't defined a bufferView, the validation fails with Message: Accessor[13] _bufferView: must be defined.
The gltf spec says thats allowed but the accessor MUST be initialized with zeros.

GLTF 2.0 Accessor specs

To Reproduce
Example glb file is attached

please complete the following information:

• OS: Windows 11
• SharpGLTF Version: 1.0.0-alpha0030

example accessor

    {
      "componentType": 5126,
      "count": 7251,
      "sparse": {
        "count": 5920,
        "indices": {
          "bufferView": 13,
          "componentType": 5123
        },
        "values": {
          "bufferView": 14
        }
      },
      "type": "VEC3"
    }

a0_005_ma__strongarms_int_l.zip

EDIT: Probably related Blender GLTF plugin commit: KhronosGroup/glTF-Blender-IO@9ea179a

[vpenades]

Yes, this is a known issue; for some reason I don't undersand (and I don't fully agree) Khronos accepts glTF with missing buffers as valid.

The problem is that supporting missing buffers breaks some stuff inside the APIs, so I am still reasearching for a proper solution.

[vpenades]

I recalled I already asked about this issue here KhronosGroup/glTF-Validator#189

I'll investigate a solution...

[BlueCyro]

Any update on this issue? I'm currently attempting to export a selection of an armature and two skinned meshes with blendshapes (annoying as it is, I can't provide the model itself), but I'm getting a similar exception that reads as-follows:

Unhandled exception. SharpGLTF.Validation.SchemaException: Accessor[8] _bufferView: must be defined.Model generated by <Khronos glTF Blender I/O v4.4.56> seems to be malformed; Please, check the file at https://github.khronos.org/glTF-Validator/
   at SharpGLTF.Schema2.ReadContext._FilterErrors(ValueTuple`2 mv) in /home/cyro/Documents/Coding/Blender/BlendshapeMerger/SharpGLTF/src/SharpGLTF.Core/Schema2/Serialization.ReadContext.cs:line 231
   at SharpGLTF.Schema2.ReadContext.ReadBinarySchema2(Stream stream) in /home/cyro/Documents/Coding/Blender/BlendshapeMerger/SharpGLTF/src/SharpGLTF.Core/Schema2/Serialization.ReadContext.cs:line 222
   at SharpGLTF.Schema2.ReadContext.ReadSchema2(Stream stream) in /home/cyro/Documents/Coding/Blender/BlendshapeMerger/SharpGLTF/src/SharpGLTF.Core/Schema2/Serialization.ReadContext.cs:line 192
   at SharpGLTF.Schema2.ReadContext.ReadSchema2(String resourceName) in /home/cyro/Documents/Coding/Blender/BlendshapeMerger/SharpGLTF/src/SharpGLTF.Core/Schema2/Serialization.ReadContext.cs:line 176
   at SharpGLTF.Schema2.ModelRoot.Load(String filePath, ReadSettings settings) in /home/cyro/Documents/Coding/Blender/BlendshapeMerger/SharpGLTF/src/SharpGLTF.Core/Schema2/Serialization.ReadSettings.cs:line 136
   at SharpGLTF.Scenes.SceneBuilder.LoadDefaultScene(String filePath, ReadSettings settings) in /home/cyro/Documents/Coding/Blender/BlendshapeMerger/SharpGLTF/src/SharpGLTF.Toolkit/Scenes/SceneBuilder.cs:line 66
   at BlendshapeMerger.Program.Main(String[] args) in /home/cyro/Documents/Coding/Blender/BlendshapeMerger/Program.cs:line 16

This issue is unfortunately being quite the thorn in my side. As a result, I can't create a scene builder out of the file in order to post-apply some very custom blendshape normals that blender (still) doesn't support exporting on it's own. Blender seems to only support exporting with sparse accessors and doesn't seem to respect doing otherwise.

This could be considered a bug on their side, but the fact that this library doesn't seem to support sparse access whatsoever is rather unfortunate and is the one thing putting a brick wall to the task at hand. :(

[vpenades]

To tell you the truth I barely have time to check this kind of issues, primarily because they require carefully understanding the issue, creating a proper unit test that showcases the issue and then fixing it. It's even more difficult if the test depends on files exported by other software.

If you want this issue to move forward, I would suggest you to push a PR of a unit test in the third party tests project. The test would implement your use case and would test the result you expect, the test would obviously fail, but I will help me figure out the problem and potential fixes much faster

[BlueCyro]

To tell you the truth I barely have time to check this kind of issues, primarily because they require carefully understanding the issue, creating a proper unit test that showcases the issue and then fixing it. It's even more difficult if the test depends on files exported by other software.

If you want this issue to move forward, I would suggest you to push a PR of a unit test in the third party tests project. The test would implement your use case and would test the result you expect, the test would obviously fail, but I will help me figure out the problem and potential fixes much faster

Thanks for the suggestion, I'll be sure to take a look at those once I have time

[Nolram12345]

I'm currently encountering this issue as well, as it occurs with quite a variety of GLB files in particular when exported from Blender. Are there any updates or known workarounds?

[vpenades]

I'm currently encountering this issue as well, as it occurs with quite a variety of GLB files in particular when exported from Blender. Are there any updates or known workarounds?

No, this is a complex issue that requires time which I don't have, and that's why I proposed opening a PR with a unit test showcasing the issue.

[Nolram12345]

For anyone else running into this issue with Blender-exported GLTFs: If you disable Data > Shape Keys > Optimize Shape Keys > Use Sparse Accessor if better in the export options of the GLTF, it will typically import just fine with otherwise default export settings.

[vpenades]

I've written a more detailed explanation of the issue here: #280