Page MenuHome

Sculpt Brush Selection UI Design
Needs Triage, NormalPublicDESIGN

Assigned To
None
Authored By
Pablo Dobarro (pablodp606)
Wed, Sep 2, 5:03 PM
Tokens
"Love" token, awarded by vladimirzb."Burninate" token, awarded by Xlindvain."Love" token, awarded by mindinsomnia."Love" token, awarded by Brandon777."Love" token, awarded by DiogoX2."The World Burns" token, awarded by Frozen_Death_Knight."Burninate" token, awarded by DaveDeer."Party Time" token, awarded by lopoIsaac."Like" token, awarded by Anubis."Like" token, awarded by MetinSeven.

Description

This task proposes a series of changes at UI and code level to make a new brush management system for sculpt mode that is compatible with the design of the new tools.
The focus of this task is to deliver Blender with a default brush library and a usable UI for the new tools as soon as possible, task focuses only on the UI related topics and not on how brush presets are stored, imported/exported and managed. The task for that is T70412.

Remove the Tool/Brush classification in the toolbar

Currently, brushes are classified in the toolbar organized by tools, some of these tools include multiple deformation types and modes inside them that can produce effects that are not related to the functionality of the tool, which are currently not directly accessible from the UI without modifying a preset.

Sculpt Mode should only have one Brush Tool in the toolbar. This tools should make accessible all the presets of a default brush library from a single place. In order to achieve this, what we currently have as sculpt tools in the code should be called deformers, stored in a deformer_type in the brush, and they should not be directly accessible from the toolbar UI. The user will directly select brush presets with the correctly preconfigured deformer when using the Brush Tool.

For advanced users, all the deformer type and options will still be available in the properties panel, so any brush preset can be created from any other one.

The experimental sculpt vertex paint brush will also include a paint_type which includes different tools that can apply colors to the mesh. This way, by adding a SCULPT_DEFORMER_NONE and SCULPT_PAINT_NONE it will be possible to create presets that paint, deform or both at the same time, supporting all kind of combinations.

Global Brush Palette and Brush Switching

Sculpting requires changing brushes way more often than painting, and the brush variety is also more extensive, so there needs to be a fast way to switch brush presets available in the UI after merging all sculpt tools into the Brush tool.

A global brush pallets will list all brushes in the brush library, that can be called from any place in the viewport when using the Brush Tool.

On top of this, there should be a way to add brush presets directly to the toolbar (or to a new UI element that can display brush presets icon over the viewport).

Having only a global brush palette without an asset manager can be problematic for fast brush switching, as the default Blender brush library will include a lot of presets for the new tools that are not relevant in most cases (like 30 cloth brushes that are only relevant when working with cloth sculpting assets).
With the asset manager, it should be possible to include as many brushes as we consider by default organized in folders and let append them to the brush palette when they need them.

Custom Topbar

The topbar should be the main way to tweak a brush in a controllable a safe way. Now it displays radius, strength and popovers with all brush properties, which some of them are not relevant when a particular deformer is enabled. For example, when using the cloth brush, texture options are not relevant and stroke options can break the intended behavior of the simulation.

Presets should be able to define a set or properties that are exposed in the topbar, with a particular design intention and use case in mind, and hide everything else.

For example, an preset called ¨Pose Inverse Kinematics¨ should display directly in the topbar the radius (used to control the bone size) the IK segments, the smooth iterations and if it should keep the anchor point. All these options can be safely used in any combination and make sense to tweak the behavior of that particular presets in a meaningful way, without exposing directly to the user all the options of the pose deformer.

There should be a way to add the properties to the topbar for users to create their own presets, probably a right click menu with a “expose in topbar” option should work.

Smooth And Invert Modes
Currently, there are quite some brush tools that have custom deformers for invert and smooth hardcoded in the tool code. (For example, the Face Set tools deforms the mesh smoothing the face sets boundaries when using shift, the pose brush changes the transform mode when pressing Ctrl). The brush swltching system should allow to remove this hardcoded configurations, but I'm still not sure how to do it. A possible option would be to allow users to define any other preset as the inverted and smooth modes of a brush and copy to this new preset all the properties exposed in the topbar when the mode is enabled, so both modes are in sync with the modified properties.

