2
$\begingroup$

I have been working with 2.91 for a long time because I have a particular modeling/rigging method that involves duplicating meshes, and altering their vertex groups for use with different bones in a rig- it works as long as each duplicated instance of said mesh has the same amount of vertex groups, in the same "arrangement". This process is particularly useful when it comes to designing machines/robots, as well as any generally repeating shape such as arms, legs, fingers, etc.

The problem however, is that this "feature" was patched out in 3.0+, meaning I would need to have a unique mesh for each instance of a part throughout the design. It's not too much of an issue if I have already compiled everything into a singular united object, but for the general WIP stages where I may potentially need to edit topology or UV maps at any time, this is a major setback as it would require me to try and edit all of these similar pieces at once. I even remember when 3.0 first came out and this broke my process, I asked around in a modeling group and they just told me that I was effectively working with black magic.

For example, here is one of my character's hands. To be extremely blunt, this is a very intricate design with lots of mechanical detail. This one section alone is nearly forty objects, all spread over eight, maybe ten duplicated meshes. The list of parts is (Hand), (knuckle), (finger A), (joint), (finger B), (finger C), and (cables) Meshes like the finger parts have only one vert group, but the knuckles and joints have up to three. enter image description here enter image description here enter image description here

Of course when I try to open this file in 3.0+ (in this case, 4.0) then the whole thing practically implodes- out of the 10-20 duplicates for each mesh, each with their own specific vertex groups, only one setup for vertex groups actually works, and is enforced across every other instance. enter image description here

If there were a way to have a similar process in 3.0+ or even 4.0, I would gladly appreciate it.

$\endgroup$
6
  • $\begingroup$ There are a number of ways to do this. You could data transfer, you could use GN modifiers to re-assign VGs, you could script those, or you could use independent armatures so that you didn't have to rename VGs at all. It's unclear to me if you're asking to fix your existing technique or replace it, but if it's to fix, we'd need to know what the technique is. The problems you're showing in your last pic look like more than just VG failures though $\endgroup$
    – Nathan
    Dec 4, 2023 at 19:02
  • $\begingroup$ Reading this comment and the below answer, I am using the Alt-D linked duplicates. To clarify, my modeling/rigging technique heavily uses linked duplicates, and I am somehow able to have duplicates with different vertex groups. That is no longer possible in 3.0+, which is what I am asking- how can I have the equivalent of linked duplicates with different vertex groups? The key point is that I want these duplicates to share the topology and UV maps of the original piece: I make any edits to one and it automatically carries over to all of the other copies. $\endgroup$
    – Komissar
    Dec 4, 2023 at 23:38
  • $\begingroup$ Linked duplicates alone won't rename your VGs, not in any version of Blender, so there's something unmentioned to your technique as well. Rumen's existing answer is a reasonable way to reassign VGs (although it is painful, and reduces much of the versatility of using linked duplicates.) The precise method I would use would probably depend on my needs-- what is my rendering engine/am I exporting? What does my armature look like? Etc. I'm loathe to give any alternate techniques without knowing that info-- I don't like hearing, "Actually, for reasons I didn't mention, that won't work." $\endgroup$
    – Nathan
    Dec 5, 2023 at 0:19
  • $\begingroup$ I just whipped up a super quick and rough example of what I am dealing with, it's a basic torso with two arms, and three-fingered hands. In 2.91 it works entirely as intended, and in 3.0+ the linked duplicates all share the vertex groups of only one of the copies, and thus the whole model collapses. $\endgroup$
    – Komissar
    Dec 5, 2023 at 1:45
  • $\begingroup$ If it helps, I have a third-party program that lets you download older/newer versions of Blender. My default is 2.91, but I've been using the launcher to open 3.5 and 4.0 for testing whatever I could between versions. $\endgroup$
    – Komissar
    Dec 5, 2023 at 2:01

2 Answers 2

1
$\begingroup$

If I understand correctly you duplicate your objects by linking (Alt+D)

So you'll get objects having the same mesh data and the same vertex groups like on the image bellow:

enter image description here Left to Right - Original object, Linked (same mesh, same vertex groups), Duplicated (different mesh, same topology, similar order of vertex groups)

