Unique generic attribute names can break armature binding process #112022

New Issue

System Information
Operating system: N/A
Graphics card: N/A

Blender Version
Broken: Current main (48950ff934)
Worked: 3.6 (before extending unique names to vgroup as 'virtual' part of generic attributes)

Related to/caused by !109910.

Short description of error
Parenting (binding) a mesh to an armature is broken if other existing generic attributes are already using some of the bones' names.

See also https://devtalk.blender.org/t/vertex-groups-generic-attributes-and-name-clashing/31073

Exact steps for others to reproduce the error
Starting with default cube from default startup file:

Add (or rename) a generic attribute to Bone (e.g. a UVMap).
Create a default, one bone armature.
Parent the cube to the armature, with one of the vgroup creation options (e.g. automatic weights).
The newly created vgroup is named Bone.001, and the bone does not deform the cube object at all.

Final result: armature_bones_generic_attributes_name_collision.blend

Note: this is a very dumb, but also very good example of the kind of issues that name uniqueness is going to cause in existing code and workflows.

**System Information** Operating system: N/A Graphics card: N/A **Blender Version** Broken: Current main (48950ff934de4) Worked: 3.6 (before extending unique names to vgroup as 'virtual' part of generic attributes) Related to/caused by !109910. **Short description of error** Parenting (binding) a mesh to an armature is broken if other existing generic attributes are already using some of the bones' names. See also https://devtalk.blender.org/t/vertex-groups-generic-attributes-and-name-clashing/31073 **Exact steps for others to reproduce the error** Starting with default cube from default startup file: 1. Add (or rename) a generic attribute to `Bone` (e.g. a UVMap). 2. Create a default, one bone armature. 3. Parent the cube to the armature, with one of the vgroup creation options (e.g. automatic weights). 4. The newly created vgroup is named `Bone.001`, and the bone does not deform the cube object at all. Final result: [armature_bones_generic_attributes_name_collision.blend](/attachments/4571142b-0d7f-4c37-8fd0-19475e4da80f) -------------------- Note: this is a very dumb, but also very good example of the kind of issues that name uniqueness is going to cause in existing code and workflows.

armature_bones_generic_attributes_name_collision.blend

115 KiB

