VRM support

[Moebytes]

Hello, I am still interested in VRM support, which is an extension of glb commonly used for vtubers.

Based on the specification available here, I think it is just the extensions "VRM" or "VRMC_vrm" added to the json:
https://github.com/vrm-c/vrm-specification

I made some changes to preserve this in the output json, but I experienced some issues where it works for some vrm files and not for others. My code changes are here:
https://github.com/Moebits/meshoptimizer/tree/vrm

Another thing of note is that I had to disable quantization -noq and enable all the keep options for it to work -kn -km -ke -kv.

Here is a VRM viewer where you can quickly test the vrm:
https://pixiv.github.io/three-vrm/packages/three-vrm/examples/dnd.html

This was one of the models that worked:
./gltfpack -i sung.vrm -noq -kn -km -ke -kv -si 0.7 -o sung2.vrm
This model didn't work:
./gltfpack -i miku.vrm -noq -kn -km -ke -kv -si 0.7 -o miku2.vrm
This is the error when loading it in that viewer (with three.js and pixiv vrm extension):

sung.vrm: https://files.catbox.moe/xz3p5l.vrm
sung2.vrm: https://files.catbox.moe/p47ntm.vrm
miku.vrm: https://files.catbox.moe/kdguiv.vrm
miku2.vrm: https://files.catbox.moe/ypqn8h.vrm

I would appreciate some help in resolving this issue as I don't know enough about glTF to fix it. It seems like the textures aren't being saved correctly. Thanks!

[zeux]

Please refer to https://github.com/zeux/meshoptimizer/blob/master/gltf/README.md#extensions for the extension support policy. No vendor specific extensions are supported and there are no plans to change that in general; my recollection is that VRM is particularly challenging because it's has a large amount of features that require fully parsing and processing the extensions, and VRM seems to be developed on a separate track - the extensions are not part of the glTF repository.

Your approach is fairly fragile - gltfpack performs changes to node / texture / mesh / etc. structure, and any references from VRM data to any other glTF objects will need to be analyzed & preserved & remapped if the indexing changes. Using all of the -k flags may help but is likely insufficient; your specific error is probably caused by removal of unused textures, to fix that you'd need to add some code that changes TextureInfo::keep to true for all textures in textures array.

For production use cases I would probably recommend investigating adding VRM support using glTF-Transform extensibility features, see "Custom extensions" here: https://gltf-transform.dev/extensions. gltfpack is, by design, limited to a strict "portable" glTF subset with no extensibility. I'm going to convert this to a discussion in case there are further questions.