Plz get this into 2.81, it's less than 2 weeks before feature freeze :)

2.83 Hopefully.. ??

Any news on this needed and handy feature?

What I don't really Like is to have the gradient defined as 3 colors. I think it would be preferable to use the weight gradient from the user preference.

In D4786#172545, @Clément Foucault (fclem) wrote:

Not 100% convinced about this being very helpful after starting transforming. But by judging about the hype this patch has received I can see this is a much requested feature. But I don't know if the hype is about some expected feature not present in the patch (preview before transform) or about the implemented feature.

I don't think it is very useful either after starting the transform, since the user can already see the mesh deforming, anyway. It is supposed to be a previsualisation feature, helping adjust the falloff distance before transforming (which currently there is no way to do).

Being able to see how the gradient changes during the transform, as you move and expand the proportional editing influence circle, is definitely the most useful part here and I'd love to see it.

However I do want to confirm some things about William's comment above. It would certainly be nice to be able to show the gradient before the transform actually starts (even though it would have to use the last known influence size somehow).

But then that almost sniffs like a viewport Overlay, or something else that can run outside of the transform. It would be good to get dev/ui input on the following before committing:

• Should the setting live in the proportional editing popover like it does now or should it move to the Overlay settings popover?
• Should this move to somewhere inside the Overlay engine proper or maybe someplace else? This looks like the first use of "DRW_*" within the transform editors...
• General question: I couldn't tell if this draws over already drawn verts or not? i.e. does this patch cause some verts to be drawn twice (once for normal vert color and again for the gradient color) or will each vert still be drawn just once?

I have no skin in this game directly, just don't want to see more time than needed spent later if changes are required.

Should this move to somewhere inside the Overlay engine proper or maybe someplace else? This looks like the first use of "DRW_*" within the transform editors...

Good catch.

General question: I couldn't tell if this draws over already drawn verts or not?

This patch does indeed reupload the vertices for each redraw which will slow down update. I think a better solution would be to have an integration as an overlay and a custom data layer to store the weight. This way we could only update the weights once. But this is way more involved.

@Clément Foucault (fclem) hey thanks for your comments.

While I agree that it would be really nice to show this before an actual transformation is happening, this is really out of scope of my patch here.
Changes like that would raise all sorts of questions, and might be not really straight forward to design. And to be fair I would just be unable to implement such an undertaking...
So it is more like a simple local tweak than anything.

This patch does indeed reupload the vertices for each redraw which will slow down update. I think a better solution would be to have an integration as an overlay and a custom data layer to store the weight. This way we could only update the weights once. But this is way more involved.

As blender gets very slow on transforming higher polycounts I never experienced any performance impact of this.. if this would be needed anyways for a proper 'gradient display before transform' feature then yeah sure sounds like a much better approach ;)

One question. Is 3 colors really necessary?
Two or even one would be enough. (In the case of one color the Alpha could define the weight).

I think to simplify the patch, we could at first use one of the colors already defined and used in the transform operator.
Later on in other patches we could improve the customization and design.

In D4786#182499, @Germano Cavalcante (mano-wii) wrote:

Two or even one would be enough. (In the case of one color the Alpha could define the weight).

I thought about using only one color only (and gradually fading as the influence gets lower) but the advantage of having two colors or more (100%sat, 100%value) is that the boundaries of the proportional editing operation becomes much more visible and defined.
The mouse cursor circle is supposed to shows the boundaries (except for the bug described in T75482 where the cursor is drawn far away from the affected vertices), but you can see In William's screenshot that even though some of the vertices appear inside the cursor circle, they will not be affected by the proportional editing (you have to be using Proportional Projected to take the cursor itself into consideration)... the bright green color is what gives the user this hint:

Here's a test with only one color (red) and alpha fading towards the boundaries:

Here's a test with a two color gradient (red to green):

Simply using the weight gradient, which can already be configured in Preferences, seems to be the simplest solution, as @Clément Foucault (fclem) says.

In D4786#183610, @William Reynish (billreynish) wrote:

Simply using the weight gradient, which can already be configured in Preferences, seems to be the simplest solution, as @Clément Foucault (fclem) says.

Who would guess to find the gradient for "proportional editing" under "weight PAINTING"? That is awefully hidden imo.
Not adding options for every little thing in Blender makes totally sense, but in this case i think a seperate option for this gradient is justified , no?

This is also a weight. It’s the weight of the influence of the proportional editing falloff. We can make sure the Preferences panel is just called Weight Gradient.

Overall I'm not so convinced about this patch, while there may be some advantage that you can see the influence, I'm not sure if it's so useful in practice, although perhaps it's a nice extra visual hint.

Some down-sides...

• When transforming you quickly see the area being adjusted. I doubt users will often view the weights before making any transformation.

