VRM Importing

[ProbablePrime]

Is your feature request related to a problem? Please describe.

VRM is an "all in one" file format for 3D Avatars that many platforms already support. There are lots of VRM tools and avatars out there.

VRM imports into Resonite are currently not fully supported. The underlying GLTF data can be looked at but other VRM features are ignored.

Describe the solution you'd like

I'd like Resonite to support the VRM standard for import/setup of avatars as closely as it can.

Describe alternatives you've considered

Extracting the GLTF data from a VRM is possible but much of the meta-data is lost.

Additional Context

I am pre-seeding the issue repository with commonly requested items to prevent those issues from being made as duplicates once open.

[Casuallynoted]

I think it would be worth linking this discussion from the Discord as well:

https://discord.com/channels/1040316820650991766/1158258132435337266

It discusses the use of VRM metadata and licensing restrictions, and various ways that Resonite may be able to go about those in a way that is respectful to creators.

[kazu0617]

From the perspective of writing a comprehensive guide article for Japanese people at Resonite and creating conversion software, I will write down the contents that may be necessary.

Links

What is VRM?: https://vrm.dev/
Article on how to implement VRM based on Japanese sources (I share this article as a reference. Keep in mind that most of the data will be missing when read as gltf): https://sharedx.notion.site/VRM-d93c6e3ae2f647e0956054efff1d20b9?pvs=4
About the Version

VRM is available in 0.x and 1.0. You can differentiate them by checking the contents of gltf and seeing whether the add-on you have is "vrm" or "VRMC_vrm-1.0".

About Data

As Prime mentioned, VRM is an extension of gltf. Therefore, I believe it's appropriate to initially read [.vrm] files as gltf2.0. Of course, it would be nice if all or a series of data could be loaded properly (for instance, a group of shape keys could be baked and added as expressions, requiring minimal modifications post-implementation. Or, avatar settings could appear in the position where they were initially set. It would be helpful if SpringBone settings could be roughly formatted as text, even if some are not compatible).

[shiftyscales]

As noted above- the only functional difference between VRM, and GLTF is the existence of licensing and other meta-data. As such, this issue is blocked by the implementation of a licensing system, e.g. #626.

[bdunderscore]

VRM also contains metadata relevant to avatar behavior, such as viewpoint positions, facial expressions, springbones, material configuration, etc…

[Geenz]

As noted above- the only functional difference between VRM, and GLTF is the existence of licensing meta-data. As such, this issue is blocked by the implementation of a licensing system, e.g. #626.

Licensing metadata is different in this case, and may not be trivial to really respect beyond the user acting in good faith. Basically our concept of a license is not likely to fully align with VRM's concept of a license.

[shiftyscales]

Good to know, @bdunderscore - I'd only previously heard about the licensing aspect of it. Adding support for those would require a much more involved/in-depth integration, as we'd have to somehow detect and map those things using equivalent components we have in Resonite.

[aaronfranke]

As mentioned above, VRM is not just a monolithic format, it is composed of many pieces, and all these pieces do a lot more than just licensing. Each .vrm file is really a .glb file with VRM-specific glTF extensions, including:

• Node constraints: Allows controlling the notation of one node/bone based on another. Can be used to implement things like digitigrade legs, taur legs, and multi-arm characters, but could also be used outside of characters.
• Spring bones: Allows for nodes/bones to spring/jiggle. Can be used to implement things like floppy ears or a dynamic tail on a furry character, but could also be used outside of characters.
• Toon materials: Allows for a less realistic toon look for meshes, usually characters, but could be other objects too.
• Animations: Allows expressions and animations to be defined on an avatar.
• Bone mapping: The base VRM extension requires a humanoid bone map, similar to Unity's bone map menu.
• First person: The base VRM extension allows defining things to hide when in first person, like hiding the mesh of the head/glasses/etc when in VR but still allowing you to look down and see your body.
• Meta: The base VRM extension defines metadata like licensing information. Also note, there is some overlap with Khronos's own KHR_xmp_json_ld extension for copyright metadata (see spec and Godot implementation).

Therefore, VRM is not just one monolithic thing, it is a standard built out of many pieces. One does not necessarily have to implement the entirety of VRM. You can for example take the extension for VRM constraints and use it outside of VRM in a regular .glb file, as I did here. It makes sense to provide these general tools for any glTF model. The complete list of VRM extensions can be found here: https://github.com/vrm-c/vrm-specification/tree/master/specification

This issue is highly related to #2778, since VRM is based on glTF. The same codebase can be used to import these files, optionally mixing and matching VRM and non-VRM features.