Sculpt Brush Management UI/UX [Proposal]

[silex]

Some time ago after beeing encouraged by @JosephEagar I made a proposal about Sculpt Brush UI/UX.
If this is ok, I want to repost it here for more open discussion and for posterity. I’m aware that sculpt devs have different ideas, as well I’m aware of recent Asset Browser redesign. Nevertheless I think this proposal can bring some interesting things to the table.

Link to the original document: sculpt_proposal.pdf - Google Drive

---

SCULPT/PAINT UI/UX & BRUSH MANAGEMENT
A design proposal for Sculpt/Paint Brush UI/UX and Brush Management.

Disclaimer:
I’m not a professional UI/UX designer and the following should be treated accordingly.

Sources:
https://developer.blender.org/T54642 Bastien Montagne, William Reinish, Asset Project: User Interface
https://developer.blender.org/T56744 William Reinish, Improving Brush Workflow in Blender
https://developer.blender.org/T68745 Pablo Dobarro, Sculpt mode defaults
https://developer.blender.org/T80384 Pablo Dobarro, Brush Selection Design
The Tools/Brush Workflow Julien Kaspar, The Tool/Brush Workflow

Acknowledgements:
Default colored brush icons courtesy of Albert de Arias (@wevon)

Definitions:

• Asset Browser Brush Section - section of Asset Browser dedicated to brushes, contains subsections dedicated to Sculpt, Texture Paint, Vertex Paint, Vertex Weight brushes. I couldn’t find a well defined term for this section so ‘Section’ is a temporary placeholder.
• Brush Set(s) – also known as brush preset(s) or palette(s). Brush Sets are located inside the Brush Section and its subsections inside the Asset Browser. Brush Sets contain all existing brushes. Special form of Brush Set is Default Set – in T80384 it is referred to as ‘global palette’. The only other form of Sets are custom Brush Sets which are derived from Default one.
• Custom Sets are to be created and managed by a user. When in Sculpt/Paint mode the selected Brush Set can be viewed in the viewport in a form of pie-menu that provides quick access to the brushes inside the selected Set.
• Brush Settings - All brush settings are located inside the Properties Tool tab. Advanced settings of active brush are located in the topbar. The most basic or frequently used settings of one selected brush are accessible through Brush Settings Pie-Menu which can be opened in the viewport in Sculpt/Paint mode.

Preface.

In cited sources and across various other places there are a lot of great ideas about improving brush UI in Blender made by both developers and users. Similarities in different propositions are a good design base, so I organized them into more presentable form. Main examples could be the ‘global brush palette’ described by Pablo Dobarro in T80384 which also pops up in many different forms in the mockups and comments made by others.

In addition to solving Sculpt brush selection issues I wanted to make brush UI a little more ‘meta’ and expand it into other areas. Such that with proper design and implementation it can potentially become a framework for Texture Paint, Vertex Color/Weight, or even tools in other workspaces. From a usability perspective it would be better to have one, workspace-agnostic management system that looks and feels more or less the same, and can handle brushes or brush-like functionalities for all editors/workspaces than to have multiple similar, but fundamentally different UI designs.

The biggest problem with brush UI at the moment is lack of clear vision of how brush settings should be exposed to users with different levels of skills, different needs and different peripheral hardware. Brush settings are duplicated in 4 different places in very similar visual form. RMB is underutilized and UI elements are not always tablet friendly. Other areas of UI like texture handling and keymap can also be improved significantly.

Fig.1 Brush settings replicated in 4 places.

---

Design.

With this in mind I want to propose four solutions:

I. Pie-menus for fundamental brush settings, brush selection and more.

Fig.2 Two sculpting pie-menus.

Pros:

• expandable design if new tools are developed
• don’t permanently clutter screen real estate
• easy to use for beginners
• with hit’n’drag input they can be pretty fast and intuitive
• good combo with pen and tablet
• require a lot less shortcuts than key-mapping every brush in Brush Set
• design flexibility – e.g. mixing circular and rectangular layouts
• option for user customization

Cons:

• design, implementation and maintenance difficulty (?)
• yet another tool interface
• can limit the amount of settings that are exposed to a user at once (also can be pros?)

Sculpting brushes, tools and their options can be structured inside floating menus (like pie) in various different forms. One example could be ‘Quick Access’ proposed by William Reinish in T56744. I’ve chosen 4 main categories, but this can be changed easily:

1. Brush Set - selecting a brush and manage brushes inside a Set (proposed shortcut - Ctrl + RMB):

