Vertex Groups should be datablocks, similar to materials

Vertex groups should be datablocks like Materials. That way, we could override them, pass them on through the pipeline, share them between objects and - most importantly - store them apart from mesh data. This would enable a proper modeling >> rigging workflow, where the final model can be linked into the rigging file. The rigging artist can continue to work on the weighting without having to touch the mesh data. Any previous workflow (including operators that alter existing vertex groups) could still work like we’re used to for local groups. Multi-user/linked vertex groups could be auto-locked by default to make sure there are no accidental edits.

2 Likes

This is, IMO, a critical feature that needs to be supported if it isn’t or documented and tutorialized.

Now, the vertex groups are actually not a Mesh property, but an Object property… although the order of vertex groups is kinda tied to the vertex data in the mesh. It’s a bit disorganized. But you can, hypothetically, use multiple instances of a mesh datablock with different vertex-group names.

I don’t think they need to be datablocks, library/static overrides should be sufficient, once they are ready for them. I would prefer this to having to wrap my head around another kind of datablock. It would be more compatible, too.

It’s true, the groups seem to be an Object property… but they’re actually part of the data.
The group property held by the object only contains ‘name’, ‘index’ and ‘relative’ attributes.
vertex_group_object

The actual vertex group assignment is part of the data and can therefore NOT be edited for linked mesh datablocks:

You can also see this when creating a linked duplicate of an object with groups. You can delete the groups of one object, edit the weights on the other and recreate the groups on the first one again. Even when it has no groups on the object, the data keeps updating and by creating/renaming groups we’re only accessing the mesh data via group id.

A vertex group datablock would bring a lot more flexibility and would be necessary for a linked rigging workflow, as well as fit the established Blender data structure.

I’m using Blender along with Max in order to leverage the Data Transfer Modifier (Face Corner Data/Custom Normals/Projected). Our target mesh often needs revisions in Max, meaning after the program switcharoo, the Vertex Groups need to be re-established each time we re-import into Blender. Being able to “Copy” the Vertex Groups from the previous iteration to the updated version would save a bunch of time, instead of having to create that Group again, even if it can only account for the same vertex locations it would still save a ton of work.

I’m honestly not sure if there is another way to accomplish this (new to Blender), but it would still make this another change that could be useful, particularly for modeling as well.