Page MenuHome

Proportional Editing Vertex Gradient
Needs RevisionPublic

Authored by Benjamin Sauder (kioku) on May 2 2019, 10:34 PM.
Tokens
"Love" token, awarded by dinhdong."Love" token, awarded by xdanic."Love" token, awarded by johnsyed."Love" token, awarded by Zuorion."Love" token, awarded by Mir-Mir-Roy."Love" token, awarded by Arkhangels."Love" token, awarded by mistajuliax."Love" token, awarded by leonumerique."Love" token, awarded by Aerie."Love" token, awarded by Monkok3D."Love" token, awarded by deadpin."Love" token, awarded by damian."Love" token, awarded by v01tech."Like" token, awarded by 1D_Inc."Love" token, awarded by noirekld."Love" token, awarded by Shimoon."Like" token, awarded by zodiac98177."Love" token, awarded by Oskar."Love" token, awarded by ckohl_art."Love" token, awarded by dpdp."Heartbreak" token, awarded by shader."Love" token, awarded by Leul."Love" token, awarded by Debuk."Love" token, awarded by ofuscado."Love" token, awarded by xan2622."Love" token, awarded by astrand130."Like" token, awarded by Fracture128."Love" token, awarded by SecuoyaEx."Love" token, awarded by hadrien."Love" token, awarded by CobraA."Love" token, awarded by Rawzombie."Burninate" token, awarded by ckat609."Love" token, awarded by koloved."Love" token, awarded by DaPaulus."Love" token, awarded by zaha."Love" token, awarded by zanqdo."Love" token, awarded by thornydre."Burninate" token, awarded by eobet."Love" token, awarded by 3Rton."Love" token, awarded by brilliant_ape."Love" token, awarded by wondrs."Love" token, awarded by Dspazio."Like" token, awarded by gottfried."Burninate" token, awarded by jonathanl."Mountain of Wealth" token, awarded by lordodin."Love" token, awarded by julperado."Love" token, awarded by sephirothtbm."Love" token, awarded by wo262."Love" token, awarded by Draise."Love" token, awarded by Tetone."Pterodactyl" token, awarded by craig_jones."Love" token, awarded by monio."Love" token, awarded by GeorgiaPacific."Like" token, awarded by bunny."Like" token, awarded by Way."Like" token, awarded by RedMser."Love" token, awarded by symstract."Love" token, awarded by helloidonthaveanyideaformyusername."Love" token, awarded by Zino."Love" token, awarded by erickblender."Love" token, awarded by elbox01."Burninate" token, awarded by DotBow."Like" token, awarded by Bit."Love" token, awarded by billreynish."Love" token, awarded by xrg."Love" token, awarded by jendrzych.

Details

Summary

Hi there,

this patch adds a vertex gradient visualization for the proportional editing falloff. This should work across different modes and objects as far as I can tell.

Here are two examples of mesh edit mode and uv edit:

Right now the colors are tweakable in the user theme settings, and the drawing of the gradient can be toggled in the recently revamped proportional editing popover.

Maybe its preferred to just use the weight mapping colors?
(Adding it to the theme settings was more of a personal exercise on how to add it there...)

The drawing itself is done in transform.c -> drawTransformView - by just using the TransInfo verts in a gpu immedite call. As depth test off isn't always a viable option to just draw over the scene I altered the GPU_SHADER_3D_FLAT_COLOR to account for the depth offset which happens to the regular vert drawing.
Im a bit unsure about this approach, I basically just followed what the other transform draw calls where doing - hope it's okay.

Thanks for your time.

Diff Detail

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

small consistency tweak, uses dots instead of squares as vertex shape.

  • rebase to current master.
CobraA (CobraA) added a subscriber: CobraA (CobraA).

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

Any news on this needed and handy feature?

Yegor R (Monkok3D) rescinded a token.
Yegor R (Monkok3D) awarded a token.

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.

source/blender/editors/transform/transform_constraints.c
987

Style : Always use brackets with conditional statements.

source/blender/editors/transform/transform_constraints.c
929

/* Use this format for comments. */ With Capital on first char and fullstop at the end.

941

Instead of modifying the shader modify the projection matrix instead. Push it and restore after drawing.

Clément Foucault (fclem) requested changes to this revision.Mar 23 2020, 8:39 PM

Maybe its preferred to just use the weight mapping colors?

Sorry I didn't read your patch description first sorry. So yes it is preferred.

If you can upload the patch using arcanist it would be even better (but not mandatory).

Edit: Probably making them always visible is much harder technically due to how transform in Blender works. Even if this is only visible while transforming initially, it's still a welcome improvement.

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.

@Campbell Barton (campbellbarton) any opinion?

source/blender/editors/transform/transform_constraints.c
964

Replace by immBeginBatchAtMost. Immediate mode can overflow and is slow.

This revision now requires changes to proceed.Mar 23 2020, 8:39 PM

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.

source/blender/editors/transform/transform_constraints.c
934

Use GPU_matrix API here.

@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.

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:

(red circled areas are vertices inside the cursor, but not affected by proportional)

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

(you can kinda see the true boundaries because the vertex shape is a square instead of a circle, but still not as clear as before)

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


So basically: 1-color is good only to show the 'global maxima' of the operation but not the boundaries... 2-colors are good to show the maxima and boundaries... and 3-colors are not really necessary, but add more contrast to the middle of the influenced area.

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

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?

source/blender/editors/transform/transform_constraints.c
897

Prefer early return, as is done above.

Could also use note on other spaces that might be supported, movie-clip for eg, did you try this?

921

Use spaces around comments & full sentences, same for other comments here.

/* For object mode just draw over everything. */

922–925

Use braces.

source/blender/makesrna/intern/rna_scene.c
2860

Draw reads like a function call, instead use prefix show_

Campbell Barton (campbellbarton) requested changes to this revision.Thu, Sep 24, 4:39 AM

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.

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.

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.