Animation: Make Vertex Weight Edit modifier inclusive #108286

Merged
Nate Rupsis merged 20 commits from nrupsis/blender:vertext-weights-inclusive into main 2023-07-12 17:52:58 +02:00
Member

Overview

The Vertex Weight Edit modifier isn't inclusive.

Exp: Empty Vertex group with default weight equal to the add threshold.
image

This PR changes VertexWeightEdit modifier to be inclusive. An empty vertex group with the default weight equal to the "add" threshold (0.5) now adds weight as expected.

image

Removing Weight:

Old behavior: Cube with Vertex group of weight 0.5 isn't removed when threshold is also 0.5
image

Patch: With the inclusiveness, the 0.5 weighted group is now removed:

image

Breaking Changes

Now that the calculations are inclusive, older files with the VertexWeighEdit modifier will be impacted (I.e, if threshold and Default weight are 0.0 or 1.0). to fix this, we there is some versioning code to modify the Group Add / Remove threshold to the nearest floating point (using C++ nexttoward) to ensure the previous behavior is kept in tact.

Additionally, increasing the add_threshold and remove_threshold property range to [-1000.0, 1000.0] to allow us to add in 3.6 backwards compatibility.

Testing:

The two 3.5 blend files attached exhibit the same behavior in 3.5 as they do in 4.0.


Ref: Issue #82831

## Overview The Vertex Weight Edit modifier isn't inclusive. Exp: Empty Vertex group with default weight equal to the add threshold. ![image](/attachments/a59c669b-fc1c-4113-8385-91f66d0397ca) This PR changes VertexWeightEdit modifier to be inclusive. An empty vertex group with the default weight equal to the "add" threshold (0.5) now adds weight as expected. ![image](/attachments/989328ff-050d-4f8f-8c65-2e51e0396204) ### Removing Weight: Old behavior: Cube with Vertex group of weight 0.5 isn't removed when threshold is also 0.5 ![image](/attachments/1aef282e-07af-4ee5-aad3-1929bacfe5b4) Patch: With the inclusiveness, the 0.5 weighted group is now removed: ![image](/attachments/f13d0801-2fee-4f80-89a8-b9951b8c4e8a) ## Breaking Changes Now that the calculations are inclusive, older files with the VertexWeighEdit modifier will be impacted (I.e, if threshold and Default weight are `0.0` or `1.0`). to fix this, we there is some versioning code to modify the Group Add / Remove threshold to the nearest floating point (using C++ nexttoward) to ensure the previous behavior is kept in tact. Additionally, increasing the `add_threshold` and `remove_threshold` property range to [-1000.0, 1000.0] to allow us to add in 3.6 backwards compatibility. Testing: The two 3.5 blend files attached exhibit the same behavior in 3.5 as they do in 4.0. --- Ref: [Issue #82831](https://projects.blender.org/blender/blender/issues/82831)
Nate Rupsis added 1 commit 2023-05-25 18:40:37 +02:00
Nate Rupsis added 1 commit 2023-05-25 18:41:23 +02:00
Nate Rupsis added the
Module
Animation & Rigging
label 2023-05-25 18:43:34 +02:00
Nate Rupsis added this to the Animation & Rigging project 2023-05-25 18:43:42 +02:00
Author
Member

Note: From module meeting, on the versioning we should bump +- to the most significant floating point number in the versioning code.

Note: From module meeting, on the versioning we should bump +- to the most significant floating point number in the versioning code.
Member

Ah, thx putting that PR up, this is exactly what I came up with in #82831, right?

Ah, thx putting that PR up, this is exactly what I came up with in #82831, right?
Author
Member

Hi @lichtwerk, yep! At the moment this is exactly what you have. However, in the Animation / Rigging module meeting, we discussed adding some versioning code to 4.0 to preserve backwards comparability (slightly modify the float value to make it act exclusive). Currently working on that bit. Thanks for the initial code!

Hi @lichtwerk, yep! At the moment this is exactly what you have. However, in the Animation / Rigging module meeting, we discussed adding some versioning code to 4.0 to preserve backwards comparability (_slightly_ modify the float value to make it act exclusive). Currently working on that bit. Thanks for the initial code!
Nate Rupsis added 1 commit 2023-05-26 16:12:15 +02:00
Hans Goudey requested review from Hans Goudey 2023-05-26 16:24:06 +02:00
Nate Rupsis added 1 commit 2023-05-30 02:32:30 +02:00
Nate Rupsis requested review from Sybren A. Stüvel 2023-05-30 02:33:29 +02:00
Nate Rupsis added 1 commit 2023-05-30 04:03:44 +02:00
buildbot/vexp-code-patch-coordinator Build done. Details
eab03f3a36
Merge branch 'main' into vertext-weights-inclusive
Nate Rupsis changed title from WIP: making weights inclusive to Animation: Make Vertex Weight Edit modifier inclusive 2023-05-30 04:06:37 +02:00
Author
Member

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR108286) when ready.
Hans Goudey requested changes 2023-05-31 19:59:46 +02:00
@ -29,0 +36,4 @@
{
/* Object */
LISTBASE_FOREACH (Object *, ob, &bmain->objects) {
Member

The blank lines before the object type check and after the modifier type check don't add much IMO.
Same with the /* Object */ and /* Object modifiers */ comments IMO, that is obvious anyway.
Best to remove those I think.

The blank lines before the object type check and after the modifier type check don't add much IMO. Same with the `/* Object */` and `/* Object modifiers */` comments IMO, that is obvious anyway. Best to remove those I think.
nrupsis marked this conversation as resolved
@ -29,2 +57,4 @@
}
}
void do_versions_after_linking_400(FileData * /*fd*/, Main *bmain)
Member

Does this still need to be in do_versions_after_linking_400, now that the mesh isn't being modified?

Does this still need to be in `do_versions_after_linking_400`, now that the mesh isn't being modified?
Author
Member

Looks like the full modifier data gets pulled in. moved it to the main blo_do_versions_400

Looks like the full modifier data gets pulled in. moved it to the main `blo_do_versions_400`
nrupsis marked this conversation as resolved
Nate Rupsis added 2 commits 2023-06-01 04:44:56 +02:00
Nate Rupsis requested review from Hans Goudey 2023-06-01 04:47:21 +02:00
Hans Goudey approved these changes 2023-06-01 05:12:10 +02:00
@ -18,2 +20,4 @@
#include "BKE_deform.h"
#include "BKE_main.h"
#include "BKE_mesh.h"
Member

Seems this include is unneeded now.

Seems this include is unneeded now.
nrupsis marked this conversation as resolved
Nate Rupsis added 1 commit 2023-06-01 16:59:43 +02:00
Nate Rupsis added 1 commit 2023-06-12 00:36:34 +02:00
Sybren A. Stüvel reviewed 2023-06-16 12:37:58 +02:00
@ -116,2 +120,4 @@
}
/* Version VertexWeightEdit modifier to make existing weights exclusive of the threshold. */
static void version_vertex_weight_edit(Main *bmain)

I think a more detailed name would be better, especially since this file will get many more versioning functions. version_vertex_weight_slightly_nudge_thresholds or something along those lines?

I think a more detailed name would be better, especially since this file will get many more versioning functions. `version_vertex_weight_slightly_nudge_thresholds` or something along those lines?
nrupsis marked this conversation as resolved
@ -118,0 +130,4 @@
LISTBASE_FOREACH (ModifierData *, md, &ob->modifiers) {
if (md->type == eModifierType_WeightVGEdit) {
WeightVGEditModifierData *wmd = (WeightVGEditModifierData *)md;
if (wmd->default_weight == wmd->add_threshold) {

What is the comparison to default_weight for? Wouldn't it be prudent to always adjust the thresholds? (honest question, not trying to suggest any change)

What is the comparison to `default_weight` for? Wouldn't it be prudent to always adjust the thresholds? (honest question, not trying to suggest any change)
Author
Member

To preserve previous behavior (i.e, exclusivity) I think we should only consider cases where the default weight is equal to the add/subtract threshold. That way we're only modifying peoples files to preserver backwards compatibly, and nothing more.

Now, I think this is a small enough corner case where it probably wouldn't matter if we just automatically adjusted all thresholds, but I don't see an obvious advantage to it.

To preserve previous behavior (i.e, exclusivity) I think we should only consider cases where the default weight is equal to the add/subtract threshold. That way we're only modifying peoples files to preserver backwards compatibly, and nothing more. Now, I think this is a small enough corner case where it _probably_ wouldn't matter if we just automatically adjusted all thresholds, but I don't see an obvious advantage to it.

From what I understand of the documentation is that it applies default_weight to those vertices with weight >= add_threshold. So in theory you could add vertices with default_weight = 60% with add_threshold = 50%. If I understand things well, the in/exclusivity of that threshold is what matters here, regardless of the weight that these vertices will get.

From what I understand of [the documentation](https://docs.blender.org/manual/en/4.0/modeling/modifiers/modify/weight_edit.html#index-0) is that it applies `default_weight` to those vertices with `weight >= add_threshold`. So in theory you could add vertices with `default_weight = 60%` with `add_threshold = 50%`. If I understand things well, the in/exclusivity of that threshold is what matters here, regardless of the weight that these vertices will get.
Author
Member

I think you're right. However, I don't know how you assign weights to vertices that are not already in a vgroup?
The tool tip for the Group add is "Lower bounds for a vertex's weight to be added to the vgroup".

From my testing, the default weight (for the Group add) only applies to vertices not in the targeted vgroup. Which, unless editable outside the vgroup, will always be 0.

This is hitting the bound of my knowledge on the subject, so perhaps I'm just misunderstanding.

I think you're right. However, I don't know how you assign weights to vertices that are not already in a vgroup? The tool tip for the Group add is "Lower bounds for a vertex's weight to be added to the vgroup". From my testing, the default weight (for the Group add) only applies to vertices _not_ in the targeted vgroup. Which, unless editable outside the vgroup, will always be 0. This is hitting the bound of my knowledge on the subject, so perhaps I'm just misunderstanding.
Author
Member

Talked about this in last weeks Animation & Rigging module. Removing the default_weight == threshold checks.

Talked about this in last weeks Animation & Rigging module. Removing the `default_weight == threshold` checks.
nrupsis marked this conversation as resolved
@ -206,6 +232,10 @@ void blo_do_versions_400(FileData * /*fd*/, Library * /*lib*/, Main *bmain)
FOREACH_NODETREE_END;
}
if (!MAIN_VERSION_ATLEAST(bmain, 400, 7)) {

I would recommend only adding versioning code to the generic 'move me when the subversion is bumped' section. At least for reviewing that makes things easier, as subsequent development on main can otherwise cause conflicts.

The actual bump & move into a version-specific section can then be done when landing. Or as a 2nd stage of the review, if you want more eyes on that as well.

I would recommend only adding versioning code to the generic 'move me when the subversion is bumped' section. At least for reviewing that makes things easier, as subsequent development on `main` can otherwise cause conflicts. The actual bump & move into a version-specific section can then be done when landing. Or as a 2nd stage of the review, if you want more eyes on that as well.
nrupsis marked this conversation as resolved
Hans Goudey reviewed 2023-06-23 17:04:02 +02:00
@ -118,0 +129,4 @@
LISTBASE_FOREACH (ModifierData *, md, &ob->modifiers) {
if (md->type == eModifierType_WeightVGEdit) {
WeightVGEditModifierData *wmd = (WeightVGEditModifierData *)md;
Member

(WeightVGEditModifierData *)md -> reinterpret_cast<WeightVGEditModifierData *>(md)

https://wiki.blender.org/wiki/Style_Guide/C_Cpp#C.2B.2B_Type_Cast

`(WeightVGEditModifierData *)md` -> `reinterpret_cast<WeightVGEditModifierData *>(md)` https://wiki.blender.org/wiki/Style_Guide/C_Cpp#C.2B.2B_Type_Cast
nrupsis marked this conversation as resolved
Nate Rupsis added 2 commits 2023-07-05 21:46:19 +02:00
Sybren A. Stüvel requested changes 2023-07-06 11:38:54 +02:00
@ -31,6 +33,8 @@
#include "BLO_readfile.h"
#include "DNA_modifier_types.h"

Keep the DNA_... includes grouped together.

Keep the `DNA_...` includes grouped together.
nrupsis marked this conversation as resolved
@ -124,0 +137,4 @@
if (md->type == eModifierType_WeightVGEdit) {
WeightVGEditModifierData *wmd = reinterpret_cast<WeightVGEditModifierData *>(md);
wmd->add_threshold = nexttoward(wmd->add_threshold, 2.0);
wmd->rem_threshold = nexttoward(wmd->rem_threshold, -1.0);

Maybe add a comment that explains what these numbers are. They are just the min/max values ±1, but that might not be obvious to everybody.

Maybe add a comment that explains what these numbers are. They are just the min/max values ±1, but that might not be obvious to everybody.
@ -134,2 +156,3 @@
"GeometryNodeStoreNamedAttribute",
"GeometryNodeInputNamedAttribute")) {
"GeometryNodeInputNamedAttribute"))
{

Formatting

Formatting
@ -5219,3 +5219,2 @@
prop = RNA_def_property(srna, "add_threshold", PROP_FLOAT, PROP_NONE);
RNA_def_property_float_sdna(prop, nullptr, "add_threshold");
RNA_def_property_range(prop, 0.0, 1.0);
RNA_def_property_float_sdna(prop, NULL, "add_threshold");

My bet is that this PR started before the code was converted to C++. Be sure to use nullptr instead of NULL in C++ code.

My bet is that this PR started before the code was converted to C++. Be sure to use `nullptr` instead of `NULL` in C++ code.

My bet is that this PR started before the code was converted to C++. Be sure to use nullptr instead of NULL in C++ code.

My bet is that this PR started before the code was converted to C++. Be sure to use `nullptr` instead of `NULL` in C++ code.
nrupsis marked this conversation as resolved
@ -5220,2 +5220,2 @@
RNA_def_property_float_sdna(prop, nullptr, "add_threshold");
RNA_def_property_range(prop, 0.0, 1.0);
RNA_def_property_float_sdna(prop, NULL, "add_threshold");
RNA_def_property_range(prop, -1000.0, 1000.0);

The PR description says nothing about expanding the allowed ranges for these thresholds. Is this a necessity for the change from exclusive to inclusive? If not, it'll be better to put into a separate commit.

The PR description says nothing about expanding the allowed ranges for these thresholds. Is this a necessity for the change from exclusive to inclusive? If not, it'll be better to put into a separate commit.
Author
Member

This change doesn't impact the exclusive to inclusive, however it is required for the versioning code to work.
Should the whole versioning bit be moved into a new PR/commit?

This change doesn't impact the exclusive to inclusive, however it is required for the versioning code to work. Should the whole versioning bit be moved into a new PR/commit?

No it's better to have the change + the versioning in one commit. I just didn't realise that this was necessary for the versioning.

No it's better to have the change + the versioning in one commit. I just didn't realise that this was necessary for the versioning.
dr.sybren marked this conversation as resolved
Nate Rupsis added 2 commits 2023-07-07 20:56:20 +02:00
Nate Rupsis added 1 commit 2023-07-07 21:07:27 +02:00
Sybren A. Stüvel reviewed 2023-07-10 15:47:45 +02:00
@ -146,3 +166,2 @@
"GeometryNodeStoreNamedAttribute",
"GeometryNodeInputNamedAttribute"))
{
"GeometryNodeInputNamedAttribute")) {

Keep unrelated changes out of the commit (even when it's fixing someone else's formatting mistakes). git gui is your friend when you want to (un)stage specific hunks/lines.

Keep unrelated changes out of the commit (even when it's fixing someone else's formatting mistakes). `git gui` is your friend when you want to (un)stage specific hunks/lines.
Sybren A. Stüvel approved these changes 2023-07-10 15:48:09 +02:00
Sybren A. Stüvel left a comment
Member

LGTM, thanks!

LGTM, thanks!
Nate Rupsis added 6 commits 2023-07-12 17:49:36 +02:00
Nate Rupsis merged commit 1837bda030 into main 2023-07-12 17:52:58 +02:00
Nate Rupsis deleted branch vertext-weights-inclusive 2023-07-12 17:53:00 +02:00
Member

Seems like this has versioning code checking MAIN_VERSION_ATLEAST(bmain, 400, 11) but BLENDER_FILE_SUBVERSION hasnt actually been bumped? (we are still at 10?)

Seems like this has versioning code checking `MAIN_VERSION_ATLEAST(bmain, 400, 11)` but `BLENDER_FILE_SUBVERSION` hasnt actually been bumped? (we are still at 10?)
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser Project (Legacy)
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No Assignees
5 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#108286
No description provided.