Unique generic attribute names can break armature binding process #112022

New Issue

Bastien Montagne · 2023-09-06T12:04:23+02:00

Bastien Montagne commented

2023-09-06 12:04:23 +02:00

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

Bastien Montagne added the

labels 2023-09-06 12:04:24 +02:00

Bastien Montagne commented

2023-09-06 12:14:30 +02:00

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).

Bastien Montagne added

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