2022-8-24 Sculpt/Texture/Paint Module Meeting

Practical Info

This is a weekly video chat meeting for planning and discussion of development related to the sculpting and painting in Blender. Any contributor (developer, UI/UX designer, writer, …) working on these features in Blender is welcome to join and add proposed items to the agenda.
Write us a message in the module chat if you’re interested.

For users and other interested parties, we ask to read the meeting notes instead so that the meeting can remain focused.


  • Joe Eagar
  • Bastien Montagne
  • Julian Eisel
  • Julien Kaspar
  • Daniel Bystedt


Needs Commit

None :+1:

High Prio Bugs

Still depending on D15428:

In Review

Targeted for 3.4:


Wait until next week when Dalai is back

In Progress

Nothing new on these tasks yet. Joe was primarily occupied with related patches.

To Do’s


  • Auto-masking features as high priority
  • Remaining high Prio bugs
    • Rewriting D15428 based on new design
  • Afterwards: Brush Refactor Design (Will be further discussed next week)
  • Joe will also write an overview of the features being worked on in sculpt-dev

New Tasks

Other Topics

Brush management project discussion

Julian and Bastien joined the meeting to discuss key topics of the brush management project.
They will soon have time to start work on the project so we need to prepare.

First we need to be aware of the team members.
Joe is the main developer on the project.
Dalai & Julien are responsible for the design and planning.
Julian is involved for the asset system integration.
Bastien is helping out for the override integration.
The geometry nodes team is also involved for any overlap in projects.

This and the coming week we need to define the scope and use cases to solve.
For this we should engage in daily meta level discussions and work out the design, even simple prototypes.
An Agile/Lean approach to the planning should be put in place as soon as possible.
Dalai would oversee the project but he’s unavailable until next week. We can already start without his involvement.
In two weeks we can then start the development properly.
Julian would also like to use this project to push general improvements to the asset system.

We discussed the scope of the project in broad terms and what are the highest priorities:

  • The basic brush asset implementation
    Already having a functional brush asset in the asset browser to link and switch brushes is vital.

  • The brush management process
    The design on this already started but needs to be further defined. The current designs might not even hold up for the final product.

  • Merging all brushes into a single tool with brush presets
    Any types of brushes would then be available as a list of brush presets in the brush settings.

  • Overriding preset preferences
    Since brushes are linked we need a way to override them. The implementation of overrides and the presets.blend would take care of this.

  • Brush picker in sidebar
    With the removal of brushes from the toolbar, we need a new interface to access the global brush library. A brush selector based on the pose library in the sidebar is the first step for this.

  • Brush Essentials Library
    With the first release of the brush assets we need to create an in-built “Essentials” asset library with all basic brushes. We still need to discuss if this would be a regular asset library or included in the binary in a read-only way.
    Apart from the currently existing brushes this would also include many variations of the cloth and boundary brushes. In total we expect an initial pack of up to 60-80 brushes.

Other medium priority tasks should follow afterwards. These also still need to be discussed more on their importance:

  • Brush refactor
    This project would have many benefits. It would help reduce the amount of brush types by making brush settings more universally available. It would also make cherry-picking brush settings much easier. It would also make it easy to add new features such as input curve settings.
    It would also allow much more in-depth brush authoring, but also grow the overall brush settings list.
    Since this requires extra UI reworking and would likely not break backwards compatibility with current brushes we could wait with this.

  • Cherry-Picking brushes and settings
    This would help a lot for usability in the UI. This feature would allow us to have the full, extensive list of brush settings in the properties editor, and ‘pin’ specific settings to be displayed in the sidebar and header.
    The user and developers could make use of this for authoring brush assets.
    This would also allow anyone to pick what brushes should appear in the toolbar, although how that would work or look like also needs more discussion.

  • Right click menu
    While a new brush selection design via a popup menu would help a lot to have a wider access to brushes, it’s not essential at first. We should also take our time to decide if a grid or pie menu design would fit best here. The most likely case is that we need to design a new kind of menu layout based on thumbnail grids.

  • More Essential Assets
    There is a lot of potential for assets to ship directly with Blender. These should solve common time-wasting setups and workflows.
    These could include textures, as well as textured brushes, base meshes, node groups and more.
    For this we first need to define the scope and use cases of this asset library and the size/complexity limit of individual assets. What do we consider an “Essential” asset?

  • Generating brush thumbnails
    There have been designs in the past to generate brush thumbnails and previews automatically. For sculpting brushes we are confident that this is either impossible or unwise to persue.
    To make creating thumbnails at least an easier manual process we could provide a default library of thumbnails.
    We could also let the user define the colors in a similar way to choosing collection colors. The user could even define the color palette but this needs to match the various themes of Blender.
    Another solution would be an operator to create a thumbnail from the active object, or a more complex editor to test and preview brush effects.

  • Node Editor
    While this could help in creating very complex or even completely new brush behaviours, it’s still unclear what use cases this needs to solve. The approach of its implementation is also not agreed on yet.