• For already dense meshes, it adds a an overlay that further obscures the underlying geometry.

• This covers the selection, which might be useful to see while transforming. (to tell the selection apart from the partial weights).

• This adds yet another-drawing-option to support.

Using immediate-mode drawing wont help performance although it's not likely to be a bottleneck either, it's still increasing technical debt a bit.

@Daniel Bystedt (dbystedt) what do you think?

Thank you for the patch and your work @Benjamin Sauder (kioku)

I don't feel a dire need for this feature personally, and my main concern is the comment from @Campbell Barton (campbellbarton)

• This adds yet another-drawing-option to support.

I would be weary of adding code that could potentially "steal developers time" in the future. It is very hard for me to evaluate how this affects developers, so I will leave the decision up to @Campbell Barton (campbellbarton)

With that said, there can be situations where this feature could be useful for users.

As an artist I do not feel that this is something I've been missing, as I can clearly evaluate how much the vertices are affected as I am translating them. I am also able to adjust the proportional size after the operation is done (see image below)

I am more interested in looking at the result of the shaded surface when I'm transforming vertices. Having these bright colors would mostly "disrupt my eye" so to speak. I would definitely feel the need to turn this overlay off if it would be implemented.

I did some more thinking regarding this patch and thought of a really useful scenario. The following writing will stray a bit from the intended implementation, but please bear with me

This type of overlay drawing could be very useful for visualizing future per mesh component attribute that is mentioned in T76659: Geometry Attributes Design. So if the user would want to visualize for instance custom float attribute per vertex with values that goes outside the 0-1 range, this could be visualized by remapping to colors per vertex that is used in this patch. I would not limit visualizing float attributes to only colors, but it would be one way of visualizing the attribute. Another way could for instance be number labels per vertex.

I do not know how relevant these thoughts are for Blender development, but I thought I should mention it.

I'll add my thoughts because I feel something may be overlooked : besides the fact that this fallof visualization is completely standard in all DCCs I used (because that alone doesn't make it a necessity in Blender), it is useful because :

1. adjusting the "proportional size" before a transform operation is impossible (it should be possible), so there is no way to know beforehand how big of an area will be affected
2. tablet users have no practical way of changing the proportional size during transform (bound to mouse wheel), so they are pretty much relegated to having to tweak the proportional size in the last operator panel
3. finally they can't even do that because Blender struggles too much when changing any value in the last operator panel if the mesh is bigger than about 50k verts (which is very, very low)

That is why, according to me, an overlay for proportional editing and a settable proportional distance outside of the transform operators is essential (I understand this patch is only about the first part, but they go hand-in-hand).

When transforming you quickly see the area being adjusted. I doubt users will often view the weights before making any transformation.

This is exactly the reason why it's not optimal. You have to manually transform to see the area affected. If you are planning the best place to grab a component, you have no idea exactly where are the boundaries to the proportional, look at the example below.
Also, once procedural transforms gets into the mix (in Everything Nodes), it would definitely be required to preview the weighted transform areas of the model, as we would not be directly editing the mesh, but doing so by means of nodes.

In D4786#183609, @Evandro Costa (Arkhangels) wrote:

Without transforming, one might assume the red circled areas would be affected by the proportional range, but they would not in this example.
Now imagine the user is transforming a multi-million vertex model, where each small transform takes seconds to do.
We are forcing users to repeatedly redo or tweak the operation until he finds the desired outcome, while we could simply provide additional information previously to the transform, to reduce the guesswork and trial-error.

For already dense meshes, it adds a an overlay that further obscures the underlying geometry.

Did I misunderstand or isn't this patch only changing the color of the vertex dots, and not adding anything, therefore not further obscuring anything that wasn't already obscured by the black dots?
In any case this conversation is related to the proposal of dynamic vertex dots size (as in the current state if you zoom-out of a dense mesh it becomes a black blob).

This covers the selection, which might be useful to see while transforming. (to tell the selection apart from the partial weights).

There's nothing preventing us from keeping the originally selected dots with their original selection color (orange in the default theme), and only color the adjacent not-selected dots.
But there was a previous discussion about edges having multiple states represented at the same time (edge seam/sharp/selected, etc), by the use of outlines. Maybe have the original selected dots with a weight outline (orange with red outline), or vice-versa.

In D4786#221348, @Daniel Bystedt (dbystedt) wrote:

This type of overlay drawing could be very useful for visualizing future per mesh component attribute

This is a great observation. I can see this coloration being extremely useful in the Everything Nodes procedural transforms to vertex clusters weights, in order to visualize what exactly these weights are and what is changing where.
Or are we to suppose that even doing procedural modelling the user would have to keep fake-transforming the mesh to see the exact regions affected by a weight-related operation? This seems completely counterproductive.