Sculpt Brush Management UI/UX [Proposal]

Thanks @JulienKaspar !

Definitely it could work too. The problem I wanted to deal with was UI duplication. Having the brushes visible in Asset Browser could give better brush management opportunites compared to the N panel. But I agree that this isn’t neccesary for more fliud sculpting. Dedicated Asset Browser workspace with assset / brush creating and editing can solve a lot of issues here.

Honestly I didn’t put much attention to the keymap in this proposal. The keys I chosen were mostly due to unconsistencies we have right now and the legacy issues with the keymap due to ditching right click select. I trust that the dev team will choose the best option available when the UI changes will be made.

I think this can be also solved with editable pie-menu layout similar to what Q is providing for modeling.
Leaving remesh in T panel seemed awkward to me as all the brushes were beeing moved to pie menus.
I guess that what I proposed as Brush-Set pie menu could also encompass remesh dyntopo and face set brushes, but having some visual distinction between them and regular brushes would be a good thing.

That’s the risk I’ve taken with shooting at the moving target. If there is a better way of dealing with this, thats great!

Both also sounds great!

6 Likes

this is very promising, though as someone who has never liked pie menus (I have trouble forming muscle memory) I’m not too enthused on that in particular. pie menus simply aren’t for me, and with how their benefits are largely based on muscle memory and speed of access for context specifics- it doesn’t seem a wise choice to attribute user generated brushes- or anything editable to it! I do think it makes a lot of sense to make things like masks always available, though, because they are often used repeatedly, between strokes, and going back to adjust masks is a far more annoying thing than needing to switch brushes. I think if there is a wheel, it should be limited to features most any brush is usable with.

I still like this proposal, though, because I’ve felt a need for a texture browser in the asset manager! I do however think you should be able to use any texture as a brush, though. not just black and white- and I know you probably intended something like this but didn’t add any colored textures in the examples, so I thought I might speak up.
Enabling using absolutely any texture, generated or not- would enable vector displacement brushes to be selected and used as easily as normal heightmap brushes. As well, whatever replaces texture nodes would be able to be used with it, enabling procedural vector displacement brushes, which just about no other program has yet.

I’m sorry to hear that.

Well, I disagree. First of all I have a feeling that you missed the part where only Brush Sets have editable layout option. The rest of the UI, like Brush Settings are not editable. The reason why Brush Sets pie menus are editable is because you are responsible for creating your own Brush Set(s), therefore it is up to you how you want them to be displayed. I see only a benefits of that. Without edit option you will end up with brushes displayed by random or arbitrary order which is stupid.
Ideally imported Brush Sets should come with the pie-menu layout configured by their creator.

Adding mask options to the Brush Settings pie-menu shouldn’t be a problem when it comes to the design. Brush Settings are unconnected to Brush selection, so I don’t see any conflict here with having Brush Set pie-menu.

Well, thanks, but Texture Asset part wasn’t invented by me. I took it from existing Asset Browser design and impelmentation.

I agree with you here. But so far we don’t have any advanced sculpt-paint features, so I didn’t want to divert into another uncharted territories in this proposal. My focus was brush UI, not brush content. The proposed design should be flexible enough to incorporate any new sculpting/painting features by creating dedicated pie-menu or adding the features to existing ones.

1 Like

alright, I’ve taken a second, more in depth though and look about this while sort of “feeling it out” playing with sculpting (not that I have made changes, just imagining it,) and I wouldn’t be opposed to this in its entirety- so if you got the idea that I wouldn’t like it, you can ignore that- as a whole, almost all of these ideas are a definite quality-of-life improvement for sculpting, compared to what exists now.

As for the radial menus, I’ve given it more thought, and some feeling it out, and it seems I was a little misinformed about my own experience here- Radial menus are generally fine- but some of the issue is that their common implementation reverses the standard “use a hotkey then click to select” paradigm, and changes it to “move the mouse, and let go of the hotkey, it selects itself” paradigm.
Because every other menu in blender has clear edges, clicking produces a result, and mousing away cancels it, if there is a radial menu, it should obey the same rules to avoid cognitive dissonance. This means a click to select an option, clear areas that define where the menu is and is not, and therefore where moving your mouse will cancel the selection.
New users also truly benefit from static menu buttons- being aware of all the tools at their disposal, so long as their use is self-evident- that’s why the buttons are on the side of the screen in the 3D viewport in the first place! Being presented with a screen and needing to know hotkeys or which menu to access to begin doing anything is a good way to confuse newcomers- we learned that from 2.6-2.7! I don’t think the buttons for brush types need a change for that reason alone, really. If they seem to take up too much space, you can even make them clearer or smaller.