Fig.3 Brush Set pie-menu seen as user. On the right – opened Asset Browser with Brush Section – more about this later.

Fig.4 Brush Set pie-menu with descriptions.

Fig.5 Another form of custom Brush Set pie-menu - with ‘Edit Set’ option disabled.

Fig.6 Custom Brush Set pie-menu with ‘Edit Set’ option enabled + descriptions.

Fig.7 Default Brush Set pie-menu seen as a user.

Fig.8 Default Brush Set pie-menu with descriptions.

2. Brush Settings - selected brush tool settings (proposed shortcut – RMB)

Fig.9 Default Brush Settings pie-menu.

Fig.10 Custom Brush Settings pie-menu.

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

Fig.12 Custom Brush Settings pie-menu with descriptions.

3. Dyntopo + Remesh (proposed shortcut - Shift + RMB)

Fig.13 Dyntopo + Remesh pie-menu. It includes also 4 brushes that are either used to alter topology or are bind to external factors like Multires.

4. Masks + Face Sets (proposed shortcut - Alt + RMB)

Fig.14 Masks + Face Sets pie-menu.

---

II. Asset Browser Brush Section.

Properties editor would be swapped for Asset Browser with Brush Section opened.

Fig.15 Asset Browser configured as editor with column layout.

Fig.16 Difference between Default and Custom Brush Sets inside Asset Browser.

Fig.17 Asset Browser used in a process of creation custom brushes from default ones.

Fig.18 Three different layouts of Asset Browser. Sidenote - with horizontal Asset Browser layout Brush Sets could be displayed in more space efficient form – e.g. tabs instead proposed horizontal subpanels (not showed in the mockup).

Brush Section functionality:

• store permanent set of default brushes from which custom ones could be derived
• provide visual feedback of a Brush Set and individual brushes
• select and highlight a Brush Set
• create, copy, delete, rename and individual brushes
• create, copy, delete, rename and Brush Sets
• add and remove brushes with drag’n’drop to Brush Set Pie-Menu
• collapse and expand Brush Set containers
• assign custom Brush Sets shortcuts (?)
• responsiveness for vertical and horizontal layout

---

III. Brush live-preview.

This isn’t immediately needed, but eventually it might be if the brushes are about to be presented in a clear visual form - as it was highlighted by William Reinish in T56744. Static icons are suboptimal - brush customization forces some form of identification between default and derived brush and making good individual brush icons/thumbnails is time consuming. Naming brushes alone can be too vague and is cumbersome to set up. Brush names can be useful inside Asset Browser, but pie-menus should visualize how the brush looks and works in the first place.

That said, I agree with what William and Julien said in the comments T56744, that this could be very difficult to implement, so the low hanging fruit would be focusing on the default Brush Set icons/thumbs, and maintain the ability of changing them in custom Brush Sets by brush creators. Although it would be nice to provide brush creators some guidelines on what a brush thumbnail/icon and name should look like – some templates or documentation would be a great starting point. Julien’s idea of a pre-made larger set of brush icons is also very good, and fits nicely within both Brush Section and pie-menu UI.

Fig.19 Same brush icon/thumbnail displayed in different places.

One solution that comes to my mind is solving this with normal maps. By changing Brush Settings users would in fact change properties of a b&w bitmap that is converted to a normal map projected to a shaded plane. Normal maps are lower tech compared to previewing displacement of a real 3 dimensional mesh, so maybe this can reduce development burden.

Generated thumbnails could then be cached and stored. Default Brush Set could have pre-generated thumbs that could be shipped with Blender installation. User made Brush Sets could also store their own thumbs. The only time thumbs rendering engine would kick in would be changing individual brush settings.

Fig.20 User generated normal map image used as brush preview. Voronoi should be swapped for customizable brush tip shape.

Obvious drawback of this method is that this is only a normal map and not a real geometry, so some brushes would be extremely tricky to simulate that way – e.g. Snake Hook.

---

IV. Brush textures.

I’ll skip non-sculpt/paint texture handling, as this is not the point of this design. I think brush textures when added should not be accessible through image or shader editor. They should become property of a brush and should not be treated as individual assets by Asset Browser. That can help design dedicated brush texture interface and settings. It can also help with data management so the brush texture files could be bound with brush assets more closely, so when Brush Sets are exchanged they would automatically contain all needed brush textures. Brushes inside Brush Set that have assigned texture to them could be displayed with little glyph for identification. This identification would be in Brush Settings Pie-Menu also, as shown previously:

Fig.21 Brush texture identification.