Initial Feedback

Really excited to see though and energy go into this. I just hope the old API code will still work to some degree. It’s curious how the brush datablock is the one and the same brush datablock already in code… which means consolidating all the settings in all the modes… this is no small coding feat. I still think you could save a tonne of time (and effort) if you keep it compartmentalized and split the brush assets per mode per object type as it is existing - both in outliner and asset browser. No need to re-invent the wheel for all brush modes. There are global brush data blocks already (and no way to tell for what mode), the modes already work and exist - so segregating the brush asset type in the asset browser per mode and object would be far less work and still a standard UX… Also, some brushes don’t translate to other modes if at all. Curve sculpt is vastly different than Object sculpt. GP sculpt is vastly different too. GP weight is vastly different than Armature weight, and Armature paint is somewhat different than Texture Paint. Etc. So… some GUI segregation might smooth things over and be much more an expectant and non-breaking UX and GUI improvement to the existing system.

Example of issue with “global” brushes

Eg. the need for identifiers.

  • A grease pencil brush has a grease pencil icon in the corner and grease pencil brush icon in outliner. If you don’t know it’s a GP brush, you won’t get expected line settings in a texture paint brush.
  • A sculpt brush has a sculpt brush icon in the corner and a sculpt brush icon in the outliner. If you don’t know it’s a sculpt brush, you won’t get the height and edge settings if you apply a grease pencil brush.
  • A weight paint brush has a weight paint icon in the corner and a weight paint brush icon in the outliner. If you don’t know it’s a weight paint brush, you won’t get the color settings you would find in a texture paint brush.
  • A texture stamp brush setting would not work with a texture paint brush setting. A brush type in the brush mode icon in the asset might also be necessary to tag and identify what brush goes where. As you can see, granularity of brush categorization is a must, specially the more complex the brush engine and mode.
  • All of these could be now be segregated datablocks in the GUI (new) or tagged datablocks (use existing brush datablocks with new API) and have them listed in outliner and file browser accordingly (if marked)
  • As you can see, storing brush sub-presets requires knowing for what goes where to have an expected UX to call and drag and drop from the asset browser.

Feedback about ideas proposed

I feel the the texture nodes editor system needs a render engine refactor and updating to be as functional as it was and would be useful for 3D space brushes and more control over custom procedural masks, mostly (current workflow is shader masks which compiles slowly with many layers and is not “paintable” till baked, think… “smart” material/texture painting…). It is useful.

With textures as assets or nodegroups from the texture node editor for the editor as assets (aka, node based brush settings also that can be chained to a brush) that is drag and droppable from the asset browser, you’d be good to go. MAYBE you can also add new “output” nodes or property override nodes to the Texture Node Editor, so the “stack” (if the prop exists in the brush and mode) in the brush settings is also overridden by the texture node editor nodegroup (like override the curve, the pressure, the color methods, etc) and can be stored as texture editor node groups (the same as GN nodegroups) - and then you’d have “global” brush settings attached to brushes, or chained to a custom brush. No need to re-invent the existing API for all the brushes and modes.

The brush asset is a must, needs to be added to the asset browser for sure… Even dragging and dropping a marked brush asset to the brush properties header, relevant tool or side panel will be great.

Removing the brushes settings from the toolbar? Maybe it’s redundency cleanup, but working full screen with this selector and settings control is really important… not a wise move to remove brush settings or selectors form header tool settings, this means full screen without the property shelf workflows will be impossible. (To test, CTRL+SPACE and fullscreen the editor and work, see if possible without property shelf showing, take note of the real estate you have to cross from brush selector to sub-brush settings selector, top left toolshelf to property shelf… is not a short trip. Specially on a widescreen.)

Auto thumbnailing would be easier with default thumbnails, good idea - and any type of autogeneration would be useful (maybe from texture used or brush blend mode and random colour)… yes… that would be nice. Shipping brush presets, yeah that would be also nice. Shipping 80-90 brushes sounds like a lot, but the default is already 80 “global” brushes. I just hope the brush system I’ve vested in with development in the custom toolshelf can be adopoted where we dynamically list each tools brushes in a panel in a custom toolshelf dynamically…

