Page MenuHome

regression, instanced object can't have different vertex group names (preventing instances to be rigged to other bones)
Closed, ArchivedPublic

Description

System Information
Operating system: Windows-10-10.0.19043-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 2070 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 497.29

Blender Version
Broken: version: 3.0.0, branch: master, commit date: 2021-12-02 18:35, hash: rBf1cca3055776
Worked: 2.93 and before

Caused by rB3b6ee8cee708: Refactor: Move vertex group names to object data

Short description of error
Vertex groups can't be unique on unigue objects sharing the same mesh anymore.

Exact steps for others to reproduce the error
In 2.93, objects could have different vertex group names (allowing them to be rigged to different bones in an armature).
In 3.0 onwards this is not possible anymore.

Event Timeline

Philipp Oeser (lichtwerk) changed the task status from Needs Triage to Needs Information from User.Jan 4 2022, 2:59 PM

It is just that the names are now part of the mesh (instead of the object) since rB3b6ee8cee708: Refactor: Move vertex group names to object data.
This has an effect for names, true, but assignments/weights were always shared (even in 2.93, no?)

Afraid this is not going to be changed (even T93778: Blender 3.0 doesn't save vertex groups from linked objects wont be changed).
Question: what was the usecase for having different names for vertexgroups on shared meshes (where the actual values would be shared [index based] anyways?)

Weight paint and armature modifier are also affected.
Opening an old file created in blender 2.9 that contains multiple instances controlled by a single armature gave me problem for this reason.

thank you.

Weight paint and armature modifier are also affected.
Opening an old file created in blender 2.9 that contains multiple instances controlled by a single armature gave me problem for this reason.

thank you.

Still dont get it, I think.
Could you try to explain in more detail what exactly is now broken in your workflow with "multiple instances controlled by a single armature gave me problem"?

Hi,
I attach here a more clear example file created in 2.93 and opened in 3.0.
Thank you.

Philipp Oeser (lichtwerk) changed the task status from Needs Information from User to Needs Information from Developers.Jan 5 2022, 8:40 AM
Philipp Oeser (lichtwerk) triaged this task as High priority.

OK, get it now.

I am afraid this wont be changed, but agree this is a usecase that is not possible anymore in 3.0 (so in a way, this is a regression).
Even though this might not be changed (pretty sure it wont), I would still like a short-term answer/classification from @Hans Goudey (HooglyBoogly) regarding this (so users know right away that they'll have to adjust their workflows...).
@Sybren A. Stüvel (sybren) might have a word here also.

Philipp Oeser (lichtwerk) renamed this task from regression, instanced object can't have different vertex group names to regression, instanced object can't have different vertex group names (preventing instances to be rigged to other bones).Jan 5 2022, 8:44 AM
Philipp Oeser (lichtwerk) updated the task description. (Show Details)
Hans Goudey (HooglyBoogly) closed this task as Archived.Jan 7 2022, 4:53 PM

Yes, there's just no way for this to work anymore. The list of names is stored in the mesh data, so it will be the same for multiple objects using the same mesh. The fact that it worked in the past seems useful in your situation, but it's not clear that it was ever actually designed behavior.

It's not ideal, but in your situation there is a simple workaround-- duplicating the mesh so that each object has a unique mesh and then renaming the groups on one of them.

I'm going to close this report, since though there is a compatibility issue with 2.93, this is the designed behavior now. Sorry for any inconvenience that caused, and thanks for the report.

(This issue is now listed in the release notes)

@Hans Goudey (HooglyBoogly)

With all the esteem and respect for those who develop this software, allow me to add a comment and apologize if I bother anyone.

Removing this option limits the functionality whereby instance objects can no longer be parented to a different rig.
In gaming this helps a lot. Object instances is a must to reduce the poly count and if those instances cannot be parented to different rig/joints, because vertex grouping is the same for every instance, it become useless.
This was a very important feature, is not ok to treeat it with such carelessness.

Hi @Daniel Toma (danieltoma), I don't mean to treat this feature carelessly. Unfortunately at the time we weren't aware of all the ways it was used.
However, I think in retrospect we would have come to the same decision in the end. Referencing geometry-level data on objects just doesn't work well from the perspective of proceduralism and data structures. The future of geometry data in Blender is attributes, and it was important to work with that.
The vertex group data was always the same for every object using the same mesh. The fact that the names could be different on different objects gave some flexibility on the object level that is gone indeed; you can't have different vertex group names on different objects now.

Unless I'm missing something, you should still be able to use the same mesh for different armatures, bones and vertex group names just have to match.

I'd also suggest that geometry nodes might be a solution to having procedural changes on an object level starting from the same mesh. Though that might not be enough in this case.
Maybe if we can provide the ability to rename attributes/vertex groups in geometry nodes, this would still be possible. Do you think that would work?