Another problem with brush textures is deciding how much texture settings should be exposed to a user. I see a design problem with putting texture settings inside the Brush Settings pie-menu. First reason for it is that this would involve importing a texture from Asset Browser and the default, planned way to do it is with drag’n’drop. That won’t do, because of the closing area Brush Settings pie-menu have – so every time the user would want to import a brush from Asset Browser the pie-menu would close.

That can be solved with a similar pie-edit button as Brush Set would have. Or by simply using texture glyph as texture add button that would open the menu. That sounds like unnecessary over-design and brings us to the second reason against this idea – Brush texture settings are already present in two places – hidden Properties editor and the topbar. Considering that the latter looks like a preferred way of accessing advanced tool settings T80384 - having them duplicated inside the pie-menu doesn’t look right.

Adding texture to a brush can be done as it is now with topbar “Texture” dropdown menu. Second option could be having second Asset Browser with Texture Section open from which user would drag texture to Brush Section. This looks cumbersome, but it doesn’t require opened and locked pie-menu to work:

Fig.22 Setting and disabling brush texture.

One possible texture-related option to have inside Brush Settings pie-menu could be quick enabling and disabling texture by hitting texture glyph as shown above.

---

Summary

1. UI Cleanup:

• Hide Properties editor in Sculpt workspace – as shown on previous mockups.
• Remove the tool tab from the ‘N’ panel (sidebar).
• Move basic brush settings to Brush Settings Pie-Menu.
• Remove brush icons from ‘T’ panel (toolbar) and leave only tools.
• Move active tool settings to topbar.

Fig.23 Cleaned toolbar panel.

2. Keymap:

Overall, the Sculpting keymap feels inconsistent and not intuitive. Personally I would wait with this until the improved keymap editor T76678 is implemented. In the meantime I’d try to do what is achievable to clean this area.

• Default keymap should be as lean as possible - this could leave room for experienced users who want to customize their interface.
• Make better use of RMB in the entire workflow as a main key for Sculpt pie-menus: Brush Set, Brush Settings, Dyntopo+Remesh, Mask+FaceSets. Reason for it aside from accessibility is that most pen tablets have a RMB equivalent option.
• Design consistency - each distinctive operation sections like: Masks, Face Sets, Trim/Hide should have it’s own shortcut prefix or key. For example Masks now use ‘I’, ‘B’, ‘M’ which is inconsistent and hard to remember.

3. UX structure:

Beginners:

• ready to use default Brush Set accessible through either a Brush Set Pie-Menu or Brush Section.
• ability to tweak selected basic brush settings through a Brush Settings Pie-Menu

Intermediate - all the above, plus:

• Brush customization with topbar settings
• customization of Brush Set layout in pie-menu and importing brushes from Brush Section
• 2 additional pie-menus, one for Dyntopo+Remesh and second one for Masks+FaceSets

Pro - all the above, plus:

• tweaking advanced Brush settings in Properties tab
• making custom brushes and Brush Sets
• custom shortcuts for Brush Sets
• custom shortcuts for most used Sculpt/Paint operations

[JuanGea]

I really like this proposal, I think @jfmatheu may have something to say too

[Cobra]

@silex

• Hide Properties editor in Sculpt workspace – as shown on previous mockups.
• Remove the tool tab from the ‘N’ panel (sidebar).

This I don’t agree with. You need the properties editor to change settings/render engines and what not, that’s why this needs to be done in either one of the sidebars & provide brush palette in another editor like the Asset brower at the bottom.
And what do you mean by Brush Set pie-menu? is it nested pie menus? because I don’t think they would agree with that.

[silex]

@Cobra

This I don’t agree with. You need the properties editor to change settings/render engines and what not, that’s why this needs to be done in either one of the sidebars & provide brush palette in another editor like the Asset brower at the bottom.

I guess that this will be reevaluated as there is plan to address better viewport <=> workspace integration: https://code.blender.org/2021/06/asset-creation-pipeline-design/
As of now the workspaces and editors are still very customisable, so the user can change proposed default settings.
Unfortunately because of design-debt cleaning this area of UI is only possible by quite radical redesign.
I’m not happy with removing Properties Editor either, but Asset Browser with Brush Sets might be more useful in sculpting workspace.

@Cobra

And what do you mean by Brush Set pie-menu? is it nested pie menus?

Brush Set pie-menu lets you quickly create, and edit Brush Sets in a visual manner. It also gives the ability to change active brush. Simply it is an interface for brush presets that are stored in Asset Browser.

@Cobra

because I don’t think they would agree with that.

