This has been sitting in my branch for a few months.

Using this test:

This is what things look like:

This new mode and multipaint thus in effect provide a way to factor the weight distribution between two bone loops into two orthogonal gradients for independent viewing and tweaking.

One limitation is that since I've always painted normalized weights (using Auto-Normalize mode), I don't understand the non-normalized workflow at all, and as a consequence, I couldn't even come up with a way how the new mode could meaningfully work there. It thus requires Auto-Normalize to be on, as a sign that the user is working with normalized weights. Multipaint is also kinda meh (but works) without normalize for the same reason.

Commenting here based on IRC discussion,

I'd like to have experienced riggers try them out and give feedback since this adds maintenance overhead to properly support.

Also having someone else test this on some production file can give useful feedback.

Could @Juan Pablo Bouza (jpbouza) or @Andy Goralczyk (eyecandy) check on this? (others welcome too of course).

I find the diff title & description a bit vague. What does "Lock-Relative mode" mean? All the way at the bottom of the patch I think the RNA tooltip is clearer than the patch description itself.

@Demeter Dzadik (Mets) what do you think of this feature?

I can definitely see the usefulness of this feature, but I think it's a bit hard to grasp, and relying on vertex group locks is a fatal flaw because they are way too slow and unwieldy to manage.

My suggestion:
Checkbox name: "Ignore Locked or Hidden".
Tooltip: "Vertex groups that are locked or belong to hidden bones are ignored and unaffected by weight painting. It is recommended to use normalized weights while this is enabled"

Instead of only checking whether a vertex group is locked or not, also check if the bone corresponding to the vertex group is visible or not. What this solves is the fact that, if you rely purely on vertex group locking, then you need ways to mass lock and mass unlock vertex groups based on a bone selection. And even then, it's still slower than hiding and unhiding, and it would result in odd operators like "Lock weights of unselected bones". This is too slow for the smallish benefit that the feature provides. So really, relying on bone visibility is the way to go I think. This would make it much more usable by new riggers, who wouldn't be confused(as much) by what it does, and experienced riggers would just have no reason not to use it pretty much all the time, since it makes you just a little bit less error-prone and more precise, without slowing you down at all.

About displaying non-normalized weights as normalized: It's really the only way to make this feature get close to making sense with non-normalized weights. It can result in some strange situations, where you have a weight value of 1 being displayed as a color other than red, so attempting to add to that weight will fail. There's not much we can do beside a tooltip asking the user to normalize their weights. Also, I wonder if the same thing should be added to Multi-Paint in the future?

In D3837#148227, @Demeter Dzadik (Mets) wrote:

Instead of only checking whether a vertex group is locked or not, also check if the bone corresponding to the vertex group is visible or not.

No, bringing hiding into this is inappropriate as far as I am concerned. The reasons being that this feature does not actually change how painting works in any way, only the weight values that are displayed; and locking is the feature intended for blocking changes to some vertex groups.

I.e. you already can lock groups with auto normalize to balance weights only between the unlocked bones. It's just that the display of the weights still shows the absolute weights, and not the fraction of the currently active unlocked weight - and this attempts to address that for situations where you might want to see the fraction.

I haven't painted anything in a while, but I've always been locking groups I wasn't working on 'just in case I click wrong', so I don't consider locking difficult, at least if you sort the groups in the list in a reasonable order. Of course, adding some shortcut keys and maybe even some way to see which bones are locked could be helpful, and, I think, is the way to go, instead of trying to hack in extra behavior for hiding.

About displaying non-normalized weights as normalized: It's really the only way to make this feature get close to making sense with non-normalized weights. It can result in some strange situations, where you have a weight value of 1 being displayed as a color other than red, so attempting to add to that weight will fail. There's not much we can do beside a tooltip asking the user to normalize their weights. Also, I wonder if the same thing should be added to Multi-Paint in the future?

I don't really understand the non-normalized weight workflow at all, so this feature has always been for normalized weights - I just found a way to make it do something potentially useful with un-normalized ones too. Previously it just didn't work at all unless you enabled Auto Normalize to indirectly signal that the weights are normalized.

As a historical note, I in fact arguably made locking less useful for non-normalized weight years ago, as originally locks were trying to preserve the relative weight of the bones when auto-normalize was off, so it was actually changing the values of groups you weren't painting on when they were locked. I found that really confusing and thought it was a bug, so eventually I removed it in my Auto-Normalize & Multi-Paint overhaul patch to make locks simply prevent the current value from changing as you'd expect.

Hmmm, at least for my use cases, it would definitely be too much hassle to manage the locks. Just the face of my character has 278 vertex groups. But I see your point about this feature only relating to display and not actual behaviour. And sure enough, if there is someone out there who uses vertex group locking, this will be useful for them. I'm just not one of those people.

Perhaps a separate, complementary feature could be, to lock the vertex weights of hidden bones. That I would use. But it's a separate thing and I don't mean to derail, just wanted to throw it out there.

Maybe this can be reclassified as a part of a bigger design issue to "make weight group locking more useful and convenient".

Update on user perspective:

Absolute madman Alexander actually went ahead and made a number of improvements to Blender since the initial posting of this patch that made a weight painting workflow involving vertex group locking actually seem quite usable. Namely, the new vertex group locking operators on K pie menu, and red shading on bones that correspond to a locked vertex group. For that workflow, (although it is brand new to me and I haven't spent serious time trying to use it yet) this patch seems like a nice addition.