Page MenuHome

Brushes Storage
Confirmed, NormalPublicDESIGN

Assigned To
None
Authored By
William Reynish (billreynish)
Oct 1 2019, 10:05 AM
Tokens
"Love" token, awarded by Pipeliner."Love" token, awarded by tiagoffcruz."Love" token, awarded by MetinSeven."Love" token, awarded by daniellapalme."Like" token, awarded by Alumx."Love" token, awarded by jfmatheu."Like" token, awarded by Oleg."Love" token, awarded by franMarz."Like" token, awarded by knightknight."Love" token, awarded by dcvertice."100" token, awarded by Frozen_Death_Knight."Like" token, awarded by xrg."Love" token, awarded by mendio."Love" token, awarded by JulienKaspar."Love" token, awarded by Mets."Yellow Medal" token, awarded by duarteframos.

Description

In Blender, one of the core issues with brushes, is that they are currently stored inside the blend file. This is not very useful, because it puts a large burden on users to then manually save and load brushes for each project or blend file.

Instead, we would like for brushes to be stored centrally, so that they will be accessible from any blend file on the user's system.

Here's how this could work:

  • Brushes are stored in a central location, much like LookDev HDRIs
  • Adding or removing a brush will affect this central repository
  • Any local changes to a brush is not saved unless users explicitly choose to do so, otherwise any temporary change would overwrite the main brush in the repo
  • Brushes are stored as 1 brush per blend file, so it's easy to manage them and share them, but will be cached in an index for fast loading and browsing.

Note: For brushes to be more useful and work well, we will also need to;

  • Create automatic dynamic previews of the brush, so you can see the opacity, spacing, texture, falloff, and so on. Otherwise browsing brushes will largely be a guessing game
  • Have a way to see brushes for all tools, and let selecting the brush set the tool
  • Have some way for users to categorize brushes (the primitive method would be to use file system folders - a nicer way could be via the asset browser)

Open Questions:

  • Should brushes tie into the assets system somehow, and should you be able to manage them in the asset browser?

Event Timeline

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

One technical issue is how to deal with image, textures and node group datablocks used by brushes. Those could be saved along with the brush into the asset .blend file. The problem is that the Blender user interface and operators very much assume that any datablock like that is part of the current scene .blend file, not existing separate from it. So being able to edit those will require some potentially deep changes.

Should brushes tie into the assets system somehow, and should you be able to manage them in the asset browser?

I think we should try to use the asset manager to handle the saving, loading and indexing. On the UI side it's a little less obvious how this integrates in the asset browser, since the typical operations are different than most assets. There is no drag & dropping of brushes into the scene and it's also not like browsing datablocks in the current scene, since the brushes wouldn't be part of the scene at all.

The asset browser could be made to work as an alternative view of whatever brush management UI is in the tool settings, but it's probably a secondary thing and not a priority.

Are brushes stored in a single brushes.blend file, or do they use 1 brush per blend, or are they stored in a different format altogether?

This is a question for asset manager design in general. I think having individual files is better from a user point of view. Then you can easily add/remove assets with just a regular file browser or zip/unzip a subset of asset files to share. Integrating with add-ons or studio pipelines is easier when you can just point Blender to a folder and it automatically presents all .blend files in there. Managing assets can still be done from the Blender UI as well, but I don't it should be the only way. There is also nothing preventing users from saving multiple assets in one .blend file, but when you create a new brush from within Blender I think it makes most sense to save that to its own .blend file.

The main challenge is performance. We can do optimizations to make individual .blend files smaller, stripping unused DNA. Mainly what we need is to have those files indexed so they can be presented quickly in the UI, and only open the actual .blend files when you use the brush (or asset). Automatic indexing is probably fine for personal assets, for files on some network folder or a big production repository, I imagine there will be some manual refresh either by pressing a refresh button in the UI, or letting a more specific asset engine handle it.

@William Reynish (billreynish) We want to make a cleaning of the Grease Pencil brush settings, because now some of them are obsolete with the new function. I think you could add a subtask for this.

EDIT: As this is more specific to Grease Pencil, we will keep this new task separated in GPencil module.

One of the problems that I see in the brush system is that when you have hundreds of brushes, you must to fight with this textures in any context. Making the use of the texture field menu difficult in simple projects.

@Brecht Van Lommel (brecht) Why not simply write them as xml instead of inside a blend file ?

Because writing them as .blend files is much simpler, as we can reuse all our existing infrastructure and not have to maintain two separate code paths for storing asset like data.

Untagging design tasks from specific releases, in general these should only be tagged with the relevant modules and listed on the module page.

The asset manager can be added as a python addon since most required functionality already exists. I created a sample brush manager to get a better idea on doing this: https://github.com/Kinthamen/blender_brush_manager. I do like the idea of creating every brush as a single blend, but with the same approach we can also make them as a pack.

Brush management should become a part of the asset manager. So I looked at this design again and together with @Julien Kaspar (JulienKaspar) came up with an updated version. It needs to be evaluated, some aspects I'm not entirely sure about.
The following is a quick/rough writeup and can be presented better.

Brushes as assets:

  • Brushes can be stored as user assets (i.e. in a user asset repository, not a project repository), for easy re-use.
  • Creating a brush asset from a local brush is an explicit action, e.g. a "Create Brush Asset" operator or a drag action to the Asset Browser.
  • These assets act more as presets. You wouldn't typically link but append them to allow local changes.
  • Maybe a brush asset should be called "Brush Preset"? Makes behavior more clear.
  • All brush preset from the user library could be added to the current .blend on file load (may not be such a great idea for non-sculpt paint modes though).
  • A brush keeps some kind of reference to the preset/asset it was created from (e.g. UUID, filepath + ID name, etc.). That way operators like "Reset Brush" still work.
  • If the reference gets lost (e.g. the brush asset is deleted) the local copy stays intact.

