More general reading / decoding of accessor data

[microsoft]

More general reading / decoding of accessor data

[bghgary]

I'm okay with this. @agrittmsft @chriche-ms Any thoughts?

[agrittmsft]

So this is just a refactor without any real functional changes? Sounds good to me.

[zeux]

The only functional change would entail getting (through refactoring) support for a full set of quantized types for geometry attributes without having to hard-code them (e.g. 8-bit normalized signed integers for normals) - which is currently outside of the set of types mandated by the spec but is useful to reduce the data size.

[agrittmsft]

What would be the new way to perform that type validation?

[agrittmsft]

Maybe something like this?

1. The completely generic data handler function which you're describing
2. A wrapper for (1) which takes std::pair<std::set, std::set> (+ maybe bool normalized?) and throws accordingly
3. Individual wrappers for (2) for specific data types (e.g. Normals)

[zeux]

Can you clarify why the validation is necessary? OTOH I don’t think glTF SDK currently thoroughly validates the document on parse. Would help to understand the specific desirable validity criteria that apply here.