That about sums up my thoughts on the radial menus. As for the actual settings and exposure of options, I do prefer menus to simply be there on the side while I’m working… but also, I find it very important, even as a novice 3D sculptor, to have all the options available from the get-go, as noted above.
To me, this means no “beginner, intermediate, pro” distinction in the UI, even in a soft sense. The UI should always be useable and helpful to both a beginner and expert. Though an expert will likely prefer a hotkey heavy workflow, there should ideally be no feature that limits functionality or access to information, techniques, or tools. Remember- new users are rarely aware of more than one way to access a tool without some experience with it.
My first real use of blender’s sculpting, ever, (there was no realistic alternative to get the detail I needed) required me to make my own brush heightmap in an art software, and it was a weird uneven rake- and it was a wonderful experience once I did figure the menu out, thanks to tooltips. My only real frustration was that ctrl-z reset my last change when I tested the brush- but that could be a paper cut suggestion maybe?
Simply put, it wouldn’t be fair to hide away some of that functionality just because “they aren’t ready for it yet”. Limiting what a user sees also limits experimentation, curiosity, and mistakes, and therefore learning. Many users would probably prefer being able to see all the possible brush settings at once if they could, too, rather than having to scroll through a small window of large settings, close some to see others, or having more specific ones in a totally different menu. Switching to a new UI as you get more familiar with the workflow also introduces a bumpy learning curve, and often is not worth the trouble compared to a steep learning curve for a very functional UI. It makes more sense to highlight the important settings in some way, and have the very niche ones in a well-labeled dropdown or sub-menu nearby.


I’m someone who won’t add ask for new menu types without an exceptionally good reason. Brushes aren’t used outside the sculpting workflow at the moment, and cannot have an effect unless you’re using them, as far as I know. Therefore, it doesn’t make too much sense to have a different menu outside of sculpt mode handle their properties and so on.
so… the context menu makes sense! it’s just terribly laid out for something like brush settings… as we’re all aware:
2021-08-28_05-33-09_1
the primary issue is the poorly used context menu. the content reads poorly in such a claustrophobic menu, and the sliders barely have enough space unless you let it take up a lot of the screen. The menus up top, though, are actually REALLY GOOD, all things considered. everything is accessible and you can see the setting section you’re looking for without using a single button.

As for how to display brush settings, here’s my two cents, based on the brush settings up top.


I simply composited all the brush options into this image, side by side, organized by purpose. There are some missing for the texture, but overall, it’s not impossible to show it all at once, not by a longshot! Even just like this, the options themselves don’t take up half of the workspace, so it’s not altogether silly to suggest simply opening all of them at once, whatever UI may do so, I think. I know people will poke holes in this, so I’ll just remind that it’s not an actual suggestion, but more an alternate visualization of the issue, and saying “maybe we should look to make all these options available all together, rather than a bunch of small dropdowns or having a dedicated brush editor or multiple menus of some sort… or maybe a dedicated brush editor IS the place to put these, I don’t know, but there are definitely ways to expose it all to the user.”

4 Likes

Hey thanks for the mention @JuanGea (and sorry cause the delay :sweat_smile:) I guess it is cause the sculpt wheel and other crazy sculpt/paint things I made?

First of all, thanks to @silex for his time, that’s a lot work with the mockups and describing the functionalities.

I made a quick read cause I don’t have so much time currently… - sorry if I miss some point or detail - but will try to give my opinnion to some points on this proposal as good as I can!



That’s an issue disscused for ages but some people still say that is good to have replicated things, is more accesible, more options… But in reality is not a clear UI, you have many options yeah but you don’t need all that, with 2 as maximum it’s ok, otherwise the interface feels dirty and not useful.
I think the procedure should be like “destroying” everything, then think how it should be from scratch knowing that now we have way more features than in 2.80.



"Live" preview seems hard to perform.
But about non-live solutions, I’ve made some testings in the past about generating thumbnails for brushes more quickly with Python and got 2 different methods:

  1. Semi-automatic: you need to sculpt something before with the brush, then click the button and done. it generates an icon with custom properties (mesh color, bg color, label, etc).
  2. Automatic: no sculpt needed. click the button and done. It sculpts over a sphere primitive for you with a preset pattern and do the camera shot for the icon (also with custom props)… CONS: sculpting from API is limited and results depending on the brush type can be really awful and not describing the behaviour of the brush.
    imageimageimageimage
    Auto-generated Brush-thumnails (no mock-ups) all those use same pattern