I don’t understand what you mean by this.

[Kenzi]

Wow, this is a good one,
I totally agree that Blender should focus on develop and utilize the pie menu instead of just a rectangular floating menu because it take less space and easier for human body to remember the movement and pick the tools.

I think the brush settings should go like Fig.1 and replicated in top bar, property and the small floating menu that will pop out on where the mouse is pointing at (Not the big one float next to the property, because it blocks the vision so much). In the Fig 7, this is also what I agree that how the default brushes are better presented.

However, have you consider modify the existing Toolbar (wm.toolbar) into a pie menu? I think this can basically one stone two(or more) birds. Once you have the Toolbar menu done, all the Toolbar menu will display the same? (I’m not coder so I don’t know) This may decrease the difficulty of maintenance and increase the chance that they take it into a official updates.

Existing Toolbar

Turn into the style like the pie menu below, and the items of the pie menu will display the groups just like the pictures above those round corner group lists; default brushes group by its color.

For the custom brushes I agree with your approach, no comment on it.

[AlexeyAdamitsky]

This is an outstanding proposal. Seems like a huge leap in the right direction for brushes management.

[blanchsb]

I think this is well thought out and would make for a much better UX.

[silex]

I wouldn’t mix different pie-menu designs between Default and Custom Brushes.
I’m not against rectangular designs when it comes to pie-menus, but all sculpting pie menus should have same style and feel.
Its possible to structure all the brushes the way you described them, but it would need to be made across all the brushes, not the Default ones only.

[Kenzi]

I see I see,
Yeah, I agree they should be in the same style,
The style in Fig 14 is the ideal one,
in term of pie style and icon style,
I think it’s match up the simplicity and style that Blender wants.
What I’m thinking right now is the reality to make this into official updates as a default,
use the existing style maybe is the closest approach,
so I’m thinking you may want to try to mix and match the Fig14 style with the rectangular pie,
let say when expend up the pie menu,
the ring of icons are the first brush of each brush then there will be a floating rectangular lists that show in rows and columns that stand aside with the ring icons,
different kind of lists will adjust accordingly like around 5 by 5, 3 by 3, 2 by 4 etc.

I don’t know,
this is just an example that I randomly think of.
To actually make it happened is totally depending on you, I wish I know how to code so that I can help you out😓

[Limarest]

Very interesting proposal, I hope this could serve as a base for the brush management project discussions. It’s been more than a year since Pablo started talking that we need it in order to overhaul sculpting workflow, but I didn’t see it going further than that…

[JulienKaspar]

Thanks a lot for all the love and attention you put into this proposal. There’s already a lot of things in here that we were considering for the brush management.
Here are some thoughts I have on this:

I think for the sculpting/painting workspaces it will make mroe sense to show the brush selection in the sidebar (similar to the pose library) and still use the far right for the properties editor.
The full asset browser with all brushes from all modes can have it’s own dedicated workspace.

I like the pie menu centred design and that the essential brush settings and brush selection is split between different pie menus. But there might be too many conflicts with modifier keys + right click.
I think RC can be used for the brush settings and a key like B could be reserved for the brush selection pie menu.
The Dyntopo + Remesh pie menu seems unnecessary for me. This can just be part of the other 2 pies.

The division between Brush-Tools and Brushes (Colored icons and custom icons) will change. So in the end it will be just a couple or even just one Brush-Tool in the Toolbar with Brushes being saved like presets with custom icons.
So the proposal of visualising them separately will not apply.

A brush live preview will still be discussed but I think the only realistic way of implementing this would be to have a pre-configured mesh and stroke (depending on the type of brush) that is then generating a preview. This could be similar to the material preview in the material tab.
More importantly with the asset browser it should also be effortless to create custom thumbnails from the viewport.

I also think the UI needs some heavy cleanup and primarily show the most important tools and settings and the keymap needs to be streamlined to the new Tools that are available.
But with the cleaned up toolbar and the pie menus it should be effortless to work without extensive keymap use.

It’s not safe to say that the visual design of the end result will be exactly like this but in spirit this should be exactly what to aim for.

[wevon]

Music for my ears, I agree with everything you say.
You are taking your time, but you are finally on the right track. XD

On the other hand, the Silex proposal is full of good ideas and has had a great acceptance, I think it shows the need and importance of making certain changes in brush management.

[silex]

Thanks @JulienKaspar !

@JulienKaspar

I think for the sculpting/painting workspaces it will make mroe sense to show the brush selection in the sidebar (similar to the pose library) and still use the far right for the properties editor.

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.

