Extension EXT_meshopt_compression

[atteneder]

Add support for the vendor extension EXT_meshopt_compression

See also: meshoptimizer / gltfpack

[PirateNick]

I used gltfpack to optimize my GLTF assets. When using either of the compressions, I get:

Required glTF extension EXT_meshopt_compression is not supported!

I'm on GLTFast 3.1.0, Draco 1.4.0.

When can we roughly expect this to be implemented?

Thanks!

Edit!

I used GLTF-transform and this worked perfectly!

[atteneder]

Hi @NickPeelman ,

First, thanks for your interest!

TL;DR: Not in my near-term planning, sorry.

gltfpack is a great, great tool, and that alone is a reason to support this extension.

However, my last comparison with Draco showed that on average it decodes MUCH faster, but is larger in size. On typical mobile connection speeds (up to LTE) this benefit does not pay off.
These comparisons involved only 3 mid- to high-polygon models, so take it with a grain of salt. Also, Draco does not compress animation (which gltfpack does), so for moving things it might be better.

That being said, I eventually want to include this extension, but cannot offer a timeline yet.

hth

[donmccurdy]

However, my last comparison with Draco showed that on average it decodes MUCH faster, but is larger in size. On typical mobile connection speeds (up to LTE) this benefit does not pay off.

I'd be curious if you included gzip on both the Draco and meshopt files? AFAIK meshopt does not provide as much compression as Draco on its own, but "instead of reducing the encoded size as much as possible, the bitstream is constructed in such a way that general-purpose compressor can compress it further." So Gzip (or other compression methods) will likely reduce meshopt-compresed GLB files still further, whereas they don't add much to Draco compression... Of course Gzip or Brotli will reduce decoding speed a bit.

[atteneder]

Hi @donmccurdy ,

Good to hear from you! Hope you enjoy the post-g life :)

I did the mentioned tests in native (macOS) builds and not WebGL. Thus there was no gzip or brotli applied.
Another factor that's different in Browsers is the current lack of webassembly threading.

I quickly tried brotli on some of my files:

One of the models tested was a Volvo car taken from this sample project. What's impressive is that meshopt was performing better on this one!

You'r right, brotli works much better on meshopt buffers than on draco.

Usually the meshopt variant would be bigger though, like with this one:

Before brotli Draco seems superiour, but after brotli compression, they're quite similar in size. Considering that meshopt decompression is suppedly way faster, it would make a lot of sense here as well!

Thanks for poking at me, I'll reconsider the prio for this!