GUI:

  • The Asset Browser shows the brush presets. Elsewhere (e.g. in the tool settings UI) only local brushes are shown.
  • Showing brushes for a tool on hold (picture below) wouldn't be used much in practice, but helps communicating the tool->brush relation.
  • Real brush previews help understanding differences between assets and the local version of it.

Interaction:

  • Activating a brush from the asset browser means: Blender adds a copy of the brush preset and sets it as active.
  • Single click could generally select an asset, double-click always adds it to the file and "activates" it if context makes clear what that means (e.g. ensure local brush from preset and activate it if in a paint mode).

Loading Brushes:

  • When loading a .blend, new brushes from the asset library are added. Existing brushes are not touched!
  • Tools needed to simply delete, remap (add a reference to an asset) or reset multiple brushes (especially to transition old files to the new brush assets).
  • Maybe not all brush assets should be added by default, only a sub-set? (option of the asset).

Factory Startup Brushes:
These are the existing default brushes.

  • Factory startup brushes are read-only.
  • Saving changes to factory startup brush creates new asset, hides factory startup one.
  • Operator to add new brush from factory startup brushes ("New Brush").

Food for thought:

  • If the Asset Browser could also display local assets, there's no need for a separate Brush selection UI for local brushes.

It seems a complex system for something that should be simple from the user's perspective.

@Julian Eisel (Severin), that's quite different than the proposal in the task description, where brushes would not be saved in regular .blend files at all, and creating a brush asset is not an explicit action.

Any time you have a system where you have to synchronize between two sets of data (local and global brushes in this case), there's a lot of potential for failures and usability issues. So what is the motivation behind doing this, is it really important to be able to have different sets of brushes in different .blend files, rather than a global library (which might still support organizing brushes into categories in some way)?

Some notes

GUI
I won't rely on anything that uses auto generated thumbnails for the UI for now. The reason is that the generation of the thumbnails heavily depends on the brush input code (the code that generates the input samples). That already has a lot of limitations and I want to improve it in the future, so until the design for it is final I would not spend time on preview generation.

Regarding sculpt brushes, generating the thumbnails automatically is just impossible. We can't make a code that can generate a meaningful preview automatically for all modes and options of the pose, cloth or elastic deform brushes, taking into account all mask, face sets and topology combinations. These images need to be created manually.

Also, we need to consider that sculpting has different necessities than painting when it comes to brush searching and switching. When you are using a sculpting software you change brushes way more often than when painting (when you can basically make an entire artwork just with 3 brushes). An UI for managing brushes consisting in folder, categories and dropdowns that require multiple clicks to get to specific brush won't work for sculpting. If we want to have this for organizing all the content of the library that is fine, but then there should be an alternative UI to switch brushes while working.

Factory Startup Brushes
There I would make a distinction between the default settings that are needed for a tool to work and the brushes we can include with Blender as part of a "standard library".
For example, the deformation code of Clay Strips needs certain defaults to have a specific value in order to do something (just to be able to deform the mesh, not to create any meaningful effect). This is what it is currently hardcoded and it should be the values Blender uses when there is no brush preset available for this deformation mode. Then, as part of the standard library we can include the properly designed brushes that share this same deformation code (Clay strips square, clay strips round...) which is what users are intended to use. I'm still not sure how managing a standard library of assets like this to include with Blender is going to be handled.

Internally I do not know what limitations there are, but I completely agree with Pablo Dobarro.

Thumbnails cannot work with systems like sculpt that simply cannot be represented in this way. The same goes for color mixing brushes, which cannot be shown with a thumbnail. For example, let's imagine that the user wants to have a preset that is only different from the line instead of the normal one. That can't be shown easily by the system without adding a lot of conditionals.

And regarding the way to manage the brushes, I don't understand why a system where the user only wants to have access to the brush presets is so complicated. The "tools" part is unnecessary, with showing standard presets that match those tools you get the same thing.

@Brecht Van Lommel (brecht), yes this is the biggest design decision I'm unsure about. The reason to have a local list of brushes is twofold:

  • We want to allow local edits that don't affect the brush library (say changing a brush size or using a scene texture), so there needs to be some local version of brushes anyway (https://code.blender.org/2020/03/feb-2020-ui-workshop/).
  • Julien said he'd find it important that you can have brushes just for the current file, that do not become part of the global library.

For the UI side I'd be happy to drop this design. We wouldn't have to expose two brush selection UIs then (one local, one for assets).

We could make it so only the active brush is truly local (allowing edits) and switching brushes looses these settings as long as they are not explicitly saved as new brush asset.
It seems like some other apps do this, but I may be totally wrong here.


Some notes

GUI
I won't rely on anything that uses auto generated thumbnails for the UI for now. The reason is that the generation of the thumbnails heavily depends on the brush input code (the code that generates the input samples). That already has a lot of limitations and I want to improve it in the future, so until the design for it is final I would not spend time on preview generation.

That's fine, my plan wasn't to start working on this now anyway. This is more to have a general design to discuss, something we'd like to have eventually.
(I was also hoping we could work on some things collaboratively, I have plenty of stuff to work on for the asset manager itself.)

Regarding sculpt brushes, generating the thumbnails automatically is just impossible.

Yes. I was thinking about ways to support custom thumbnails for cases where the default way isn't enough (e.g. default way of capturing object thumbnails). But for sculpting that would be the rule, not the exception I think. In that case we shouldn't even attempt it I think.

An UI for managing brushes consisting in folder, categories and dropdowns that require multiple clicks to get to specific brush won't work for sculpting. If we want to have this for organizing all the content of the library that is fine, but then there should be an alternative UI to switch brushes while working.

Yes, I'd expect the UI to select brushes would be a flat list by default, no directories or such. Of course if you want to use categories or tags for filtering that can be an option.

