VRM support

[Moebits]

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.

[Moebits]

Thanks for the tip, I added a new keep_textures option and overrode all the keep settings to always be on for vrm. It seems to be working now.

If interested I could still contribute my fix as experimental vrm support. Currently there aren't any options for it (I only found one old project vrmpack that I wasn't able to compile). But it's understandable if you don't want to support custom extensions especially with a crude workaround.

Properly supporting VRM without using the keep options would require more in-depth research on both your code and the VRM format, and currently is probably beyond my skill level.

[fire]

Hi I developed the previous version of the meshoptimizer vrm. I might be able to help out.

[Moebits]

It's fine I think I already got it working: https://github.com/Moebits/meshoptimizer-vrm/tree/vrm