Open ptrgags opened 2 years ago
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.
The old
Model
class didn't handle sparse accessors from the glTF spec. For better spec compliance, the newModelExperimental
should add this.Not sure the exact scope of how to implement this, but some thoughts:
GltfLoader
(or related loaders) would need more parsing logic for sparse accessorsGeometryPipelineStage
don't need to worry about whether the accessor was sparse or dense.