If we drop the idea of a local brush list, there could just be the asset manager with all your brushes visible as a flat list in a workspace. You'd use it to change brushes.

Factory Startup Brushes
There I would make a distinction between the default settings that are needed for a tool to work and the brushes we can include with Blender as part of a "standard library".

Right what I'm referring to are the default brushes with the settings needed for a tool to work. Further "standard library" brushes is a separate thing in my mind. We may only provide these with a separate download (or not...).


It seems a complex system for something that should be simple from the user's perspective.

Intention of my notes is not to explain the workflow but to describe the entire design. There's more to a design than just what the user sees in common usage. E.g. Google "UI Design Iceberg".
The resulting system should be simple to use.

I also find ok the idea of having a local list of brushes per blend file and an asset browser to load them to the local list

We could make it so only the active brush is truly local (allowing edits) and switching brushes looses these settings as long as they are not explicitly saved as new brush asset.

I also think it should work this way, except maybe for some properties like radius and strength that could be saved automatically to the local copy.

Further "standard library" brushes is a separate thing in my mind. We may only provide these with a separate download (or not...).

This is what is concerning me the most right now. The problem is that most sculpt tools don't work in a meaningful way without a specific brush preset. With the current tool/brush design, the default brush for a tool can only be reset to a single preset and that is what is included with Blender in a release, using the toolbar as a replacement for a brush management and switching system. Without a way to include an standard library, almost all functionality designed for the tools is hidden under combinations of 10 brush settings that is impossible to know unless you read it in the description of a patch.

As someone who has been more of a 2D digital artist than a 3D artist, there are certain criteria I have come to expect out of any brush management system. Things such as:

  1. The brushes need to be global. Having different brushes available for each project makes brush management a nightmare where even the slightest change in brushes can make work consistency from project to project be very hard to maintain.
  1. The brushes need to be capable of being sorted and categorised into a comprehensive list. When everything is global, you need to be able to sort them properly with names, custom ordering with draggable brushes, group folders to put specific brushes in, etc. Having the brushes as separate tools may work in some cases, but a global list where everything is in place is the most ideal workflow.
  1. The brushes need to be easily sharable by having a single file format that you can save all your brushes in. This is to ensure that you can move from one computer to the next and you will always have your brush collection available in one piece with little to no hiccups. It would also open up for better community assets where users can even sell their more advanced brush collections if they have hand tailored everything for more professional work (i.e. high quality texture packages).
  1. It should be possible to load multiple brush files as mentioned in point 3 and have a list of different brush lists. You don't want to mix multiple lists of brushes with each other if you don't want to. Especially if you happen to use licensed brushes from other creators which you bought and don't want to mix with your free and unlicensed brush packages.
  1. The amount of brush tools need to be kept to a minimum with an emphasis on using this previously mentioned list. This is to make sure that the left side toolbar isn't completely full of brush tool icons, thus leaving room for other tools that aren't necessarily brushes. Of course some exceptions could be made (i.e. masking brushes and face set brushes don't need to be in the same global list as sculpting and grab type brushes), but for the most part brushes should only have one icon on the toolbar and a single global list.
  1. The list needs to have some visual indicators of what type of settings they use. I.e. texture nozzles, brush spacing, custom symmetry activated in x, y, and z-axis, brush size, Autosmooth, Hardness, Falloff, etc. Of course some may be harder to pull off than others, but at least some better UX in this department would do a lot to make brush management clearer.

These are the criteria I consider to be a solid brush management system. Based on some of the latest suggestions, I can see that the design still insists on using multiple brush tool icons on the toolbar, which is not really solving the problem of brushes being all over the place with no global brush list. You can still use the current icons as a way to group some brushes into a list system, but you need to move away from having too many brush tools when you only need a couple of them at best with an easy to use list with advanced features to back those brush tools up.

I most emphatically agree with Kenn. Categorizing brushes by tool only makes a certain sense from a programmer perspective. For the sculptor, the brush is the first class citizen, not the tool, and users ought to be able to group and categorize their brushes freely.

Given the number of new tools added recently to sculpt mode, I reckon it'd make sense to only have a single "brush" tool, and have all brushes be accessible from there.

Something I don't see mentioned here is IMO a big problem with Blender's current brush implementation... Stencils!

In my own projects, I tend to save lots of stencil brushes, because otherwise I would have to re-scale the stencil texture every time I open it, since they all have different aspect ratios. It would be wonderful if stencil textures were dealt with a little differently than other textures, so their scale/rotation could be associated with the texture itself than with the brush. If you have a lot of stencils and you want them all to use the same brush, you either have to use the one brush and deal with the cumbersome UI for loading textures (scroll down and open the menu, click "new texture", click the Fake User button, open the properties panel and load the texture, then Reset Transform then Image Aspect then finally reset the scaling and rotation to a correct value... also, if the image was flipped by scaling x or y to -1, Image Aspect fails, adding another step. Finally.... naming things.) or load them all up before hand and set them up in advance and hope you don't need to change a brush setting later.

Basically, the UI/UX for stencils makes it necesary to have lots and lots of stencil brushes. For me this is a huge papercut. But I'm not trying to sneak in a feature request here... for the purpose of this design task I think it would be a potential problem, since stencil brushes might greatly outnumber the other brushes (since you may have multiple versions of each stencil with different alphas for instance). Furthermore, saving many stencils to different presets keeps them from sharing settings, even if this is desired. The artist must choose to have the stencil's transform information in the preset, or the common brush settings the stencils are meant to share. There isn't a way of preserving both. But brush presets should have both!

For texture brushes in general... I wonder if it would be good to have brush preset templates they can "inherit" settings from and only the texture settings are modified? Then the artist can change the parent template and all the texture presets would adapt. Another possible solution is to save brushes and textures in separate files, and textures would just be image datablocks with special metadata for how they are mapped in brushes as stencils or what-have-you. The artist' UI when loading brushes may be somethng like "load brush with texture" and first the artists would choose a brush, then a separate file browser would oepn with textures and the artist could choose all the needed textures. And while working, choosing textures would be temporary settings that don't modify the brush itself. Choosing the texture datablock from the database would automatically supply the brush with the mapping information when loaded.

Does this make sense? Anyone else had this experience?
Thanks :)