Plan of action

  • Code refactor: Remove all ¨tool¨ references in the sculpt code, convert everything to deformers and organize them properly. For example, smooth and surface smooth are completely different deformers that don’t share any code, they can now be split for better organization).
  • Remove the toolbar UI, create a single Brush Tool.
  • Implement a global brush palette with a basic brush library. We can consider if including a full brush library by default is ok at this point.
  • Implement the new Topbar UI with a custom UI per preset.

Related Objects

Event Timeline

Can the title of the task be changed to indicate that this is about the UI for selecting and using brushes, rather than managing brushes?

In order to achieve this, what we currently have as sculpt tools in the code should be called deformers, stored in a deformer_type in the brush, and they should not be directly accessible from the toolbar UI.

What would remain in the toolbar? Would Mask and Draw Face Sets remain as brushes, and if so, does calling them "deformers" make sense?

Remove the toolbar UI, create a single Brush Tool.

I guess this does not mean removing the toolbar entirely, it would still remain but with only a handful of tools.

Pablo Dobarro (pablodp606) renamed this task from Sculpt Brush Management Design to Sculpt Brush Management UI Design.Wed, Sep 2, 5:27 PM

What would remain in the toolbar? Would Mask and Draw Face Sets remain as brushes, and if so, does calling them "deformers" make sense?

The toolbar will still have the gesture tools, transforms, annotate, filters, mask by color... This will basically merge all tools of the first block (everything that uses the paint_stroke operator and brush presets). Draw face sets and mask will also be merged into the Brush Tool.
Agree, deformer is probably not the best name, maybe we can add another property for brushes that modify "data" or find more generic name (simplify and erase displacement also fall into this category).

We can also add the ability to add brush presets directly to the toolbar, but I would say that it would be better to add a separate UI element for this which only appears when the brush tools is selected.

Pablo Dobarro (pablodp606) renamed this task from Sculpt Brush Management UI Design to Sculpt Brush Selection UI Design.Wed, Sep 2, 5:32 PM

Agree, deformer is probably not the best name, maybe we can add another property for brushes that modify "data" or find more generic name (simplify and erase displacement also fall into this category).

It's not just about the name, it's also that those brushes can't be combined with a paint tool in a single brush, and don't belong in either the deform or paint category.

I think there would need to be brush types like:

  • Sculpt / Paint
  • Mask
  • Face Sets
  • Simplify

And then for the Sculpt / Paint brush type, you can select a deform type and/or paint type.

We can also add the ability to add brush presets directly to the toolbar, but I would say that it would be better to add a separate UI element for this which only appears when the brush tools is selected.

I think adding brushes directly to the toolbar should be avoided, it makes the design fuzzy. The asset browser could show the brushes, if some users want to have them always visible? It wouldn't be an overlay in the 3D viewport, but I think it's pretty standard to do it in an asset browser, and the 3D viewport already has many overlay elements.

It's not just about the name, it's also that those brushes can't be combined with a paint tool in a single brush, and don't belong in either the deform or paint category.

In that case, it would make sense to add another enum property called something like target_data with values like TARGET_DEFORM_PAINT, TARGET_MASK, TARGET_FACE_SETS. This will help to organize the code even further because it will be possible to know which data brushes are going to change just by checking that property to use the correct undo type, mesh restore and so on, without adding checks all over the code. Then, for a brush with TARGET_DEFORM_PAINT, it can still have a deform type, subtype and paint mode.

I think adding brushes directly to the toolbar should be avoided, it makes the design fuzzy.

I also don't like the idea of adding the presets to the toolbar itself, but this will depend on how the asset browser final UI is going to look. I was imagining something like an extra menu on top of the toolbar or a bar in the bottom of the viewport. In the first case, it should not take much more space than what we currently have.
Another option could be adding this as a tab in the N panel.

