Vertex Group/Weight Paint Dilemma

As much i’m a fan of the whole vertex group concept, sometimes you run into unpleasant situations with it, specially when armatures are involved.

Lets say you finished weight painting your character and beside your amature vertex groups you have a bunch of additional vertex groups unrelated to your armature like corrective smooth, cloth, particle simulations and what not. After animating a while with it you realise that some weight painted vertices are not normalized. No problem right? You just go back in and normalize your weights. Oh wait, these unrelated armature VG’s get normalized too, and totally screw up your armature weights…

Unfortunately i can’t come up with an easy way to fix this. The only solution i can think of is to make another copy of your character. Delete all VG’s related to the armature on the copied character mesh and on the orignal character mesh delete all unrelated Armature VG’s. Then normalize all armature weights and copy the unrelated VG’s back to the orignal. A tedious task! Unfortunately Auto Normalize is off by default which is odd cause i can’t think of any situation were i need a vertex weight above 1.

I wish there were a seperation between armature VG’s and non-armature VG’s to avoid these obsticals.
Anyway, rant mode off, i need a beer…

You can lock vertex groups.
You can give a prefix or suffix to vertex group names, filter vertex groups items in list and lock the ones that are not relative to armature.

Normalize All Groups have options in Redo panel to normalize only deform pose bones or selected pose bones.
When using auto-normalize option while painting only deform pose bones are affected.

1 Like

Awesome, locking vertex groups, didn’t think of that. You just earned a little heart mister. :smiling_face_with_three_hearts:

Well, try it out, but it doesn’t work for what you want. (It works for something else though.)

Let’s say you’re weighted 1.0 to hand, 1.0 to arm, and 1.0 to corrective smooth, and you lock corrective smooth. When you normalize these weights, you’ll get 0,0,1 weights-- not at all what you wanted. Locking prevents the weights from changing; it doesn’t prevent the weights from being entered into the normalization calculations.

This is actually pretty handy behavior for some weight painting tasks, where you can normalize some gradient you just painted pretty easily. So that behavior probably shouldn’t change, it’s not like it’s a bug.

Normalize All used to have an option to normalize only deform or selected. It hasn’t for a while. It has that subset choice, but only ever offers “all groups”. Maybe, because it never worked. (It did something weird like lock non-deforming, which isn’t what you want.)

Unfortunately, this is one of those places where Blender just isn’t very good. I agree, there really needs to be a way to normalize a subset to a subset. As far as I can tell, you’re right about the workaround, and yes, it is tedious.

But most of the time, you don’t actually need to normalize deforming weights anyways. Blender autonormalizes deforming groups at the time of evaluation of the armature modifier. 1.0 hand 1.0 arm weights are perfectly valid.

Well i think it worked. Deformation looking ok now and i just checked some troubled verts and so far these values seem ok. The vertices are evenly add up to 1 and kept there percentive ratio just fine.

But seriously, like i mentioned above, cant think of a reason to have weights above 1. What is the point that? Same goes for for Maya and Max. Never understood why. When do i need weights above 1?

It’s not that you need them. It’s that you don’t need to normalize. It’s the ratio that’s important, not the individual numbers. Blender doesn’t care about the actual numbers. So hand 0.5, arm 0.5 is the same as 1,1, which is the same as 0.1,0.1.

Normalizing is still an important bit of some weighting processes for interim stuff though, so what you’re talking about with the difficulty of normalizing deforming weights is an issue with Blender.

Make a simple cube test to see what I’m talking about. Unless for some reasons our versions of Blender are operating completely differently, it doesn’t work. Not via “normalize all vertex groups” operation at least. Normalize button on sidebar, on deform tabbed groups, works, but only on a single vertex at a time.

You were right. It worked for the most part but down at the bottom i have a few vertices sticking out. Turns out that the cloth vertex group are now part of the deforming armature vertex groups after normalization. But just for these few vertices, the rest is ok. Something is really wrong here. The subset setting in the ‘normalize all’ dialog did nothing for me.

My idea, to temporary move these unrelated groups to another mesh, doesnt work neither. When i copy them back with ‘copy vertex group to selected’, the old ones get overwritten. Guess i have to delete all unrelated vertex groups and paint them new. There seem to be no way around it.

Are they aware of this problem? Cause i didn.t found anything on the developers blog about it.

You have to delete the deforming vertex groups from the copy.

Okay, so you have a mesh with groups Hand, Arm, CS.

  1. Duplicate mesh. Delete CS group from original. Delete Hand + Arm groups from copy.
  2. Normalize all vertex groups on original.
  3. Data transfer (topology, vertex data, vertex groups, all layers by name) from copy to original. Generate data layers then apply.
1 Like

It worked!! Never used the data transfer modifier before. This thing is awesome.
Thank you so much for this bandages. Have a nice day. :slight_smile:

Oops, i just noticed that the fresh copied cloth vertex group is deforming the mesh once again. Even tho its not declared as deforming vertex group in the viewport property menu. This turns into a nightmare. Any more ideas how to fix it?

I’m afraid I don’t understand the question or the situation. A file might help.

Ok, everythings good now. I found the root of the cause. Its true that the cloth vertex group was deforming the mesh. That was a few days before when i did what zeauro suggested. I thought it worked and meanwhile i made some changes on the mesh and saved it as shape key (and with it these the few troubled vertices at the bottom that i didn’t noticed then)

Then you posted that this might not work and you were right, but the changes were already saved in that shape key and of course, after the data transfer process, i assumed that the cloth vg would still deform the mesh after copying it back to the orignal. I only discovered it by chance while preparing the file for you to look at…case of bad timing, kinda embarrasing :blush: but also funny in a way. I’m just happy i found the mistake.

Again, thank you so much for taking the time.