I like its simplicity, the subtil smooth gradient to pop-up the settings and the point of the brush/texture context switch for the settings.

Also, tho I love you removed the radius/strength sliders from the tool header, I think that will make some people angry but… Also there is a lot of free quick-access space there that is not being used and for me is a completely waste of space, more than having not useful options there.

I would say the ideal way of doing it is a custom interface. As a reference, this experiment I made, a draggable and completely customizable tool header supporting add/remove/move(drag) actions, custom properties and inserting custom UI elements, as well as spacers and dividers for grouping:
- Drag&Drop UI: https://twitter.com/jfranmatheu/status/1270649537275793412
- +UI elements with editable properties: https://twitter.com/jfranmatheu/status/1287347037864951810

Just to be critic in something:

  • I would place the name and value above the sliders header placement is better and users can see the value without the hand overlapping the value (except hardcore mouse sculptors) plus no matter left/right handed. Or a popup on top of the knob while you move it.

  • You added 2 buttons apart from each other for changing the context between brush and texture but we really just need one toggle, also it avoids confusion of having a button that activates the existing context. I imagine something like this but with the brush/texture icons:

  • Not a big fan of sliders for things like brush radius or strength cause those are settings that you change all time and sliders are not fast nor precise enough nor have a preview of how it’s changing the size in the screen space. Tho that may be a personal thing I prefer gestures for those.



And talking of gestures, when I saw this one…

I was thinking more of gestures than having sliders in different directions which is strange. Maybe some indicators - that are highlighted based on angle - of each property to where you can move or drag whitin a safe-circular-threshold to change that setting without having to click in the specific slider knob, that way would be way faster.



I really like the idea of having those separated from the rest so tools and brushes are better splitted and group together. Nice point!



Cool thing about this is user could edit the settings and see the result in real time, including rotation, falloff, strength…
Also consintency with brush settings so all keeps unified.



I think that a brush tool should be there in the toolbar.
I just add this as a reference of the set of tools I think should be there (don’t pay attention to the widget itself just the tools):

  • Sculpt brush tool
  • Paint brush tool (sculpt vertex colors)
  • Mask tools
  • Sets tools
  • Transform tools
  • Filter tools (tools that affect the entire mesh)
  • [missing there] Annotations


YES. Completely not intuitive.
I think that brush types should not be mapped (and once brush system is unified it will have less sense to have it that way). And also that modifiers and RMB is not that well used, while they are more accesible and quick keys, rather than searching for random F key or shift-F, why not Ctrl+Alt with horizontal/vertical gestures for most used actions as changing brush size? and so on…

I would probably wait for the brush storage task design to see how brushes will finaly be managed.
https://developer.blender.org/T70412

13 Likes

I can’t comment in as much detail as I’d like right now, so I’m sorry if this is a bit short and to the point, but one point I’d love to contribute:
Don’t re-invent the wheel on things that are time-tested and researched!
This is something Blender had traditionally done quite poorly on in the pre-2.5 days, and I think we’re all reaping the benefits of leaving that behind and reaching a larger audience.

Fitt’s law, radial menus, sliders… all of this has been researched and shouldn’t be thrown out.

Some thoughts on what I’m seeing:

-A radial menu becomes less functional with every entry above 8 that you add to it. In fig.7 I see 24!
-Fig 11 shows angled sliders. What fault of regular sliders does this solve, and are any extra problems it creates worth it?
-Why do the Brush Settings ‘pie’ menus have a big icon in the middle which splits the important parts (the settings) alongside it… making users travel further? What problem does this solve that a regular rectangular menu does not?
-Not every brush can be adequately condensed into a thumbnail, so text is definitely useful to have. In the screenshots the sea of gray blobs makes it hard to see what’s what.
-You’ve removed a lot of the discoverable locations that settings live in (the topbar most of all), and hidden them behind hotkeys. While this can be desirable for power users, it’s something that stands in the way of those who are new to the program. Power Users would be in a far better place to make a small adjustment to the program to tweak it to their desire and hide the top/side bar if it helps their workflow.
Fig.13 shows a radial menu that uses North, South (two cardinal directions), and then all the intercardinal directions. The most memorable/functional directions are the cardinals, so I’d always strive to use those first.
Fig.14 uses none of the intercardinal, and instead has cardinals and then odd subdivisions. In your (muscle) memory, it’s easy to remember ‘This tool is up, this tool is to the left’, but much harder to remember 'It’s kind of up and to the left, but not fully North-West)
The more entries and therefore the less space between them, the bigger the failure rate of muscle memory ‘flicks’.