Personally, I would much rather not enforce uniqueness of names across data that have semantically no relations to each other. For the vast majority of our user base, a UVmap has nothing to do with a vertex group. The fact that these data layers can be mixed or otherwise get advanced complex processing in geometry nodes is not enough (in itself) to justify breaking existing, much simpler and much more 'every day' processes. It also will cause issues with I/O code (see e.g. these USD PRs: #111894, #111747), since may external tools do not handle such data layers in a complete abstract, generic way.

I would rather expect some sort of namespace system here, able to generate unique names (when these are required) with more meaningful info, e.g. som sort of namespace system: domain.type_or_generic.basename (vertex.vgroup.Bone, face_corner.UVMap.Bone, vertex.generic.Bone, vertex.generic.Bone.001, and so on).

Personally, I would much rather _not_ enforce uniqueness of names across data that have semantically no relations to each other. For the vast majority of our user base, a UVmap has nothing to do with a vertex group. The fact that these data layers can be mixed or otherwise get advanced complex processing in geometry nodes is not enough (in itself) to justify breaking existing, much simpler and much more 'every day' processes. It also will cause issues with I/O code (see e.g. these USD PRs: https://projects.blender.org/blender/blender/pulls/111894, https://projects.blender.org/blender/blender/pulls/111747), since may external tools do not handle such data layers in a complete abstract, generic way. I would rather expect some sort of namespace system here, able to generate unique names (when these are required) with more meaningful info, e.g. som sort of namespace system: `domain.type_or_generic.basename` (`vertex.vgroup.Bone`, `face_corner.UVMap.Bone`, `vertex.generic.Bone`, `vertex.generic.Bone.001`, and so on).

@dfelinto @JacquesLucke @lichtwerk @brecht For awareness.

Setting prio to high, since I don't think we can ship 4.0 with the issue described in this report.

@dfelinto @JacquesLucke @lichtwerk @brecht For awareness. Setting prio to high, since I don't think we can ship 4.0 with the issue described in this report.

Related:
#93087: Vertex groups with identical names can exist, and when they do, a lot of things break.

Related: #93087: Vertex groups with identical names can exist, and when they do, a lot of things break.

Main problem here is that generic attributes cannot be used by other modifiers. Automatic type and domain conversion would be enough here (to rewrite old attribute with the same name but new type/domain and data or just continue to use it as weight with convertion in read).
Generic attributes shouldn't have any namespaces seens whole geometry is namespace already. Instead of this, bones bindings should not use names only, but maybe socket connections.
But anyway, problem caused by the fact that vertex groups is still exist, and modifiers can't use generic attributes.

Main problem here is that generic attributes cannot be used by other modifiers. Automatic type and domain conversion would be enough here (to rewrite old attribute with the same name but new type/domain and data or just continue to use it as weight with convertion in read). Generic attributes shouldn't have any namespaces seens whole geometry is namespace already. Instead of this, bones bindings should not use names only, but maybe socket connections. But anyway, problem caused by the fact that vertex groups is still exist, and modifiers can't use generic attributes.

I expanded the docs about attribute naming in the wiki: https://wiki.blender.org/wiki/Source/Objects/Attributes#Naming

I think we'll have to either rename attributes or bones in this situation-- probably attributes. As long as it's reported to the user, that should be okay IMO.

We have to keep in mind that like Iliya was saying, the separate storage of attributes and vertex groups is planned to be unified once we get the ability to store attributes sparsely.

I expanded the docs about attribute naming in the wiki: https://wiki.blender.org/wiki/Source/Objects/Attributes#Naming I think we'll have to either rename attributes or bones in this situation-- probably attributes. As long as it's reported to the user, that should be okay IMO. We have to keep in mind that like Iliya was saying, the separate storage of attributes and vertex groups is planned to be unified once we get the ability to store attributes sparsely.

I think we'll have to either rename attributes or bones in this situation-- probably attributes. As long as it's reported to the user, that should be okay IMO.

As an alternative, instead of changing data names (and then informing the user we did that afterwards), could we check on clashing names prior to e.g. binding / parenting to armature and then just cancel the operation (spitting out the info why it was canceled). Or do the check in invoke and spit out an additional dialog with the warning, requiring the user to explicitly confirm OK to automatic renaming of attributes/bones (still giving the chance of cancelling out.

It seems to me this would encourage awareness of how clashing names can be problematic much more (as convenience, we could provide an operator to check/correct possible clashing attribute names).

> I think we'll have to either rename attributes or bones in this situation-- probably attributes. As long as it's reported to the user, that should be okay IMO. As an alternative, instead of changing data names (and then informing the user we did that **afterwards**), could we check on clashing names **prior** to e.g. binding / parenting to armature and then just cancel the operation (spitting out the info why it was canceled). Or do the check in invoke and spit out an additional dialog with the warning, requiring the user to explicitly confirm `OK` to automatic renaming of attributes/bones (still giving the chance of cancelling out. It seems to me this would encourage awareness of how clashing names can be problematic much more (as convenience, we could provide an operator to check/correct possible clashing attribute names).

There is a proposal to revert this change (enforcing unique names across generic attributes and vertex groups): https://devtalk.blender.org/t/vertex-groups-generic-attributes-and-name-clashing/31073

@mont29 Does my response in the thread sound ok to you?

@mont29 Does my [response](https://devtalk.blender.org/t/vertex-groups-generic-attributes-and-name-clashing/31073/7?u=jacqueslucke) in the thread sound ok to you?

@JacquesLucke for the short-term solution, yes.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Unique generic attribute names can break armature binding process #112022