EXT_mesh_gpu_instancing should support quantized quaternions

[zeux]

EXT_mesh_gpu_instancing was just merged in #1691 but it specifies quaternions as FLOAT_VEC4:

For "rotation" the values are quaternion FLOAT_VEC4's in the order (x, y, z, w), where w is the scalar.

This is problematic for transmission size reasons. There's a substantial difference in size between a floating-point vec4 quaternion (16 bytes) and signed-normalized 16-bit quaternion (8 bytes). In the basic case I'd expect a typical instance stream to contain 12-byte positions and 16-byte rotations right now (assuming no scaling) which adds up to 28 bytes, vs 20 bytes for signed-normalized representation.

Additionally using #1702 the quantized quaternions can be compressed further with more efficiency compared to non-quantized quaternions.

gltfpack currently only implements quantized storage. Babylon.JS already supports quantized inputs, Three.JS can trivially do so as discussed on the issue.

I'd like to ask that the spec be amended to change the rotation requirements.

[emackey]

@ultrafishotoy Is this something that can be added?

[ultrafishotoy]

@ultrafishotoy Is this something that can be added?

I think its just a matter of adding some language to the description line of schema.

[emackey]

@zeux I think you're the most qualified, would you mind opening a PR to fix this?

[donmccurdy]

Agreed, as this is also more consistent with the existing animation spec.

[lexaknyazev]

The extension spec should have a normative list of allowed element types for each known instanced semantic. Also, while we're here, the extension spec should mention that all accessors used in the same extension object must be of the same count and that count is the number of instances.

[ultrafishotoy]

The extension spec should have a normative list of allowed element types for each known

thanks @lexaknyazev, can someone point me to some example schema that does that? I did a search of the existing schema's and can't seem find any that specify the data type of a quaternion. It seems like the correct thing to do is to remove any references to the parameter data types from the schema and maybe mention them in the readme.md??

[lexaknyazev]

It seems like the correct thing to do is to remove any references to the parameter data types from the schema and maybe mention them in the readme.md?

Exactly. The core spec has the table for attribute semantics and their types. It could be used as a template.

[zeux]

@ultrafishotoy Let me know if you'd like me to submit a PR for this or if you're going to do it (making sure we avoid conflicts)

[ultrafishotoy]

@ultrafishotoy Let me know if you'd like me to submit a PR for this or if you're going to do it (making sure we avoid conflicts)

Please go ahead and thanks!