@Joseph Brandenburg (TheAngerSpecialist), that's off-topic here, please use this task only for discussion of brush management.

@Brecht Van Lommel (brecht), yes this is the biggest design decision I'm unsure about. The reason to have a local list of brushes is twofold:

This is true, but my concern is more about adding/removing/loading brushes. Allowing local edits to the strength or texture is simpler. The task description mentions that such local edits to brushes would need to be saved manually to the global brush library if desired. We also have some scene level settings already, like unified radius, stencil masks (in texture paint mode), etc. These would always remain local.

When you add a brush, I think by default it should be globally available regardless of the .blend file. If you open another .blend and now need to do some explicit step to import that brush or do some kind of syncing, that seems like adding too much burden to the user.

  • Julien said he'd find it important that you can have brushes just for the current file, that do not become part of the global library.

If this is really important, it could be an additional feature. When you add a brush you could have the option to add it local, but by default it wouldn't be. And the first implementation of brush management wouldn't need to support local brushes.

We could make it so only the active brush is truly local (allowing edits) and switching brushes looses these settings as long as they are not explicitly saved as new brush asset.
It seems like some other apps do this, but I may be totally wrong here.

I'm not sure just the active brush would need to keep the settings? To me it seems convenient to be able to change settings on all brushes and not lose them when you switch between brushes. But such changes would not be saved back to the global brush library automatically, it would be a manual step if you want to modify the global brushes.

Factory Startup Brushes
There I would make a distinction between the default settings that are needed for a tool to work and the brushes we can include with Blender as part of a "standard library".

I'm not sure which distinction this refers to. Tools would have default settings, and then we also ship a set of default brushes with Blender, many of which will be the same tool with different settings? As far as brush management goes, I imagine we'd still ship just a single library of default brushes with Blender?

Right what I'm referring to are the default brushes with the settings needed for a tool to work. Further "standard library" brushes is a separate thing in my mind. We may only provide these with a separate download (or not...).

We can ship a good set of default brushes with Blender, and 3rd parties can then provide additional brush packs. I don't see why we'd provide additional downloads?

I also find ok the idea of having a local list of brushes per blend file and an asset browser to load them to the local list

...

We could make it so only the active brush is truly local (allowing edits) and switching brushes looses these settings as long as they are not explicitly saved as new brush asset.

I also think it should work this way, except maybe for some properties like radius and strength that could be saved automatically to the local copy.

I'm not sure I understand, these seem like two very different approaches. You find both of them ok and don't have a strong preference?

I'm not sure I understand, these seem like two very different approaches. You find both of them ok and don't have a strong preference?

I thought they were referring to the same thing. What I understood is that there will be global repository of brushes in the asset manager, when you select a brush from there, it is copied to a local list of brushes in the blend file in order to use it. Modifications in this local copy are never saved unless the modified copy is saved to the global repository in the asset manager. On top of this, we can make an exception and automatically save strength and radius to the local copy.

I thought they were referring to the same thing. What I understood is that there will be global repository of brushes in the asset manager, when you select a brush from there, it is copied to a local list of brushes in the blend file in order to use it. Modifications in this local copy are never saved unless the modified copy is saved to the global repository in the asset manager. On top of this, we can make an exception and automatically save strength and radius to the local copy.

So you would have global brush settings, per .blend brush settings, and per session brush settings? Just two levels is already rather tricky to create a predictable UI for, three levels seems excessive.

So you would have global brush settings, per .blend brush settings, and per session brush settings? Just two levels is already rather tricky to create a predictable UI for, three levels seems excessive.

I'm thinking about something like this:

  • You load a brush from the global repository into the session. All brushes in the session are saved in the blend file with the references to the copy in the global repository. Modifications to brushes in the session are not saved and they are always reset to the repository copy if it exists.
  • If you modify and save a brush that is in the session, a duplicate is created without a copy in the repository. This brush is also saved in the blend file.
  • Then you have the option to store these modified brushes in the repository to be used from another sessions.
  • Then you have the option to store these modified brushes in the repository to be used from another sessions.

Hi,
I can't see the benefit of this speaking on terms of UX. Is that user has to press a button each time you change someting in any brush to be able to use it in other blend files...?

My point of view is quite more simple:

  • You have your library of brushes, independant from any .blend file. (thinking of it as a cloud)
  • You have your loaded brushes with tangible settings that are shared across ALL of your .blend files.

This way:

  • Changes affects all projects so no need to save and save all the time.
  • You still have a copy of the original brush from where you can reset or update to match the actual changes.

So basically:
'Cloud' Library:

  • Acts as an immutable copy of the brushes that store their original settings.
  • Blend files can access to it to: 1, 'load default brush' config and replace or load brushes that are not currently loaded; 2, 'save as default brush' to save changes or store brush if it's a new one.

'Shared' Lib:

  • Stores modified settings shared across .blend files.
  • Blend files load data from it on startup, that means is not live sync between blend files so you can still have some short of per session settings.

Just in case that per project settings is a MUST NEED, that's quite easy, with some unlink option so you can say to Blender "hey, don't update this brush from shared library on startup".

This approach along with the ability to import/export brush packs to the library and save/load configuration presets from your blend files shared config.
As well as the ability to sort by categories. Very important in my opinion.

I hope this is helpful for you.

Im agreeing with @Kenn Nyström (Frozen_Death_Knight)

Speaking from an Artist level:
Krita has a good approach even-tough its a 2d software.

