GLTFLoader: Implement support for KHR_meshopt_compression

[zeux]

Specification: KhronosGroup/glTF#2517

Since the extension uses the exact same JSON structure as EXT variant,
and meshopt decoder automatically decodes v1 attribute blobs and
automatically picks up color filters through filter name, the only thing
we need to do is to register the extension code twice for two different
names.

To decode new v1 vertex streams and color filters, meshopt_decoder
needs to be updated to v0.25; the updated module is of course fully
compatible with all prior encoded data.

When using gzip/Brotli compression, the .js file got 1.5 KB larger:

• gzip, before: 6432 bytes
• gzip, after: 8051 bytes (+25%)
• Brotli, before: 5754 bytes
• Brotli, after: 7203 bytes (+25%)

This increase is significant on a relative basis, but given that CDN response
headers often approach 1 KB, it's perhaps reasonable in absolute terms. If this
becomes a problem in the future, it is possible to shrink the file in various ways,
for example removing support for pre-SIMD Wasm engines would remove 2 KB
post-gzip.

[donmccurdy]

Thank you @zeux!

Support for WASM SIMD looks quite good...

• https://webassembly.org/features/
• https://caniuse.com/wasm-simd

... assuming support depends only on the runtime/browser, and not the device/CPU? If that's the case, then I think dropping non-SIMD support would be reasonable. But for three.js' purposes, the Meshopt decoder is already much smaller than Draco or Basis decoders, so I'm not complaining about +1.5 kb here. :)

It'd be nice to have the draft at "Review Draft" or "Release Candidate" status before we merge, but open to other suggestions as well.

Work in progress for glTF Transform:

• feat(extensions): Add KHR_meshopt_compression donmccurdy/glTF-Transform#1745

[zeux]

support depends only on the runtime/browser, and not the device/CPU

There is some dependency on CPU features too - I'm not sure caniuse report incorporates this. I would not expect this to notably affect the usage percentage. Regardless, this is more of a possibility in the future; I agree that for now the increase seems fine relative to other projects, it's just visible when looking at it relative to the older size :)

Agreed wrt extension status, I posted this PR a draft for awareness + to move the extension along (hopefully existence of draft implementations encourages extension review progress!).

[zeux]

I've updated the PR with the 1.0 version of the decoder module; it's more or less the same in terms of size as the original comments indicate (+-20 bytes post deflate); the update is not essential but it's nice to depend on the latest stable release.

[zeux]

Per KhronosGroup/glTF#2517 (comment) this extension is in "review draft" and so hopefully this PR can be reviewed now.

For testing, assets from this comment could be used: KhronosGroup/glTF#2517 (comment) (glTF-Sample-Assets will get test assets in the future). gltfpack 1.0 also supports this extension via -cz command line argument and could be used for testing on arbitrary glTF files, including re-compressing the asset used in existing three.js sample for glTF compression.

Here's a synthetic cube grid asset that uses various combinations of modes too, and should look approximately like this:

[zeux]

For completeness, here's an updated version of the asset used by three.js 'webgl_loader_gltf_compressed' example; it can be copied to examples/models/gltf/ folder to test this PR as well. (it seems better to keep this PR focused on the extension support and do that in a separate PR)

coffeemat.zip

@donmccurdy Please let me know if you have any comments!

[donmccurdy]

Thank you @zeux! Changes look good to me. Given the "review draft" status, applicability and adoption of the EXT extension, and minimal added complexity of the implementation, I think we can merge support for KHR_meshopt_compression now.