I’m loving the idea of being able to create radial menus in Blender though, and brush sets sound like they’d be great for customisation!

6 Likes

Totally agree with you here, While all those mockups look nice and dandy they don’t seem quite usable.

1 Like

Oh, now I understand your point. Don’t get me wrong I like consistency, but the thing is that pie-menu can contain very different options, some of which are to be used very fast, and some require more time for making a decision. With that I think having pie-menus with slightly different behaviour is a good thing, but it is debatable.

I agree with you, and the topbar with all advanced options is still present in my proposal, thou I didn’t put much effort in showing it fully. Look at Fig.23 (pink color).
Also I don’t think that having more lean, optional interface element (pie-menu) with the most important settings that can be accessed with a shortcut is a bad thing here. With topbar present no one force you to use pie-menus. You can rely solely on Asset Browser and topbar for choosing a brush and changing its settings.



Thanks for the feedback @jfmatheu !

Agree on that.

That I think would work the best. The drawback from fully automatic options is not worth it imho.

That would be very nice, althou Blender should be shipped with some sane defaults.

That is a very good point!

I’m not sure I’m following you here. Inside pie-menu there is only one button (bottom texture glyph). Top one is only an indicator of default brush. Probably I should have made it clearer. I think that issue is moot thou, because of what Julien wrote about abandoning the concept of default brushes.

I prefer those too. I putted those settings in pie-menu mainly for beginners.

You can discard that mockup, it is a design experiment. I even thought about another design with left and right handed versions tilted in different angles. Main point is that the most natural movement for a hand with pen and tablet is diagonal, not horizontal. So for left handed people the sliders could go from top left to bottom right, and vice-versa for right handed.
But I agree that pure gesture based solution is the best. The problem with it is that its harder to discover those functions. I think Blender should have some kind of quick helper with gestures and shortcuts layed out for specific workspaces.

Now that I think of it, yes, that makes sense.



I think that problem is going away, as Julien mentioned that there will be no distintion between default and custom brushes.
I also thought about rectangular design for brush changing, and it should be better in this example. On the other hand radial design gives you more flexibility with custom brush sets shown in Fig.3-4-5. I didn’t wanted to mix different layout shapes, so I went with circular for default brushes. Tho I agree that there are drawbacks for having too imuch items in a circle.

This isn’t only an icon. It can show you how the brush looks and behaves in real time. If you are working with more detailed brush having a big preview can be helpful. Cursor travel can be improved with moving the brush preview upwards and joining two settings parts together.

That’s why they are in Asset Browser brush section. If you have lets say 20 or 30 brushes in one brush set having text descriptions can make the pie-menu UI very crowded.

I didn’t removed the topbar!1

Look closely on Fig.23 (pink color). Hell, I explicitly included this functionality inside UX structure:

That can be solved with adding two more empty places for future dyntopo and remesh functions (8 instead of 6).

Thats the problem with random and constantly changing number of functions. I went with what you see, which is dividing circle into the number of functions required. The other way which you are describing is to design layouts based on particular subdivisions. I say both have pros and cons. For example with the second approach how would you design a radial pie menu for any odd number of items or even number that is not 2, 4, 8.

Can you describe where exactly you see an issue?

2 Likes

Your personal experience or hunch counts for less than the research that has already gone into this. A radial menu with random subdivisions serves no proven purpose that a regular menu doesn’t do equally well or better.
Don Hopkins has a lot of research on this, sadly his website is down. Here are some excerpts though: https://ux.stackexchange.com/a/154
Note the first response: Radial Menus have a poor perception because of bad implementations. This is what I’m trying to avoid!

More than 8: You wouldn’t! 12’s the accepted maximum. I haven’t seen studies on how effective a 12-slice pie is, but from personal experience I’d say it’s already less practical than 8. There’s a reason there can be a linear runoff menu at the bottom.
An odd number: simple. You start with filling the main ones (up, down, left, right), and then the ones inbetween. You decide how to logically group them.

2 Likes

Very interesting studies. Thanks!

Compliments for the mockups, they look great. Positive feedback: consider to help out on existing code projects we have to help improving UIs (asset browser, geometry nodes, etc). It’s rewarding to contribute designs to areas that are fleshed out already and will (likely) be accepted.