Example of working thumbnail UX with the brush panels addon we developed:

The way we handle “thumbnails” or brush iconography from an addon in another Blender fork we distribute:

  1. A brush defaults to a blend mode icon.
  2. If user adds a custom thumbnail, it will draw the thumbnail and override that icon
  3. To access the brush, we added back toolshelf panels and tabs to the Toolshelf to see iconography and also top-level access to operators and brushes.
  4. Now the brushes are top level (click and select, no hidden menu, no pie, no grid to first call then dig , no extra hotkey, no popup… just point and click) and it has visual identifiers: user custom or some default differentiation per brush preset type

The work coming:

This method above works with the existing API. Improving how a brush draws a default thumbnail in the library engine could be a great project. Working the asset browser to segregate each brush type per editor per mode per object (which is more than a handful of editors, modules, brush engines and more that would need to be refactored and worked on to make all brushes work otherwise) may be the shorter clearer less breaking route. I feel you’d have to re-write how the brush datablock would have to be read in texture paint, weight paint, vertex paint, sculpt, grease pencil sculpt, grease pencil weight, grease pencil draw and then in 3D view object variations: the hair curve object and armature object. You’d have to rework all the brush engines in all the modes and object types to be compatible, when in UX there are some brush settings that don’t translate per mode, per tool, per method per UX. As a user, how do you predict what setting is stored and translated when an expected brush is specifically built for a mode and workflow? How do you know what’s good per tool per mode per workflow? I can see this the most difficult to answer when the grease pencil brush engine needs to be compatible with the sculpt brush engine, two completely different paradigms. Even texture painting to grease pencil doesn’t translate, one is essentially a vector engine, the other is a raster engine. How do you smudge a grease pencil? You’d have to rebuild the entire greasepencil engine and brush paradigm.

It would be a HUGE engineering feat to consolidate all the brush drawing engines and global settings in all the object types, modes and brushes - and it’s not polish, it’s re-creating what’s already there and replacing what needs refinement. This may be the long route around. Starting this in master or experimental will make the project drag on, since you will have to go through all brush related modules to work together in the UX to set the ground work for brush assets! - and you all are already spread too thin for such an endevour. What about the rest of the modules you are head of? Pipeline? File Browser? Core development? Bug fixing and file I/O? The asset browser yeah… that could be finished. But yet another project on the many you’re all leads on?

The brush panel and listing at a top level with custom iconography and user overridden iconography is already doable. How we ship brushes now is the next question. How you generate brush textures and masks is the next question - or how to generate global property overrides - (big hint, the texture node editor could solve this with it’s own nodegroup category and property “output” or override node).

TLDR, feedback in list form

I would try boil it down to this to improve the texture painting UX:

  1. Brush thumbnails auto generation, yes (based on brush mode, or texture + random color or symbol signifier for unique auto iconography, or override with user thumbnail - how it draws doesn’t have to be literal, it could be symbolic)
  2. Brush segregation by mode and object type in the asset browser would be easier than re-writing all the brush engines to be compatible (instead of “all” global brushes as the same datablocks per mode, per brush - GUI segregation would solve this UX without re-writing everything)
  3. Drag and drop of brush categories from asset browser, yes, most definitely, can’t wait!
  4. Ship defaults, yes.
  5. Fullscreen access of brushes from header tool settings and property shelf, please keep important.
  6. Texture Nodes Editor, please revive it. 3D Textures and procedural masks is very useful there and the engine already is built in and useable as a UX. Shake off the dust and polish it. Don’t re-invent it.
  7. Access to brushes improvement? Think top-level. Think point and click. Anything in a pie, in a floating menu, in a floating grid, or other will require +50% more user action to use (1. call floating menu, 2. then search for brush, 3. then click) instead of search for brush and click. We addressed that with a custom top-level brush panel, that lists all brush presets in the toolshelf in a tab in a panel per brush type. It works and is a blast to work in. A pie menu still needs to be called and you save maybe 20-30% user time by saving real-estate in mouse movement and maybe 10-20% user thought on searching - but you still can’t list more brushes than 7 before being overwhelemed anyway, let alone many brush presets to toggle! - A pie useful for presets like this would be 2 layers deep and super flashy and heavy to navigate - it would solve nothing. A called grid to toggle… is still no improvement to existing methos: 1. call menu, 2. then search for brush, 3. then click, rinse and repeat to toggle a preset.

