Sparse accessors are not handled correctly by iterators

[bwasty]

The SimpleSparseAccessor sample model is rendering like this in my viewer:

It should look like this:
https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0/SimpleSparseAccessor

Looking at the data layout / geometry explanations (in the sample model readme), it seems to me like sparse accessors are not considered by the iterators.

[alteous]

The library currently does not expose sparse iterators. I expect what you currently render is the 'base case' where vertices are not perturbed.

[bwasty]

I'd still call it a bug. The iterators should at least fail instead of delivering wrong data if the underlying accessor is sparse.

[alteous]

Let's fix this before the next release.

[bwasty]

Possibly helpful: https://github.com/bwasty/gltf-loader-ts/blob/3b44a0e9c58c3bb5092ac8586e1bc9779e92f1b0/source/gltf-asset.ts#L91-L115 (TypeScript implementation I did a while ago).

[alteous]

I'm attempting this now. It's quite difficult to achieve for all accessors. I suggest we start with morph targets (positions, normals, and tangents) and expand from there.

[alteous]

A sparse accessor differs from a regular one in that bufferView property isn't required. When it's omitted, the sparse accessor is initialized as an array of zeros of size (size of the accessor element) * (accessor.count) bytes. A sparse accessor min and max properties correspond, respectively, to the minimum and maximum component values once the sparse substitution is applied.

When neither sparse nor bufferView is defined, min and max properties could have any values. This is intended for use cases when binary data is supplied by external means (e.g., via extensions).

Our handling of sparse accessors is more broken than originally thought!

[bwasty]

I haven't looked into the code for a while (and I'm currently traveling), but I wonder what makes it so hard to do generically for all accessors - in TypeScript (linked above) I found it surprisingly easy in the end.