A radical change as you present with overlays here is not a topic we can quickly decide on. I think it’s overshooting on practical usability and it’s a big step away from core UIX concepts we use in Blender. I think it’s better to first agree on a general direction we should go to with overlays (pie menus, button panels) before going into detail as this. During the upcoming 3.x series there’s plenty of time and space for such discussion and design reviews.

I also want to see more developers/designers to join the team. We need to find people who bring in many years of experience in the 3d tools field, people who fully grasp the history of what we did (what’s good, what to improve) and develop a well supported vision where UIs in Blender will go to in the next years.

For that reason the UI module is kept on a short leash - they should first assist on existing projects and module teams, to work on generally accepted concepts, finish what’s not fully fleshed out, work on quality, do all the essential maintenance.

Thanks.

31 Likes

This concept can be easily be implemented as an addon with BGL drawing and a modal operator. However drawing images as Buttons or Menus in Panels is not feasible.

If you consider the two options that are “develop addon” or “develop in core c”, that are both experimental and time consuming, the only feasible solution is to re-use every possible existing infrastructure that Blender provides, thus you go with Pie menus or Panels (same as making custom addon though).

Plus the most important, to consider, if is really helpful to draw custom images on Operator buttons, other than setting the standard icon= parameter to use an existing internal icon.

So to recap, what can be examined:

  • Develop addon: easily done by anyone for research purposes, the most possible outcome is to consider the possibility of a BGL based GUI to emerge that it would be presented in more flexible and creative ways.

  • Develop core c: super difficult in terms of not-development.

  • Develop core c to support custom image drawing: if there are many uses cases and actual need to support such a feature, weighting the pros and cons, thus you can get Pie Menus or floating panels ( bpy.ops.wm.call_panel) with custom images that will make them look good. But the final point if actually #1 makes more sense.

4 Likes

Wow, I hadn’t seen your proposal yet, @silex . Very impressive and useful. It’s users like you who really contribute to Blender’s improvement. :+1:

6 Likes

It’s good (in docks on right). When imagine the other tools on right, next to menu after change sides (gizmo to left) then work can be more comfy and faster.
The brushes can be more easy understand with role, and adding new/own or custom can be comfy here.
The basic tools with icon on left can be as option if somebody want old style.
Maybe grouping new, or favorites can be more useful, this same “last used” list.
Not sure about implementation search by name here or filter (eg. with proposed groups), especially if many new. In plans “online brushes” as addon? Then management need more expetations.

The solution touching problem around material management from online asset addons, can be included in to this as some “template” to usage around UX/GUI. On RCS was propositions with this.

About “Fig.11 Another layout variant of custom Brush Settings pie-menu”

  • can be option to test, and after experiments user can grab new experience, this can be ok on tablets, etc. where screen can have changed orientation by angle not like on PC/Laptops. On 1st look reaction was “why”, but “maybe”…
  • this same on center… but imagine… some AR/VR solutions…

About custom parameters around brush in center… I think this sould be more “pure” as tool panel on right side GUI and next to whole menu (as ctr+t).

3 Likes

Can I see this ui/UX in version 3.1? I think the brush ui is very visual compared to the original Ui and functional role

When will this ui be available in blender?

1 Like

Blender 3.1 is well underway, i would like to ask if there has been any talk of developing discussing this further, any plans to tackle this proposal ?

1 Like

I just want to say this is such a WINNER in the mockup. This should be very much considered, if not, reconsidered. *All of the ones shown are great, but this one definitely encompasses what Blender has, and the users of Sculpt mode are already accustomed to. This just happens to appear more streamlined. Lovin it, I hope its being considered.

4 Likes

hii, tbh it looks more like a stylized Uix of a nice addon. It doesnt match with the current UI/UX of Blender. The proposal has to be more streamlined with blender’s UIX . The mockup’s UIX is good for an addon!

9 Likes

I disagree.
That does not go against Blender’s UI or UX.
That would make a great UI for a global menu in this mode.

Menus have to be in phase with the mode.
In object mode, right click menu can adjust a spot light size which is also available by gizmo.
In edit mode, right click menu is corresponding to specials of selection mode.
In currrent texture and vertex paint mode, right click menu is showing a color disk.

That is totally in phase with a new advanced sculpt&paint mode to have a right click menu showing basics of active brush and a quick way to switch to another one or go back to last one used.

That is what is represented in the mock-up that is important. Not the graphic style used by mock-up’s author.

2 Likes