About a month ago I was fiddling with this design but abandoned it.

The idea is you can drag and drop brushes into 8 slots that show up in the RMB-menu. Krita has a similar RMB-Menu for brushes, but also incorporates custom tags, so you can easily swap between entire sets of brushes e.g. sketch brushes or watercolor brushes. Might be worth looking at for inspiration if you haven't messed with Krita much.

An attempt to organize the tool bar a bit better. Not all the tools conveniently fit, though (especially recent ones).

I think it would be good consider that certain tools are available through modifiers that can be changed during work. I.e. ctrl modifier allows you to pick Mask Brush/Lasso/Box/Line, Hide Lasso/Box/Line, Trim Lasso/Box/Line, etc.,etc. Same for shift for smoothing tools and sharpening tools. Being able to use the shift version of Slide Relax with Autosmooth (much better surface smooth than current surface smooth imo), the shift version of smooth face sets boundaries, mask smoothing from the Mask Brush, Surface Smooth, and also the new intensify details setting for the Smooth Brush using alt among others with any brush would be an absolutely fantastic feature.

This way you always have access to more than one tool at a time with ways to allow you to sort these tools based on modifier keys. You have the main brushes as one tool, then shift has its own section of tools in a single list and then ctrl with the examples I gave earlier. Alt brushing could be customisable through the new brush settings UI where you can switch out effects and also allow you to change stuff like Falloff for the two modes (maybe you want a strong Falloff with regular brushing while alt brushing has very weak Falloff, for instance).

At most you would need the same number of tools as there are modifier keys on the left toolbar. Also, since you can already use modifier combinations like ctrl+shift, ctrl+alt, and more there is a lot of possibilities when designing the new system with this kind of customisation.

SavMartin added a subscriber: SavMartin.EditedSun, Sep 6, 3:36 PM

You have seen this development that is doing weeks ago??

https://twitter.com/jfranmatheu/status/1302237084191805441

You have seen this development that is doing weeks ago??

https://twitter.com/jfranmatheu/status/1302237084191805441

Oh yes!

This development feels amazing, I think @Juanfran Matheu (jfmatheu) is doing it as an addon, but having this UI for brushes in general as a native implementation would be amazing :)

Although it all started with the design of the icons for version 2.91, I would like to make a few notes about the organization of the sculpture tools.

For one thing I love the organization of xrg, grouping all the bump modeling brushes together as presets.

I think that the mask concept should be reserved for when we have layers of modeling and painting, and replace it with "frozen".

There should also be some guidelines for creating the icons, since the inset is sometimes interpreted as a rectangular projection and sometimes it means that it affects the entire mesh.

Finally, as the image shows, I would organize the brushes by function and affectation. Although functions are missing and the icons can be improved, I think it can be a good way to structure them. Perhaps the affectation could be a submode of the function.

You have seen this development that is doing weeks ago??
https://twitter.com/jfranmatheu/status/1302237084191805441

Oh yes!

This development feels amazing, I think @Juanfran Matheu (jfmatheu) is doing it as an addon, but having this UI for brushes in general as a native implementation would be amazing :)

Well If you like this kind of widget for sculpt we can work together to design - a maybe unified - one for master, in a way that it can coexist with Blender UI/UX the better, that, is, in the Blender way.
@Pablo Dobarro (pablodp606)

It is an addon but the concept could be really simple to add in C. The most mysterious thing for me is the gpu shaders in C source, cause never touched/saw that, only in python so maybe it's similar in a more abstract way, but having the glsl (for example of the color picker rectangle and ring) as I have should be easy to add with some guiding and/or exploring into that matter.

My only concern is if such interface can break the style of Blender UI making it not eligible for master, so to not waste time in developing it we should explore and design it in a Blender way that push forward the idea, that is, if it's a real interest for you into implementing that kind of widgets.

Albert (wevon) added a comment.EditedMon, Sep 14, 2:22 PM

Since the organization of the brushes is being rethought, I make a drastic proposal.