@JulienKaspar

I think RC can be used for the brush settings and a key like B could be reserved for the brush selection pie menu.

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.

@JulienKaspar

The Dyntopo + Remesh pie menu seems unnecessary for me. This can just be part of the other 2 pies.

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.

@JulienKaspar

The division between Brush-Tools and Brushes (Colored icons and custom icons) will change. So in the end it will be just a couple or even just one Brush-Tool in the Toolbar with Brushes being saved like presets with custom icons.
So the proposal of visualising them separately will not apply.

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!

@JulienKaspar

A brush live preview will still be discussed but I think the only realistic way of implementing this would be to have a pre-configured mesh and stroke (depending on the type of brush) that is then generating a preview. This could be similar to the material preview in the material tab.
More importantly with the asset browser it should also be effortless to create custom thumbnails from the viewport.

@JulienKaspar

It’s not safe to say that the visual design of the end result will be exactly like this but in spirit this should be exactly what to aim for.

Both also sounds great!

[Nubnubbud]

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.

[silex]

@Nubnubbud

I have trouble forming muscle memory

I’m sorry to hear that.

@Nubnubbud

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!

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.

@Nubnubbud

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.

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.

@Nubnubbud

I still like this proposal, though, because I’ve felt a need for a texture browser in the asset manager!

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

@Nubnubbud

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.

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.

[Nubnubbud]

@silex

Well, I disagree. First of all … /…with the pie-menu layout configured by their creator.

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:

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

[jfmatheu]

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

@JuanGea

I really like this proposal, I think @jfmatheu may have something to say too

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!

---

---

@silex

Fig.1 Brush settings replicated in 4 places.

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.

---

---

@silex

III. Brush live-preview.

“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.
   
   Auto-generated Brush-thumnails (no mock-ups) all those use same pattern

---

---

@silex

Fig.10 Custom Brush Settings pie-menu.

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: x.com
- +UI elements with editable properties: x.com

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…

@silex

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

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.

---

---

@silex

3. Dyntopo + Remesh (proposed shortcut - Shift + RMB)

Fig.13 Dyntopo + Remesh pie-menu. It includes also 4 brushes that are either used to alter topology or are bind to external factors like Multires.

4. Masks + Face Sets (proposed shortcut - Alt + RMB)

Fig.14 Masks + Face Sets pie-menu.

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

---

---

@silex

Fig.20 User generated normal map image used as brush preview. Voronoi should be swapped for customizable brush tip shape.

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.

---

---

@silex

Fig.23 Cleaned toolbar panel.

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

---

---

@silex

Overall, the Sculpting keymap feels inconsistent and not intuitive.

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…

@silex

II. Asset Browser Brush Section.

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

[michaelknubben]

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!

[Branskugel]

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

[silex]

@Nubnubbud

[…] That about sums up my thoughts on the radial menus.

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.

@Nubnubbud

Limiting what a user sees also limits experimentation, curiosity, and mistakes, and therefore learning.

@Nubnubbud

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.

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 !

@jfmatheu

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.

Agree on that.

@jfmatheu

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

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

@jfmatheu

I would say the ideal way of doing it is a custom interface.

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

@jfmatheu

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.

That is a very good point!

@jfmatheu

You added 2 buttons apart from each other for changing the context between brush and texture

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.

@jfmatheu

Tho that may be a personal thing I prefer gestures for those.

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

@jfmatheu

I was thinking more of gestures than having sliders in different directions which is strange.

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.

@jfmatheu

I think that a brush tool should be there in the toolbar.

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

---

---

@michaelknubben

-A radial menu becomes less functional with every entry above 8 that you add to it. In fig.7 I see 24!

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.

@michaelknubben

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?

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.

@michaelknubben

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.

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.

@michaelknubben

You’ve removed a lot of the discoverable locations that settings live in (the topbar most of all)

I didn’t removed the topbar!1

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

@silex

Intermediate - all the above, plus:

• Brush customization with topbar settings
• customization of Brush Set layout in pie-menu and importing brushes from Brush Section
• 2 additional pie-menus, one for Dyntopo+Remesh and second one for Masks+FaceSets

Pro - all the above, plus:

• tweaking advanced Brush settings in Properties tab
• making custom brushes and Brush Sets
• custom shortcuts for Brush Sets
• custom shortcuts for most used Sculpt/Paint operations

@michaelknubben

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.

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

@michaelknubben

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

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.

@Branskugel

While all those mockups look nice and dandy they don’t seem quite usable.

Can you describe where exactly you see an issue?