CesiumGS
Support sparse accessors in Model
The old Model class didn't handle sparse accessors from the glTF spec. For better spec compliance, the new ModelExperimental should add this.
Not sure the exact scope of how to implement this, but some thoughts:
- Certainly
GltfLoader(or related loaders) would need more parsing logic for sparse accessors - If it's possible, handle this completely at load time so ModelComponents and runtime code such as the
GeometryPipelineStagedon't need to worry about whether the accessor was sparse or dense.
This would also be useful for animation with morph targets, since the weights are packed per keyframe. It gets even more cumbersome to pull the data when CUBICSPLINE interpolation is involved, since there are three values per morph weight per keyframe.
In https://github.com/CesiumGS/cesium/issues/11961, @mramato pointed out a glTF which fails to load, and @javagl Identified lack of support for sparse accessors as the cause for the failure.
house.glb.txt is a draco encoded glTF model that loads fine in all viewers I tried except for CesiumJS. It validates cleanly with no errors.
When loaded into CesiumJS, it reports:
RuntimeError: Failed to load model: ../../SampleData/models/house.glb
Failed to load glTF
One of options.bufferViewId and options.draco must be defined.
... the way CesiumJS is failing here is not very useful and a clear error message or warning about lack of sparse accessors would be the least we could do. But it definitely bugs me that there is part of the glTF standard we seem to not support, especially since tools like gltf-transform's optimize function produces sparse accessors where applicable.
@ggetz @lilleyse What is the level of effort to support them?
What is the level of effort to support them?
Correct me if I'm wrong @lilleyse, but supporting sparse accessors is a matter of updating the loader parsing and shouldn't be complex to support.
Yeah it seems pretty straightforward. The simplest approach would be to expand the sparse accessor at load time.
