Implement skinning with MultiMeshInstance

[Arnklit]

Describe the project you are working on: A fur add-on https://github.com/Arnklit/ShellFurGodot

Describe the problem or limitation you are having in your project: To generate the fur I'm using a shell method of generating many copies of the mesh. When the mesh is static I can use MultiMeshInstance and it works great, but when it's a skinned mesh I currently need to generate a single mesh of many copies of the original mesh and bind them all to the skeleton. This means I end up with really heavy skinning and I'm not getting the benefits of MMI where you can choose to only display some of the instances and I'm not able to use blendshapes, since that would make the generated mesh size even worse.

Describe the feature / enhancement and how it helps to overcome the problem or limitation: It would make my fur tool much more efficient and able to handle blendshapes.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams: MultiMeshInstance could simply have the same options as MeshInstance with skeleton, skin and blendshapes or it could be hidden and just available through API.

If this enhancement will not be used often, can it be worked around with a few lines of script?: I don't think there is any way to work around it. As far as I can tell there is no way to manually manipulate the mesh being given to the MMI in the same way as the MeshInstance deforms it with the skeleton.

Is there a reason why this should be core and not an add-on in the asset library?: I'm not sure about this, maybe it would be possible to do a GDNative or module version where I make my own version of MMI that supports this, but I wouldn't know how at this point.

[fire]

I support this. @Arnklit Do you have a good design? I recall the particle system modified this too.

[ODtian]

Currently we have 3 ways to skin.

• Skin all vertices of a multimesh for each instance and store them in a buffer and send to main pass.

  • This is just what batching do, it decreases the draw call but increase vram usage
  • It will be limited by the max vertex number in one draw call, so not for sure for performance.

• Send all bones' transform for all multimesh instance to main pass, do multimesh instance transform and skin at the same stage.

  • Require less memory and support much more instances per draw call.
  • We are using CPU to calculate bone transform, therefore current animation features can be fully integrated.
  • Same idea is seen when Godot handling particles trail here , but too little docs to explain how to use it.
  • GPU particles with skin is highly related, multimesh is GPU particle but we update instances' transform in CPU. some related material: https://github.com/godotengine/godot-proposals/issues/5051, reduz proposal

• Don't send all bones' transform but a set of parameters like animation index, frame index, we bake skeleton animation to texture and look up transform for skinning by given parameters while instancing.

  • Use a little bit more vram to store animation but save huge time uploading instances' uniform buffer, it's the fastest way and used mostly common in other engines.
  • Can be currently implement in Godot, use custom data to send skeleton state to instances and skin manually in vertex shader.
  • Provide poor animation features, you have to manually control the animation, also hard to handle complex blend.

I like the second way the most, advanced animation feature is important to skinning mesh, you may want full support for animation blending, ragdoll or even IK not just playing same animation, although syncing a lot of bone transforms maybe a challenge.

By the way here is a video to show how impressive instanced skinning mesh is, even on webgl.

[fire]

I agree with the proposal but I don’t know if its feasible. Someone needs to investigate