Brushes Storage #70412
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
28 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#70412
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
Note: For brushes to be more useful and work well, we will also need to;
Open Questions:
Added subscribers: @WilliamReynish, @CharlieJolly, @zreinhardt, @JulienKaspar, @ideasman42, @mendio, @brecht, @antoniov, @PabloDobarro
#80502 was marked as duplicate of this issue
Added subscriber: @Mets
Added subscriber: @mont29
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.
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.
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.
@WilliamReynish 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.
Added subscriber: @AlbertoVelazquez
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.
Added subscriber: @hadrien
@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.
Added subscriber: @BartekMoniewski
Untagging design tasks from specific releases, in general these should only be tagged with the relevant modules and listed on the module page.
Added subscriber: @Kinthamen
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.
Added subscriber: @JulianEisel
Brush management should become a part of the asset manager. So I looked at this design again and together with @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:
GUI:
Interaction:
Loading Brushes:
Factory Startup Brushes:
These are the existing default brushes.
Food for thought:
It seems a complex system for something that should be simple from the user's perspective.
@JulianEisel, 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.
Added subscriber: @ErickNyanduKabongo
@brecht, yes this is the biggest design decision I'm unsure about. The reason to have a local list of brushes is twofold:
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.
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.)
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.
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.
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...).
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
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.
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.
Added subscriber: @Frozen_Death_Knight
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:
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.
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.
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).
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.
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.
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.
Added subscriber: @ckohl_art
Added subscriber: @MadMinstrel
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.
Added subscriber: @RedMser
Added subscriber: @Josephbburg
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 :)
@Josephbburg, that's off-topic here, please use this task only for discussion of brush management.
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.
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.
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.
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?
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'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.
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:
Added subscriber: @jfmatheu
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:This way:So basically:'Cloud' Library:
'Shared' Lib:
Just in case thatper 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.
Added subscriber: @Jewls
Im agreeing with @Frozen_Death_Knight
Speaking from an Artist level:
Krita has a good approach even-tough its a 2d software.
with some good brushes like @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 @JulianEisel ´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.
Added subscriber: @Imaginer
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.
Added subscribers: @OPDesign, @mano-wii
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:
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.
Obviously this is a design with limitations, because we try to capture the essence before adding "handy" features.
Storing Brushes
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.
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 could be features to make creating these very efficient.
So there are three levels of brush access:
Vague points needing more thoughts:
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 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.
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.
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?
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.
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.
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.
As part of this project (more details in #80384), 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.
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.
Added subscriber: @tiagoffcruz
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:
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.
@JulianEisel So I want to iterate on this part a bit.
@PabloDobarro This is really interesting.
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:
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.
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:
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.
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.
@PabloDobarro 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.
Added subscriber: @wevon-2
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.
@wevon-2 Cool icons! I think the combined option is a very interesting way of showing both texture and displacement.
@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
@wevon-2 They look great! Thanks for sharing! I especially like the VERTEXCOL ones.
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.
Added subscriber: @Pipeliner
Added subscriber: @shinyuu
This task needs to be reworked for the brush asset project.
Changed status from 'Confirmed' to: 'Needs Developer To Reproduce'
Added subscriber: @Nika-Kutsniashvili
The current design is #116338. That's being implemented in #106303.