Other than the work to the asset browser integration and brush categorization,the texture node editor revival, the drag and drop of textures, texture editor nodegroups as assets, and brushes to and from the asset browser - and some auto-thumbnail generators (with symbolic iconography maybe) - everything can and has been done with existing API.

UX Goals I’d put to work:

A. Focus the brush GUI and UX improvement to be a top level access to a set of brush presets. Draw from existing examples (tabs and panels in a toolshelf), anything else is 50% more user work per brush preset selection and toggle. Be it a single click in the asset browser to toggle settings, sure. Go for it. Point and click. Ideally in a toolshelf would be better.
B. Work on a concept of using a pre-made/generated icons for a brush thumbnail, yes. We got this UX going with toolshelf brush buttons atleast, not in the brush library engine. It works as a good UX. You could work a similar concept for the brush library engine and brush thumbnail engine too.
C. Global brushes already is an existing datablock concept - but it shouldn’t be. Refine expected UX with categorization of brush types and modes. Know what preset is for what with what already exists. Reworking ALL the modes and methods to be compatible and consolidated to the one and same data block is the long painful route. Segregating the UX and brush GUI so it’s more an expected and segregated experience with datablock display and asset browser display may make it easier to know what you’re gonna get. (Work: 1. create datablock sub-category and iconography of brush types from outliner, 2. work Datablock handling of brush types by mode tag with the sub-categories 3. Work asset browser to list brush types with relevant icography - leave the other module brush code alone to get up and running and polished quickly, even for this year). Benefit: A user knows he needs sculpt brushes, he’d look for sculpt brushes and presets in the asset browser. A user knows he needs grease pencil brushes, he’s gonna look for grease pencil brushes in the outliner to mark, save, then call from asset browser. As it stands, there is no way to know which linked or appended brush is for which mode - this UX could be improved. Even if all brush settings are consolidated (which I doubt is possible per workflow paradigms) - don’t work it as it already is (it is “global” in the linking/appending paradigm already) but segregate it in the GUI without re-working all the modes and refactoring a MASSIVE chunk of the blender core code per brush type and mode, which may break backwards compatibility also.
D. Work on brush global overrides by using an existing editor (Texture Node Editor) and it’s UX paradigm so that a user could “chain” global setting overrides on brushes. (textures, properties, procedural attributes) from the texture node editor that link the same throughout all the interface, editors and modes, including geometry nodes, shaders, compositor, modifiers and more.

End goals to keep in mind:

  • Visual Reconizability of brushes in library (symbolic iconography or quick thumbnail generators) that also works in the asset browser with user custom thumbnails
  • Interoperability of brushes with asset browser and users pipelines (ship to and from files easily)
  • Top Level Access of brushes (quick and easy selection of presets in the GUI, point and click)
  • Categorization and Compartmentalization of brushes in the GUI: no-reworking a dozen modes and brush types to be the same, but work more GUI indication and segregation of existing brush types (faster development turnaround since it is mostly Outliner and Filebrowser GUI with the added benefits of a clarified and expected brush UX as required by vastly different brush workflows and pipelines in the existing software)
  • Make what exists relevant, revive the Texture Node Editor (and allow calling the output in Shaders, Brushes, Compositor and Geometry Nodes)
  • If we want global brush preset between brush types and modes that is un-invasive, this could be done with the Texture Node Editor (or “Brush Node Editor”) with “override property output” nodes set by a chained brush to the Texture Node Editor nodegroup set in the node editor and chained to a brush setting, a bit like “Use Nodes” in shaders, but for texture blocks or brush blocks. The old method was a good one.

User Case Study of why categorization is important and why the texture node editor is useful:

