In Blender 3.6 LTS any new (generic) Attribute is required to not clash with an existent Vertex Group name. This rule is enforced by:
Failing to create a new Attribute (unfortunatelly it is a silent error at the moment).
This was one-directional. While it made impossible for new Attributes to clash, Vertex Groups could still be created freely. If any conflict was caused by this, Blender would show a warning on the attributes panel:
4.0 Alpha
In the current state of 4.0 this was taken a step further. To help fixing a bug, a more strict rule was applied.
That made it impossible to get the collision. Which in turn introduced a new issue for armature rigging binding and raised a few concerns for I/O.
Proposed Solution for 4.0
Revert the recent fix and set things back to where they were in 3.6 LTS.
Future
When the topic of unifying Vertex Groups and Attributes popup again, it should take into consideration:
Allow the possibility of multiple sets of Vertex Groups.
Enforce uniqueness of names within sets. While the name of the Set itself would be unique among the other Attributes.
Weight paint (on unskinned mesh) should create Attributes.
Modifiers should be changed to support Attributes instead of Vertex Groups.
It is beyond the scope of this proposal to define whether we should have sets as a new Attribute type (with support to name binding), or just a generic Namespace functionality that could be applied to any Attribute.
Just want to note that reverting the fix creates non-future-proof behavior when vertex group and attribute storage is combined in the future.
When that happens, the separate vertex_group_names list on the mesh would be removed, and vertex groups would just be attributes, so unique names would be required. As long as weāre okay with dealing with that change in the future, I think itās okay to revert the fix for now.
Actually, I think Iāll reconsider my opinion above. I think the cases with name conflicts between vertex groups and attributes are better solved in other places-- by renaming when there are name conflicts when importing, and by renaming when there are bone/attribute name conflicts when binding a mesh to an armature.
The fact that names are unique between vertex groups and armatures is important for geometry nodes, especially in the future as these concepts are unified more and more.
The way this design implies features like namespacing for attributes I donāt think makes sense. Thereās no way around the uniqueness enforced by the commit in the future.
Attribute prefixes are namespaces. But these are still names, unique, and user-controlled. This is simpler than the new interface, so that the user do not must understand why nameA != nameA (due to differend name spaces), and we do not have to propagate this interface in everywhere (nodes, sculpt/paint layers/shaders/export/bones/ā¦).
I donāt think the current generic attributes system has everything need to make working with armature vertex groups user friendly. So itās not obvious to me yet what a future proof solution actually looks like.
Some issues to consider:
Naming conflicts can happen.
Putting vertex groups and attributes in a single list with all other attributes is difficult to manage for users.
Weight painting needs to be able to keep weights normalized. That is vertex group values summing to 1 at each vertex.
Other file formats often do not consider binding weights to be generic attributes, so exporters need a way to distinguish them from other types of attributes.
If vertex groups used for armature binding become attributes, I think we still want some way to group them together in the UI. This could be done with a special flag on the attribute to indicate can be used for armature binding, a prefix convention in the attribute names, a attribute grouping system, etc.
In some of those solutions, vertex group names would not exists in the same namespace as other attributes due a prefix or grouping.
If some better way for actually handling AttributeGroup as isolated group is found, we should consider ācolor_attributesā in that transition as well.
Iād like us to agree that attribute names should be unique per geometry.
The goal here is to have a simple but powerful core data model that all geometry processing can use. Allowing duplicate attribute names causes complexity whereever attributes are used. When all names are unique within Blender, we only have to deal with duplicate names when data enters or exits Blender.
There are different possible futures for vertex groups. Iām not sure which one weāll end up persuing.
All vertex groups become generic float attributes, potentially with some flag on the attribute.
A set of vertex groups is packed together into a single attribute that has a unique name across all other attributes on the geometry, but vertex groups in this packed attribute have a separate namespace. In this case, geometry nodes needs special nodes to deal with these packed attributes.
I propose the following next steps:
Revert this commit so that vertex groups can have the same name as attributes again.
Show a warning in the vertex groups panel when there are duplicate attribute names, similar to the attributes panel. In all possible futures of vertex groups, that is a good thing because existing vertex groups are already used as generic attributes and thus are already in the same namespace. Even if we persue the packed attributes solution, some, if not all, vertex groups will have to be versioned to become generic attributes for backward compatibility.
Show a warning when binding an armature to a mesh to avoid duplicate names in practice.
Add extra import/export settings where necessary to deal with file formats that support duplicate attribute names.
I cannot imagine production meshes with hundreds of custom layers, without any tooling to help artists organize them, name them properly, help them avoid name collisions, help them handling renaming (such that usages of these generic attributes are not broken by a rename), and so on.
Whether that tooling would integrate some namespace/grouping concept or not is up for debate, but imho current bare-metal naming system is not sustainable if all mesh data are to be moved to the unified generic attributes system.
Define ānameā. Attributes should have a unique identifier (per geometry), yes. That uid being a plane, semantically-void string isā¦ highly disputable for me. I would expect Blender helping artists to make that name as meaningful and useful as possible, and not to hope for the artists to do all the work (which wonāt happen in the vast majority of cases, at least not in a reliable way).
Should the user change the namespace extension in all places where he used it to access the attribute? Or should they be data block with smart name changes, as if they were simply collections? Need something like attribute collections? And wherever an attribute is used, you also need to select its collectionā¦
Python can draw a tree structure to handle name-prefix conventions in ui, but does it really need to be a built-in, strict policy for all places instead of mesh properties only?
Would it be possible to introduce some sort of namespaces for Attributes? Something like attribute collections, that way, after the merge of vertex groups with attributes, an armatures attributes would be namespaced for that modifier / armature, and attributes that have the same name but not the same namespace would not clash. Could be nice for auto-weights and normalization too.
A set of vertex groups is packed together into a single attribute that has a unique name across all other attributes on the geometry, but vertex groups in this packed attribute have a separate namespace. In this case, geometry nodes needs special nodes to deal with these packed attributes.
One additional advantage of this approach could be an ability to easily implement weight painting layers, which I think is a feature that has been discussed at various times. You would just need a node that can do arithmetic operations on all attributes within two packs, using names to match and outputting another pack.