To test the objects I added 3 Displacement modifiers for each of their vertex groups. The vertex groups of the independent third object is altered as can be seen above.

If you want having the Vertex Groups data mapped from the third object to the second (linked) object. You can do this by adding Data Transfer Modifier before your deforming modifiers. This way the shape of the linked object is still controlled by the original mesh, but the VG data can be read from another template mesh.

enter image description here

As long as the meshes are topologically equivalent and the vertex groups are in the same order (or name) you can easily transfer the vertex data with this modifier.

Here is a closer look of the modifier settings

enter image description here

Make sure Vertex Data is enabled with Vertex Groups - on, Mapping is set to Topology and Layer Mapping is set to By Order (or By Name, if you are sure the names of the vertex groups match).

$\endgroup$
1
$\begingroup$

It appears that, sometime prior to 3.0, Blender stored VGs on mesh data only as indices to VGs and values for those indices, while the names were stored in the object-- the names, as object data, were individually editable. This probably changed as part of a push to get GN to work properly with VGs.

I can see how this would be described as "black magic"-- it relies on undocumented design decisions in Blender, which of course can change, did change; and it can lead to some unexpected results sometimes (like sorting vertex groups also sorts vertex groups on linked meshes, with differently named VGs.)

If you need to use a model designed like this in current versions of Blender, and you no longer need to edit it, you can "make single user"->"object and data" to unlink the meshes, then save or export or copy/paste into a newer version.

It seems to me that your goal here, with the use of linked meshes, is for the purposes of editing. There are a number of ways to maintain this kind of edit-once functionality, and not all of them involve linked meshes:

  1. Mirror modifier. This is appropriate, in lieu of linked duplication, for anything that you're going to mirror over a single plane. On default settings, it automatically renames *.L groups to *.R and vice versa. You can specify a mirror object (usually, an unrotated empty at the world origin) to override existing object transforms if you want.

  2. Bone parenting instead of armature deformation. This is appropriate for any objects that are weighted to only a single vertex group. Since parenting is object data, not mesh data, each linked duplicate can have its own parent. This is usually accompanied by significantly better performance than armature deformation, as an added boost.

  3. Multiple armatures:

enter image description here

The only restriction on bones with the same name is within a single armature. If multiple armatures are used, then vertex groups don't have to be renamed in the first place. You can just duplicate the armature (linked or not) at the same time you duplicate the mesh. Then, these sub-armatures are bone parented to bones in another armature.

This can complicate some rigging techniques, and it's not easy to "fix" it back into a single armature without scripting. It won't export well.

  1. Dynamic assignment of VGs. This is the use of any kind of modifiers (data transfer, vertex weight edit/mix/proximity, geometry nodes) to reassign vertex group data. Rumen Belev has mentioned the data transfer modifier as one example of this. Data transfer is appropriate sometimes, but it limits edits that can be made to the meshes (without corresponding edits to the data transfer object.)

My preference, for a-bomb level reassignment of vertex groups, is to use a geometry nodes modifier:

enter image description here

In this case, the prototype has all of the vertex groups that we'll ever want on any of its linked duplicates, and we use the modifier to assign left to right and vice versa. Once made, this modifier can easily be copied to any number of objects, but the parameters for each object should be individually specified. This particular example switches two vertex groups; you can make it switch any number you want, and you can leave parameter fields empty if you want to use a modifier that swaps many number of groups on an object with few groups. But, there is the tedium of actually setting up the modifier and filling its fields.

It's possible to do the same kind of thing with vertex weight edit and mix modifiers, but the GN way is a lot easier, a lot cleaner.

$\endgroup$
1
  • $\begingroup$ I have attempted #1 before, it's usually better for parts in the center of the character/model rather than further out like fingers, toes, etc. I have heard about the bone parenting in #2 before, it's interesting, but many of my parts have more than one vert group. I have attempted #3 when I had first started modeling in 2018... it was gross, haha. #4 looks promising however, though it seems like it may effect performance in regards to larger projects like what I had first shown. I'll try looking into it later today, though. $\endgroup$
    – Komissar
    Dec 5, 2023 at 17:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .