Page MenuHome

Weld Modifier - Average vertex weights of welded vertices
AbandonedPublic

Authored by Cody Winchester (CodyWinch) on Mar 31 2020, 5:08 AM.

Details

Summary

This patch aims to give the user the option to average the merged vertex weights with the weld modifier.

The current functionality adds together all of the vertices weights and clamps 0-1. This will add the weights together and divide by the total # of vertices. Vertices not assigned to the existing vertex group will be treated as a weight of 0.0f

The option is now a single boolean that reuses the existing flag.

Diff Detail

Repository
rB Blender

Event Timeline

It seems that vertex weights are already interpolated in the last master. Could you check?

It seems that vertex weights are already interpolated in the last master. Could you check?

Seems like you are correct. It appears to now add all the weights of the weld verts together. This actually results in weights above 1.0 from my small testing.

I will take a look at the new code and see if I can better implement averaging as an option. Thanks for notifying me.

Cody Winchester (CodyWinch) planned changes to this revision.Apr 3 2020, 9:55 PM

Modified for new master.

In the new master the vertex weights are all added together and can result in weights greater than 1.0f.

Now the patch averages based on all of the vertices welded. So a vert not assigned to the vertex group acts as a weight of 0.0f.

Cody Winchester (CodyWinch) edited the summary of this revision. (Show Details)

Updated for new master.

New version has the vertex weight mixing method as an option for the user to choose from.

There are 3 modes:

  • Highest Weight - This is the default and current functionality where is uses the highest weight of the source vertices weights
  • Lowest Weight - This is the default and current functionality where is uses the lowest weight of the source vertices weights
  • Averaged Weight - This mode averages all of the source vertices weights. If one of the vertices is not assigned to the vertex group then it is treated as a weight of 0.0f

Thanks for the patch.
I wonder how essential this feature is.
It’s good to keep in mind that there are still other Weld Modifier priority list items.
Among the advantages, this can bring some disadvantages:

  • Very informative layout,
  • Small overhead when merging vetices,
  • More code to maintain.
source/blender/makesdna/DNA_modifier_types.h
1942 ↗(On Diff #25185)

Could you use flags here? And join with the other flags?
Since there are a lot of modifiers in this file, it might be good to keep things more compact.
And it could also reuse the flag member thus reducing the size of the WeldModifierData struct.

Thanks for the patch.
I wonder how essential this feature is.
It’s good to keep in mind that there are still other Weld Modifier priority list items.
Among the advantages, this can bring some disadvantages:

  • Very informative layout,
  • Small overhead when merging vetices,
  • More code to maintain.
  • Layout can be improved. I am fine with any changes need to the layout.
  • The overhead should only be there when the user chooses to use one of the other options. The default option is the exact same as it was before.
  • I don't see how this is a real disadvantage. Pretty much any new functionality/options added is going to add more code to maintain. The added code to the weld file is isolated to its own section.

I have another version of the patch that adds the average weights functionality as a single boolean. This would do away with the third option of using the lowest weight. This would address your concerns about the use of an additional flag and making the modifier struct larger. It would reuse the existing flag and only add 1 option to it.

source/blender/makesdna/DNA_modifier_types.h
1942 ↗(On Diff #25185)

This follows the way other modifiers have similar modes. They are separated to their own flag.

It could work to combine with the existing flag, but then the enum would just be named Flag. That isn't very descriptive about what this enum is doing.

The actual size of the struct should be the same since I am reducing the padding to make room for the new flag. Unless you mean size in terms of how many lines of code.

Cody Winchester (CodyWinch) edited the summary of this revision. (Show Details)

Changed to a single option boolean. I thought the current weight mixing was using the highest vertex weight, but I was wrong and it adds the weights together then clamps to 0-1. So I have simplified the added change to just an averaging option.

It's ok for me. But I will let the reviewers approve.

Are there any situations where the current behavior of adding all the vertex weights together and then clamping is actually preferred?

I'm not sure I like the idea of adding an option for behavior that most people expect anyway. (IMO the current behavior mentioned above of adding them up would not be expected)

If the option is necessary for performance I'd rather have a choice between "Nothing" and "Expected Behavior" than a choice between "Unexpected Behavior" and "Expected Behavior".

Updated for new master.

Are there any situations where the current behavior of adding all the vertex weights together and then clamping is actually preferred?

I'm not sure I like the idea of adding an option for behavior that most people expect anyway. (IMO the current behavior mentioned above of adding them up would not be expected)

If the option is necessary for performance I'd rather have a choice between "Nothing" and "Expected Behavior" than a choice between "Unexpected Behavior" and "Expected Behavior".

Are there any situations where the current behavior of adding all the vertex weights together and then clamping is actually preferred?

I'm not sure I like the idea of adding an option for behavior that most people expect anyway. (IMO the current behavior mentioned above of adding them up would not be expected)

If the option is necessary for performance I'd rather have a choice between "Nothing" and "Expected Behavior" than a choice between "Unexpected Behavior" and "Expected Behavior".

I would agree that averaging should be the default behavior. In this case I am not sure what the "Nothing" behavior would be.

This is not the proper way to fix this issue.

The root of the issue comes from calling CustomData_interp() with NULL weights (it is the only place in code we do that currently, I think). Instead of generating average values, that function will instead just add them. I cannot see any good reason for this behavior, so added D9114: Refactor CustomData interpolation code., which indeed fixes the problem here.