--A global brushpalette--
with some good brushes like @Brecht Van Lommel (brecht) said, the opportunity to download several more brushes
and if even required to create new brushes from existing by tweaking values.
Also an interesting approach is if you change a brush its stored with its temporal changes till you switch it then it will be default again.

I don't know if it makes sense to store brushes locally (how would it be displayed without a mess like right click to expand some sections like @Julian Eisel (Severin) ´s mockup?
would the local brushes need an indicator (symbol) to identify its a local brush?
Could it be converted to a global brush?

Maybe we could link the local brush approach with the asset manager somehow so if you need a special brush just drop it in your file. (And you could easily control your default brushes that you need without re-importing it every time.??)

Maybe there could be another call for content for brushes but its out of scope in this discussion.

I don't know about everyone else, but I would hate it if I made modifications to a brush, switched to another brush, and then found all my modifications gone when I switched back to the first brush.
I like the idea of a global brush palette and having an easy way to save a custom brush to it, I just don't think any modifications of a brush should be reset until blender is closed (then it can be reset). And, just to be clear, I don't think the brush should be saved with a blend file or when you save a blend file, I think there should be a "save brush" button.

Just my two cents.

I would like to add to my previous comment regarding point 4. Another reason that having a list for your brush list sets on top the regular global brush list is because it allows Blender to have its own default brush packages which can be constantly tinkered with by the developers without necessarily affecting personal brush lists. That way you can always guarantee a certain level of standard from version to version and more advanced users will be more happy with their custom sets of brushes.

Also, I forgot to mention that you should be allowed to copy brushes from one set to another to make management even easier. Just a common and expected feature based on several art programs I have used over the years.

Here's a proposal with a different approach. Based on my Asset Browser work and a bunch of conversations with Julien Kasper.


Asset Browser Design