And also how you can have “global” presets per brush, but still categorize brushes without a massive refactor of the core architecture.

  1. I’m in grease pencil and texture based painterly project.
  2. I want a global override of my grease pencil to link to a texture paint brush settings. Since I’m using both GP and texture paint in the project.
  3. I make a node group in the Texture Node Editor with the painterly.
  4. I link both brushes to the node group from the Texture Node Editor
  5. Both brushes now inherit the nodegroups overrides.
  6. Now I want to save the node group for another project.
  7. I start a new scene, new mood. But I want a consistent setting both in GP and Texture paint, but personalized brush strokes both in texture and GP.
  8. I saved the Texture Node Group preset to the asset library.
  9. Now I can drag and drop (and link) this texture nodegroup and chain it to the two brushes in the two modes.
  10. I make GP changes to that brush for the mood, while still keeping the nodegroup settings from the node editor for consistency between brushes and looks.
  11. Now in animation, I don’t need texture paint mode, it’s all baked now - so now I just drag and drop the Grease Pencil brush asset and paint and animate fixes on the character as I animate. The Grease pencil brush is clearly easy to find in the outliner or asset browser (from icon) and the grease pencil brush drags in the linked project texture brush node group from the texture node editor too if it has overrides.
    (Just a note: the texture paint presets with overrides and brush settings I don’t want on the grease pencil vector drawing mentality - only some things translate, but not all. So keeping categorization helps the art like knowing when to use what brush or tool with what paint type. Globalizing the paint tools and “materials” for the art is like… homogenizing paint and art techniques. It won’t work. Some things do need to be consistent between methods, but each differs… Blend it!).
  12. I paint custom strokes while keeping the linked overrides “global” per the project.
  13. A TD can modifiy or improve the “painterly” look of that node group any time, and linked brushes referring to that nodegroup will all update throughout the project.

Basically, replicate the Modifier stack but for brushes with the idea of Geometry Nodes “overriding” object data. The Texture Node tab and old editor… used to do this to a degree.

Bonus note:

The texture node editor in its day was useful: 1. It had node previews, super easy to work with. 2. It allowed consistent textures in brushes, compositor, shader nodes, displacement modifiers and more from the same source - those texture/brush blocks were HANDY. 3. A method to do 3D Brush textures that was easy to make interesting shapes both for sculpting and texturing was really useful and handy (and the power of Blender texturing back in the day). It has been many years without it… and I still miss it ever since 2.8 came out - I jumped in joy seeing that some code was being worked to MAYBE revive it. Here’s hoping! It was a rough blow seeing it no-longer relevant nor usable. Now it’s more potentially useful than ever since the same texture could be used both in GN and Shader nodes at once - since the workaround is really rough to keep both systems synced on a texture basis. This also can be true in sculpting and texture painting since they are now more performant and interesting, Procedural textures for 3D brushes are more relevant than ever.

Well that took a few hours from my time this morning, back to work! Thanks for reading the feedback up to this point. Thanks again for looking at the polish for the workflow with brushes. Looking forward to see what you do with it. Can’t wait till a brush is an asset.


Thanks for the extensive response!

consolidating all the settings in all the modes

Sorry for the misunderstanding! We don’t mean with a “global brush palette” that the all brushes and settings will be globalised. We very much intend to keep the brush settings per brush type, per mode and per object type.
The global brush palette just means that you can access all brushes that belong to a mode, instead of only all brushes within a tool.

We’re also not planning to remove brush settings from the header. It’s just about letting the developers and users customise how that space is used for settings.
The toolbar should also be used to display brushes. But this is just less of a priority and likely means reworking how the toolbar works.
This means that for the initial implementation the toolbar and header will stay the way they are (Except that the brushes will no longer be accessible in the toolbar).

Making the workflows functional in full screen will also definitely be a goal.


Ah, thanks for the clarification.

(Except that the brushes will no longer be accessible in the toolbar).

Just to clarify, the toolbar is located in the header? Or the toolbar is what you would refer to as the toolshelf? If not accessible from the toolshelf… that would be a big issue.

So in essence, the tool brush presets will no-longer be accessible from the top left dropdown grid menu located in the header? If this is so, I still think this is an odd inconvenient idea (alternative UX: go to the Property Shelf on the other side of the screen in the 3D View or to another disconnect editor to change a brush setting, be it the asset browser or the properties editor, also somewhat inconvenient). This means a UX of crossing the mouse accros the entire screen to change a preset, really slow for toggling often all day every day, OR for a UX where calling exclusive hidden floating menus from hotkey is normal - which is not a discoverable workflow per GUI standards.

Will the tool presets be accessible alternatively from a dropdown or floating menu directly from the brush tool button instead? (press and hold the brush, the stored presets scroll out to select?)

… I feel some visuals may be needed on the proposal.


Will there be more brushes and intuitive layers?

1 Like

The terminology you use is a bit different. What you refer to as the “Toolshelf” is the Toolbar. The “Property Shelf” is called the Sidebar.
The brush selector in the header should ideally stay.

More discussions and mockups will follow soon.


For my part, I think the brush essentials library should be included in a read-only way so inexperienced users don’t accidentally modify the default brushes while playing around. I’ve made mistakes like that so many times when I’ve tried out new software…

