Weird auto-normalize behavior in weight paint with locked groups. #47123

New Issue

Alexander Gavrilov · 2016-01-05T20:14:18+01:00

Alexander Gavrilov commented

2016-01-05 20:14:18 +01:00

System Information

Fedora 21

Blender Version

Broken: 2.76b

Exact steps for others to reproduce the error

Load this blend file: test-weight-norm.blend

Note that Auto Normalize, Multipaint and Mirror are off. Click on the selected vertex to paint.

    ==> You can see on the right that a 'new' group is added with weight 1 as expected.

Undo the paint, lock the lock_me group in the list, and click on the vertex again.

   ==> Now, unexpectedly, the 'new' group only gets weight 0.3, and all other unlocked groups are wiped.

    Investigation shows that this is caused by a switch to a different code branch, which calls the `enforce_locks` function in `paint_vertex.c`. Further debugging uncovers a sign problem in `redistribute_change`.

Apply this patch, and try painting with locked group again: 0001-Fix-sign-error-in-redistribute_change-to-avoid-too-m.patch

   ==> The painted weight now is 0.9, which matches the expected value with Auto-Normalize on, but it is off. This result is better than before, but:

Undo, change the paint weight to 0.6 and try painting again.

   ==> Now some of the weight remains in the other 3 groups, and it is evident that it is not proper normalization that keeps the proportion betwen them. Instead, 0.2 is simply subtracted from each one.

In order to understand the code better and see if it's possible to solve the last problem, I tried disabling enforce_locks. This made it evident that the function forces normalize to obey locks by in fact doing an ersatz normalization so that the real normalize step becomes a no-op. As an experiment I tried making the real normalization aware of locked groups, and that seems to result in correct proportional weights. However I don't understand what's going on in that code re multipainting:

0002-Experiment-try-to-replace-enforce_locks-with-lock-su.patch

It may also be the case that with lock support in normalize code, there is now no need to enter the multipainting branch just because of the locks.

**System Information** Fedora 21 **Blender Version** Broken: 2.76b **Exact steps for others to reproduce the error** Load this blend file: [test-weight-norm.blend](https://archive.blender.org/developer/F271631/test-weight-norm.blend) # Note that Auto Normalize, Multipaint and Mirror are off. Click on the selected vertex to paint. ``` ==> You can see on the right that a 'new' group is added with weight 1 as expected. ``` ``` . ``` # Undo the paint, lock the lock_me group in the list, and click on the vertex again. ``` ==> Now, unexpectedly, the 'new' group only gets weight 0.3, and all other unlocked groups are wiped. ``` ``` Investigation shows that this is caused by a switch to a different code branch, which calls the `enforce_locks` function in `paint_vertex.c`. Further debugging uncovers a sign problem in `redistribute_change`. ``` ``` . ``` # Apply this patch, and try painting with locked group again: [0001-Fix-sign-error-in-redistribute_change-to-avoid-too-m.patch](https://archive.blender.org/developer/F271632/0001-Fix-sign-error-in-redistribute_change-to-avoid-too-m.patch) ``` ==> The painted weight now is 0.9, which matches the expected value with Auto-Normalize on, but it is off. This result is better than before, but: ``` ``` . ``` # Undo, change the paint weight to 0.6 and try painting again. ``` ==> Now some of the weight remains in the other 3 groups, and it is evident that it is not proper normalization that keeps the proportion betwen them. Instead, 0.2 is simply subtracted from each one. ``` In order to understand the code better and see if it's possible to solve the last problem, I tried disabling `enforce_locks`. This made it evident that the function forces normalize to obey locks by in fact doing an ersatz normalization so that the real normalize step becomes a no-op. As an experiment I tried making the real normalization aware of locked groups, and that seems to result in correct proportional weights. However I don't understand what's going on in that code re multipainting: [0002-Experiment-try-to-replace-enforce_locks-with-lock-su.patch](https://archive.blender.org/developer/F271633/0002-Experiment-try-to-replace-enforce_locks-with-lock-su.patch) It may also be the case that with lock support in normalize code, there is now no need to enter the multipainting branch just because of the locks.

Alexander Gavrilov commented

2016-01-05 20:14:18 +01:00

Changed status to: 'Open'

Alexander Gavrilov commented

2016-01-05 20:14:18 +01:00

Added subscriber: @angavrilov

Alexander Gavrilov commented

2016-01-06 10:02:15 +01:00

Actually realized that this test illustrates an even worse problem:

Use unpatched blender, lock lock_me, enable Auto-Normalize, paint. It sets the new group to 0.75, and changes the locked group to 0.25.

This issue should also be mitigated by the first simple patch, since it achieves valid normalization.

Actually realized that this test illustrates an even worse problem: Use unpatched blender, lock lock_me, enable Auto-Normalize, paint. It sets the new group to 0.75, and *changes the locked group* to 0.25. This issue should also be mitigated by the first simple patch, since it achieves valid normalization.

Campbell Barton self-assigned this 2016-01-06 14:12:23 +01:00

Sergey Sharybin commented

2016-01-07 10:08:53 +01:00

Added subscriber: @Sergey

Campbell Barton commented

2016-01-14 04:24:13 +01:00

Applied: 0001-Fix-sign-error-in-redistribute_change-to-avoid-too-m.patch 3a51a90e56
Fixed the strange behavior with locking unintentionally enabling normalize 10ac7c0f15

- Applied: [0001-Fix-sign-error-in-redistribute_change-to-avoid-too-m.patch](https://archive.blender.org/developer/F271632/0001-Fix-sign-error-in-redistribute_change-to-avoid-too-m.patch) 3a51a90e56 - Fixed the strange behavior with locking unintentionally enabling normalize 10ac7c0f15

Campbell Barton commented

2016-01-14 06:15:42 +01:00

Committed change that makes normalize respect locks, d67535eea0

@angavrilov, Can you double check issues from this report are now resolved?

Committed change that makes normalize respect locks, d67535eea0 @angavrilov, Can you double check issues from this report are now resolved?

Campbell Barton commented

2016-01-18 00:42:32 +01:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2016-01-18 00:42:32 +01:00

Campbell Barton commented

2016-01-18 00:42:32 +01:00

Closing
Logic changed here enough that new issues can be raised as new bugs.

Closing Logic changed here enough that new issues can be raised as new bugs.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Weird auto-normalize behavior in weight paint with locked groups. #47123

Note that Auto Normalize, Multipaint and Mirror are off. Click on the selected vertex to paint.

Undo the paint, lock the lock_me group in the list, and click on the vertex again.

Apply this patch, and try painting with locked group again: 0001-Fix-sign-error-in-redistribute_change-to-avoid-too-m.patch

Undo, change the paint weight to 0.6 and try painting again.