Some key points on the core Asset Browser design are:

  • We build an asset browser, not an asset manager.
  • For the first milestone, the user will be the asset manager (e.g. Blender doesn't automatically edit asset repositories, store brushes, decide how many assets per .blend, etc.).
    • Assets are created for the current .blend file only.
    • Later on we can add ways to add an asset to a different repository/.blend. But this is an additional feature that we don't depend on right now. Let's call this feature Add Asset to Existing Repository for now.
  • In the Preferences, users can set up custom asset repositories (a single .blend or directory with .blend's). This makes the repository's assets globally available via the Asset Browser.
  • Smart Filters (presets of filter settings) can be stored to select a sub-set of assets of a certain type. E.g. "textures with dirt tag".

Obviously this is a design with limitations, because we try to capture the essence before adding "handy" features.


Storing Brushes
  • Creating a new brush would always create a brush as asset.
  • For the start, a brush asset will be created for the current .blend file only, like other assets.
    • To re-use it, the .blend or its parent directory has to be added to the custom asset repositories in the Preferences.
    • This isn't very convenient yet, but aligns well with the Asset Browser project.
  • Later, once the Add Asset to Existing Repository feature is added, brushes can by default be stored in a global brush repository (one brush per .blend file or not).

Again, let me be clear: I know this isn't very convenient yet! It's a first, reasonable step that should allow us to manage the brush and asset projects better.

Selecting Brushes
  • There's a single local brush: The active one.
  • Selecting a brush asset (e.g. from the Asset Browser) copies its settings to the active one. So brush assets are essentially presets.
  • Some brush settings can be global and do not change when switching brushes (size, hardness, ...). The user can add more as needed.
  • The Asset Browser lists all brushes from an asset repository. Possibly 100s of brushes.
  • Using Smart Filters, users can organize them into smaller groups.
    • There could be features to make creating these very efficient.
  • In the tool-settings, users can select a sub-set of all brushes by selecting a Smart Filter. The UI could look something like this:
    Note the drop-down at the top, which would be the Smart Filter selector.
  • An even smaller sub-set of brushes could be assigned to Quick Access Slots to make them faster to access. E.g. via shortcuts, or a right-click popup à la sculpt-wheel Add-on:

So there are three levels of brush access:

  • Asset Browser: May be 100s of brushes
  • Tool Settings: Smaller sub-sets defined with Smart Filters
  • Quick access menus/shortcuts: Small list of favorite brushes.

Vague points needing more thoughts:

  • How exactly are brushes assigned to Quick Access Slots?
  • What role plays the toolbar in the brush selection?

There's still the big question of: What is a brush exactly? How does it relate to tools? If we want to continue with this proposal, we can figure out appropriate solutions (the designs really depend on each other).

Ideally, brush management and the definition of what a brush is are done well enough, that users don't often change brush settings other than the usual ones (size, hardness, ...) which are global by default. If brush presets override any un-saved changes, that may not be a big deal because it rarely ever happens.

Note that the design I have in mind for Pose Libraries is quite similar.

I will not go into the part of how to manage the data of the brushes. But regarding the idea of the list of brushes and other ideas of UI I see a quite fundamental problem. It is mixing tool with tool list. It is not the same and users are not interested in having both things mixed in the same panel.

I know that the most photo-shop lovers are not able to come up with an interface without a list like photoshop. But when you are sculpting you are not interested in the importance of your work, the settings of the tool, it is hidden under an infinite list of thumbnails that only work when you paint textures. And that are ineffective when you are sculpting.

The thumbnail list or menu of brushes must be independent of the tool settings. If anything it can be called as it was in blender 2.79.

About quick access... some time ago I proposed a similar menu to unify activetools menu, sculpt menu and others. Let it be similar in design and work the same everywhere. Without being the Q menu.

In the Preferences, users can set up custom asset repositories (a single .blend or directory with .blend's). This makes the repository's assets globally available via the Asset Browser.

In this case, I guess that a possible solution to include a default library would be to include in Blender a function that generates a blend file with all the brushes for the default library included. That way changes in the library an in the deformation code of the brushes can always be in sync in a single commit (like it happens now). If this can be done this way, then this seems ok.

Smart Filters (presets of filter settings) can be stored to select a sub-set of assets of a certain type. E.g. "textures with dirt tag".

Depending on how the UI of the asset browser will look like, I would not consider the smart filter functionality as part of the initial milestone (but it is nice to have later). If the UI of the asset browser is simple enough and it supports folders, that should be ok to cover most of the use cases in an initial version.

Some brush settings can be global and do not change when switching brushes (size, hardness, ...). The user can add more as needed.

I would not add the ability to add more properties to be global. Currently, the only property in sculpt mode that is more or less supported to be global is radius. Strength, even if it is already implemented to be global, its effect on the behavior of the brushes varies too much between different tools, so it is not really useful. Most of the properties that are shared fall into this category, and the rest are specific to a particular brush.

Also, when you select a brush and change one of its non-global settings, when you switch to another one, those changes are lost, right?

How exactly are brushes assigned to Quick Access Slots

For the quick access slots I was thinking in a static menu were you can add brushes from the asset browser with a right click menu (or something similar) and a dynamic menu that shows the most recently used brushes.

What role plays the toolbar in the brush selection?

Nothing. The toolbar should only be used to select the brush tool. We may want to add the brushes in Quick Access to a separate UI widget that is the same place as the toolbar (or in the bottom of the screen), to have them always accessible, in order to have something similar to the current design.

There's still the big question of: What is a brush exactly? How does it relate to tools?

To me, brushes are all tools that are executed with the paint_stroke operator, which are intended to create a continuous effect in one specific area of the mesh defined by the cursor. For example, the filters are not brushes because they modify the entire object without taking the cursor position into account. Trimming tools are not brushes because they just run a single operation when the tool is executed.

Once this is in place, we can have a similar system to create presets for the filter and the gesture tools and unify them, which will allow us to have just one brush tool, a filter tool and a gesture tool in the toolbar, and the rest of the functionality managed via presets in the asset browser.

Ideally, brush management and the definition of what a brush is are done well enough, that users don't often change brush settings other than the usual ones

As part of this project (more details in T80384), my idea was to let users decide the "main" properties for a preset, which will be exposed in the top bar. These properties are intended to be changed, so it would be nice that its changes can be preserved when switching presets.

I'm fine with the idea of the available list of brushes being the ones that are in the asset repositories, and having their storage managed by the asset manager.

For this feature to be ready for release, I think that being able to create and manage brushes is a requirement. Otherwise the system will be almost very hard to use with reading docs. In terms of milestones for development it doesn't all need to be there immediately, but I would not release it without that.

There is no mention of default brushes shipped with Blender. I assume this would be another repository that is enabled by default. There is the question of how to edit or delete such brushes, though this is a general asset manager question.

Smart filters would be useful for the asset browser in general, but I'm not sure I would make that a requirement. If they're already there by the time work on this starts, then we might as well use them.

So there are three levels of brush access:

Asset Browser: May be 100s of brushes
Tool Settings: Smaller sub-sets defined with Smart Filters
Quick access menus/shortcuts: Small list of favorite brushes.

I'm not sure that the number of brushes and smart filters are really what set the asset browser and tool settings apart. Whatever filter or folder system there is can work in both, and both should also be able to show the complete list of brushes or just a subset?

To me the distinction would be that one is an asset browser with many options, and is an editor you can give a permanent place in the UI. For the tool settings or shortcut you have a popup that is streamlined and quick to use. I think this would be a general principle in the asset system, there's the asset browser where you have all the details, but you can also have popups in particular contexts to quickly pick a brush, material, node group, .. without having to open an editor. And those kinds of popups could be based on search and smarter filters.

I'm not sure there is a need to have a list of brushes show in the properties editor tool settings. It seems redundant with the asset browser, and too small a space. Especially with the mockup with previews that are so big only a handful of brushes can be shown.

Ideally, brush management and the definition of what a brush is are done well enough, that users don't often change brush settings other than the usual ones (size, hardness, ...) which are global by default. If brush presets override any un-saved changes, that may not be a big deal because it rarely ever happens.

If un-saved changes get overwritten then this system punishes users for experimenting. e.g. "I want to try with these temporary settings" and scribble for a bit, then compare to a different tool and scribble a bit, then switch back. The act of flipping back and forth for A/B comparison lets someone get a feel for whether a given set of settings are working acceptably before they decide to commit those settings into a preset. Well in this new design now someone wouldn't be able to 'switch back' because they aren't switching between two different tools, those settings would have been overwritten the moment the second preset was loaded. In effect this would destroy entire workflows. The workaround would be that every small change would have to be saved into a preset that clutters up the repository/browser in order to prevent loss, and later these "temporary" presets would have to be cleaned up and removed. That would introduce lots of overhead work for the user.

This is why other programs have multiple tools instead of 'one tool to rule them all.' Each tool has its own persistence and changes in one tool have no effect on another tool. This is how Blender works right now, as well; e.g. right now I can be working with Draw Sharp and make some changes to its settings, quickly switch to Grab or to Clay Strips to adjust the sculpt's shape/form, then back to Draw Sharp without losing the un-saved Draw Sharp settings. This is completely impossible in a system where there is only a single tool and un-saved changes get erased when the "Grab" preset is loaded to replace the "Draw Sharp" preset. There is no flexibility in such a system; that is very prescriptive and rigid. Everything is either a preset or becomes lost.

I want to make one thing very clear, though, because my first two paragraphs may sound negative; I'm not opposed to change, I think it just needs to be the right change. We all know that we can't just have dozens of separate tools on the toolbar in sculpt mode. The sculpt toolbar is already overly crowded. However, I think collapsing all brush tools into a single tool is a bridge too far in the other direction.

But! I think I have an idea for a viable middle path between the two extremes:

  • In this middle path the brush tools do all get collapsed into "one" brush tool in the back-end/internal code just like Pablo's suggestion..
  • but a user-choosable number of "Quick Access Slots" on a toolbar/widget/whatever are treated as "instances" or copies of the one brush tool (like instancing a class; brush tool instance 1, brush tool instance 2, etc.). In this middle path the Quick Access Slots would be more than just a simple favorites menu and preset switcher for a single tool; instead, each instanced tool on the widget would be treated like its own tool and retain its own settings and could independently load presets so that they don't interfere with each other.
  • Functionally speaking the user-facing behavior for switching between these "instances" would be essentially the same as Blender is now with multiple "tools" in the widget or toolbar but on the back-end the code would only be one brush tool; the "instances" would handle the user-facing behavior and the user could choose how many of these Quick Access Slot "instances" appear on the toolbar/widget/whatever so that we can cut down on the crowding in the toolbar.
  • An asset browser/library is used for managing all the presets and loading the presets into each brush instance. (I have no proposed modifications to the browser/library; my proposal is limited to the toolbar/widget/whatever and tool switching.)

I hope my description of one brush tool that gets instanced makes sense. It would allow for collapsing the current tools into "one" brush tool but would also preserve the current ability to non-destructively switch between 'tools' with un-saved changes, with the ultimate end goal of reducing the tool clutter on the toolbar. The user could have just 1 brush tool on their toolbar or they could choose 2, 3, 6, 10, etc; whatever number they desire.

@Julian Eisel (Severin) So I want to iterate on this part a bit.

So there are three levels of brush access:

Asset Browser: May be 100s of brushes
Tool Settings: Smaller sub-sets defined with Smart Filters
Quick access menus/shortcuts: Small list of favorite brushes.

@Pablo Dobarro (pablodp606) This is really interesting.

Once this is in place, we can have a similar system to create presets for the filter and the gesture tools and unify them, which will allow us to have just one brush tool, a filter tool and a gesture tool in the toolbar, and the rest of the functionality managed via presets in the asset browser.

Although it's the logical next step based on what the plan is with the brushes I heavily oppose this unless there's a good design for the UI/UX behind it.
Imagine if all green Tools in the Edit Mode Toolbar get unified. How does that help the user?
I think it's really important not to forget what the singular purpose of the toolbar is right now: Selecting the Active Tool/Brush.
If all brushes and Tools are merged/grouped into just a couple Tools and the specific Tool preset is selected somewhere else then the Toolbar loses all purpose.
In the case of sculpt mode it would lead to a handful of icons that are not even clicked anymore.
For vertex paint mode for example it would result in 2 icons for the entire Toolbar, and only one of them (The annotate tool) would be clicked.
Showing a list of brushes/tools in the asset browser or sidebar meanwhile wastes space that is meant for other settings or the 3D Viewport.

So while the Asset Browser can be used to view and manage potential 100s of brushes and other asset from time to time, we also need a designated space to view up to a couple dozen brushes all the time. And I think this should still be in the Toolbar since it is part of the editor and the Toolbar is otherwise left vacant.
Then there are shortcuts and the RMB menu to quickly access the most essential / most used Tools/Brushes.
That's at least my feedback on that.

My proposal is:
We should have a Tool selection and a Brush selection in the Toolbar. These can be separated with a space between them. But brushes and Tools would both be displayed as square thumbnails. There would not be something like a single brush-tool for all of them since there is not purpose in clicking it.
Either in the header or on the top of the Toolbar can be a button to open further options for the Toolbar like:

  • Mix Brushes with Tools or sort them separately (Tools on top, brushes below)
  • What order the brushes are in (alphabetical, assigned order, recently used, etc)
  • Lock the toolbar layout to a Grid/List layout (will make it easier to get to a 3/4/5 column layout for grids (Also look at D9232 for this)
  • What filter to apply to the brushes like "all", "favorites", "sculpting", "painting" "posing", "cloth", etc

We should ship a selection of filters in Blender like the ones I mentioned above. By default it could be set to "favorites" with a selection of essential brushes already marked.

If any brush is used that is not displayed in the Toolbar via a shortcut or asset manager then it will be indicated in the header and sidebar but there's no highlighted icon in the toolbar. Alternatively it could also be temporarily added to the bottom of the Toolbar.
Once a brush is duplicated or added it will immediately appear in the Toolbar if it matches the filter settings.
We would also need an extensive list of brush icons to ship with Blender that users can choose from to make their brushes easy to spot & customize. Assigning your own images as icons should also be an option, which get immediately packed and merged with the asset. But with a great selection of icons that would be the corner case, like when the brush has a special behavior or the user wants to use the texture that is being used.
The proposed wide live brush preview can still be used in the brush settings (Similar to Krita) instead of being used for the brush selection like in this proposal:

The brush workflow is on the 2.92 roadmap for the UI team. That just means that we intend to spend time on this and try to figure out the design and scope of the changes. At this point there's nobody available to spend much time on the implementation, which is a problem and we have to see how we can solve this together with the sculpting team.

This is an important topic given how many features are being added to sculpt/paint modes recently.

So while the Asset Browser can be used to view and manage potential 100s of brushes and other asset from time to time, we also need a designated space to view up to a couple dozen brushes all the time. And I think this should still be in the Toolbar since it is part of the editor and the Toolbar is otherwise left vacant.

Yes, that is exactly the idea.

I understand the confusion because in sculpt mode the brushes and toolbar work in a different way than in the rest of the modes since 2.80. In Blender, a tool in the toolbar is basically a keymap that is enabled when the tool is active. For example, when you enable the Mesh Filter tool, it will enable an entry to the keymap that will execute the mesh filter operator when you click and drag on the viewport. This also works the same way for the gesture tools.

For brushes, a special code was added which generates tools dynamically from the list of available deformation modes implemented in C. So, for each deformation mode (grab, draw, clay strips...) a new tool is generated, that will use the stroke_paint operator, and that will only display brushes that have that deformation mode assigned.

The proposal of keeping those 3 icons in the toolbar (for brushes, filter and gestures) is just to keep the same tool design (keymap + operator) than the rest of Blender, without needed to redesign the concept of tool itself. This is because, for example, all gestures can run from the same operator, so we just need a preset to tell the operator what should it do. If you select the gesture tool directly without a preset, it will just default to a behavior. So, as you said, you won't be actually interacting with the current tool system anymore.

What I was proposing is to add a different widget (it can look exactly the same as the toolbar and it can be placed in the same place in the UI), that displays several dozens of presets for all tools (brushes, filters, gestures and editing operations). The user should be able to load into this widgets the presets he/she needs, assign them to shortcuts, save the layouts...

So, for example, if you are working on a cloth piece and you want to do the thing that makes the cloth fall, currently you have to:

  • Select the cloth filter
  • Set the mode to gravity
  • Set the orientation to view
  • Enable all force axis
  • Set the damping to 0
  • Disable "Use face sets"

With this new design, there will be a filter preset called something like "Cloth View Gravity" that you can add directly to this new widget that will configure all this for you. When selecting this preset, the filter tool will be activated with all these settings and it will be ready to use. This will work in the exact same way for brushes and gestures, depending if the presets needs to run using the paint_stroke operator, the filter operator or the gesture operator, it will activate different tools automatically.

Of course, the design of this "preset toolbar" widget still needs to be disused. It can look exactly the same as the current toolbar, but it can also have more columns, it can be located in a different place (I would really prefer having it in the bottom right of the viewport...), it will also replace the current toolbar that shows when you press space...

Basically, the tools needs to be there just to fit the current keymap/operator design, but they won't have any purpose. If it is possible to hide them from the UI, that is ok.

We would also need an extensive list of brush icons to ship with Blender that users can choose from to make their brushes easy to spot & customize. Assigning your own images as icons should also be an option, which get immediately packed and merged with the asset.

This is also important. The default preset library will probably contain more than 200 presets, and it would be nice for all these presets to have nice icons/miniatures. We should agree on a style and workflow that enables us to make all these icons fast, because there is no way to generate the preview automatically for all this functionality.

@Pablo Dobarro (pablodp606) Sounds good. I do really think that if the 3 Tool icons serve no purpose for the user then they should be hidden to save space. Presets could still be grouped into brushes, filters and gestures so the internal logic is still being represented in the UI.
But having using the Toolbar for showing those presets I think is absolutely necessary.

Albert (wevon) added a subscriber: Albert (wevon).EditedOct 20 2020, 7:08 PM

With Pablo's idea of having four active tools (brushes, filters, gestures and editing operations), I thought of a quick and simple access presets using the keyboard.

S -> Sculpt brushes
S + S -> Sculpt brushes pop-up menu

F -> Filters
F + F-> Filters pop-up menu

G -> Gestures
G + G-> Gestures pop-up menu

O -> Operations
O + O-> Operations pop-up menu

For beginners, click on the active tool icon and hold to display the floating menu and be able to select the presets or select them from the Asset browser.

I upload some icons for preset, which I made for Billrey some time ago but it came to nothing.
My idea was to be able to create them fast, using a simple editor, which starting from few primitive objects and the vertex color, would allow to show and store the functions of the brushes. I don't think automatic dynamic previews for sculpt brushes is going to work well, and the process to create the flat icons is too elaborate to generate presets.
As we are talking about grouping the active tools and working from presets, I leave it here for reference.



Another option would be to combine both the icon created with the editor and the dynamic brushstroke, with options to filter one or the other.

@Albert (wevon) Cool icons! I think the combined option is a very interesting way of showing both texture and displacement.

@Ryan Inch (Imaginer)
The renderings, work files and various tests that I have carried out to preview the sculpture brushes are shared on the drive.
These can be found in the SCULPT BALL ICONS VERTEXCOL folder.

https://drive.google.com/drive/folders/1iqJ4Kkrqn0EKKeyOaLlAYXCSWQ4JvOqO?usp=sharing

@Albert (wevon) They look great! Thanks for sharing! I especially like the VERTEXCOL ones.

Albert (wevon) added a comment.EditedSat, Oct 31, 10:11 AM

This mockup starts from the basis that there are only 4 active tools in
Sculpt mode:
· Brushes
· Filters
· Gestures
· Operations.

I have focused on the Brushes options and Tool Setting bar and the vertical Tool Panel are cloned.

I have added an Assets selector and a Functions menu (the latter is currently in the tools panel, hidden in the brush options, within an arrow-shaped drop-down).

Keeping the menu options, in order to quickly access functions, sizes, textures ... I have added some icons at the beginning of the text.
These menu icons on the side panel, since there is more space, could show a thumbnail of the selected option.

In the case of Assets there is an icon to edit them, since I find it impossible to do it automatically. When starting to edit the ball it would be clean and the layout empty, and at the end of the edition a capture of both would be made, removing the 3D model with Multires from memory.

Clicking on right panel thumbnails, a floating menu could be displayed, or temporarily overdrawn the side panel until the desired option was chosen. They could also center the attributes related to the thumbnail under the cursor.

These floating menus should be accessible by keyboard or remain fixed in the Asset Manager, more or less emulating what we have now.

Another detail, the way the textures are currently accessed, is a nightmare, you have to jump to the tab and it is confusing, it should be direct.

I hope you like it.

Edited:
Another thing that would be good is, partially load the asset settings, that is, filter some attributes such as the radius and the intensity of the brush. Instead of making these attributes global in the mode, let them not load to call the preset. A checklist like Outliner filters with brush options would be fine.