Making the brush essentials read-only could also provide a way to create new custom brushes easily just by duplicating one of the read-only brushes (meaning users would have what amounts to between 60 and 80 brush templates.


It’s quite certain that the essentials would be read-only effectively, to avoid issues like the ones you mentioned, but also to avoid version conflicts as the brushes are updated in Blender.

The question was more about, should we just put the asset library into the user’s hidden config path (where we also install custom preferences, installed add-ons and such into) and assume that users won’t open the file there and edit it? Users shouldn’t have to access it (emphasis on shouldn’t, because reality is different), so that assumption may be reasonable. Or should we compile it into the Blender binary, making edits entirely impossible? The point has been raised that compiling it into the binary would make reading the asset library more complicated. However my opinion is that it’s trivial to do, the asset system is designed to have this flexibility.

1 Like

Ah ok, so now I know where the toolbar is referenced to… this here is very worrying. The pose library is not a top level access, and nothing other than a toolbar will allow top level access to brushes or to quick presets for brushes… Removing this workflow, I think, is somewhat counter intuitive for a good brush selecting UX. I’ll keep my eyes open on proposals and hope it’s point and click. Also hope there won’t need to be any refactoring of the toolbar to get the new brush preset UX in master sooner than later.




I thought that formulation was misleading, that they wanted to refactor brush access UI in toolbar, not place it in sidebar. “In the sidebar” was referring to where is displayed pose library.
But I misread it. It is in the title of paragraph, too.

I am only fine with the idea to copy this principle, in toolbar.

But instead of pose assets thumbnails, there would be brush assets thumbnails.

Current problems with pose library are related to lack of shortcuts and options in right click menu, not really access from the sidebar.

A sidebar used for brush access means that in fullscreen mode, we are forced to use Topbar, and we lost quick access to other sidebar tabs, view properties, workspace properties and add-ons buttons.
We will be forced to a permanent tab switching or renouncement to sculpt in a maximized area.

It is really annoying that toolbar is not as flexible as sidebar.
I don’t understand why it could not have tabs like sidebar.

I understand that toolbar looks cool, pretty and useful, now.
But damn, 2.5x principle of “quick access buttons in toolbar and properties in sidebar” was a good and valid principle that should have been kept.


Honestly, I’m leaning towards the idea of compiling the essentials into the binary. My feeling is that just making them read-only could lead to a situation where a new user somehow finds a way to edit them by accident, only for the files’ read-only status to make the problem hard for the beginner to fix.

Wouldn’t a simple python operator “reload standard brush library” do the job ? instead of locking these presets. This is in essence what the “load factory settings” operator does


I agree, please don’t lock any brush settings. A convenient reload defaults should work just as well.

Got to agree here. Are there any mockups or some proof of concept for this change? Seems pretty clunky, I’m ready to be convinced otherwise though. The lack of ability to easily create pie menus for brushes makes one reliant on the UI which is anything but flexible.

Also, what is the toolbar going to be populated with, if not brushes?


We are taking all of this into account. Don’t worry.

Keeping the Essential library read-only does not prevent any changes. It just means that the original state of the asset will always be preserved.
More on that design soon.

I also agree that having the brush selector in the sidebar is not the ideal solution for every workflow.
But redesigning the toolbar to house the brushes instead will take more time.
The brush selector popup also should be completely remade.
So the sidebar is the easiest short-term goal since the UI for it already exists.

We are aware that the pose library picker is currently taking too much space.
There will be more discussions on how to make the UI way more compact, while still being able to display a good amount of brushes.


The problem with the sidebar in my opinion (apart from me much preferring to have the brush menu on the left) is that it might be used for other things depending on ones workflow. Similarly to the asset browser. Having to choose between selecting brushes and whatever else one starts to use the sidebar/asset browser for would make the workflow a lot more clunky.

Just my 2 cents, but being able to customize the toolbar by just selecting/grouping the most needed brushes from a list, or having a built in way to make a pie menu for brushes (a bit like the custom menu GSOC) would be much preferred. Actually, I think I’d even prefer the current solution with a cluttered toolbar to having an asset browser in the sidebar.


The toolbar doesn’t need to be urgently redesigned for that. No point trying to display all the brushes in the toolbar.
Ideally the toolbar should become customizable, but for now all it needs is the “brush selector” to be there, instead of putting it in the sidebar.
Having brushes in the sidebar would be a massive regression in workflow, imo.