Support sparse accessors? about cgltf HOT 7 CLOSED

This would be great - gltfpack doesn't support sparse data atm either. Transparent support would be much appreciated.

I see two ways to do it:

1. Provide a function to convert from sparse to dense storage. Clients would call it first, and then read_float would work as is. There's a memory cost to that, but the implementation gets to be very simple.

2. Automatically extract sparse data. The indices in sparse accessors are sorted so a simple implementation could involve a binary search through indices. If we wanted to optimize this further, we could cache the last accessed index and start by checking if the index requested is between this and the next one, but probably binary search alone is reasonably practical.

Also read_float currently fails for zero-filled accessors (you can specify an accessor without a buffer view even in absence of sparse data), which would be great to fix as well.

from cgltf.

I like your option 1. Maybe we keep read_float as-is and add a slightly higher-level API that looks like this:

cgltf_size cgltf_accessor_unpack_floats(const cgltf_accessor* accessor,
		cgltf_float* out, cgltf_size count);

Clients could call this instead of the one-at-a-time API, and they could do so without even bothering to check if the accessor is sparse or non-sparse.

The primary purpose of the count is to verify that enough space exists at the destination address. It could also be used to extract only the first few elements but that's just a side effect. As per our February discussion, we don't need to support a custom range (i.e. an offset), since it's best to keep the API simple.

Some details: the returned count is the number of floats actually written, which might be less than the provided count. If out is null, this function returns the number of required floats (which is cgltf_num_components(accessor->type) * accessor->count).

from cgltf.

With unpack_floats, what would the count argument mean? Component count of each element?

For gltfpack use, there's three key areas where read_float is utilized right now:

1. Reading vertex component data - this can be trivially converted to unpack_floats, if it takes a custom element count (4 in this case) as an input.

for (size_t i = 0; i < attr.data->count; ++i)
	cgltf_accessor_read_float(attr.data, i, s.data[i].f, 4);

2. Reading skin matrices - this reads a matrix at a time right now but can be converted to unpack_floats without too much trouble:

cgltf_accessor_read_float(skin.inverse_bind_matrices, j, transform, 16);

3. Reading animation data. This code is really complex :-/ it can probably benefit from using unpack_floats if the entire animation track is unpacked first - I think this would work. This is the only part that isn't very straightforward because the code is reading one animated element at a time at indices that are complex, e.g.

case cgltf_interpolation_type_cubic_spline:
{
	Attr v0 = {};
	Attr b0 = {};
	Attr a1 = {};
	Attr v1 = {};
	cgltf_accessor_read_float(sampler.output, (cursor * 3 + 1) * components + j, v0.f, 4);
	cgltf_accessor_read_float(sampler.output, (cursor * 3 + 2) * components + j, b0.f, 4);
	cgltf_accessor_read_float(sampler.output, (cursor * 3 + 3) * components + j, a1.f, 4);
	cgltf_accessor_read_float(sampler.output, (cursor * 3 + 4) * components + j, v1.f, 4);
	data.push_back(interpolateHermite(v0, b0, v1, a1, t, range, type));
}

from cgltf.

Count is the requested number of floats. To read one 4x4 matrix, it would be 16. The actual number of floats written would be the min of the number of requested floats and required floats.

from cgltf.

This would require knowing the component count - note that cgltf_num_components isn't exposed right now.

from cgltf.

Yes, I think we should also expose the num_components function (which, incidentally, is also useful for users of the existing one-at-a-time API). Also, note that clients can pass null to the unpack function to get a total float count.

from cgltf.

Good news: this will be only ~25 lines of code.

However one issue is that the glTF spec is unclear in how to treat accessor->sparse.values_byte_offset: does it add to or replace the offset in the base accessor?

EDIT: It must be replace since the buffer view is replaced as well; the source val array is decoupled from the dest val array.

from cgltf.