EXT_meshopt_compression

[Inviz]

I want to compress my files with gltfpack but unfortunately, because it uses its custom decoder, i can not feed compressed files to gltf-transform. The issue I have with gltfpack is that it's a bit too rigid and sometimes does unwanted things like hyperoptimizing animation tracks. I would love to be able to merge compressed and un-compressed files together with gltf-transform.

[Inviz]

I guess for my needs even gluing two glb files together (of them one compressed with EXT_meshopt_compression) would be good enough.

Another issue with gltfpack is that it does not support multiple scenes, so it lumps them all into one. So i have to do turn scenes into nodes with gltf-transform before feeding to gltfpack, which is pretty ugly and unfortunate. But i made peace with it

[donmccurdy]

The issue I have with gltf-transform is that it's a bit too rigid and sometimes does unwanted things like hyperoptimizing animation tracks

You mean gltfpack here, correct?

I need to think about how to support this... one option would be to decompress the file while loading and then recompress it while writing, which would probably depend on zeux/meshoptimizer#164, or something like it. Currently KHR_draco_mesh_compression is decompressed while loading, but I haven't implemented the compression side for export yet. But repeated lossy compression doesn't sound ideal, with either compression method.

I'd also like to support quantization — one of the compression techniques that gltfpack uses — directly in this tool see #59.

Probably not a quick fix here, sorry. You might get a more helpful response requesting that gltfpack provide some options for individual optimizations in isolation? Otherwise I may need to wait and see what happens with zeux/meshoptimizer#164.

[Inviz]

You mean gltfpack here, correct?

Yes, I apologize. I mean gltfpack

But repeated lossy compression doesn't sound ideal, with either compression method.

Yeah for sure. If re-packing means re-quanitifying the files, then it will lead to even more losses. Not good, for sure. I guess just allowing compressed file to be glued together with other files would work for my case well.

However un-packing and re-packing the EXT_meshopt_compression does not sounds like a lossy operation. So i think it could be possibly to decode those. And then gltfpack has -noquantify option, so that it would not want to re-quanitify file that was quantified previously and glued together with gltf-transform, it could work well by only re-encoding the files. So on your end there would only need to be a decoding. But i guess that thing is a bit moot, because you could do that right now too, if files were never compressed before gltf-transform. I guess i had some bug with noq or something that made me want to do it this way, and gltfpack also does not support multi-scene files as of yet so that also breaks stuff.

I'd also like to support quantization — one of the compression techniques that gltfpack uses — directly in this tool see #59.

Sounds like a good idea, if it would be possibly to plug into to gltfpack directly, instead of duplicating the effort.
I'll chime in to that issue you linked.

Thank you!

[donmccurdy]

Have added support for decoding EXT_meshopt_compression so far: #314.

Working on encoding now, beginning with #321.