Support for "MESHOPT_compression" GLTF Extension

[karanganesan]

I was recently looking into @zeux's work on https://github.com/zeux/meshoptimizer/
this is mind blowing compression tool

I can confirm that normal gltfpack compression with "KHR_mesh_quantization" works Model Viewer 0.10.0

but when I compressed the model with meshoptimizer codecs (-c) it didn't work on Model Viewer 0.10.0

I got

GLTFLoader.js:267 THREE.GLTFLoader: Unknown extension "MESHOPT_compression".

So ya it would be great to see this added to model viewer

A little how to is also mentioned here https://github.com/zeux/meshoptimizer/tree/master/gltf

this is the size I got when I did the compression

Thanks :)

[lanxinger]

@karanganesan in our tests we almost always got better results with Draco compression. but it would of course be welcome to have another supported extension but not sure what the performance implications are.

[donmccurdy]

My assumption is that Draco comes out slightly ahead on raw geometry compression, but Meshopt decompresses much more efficiently on the client. Meshopt also compresses animation, which Draco does not. So, either may be a reasonable choice depending on your needs.

I don't expect a MESHOPT-prefixed extension would be supported directly by three.js, but there is interest in making THREE.GLTFLoader more extensible for customization (mrdoob/three.js#19144). Support in <model-viewer/> would probably require that.

[zeux]

The current draft is MESHOPT-prefixed but I am hoping that this extension will be standardized as EXT/KHR because it quite neatly fills large gaps in existing compression capability - it's not just animation, but even in geometry land point clouds and morph targets can't be compressed by Draco. Of course the plugins are welcome regardless :)

[zeux]

FWIW this extension is available as EXT_meshtopt_compression and is exposed in three.js, you just need to call setMeshoptDecoder on the GLTFLoader and that's it. Example: mrdoob/three.js#21111

[arthurrmp]

@zeux any examples about how can I do that? I've not been able to access the Three.JS scene.

[zeux]

https://github.com/mrdoob/three.js/blob/dev/examples/webgl_loader_gltf_compressed.html

[arthurrmp]

https://github.com/mrdoob/three.js/blob/dev/examples/webgl_loader_gltf_compressed.html

Sorry, I can't understand... Is there a way to do this on ?

[donmccurdy]

@arthurrmp if you're hoping to use EXT_meshopt_compression in <model-viewer>, I think it's necessary to wait until <model-viewer> itself adds support, or to write a PR. The changes should be pretty minor though.

[donmccurdy]

Is this something <model-viewer/> would be interested in a PR for? The meshopt decoder is about 15kb gzipped, and could be lazy-loaded similarly to Draco or Basis loaders. three.js supports EXT_meshopt_compression now and I do think that it fills an important gap in the optimization space.

[elalish]

Sure! How common is it relative to DRACO? Are there any performance tradeoffs?

[donmccurdy]

Would be awesome to see usage stats but unfortunately I don't have them! I'm working on an implementation in glTF-Transform (both encode and decode) now, and will make that available as a GUI option in https://gltf.report/, alongside Draco, as well. My impression of the performance implications so far:

• Compressed size for static geometry: Tossup. Both usually in the same ballpark, but I do find models where one or the other comes out ahead, too. Need to compare sizes including gzip or brotli compression for an apples-to-apples result. Some hosts (*cough* GitHub Pages) don't support Gzip for GLB files and so will do better with Draco.
• Compressed size for animation or morph targets: Draco doesn't compress these, so clear advantage to Meshopt here. Could presumably use both (Draco for static geometry, Meshopt for animation tracks) if you want, my implementation should allow that, but too early to say if there's much value in hybrid compression.
• Compression speed: Haven't compared.
• Decompression speed: Significant advantage to Meshopt.

[zeux]

The meshopt decoder is about 15kb gzipped

Small correction: it should be ~6.5kb (gzip -1 produces 6657 byte file from meshopt_decoder.js). There's also a few hundred bytes that you pay for the plugin in three.js loader but presumably model-viewer already pays that cost by virtue of using the loader with that plugin integrated.

[elalish]

Sounds great! I'm getting more issues related to animation, so it seems related features will be getting more important.

[donmccurdy]

Opened: #2706