Move blendshapes values to the Mesh resource instead of being in the MeshInstance

[lukostello]

Describe the project you are working on

I am working on a sokoban-like with twisty puzzle elements

Describe the problem or limitation you are having in your project

I am trying to give the impression that my level loops infinitely, to accomplish this I am making an array of mesh instances for every element in my level. Most of my elements have blend shapes. I would like to save resources by having them all share the same mesh resource which has a mesh with an applied blend shape on it. This is the way it works right now but there is a bug that only allows the first instance to apply its blend shape values to the mesh resource. Here is were I reported that bug: godotengine/godot#54062 it may be a bit confusing to read because at first I thought I wanted to have a bunch of mesh instances share a mesh resource but apply their blend shapes independently. (this is because there are several elements within each level which have the same mesh but different blend shapes) Then I realized that I can just set the mesh resource as local to scene which would allow me to apply them independently. What is more challenging is when I have to take those elements and make an array of them, all with the same blend shapes. (to accomplish the infinite effect) I found a work around by using a setter to adjust the values of the first instance whose values are actually applied. Its all in here: https://github.com/godotengine/godot/files/7407042/local_to_scene_bug.zip
Its still very wasteful for all the instances which don't have their blend shapes applied to store them anyway.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

My solution is to put the blend shape values inside the mesh resource instead of inside the mesh instance. If you were to solve it instead by allowing each instance to apply its blend shape data independently even though they share the same mesh resource then there would be no way to accomplish the infinite effect I am doing not without setting the blend shape data for each instance which would be wasteful. Plus same effect can be accomplished right now by checking mesh as local to scene. If you want checking local to scene on the mesh resource to actually matter, you must put blend shape data inside the mesh resource. It also makes sense that since the blend shapes are dependent on which mesh you are using that it be paired with it. Since multimesh instance takes in mesh it might be able to use the blend shape data before it makes its multiples, otherwise it would just have to ignore the data

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

mesh_instance.mesh.blend_shapes.shape1 = .3
my_blendshape = mesh_instance.mesh.blend_shapes.shape1

If this enhancement will not be used often, can it be worked around with a few lines of script?

the work around is extremely ugly and wasteful. It also relies on knowing which mesh instance was made first. If that instance gets deleted, then who knows which instances blendshape data is getting applied then. Its total chaos.

Is there a reason why this should be core and not an add-on in the asset library?

it makes more organizational sense, saves resources, and allows more flexible behavior

[Calinou]

Isn't this the opposite of #2465?

[lukostello]

@Calinou Kind of, I think blendshape modifiers must be the thing that blendshape values are applied to because otherwise idk what they are talking about. Right now every mesh instance its giving the impression that they can apply their own blendshape to a mesh resource when they cannot, thats why the bug I mentioned is happening. If you tried to solve it by changing the visual server to apply each blendshape independently you'd have to duplicate the mesh resource anyway at runtime every frame (I suspect at least, its difficult to imagine the same mesh resource being able to take turns using different blendshape values if all the mesh instances are on screen at once) if I am correct having blendshapes values inside the mesh resource would mean there is already a duplicate of the mesh resource and you wouldn't need to duplicate it every frame when rendering.

However if my solution is implemented it would prevent @smix8 from having the same blendshapes be applied to different meshes as they mentioned. One solution they mentioned is to have a blendshape resource that keeps track of the blendshape values. Which could be a good compromise. But it would be difficult to code optimally. There would have to be like a table that keeps track of all the different meshes and all the different blendshape resources being applied to each mesh such that if there are 2 mesh instances with the same mesh resource and blendshape resource they wouldn't need to be calculated twice it would calculate once for the first one then the 2nd one would find the calculation done for the first one on the table. The blend shape value resource should probably be kept inside the mesh instance.

Although it seems very strange to me that different meshes share the same blendshape data since there is nothing that guarantees that any 2 meshes have the same number or named blendshapes. If one intentionally does so it might make more sense to use a setter or a signal to change the values of all meshes you want to change the blendshape values of.

[lyuma]

I think changing the intended functionality of MeshInstance3D is a mistake, and indeed Godot 4.x already should solve the bug referenced #54062.

I would also love to see bug godotengine/godot#54062 (a.k.a. proposal #2465 and bug godotengine/godot#10402) fixed, since my own project runs into this and I have documented it also at V-Sekai/godot-vrm#18 and

As for the proposed functionality, perhaps the only way I could see this feature make sense implementation-wise is if MultiMeshInstance3D is allowed to apply blend shapes, and then you can have that mesh appear in multiple places by feeding them in as instances.

I would like to propose changing your feature request to be specific to MultiMeshInstance3D.

[kayomn]

In other engines (such as Unity3D), the blend shape modifiers appear on the MeshRenderer component (MeshInstance) however I understand ad populum is not a good reason to replicate such behavior.

Practically, I have no grievance with having to manually make each mesh unique and apply blend shapes individually (i.e. what was mentioned by @smix8 and @lukostello in #2465). If this solves more issues than my original proposal, prefer this one.