Initial Feedback
Really excited to see though and energy go into this. I just hope the old API code will still work to some degree. It’s curious how the brush datablock is the one and the same brush datablock already in code… which means consolidating all the settings in all the modes… this is no small coding feat. I still think you could save a tonne of time (and effort) if you keep it compartmentalized and split the brush assets per mode per object type as it is existing - both in outliner and asset browser. No need to re-invent the wheel for all brush modes. There are global brush data blocks already (and no way to tell for what mode), the modes already work and exist - so segregating the brush asset type in the asset browser per mode and object would be far less work and still a standard UX… Also, some brushes don’t translate to other modes if at all. Curve sculpt is vastly different than Object sculpt. GP sculpt is vastly different too. GP weight is vastly different than Armature weight, and Armature paint is somewhat different than Texture Paint. Etc. So… some GUI segregation might smooth things over and be much more an expectant and non-breaking UX and GUI improvement to the existing system.
Example of issue with “global” brushes
Eg. the need for identifiers.
- A grease pencil brush has a grease pencil icon in the corner and grease pencil brush icon in outliner. If you don’t know it’s a GP brush, you won’t get expected line settings in a texture paint brush.
- A sculpt brush has a sculpt brush icon in the corner and a sculpt brush icon in the outliner. If you don’t know it’s a sculpt brush, you won’t get the height and edge settings if you apply a grease pencil brush.
- A weight paint brush has a weight paint icon in the corner and a weight paint brush icon in the outliner. If you don’t know it’s a weight paint brush, you won’t get the color settings you would find in a texture paint brush.
- A texture stamp brush setting would not work with a texture paint brush setting. A brush type in the brush mode icon in the asset might also be necessary to tag and identify what brush goes where. As you can see, granularity of brush categorization is a must, specially the more complex the brush engine and mode.
- All of these could be now be segregated datablocks in the GUI (new) or tagged datablocks (use existing brush datablocks with new API) and have them listed in outliner and file browser accordingly (if marked)
- As you can see, storing brush sub-presets requires knowing for what goes where to have an expected UX to call and drag and drop from the asset browser.
Feedback about ideas proposed
I feel the the texture nodes editor system needs a render engine refactor and updating to be as functional as it was and would be useful for 3D space brushes and more control over custom procedural masks, mostly (current workflow is shader masks which compiles slowly with many layers and is not “paintable” till baked, think… “smart” material/texture painting…). It is useful.
With textures as assets or nodegroups from the texture node editor for the editor as assets (aka, node based brush settings also that can be chained to a brush) that is drag and droppable from the asset browser, you’d be good to go. MAYBE you can also add new “output” nodes or property override nodes to the Texture Node Editor, so the “stack” (if the prop exists in the brush and mode) in the brush settings is also overridden by the texture node editor nodegroup (like override the curve, the pressure, the color methods, etc) and can be stored as texture editor node groups (the same as GN nodegroups) - and then you’d have “global” brush settings attached to brushes, or chained to a custom brush. No need to re-invent the existing API for all the brushes and modes.
The brush asset is a must, needs to be added to the asset browser for sure… Even dragging and dropping a marked brush asset to the brush properties header, relevant tool or side panel will be great.
Removing the brushes settings from the toolbar? Maybe it’s redundency cleanup, but working full screen with this selector and settings control is really important… not a wise move to remove brush settings or selectors form header tool settings, this means full screen without the property shelf workflows will be impossible. (To test, CTRL+SPACE and fullscreen the editor and work, see if possible without property shelf showing, take note of the real estate you have to cross from brush selector to sub-brush settings selector, top left toolshelf to property shelf… is not a short trip. Specially on a widescreen.)
Auto thumbnailing would be easier with default thumbnails, good idea - and any type of autogeneration would be useful (maybe from texture used or brush blend mode and random colour)… yes… that would be nice. Shipping brush presets, yeah that would be also nice. Shipping 80-90 brushes sounds like a lot, but the default is already 80 “global” brushes. I just hope the brush system I’ve vested in with development in the custom toolshelf can be adopoted where we dynamically list each tools brushes in a panel in a custom toolshelf dynamically…
Example of working thumbnail UX with the brush panels addon we developed:
The way we handle “thumbnails” or brush iconography from an addon in another Blender fork we distribute:
- A brush defaults to a blend mode icon.
- If user adds a custom thumbnail, it will draw the thumbnail and override that icon
- To access the brush, we added back toolshelf panels and tabs to the Toolshelf to see iconography and also top-level access to operators and brushes.
- Now the brushes are top level (click and select, no hidden menu, no pie, no grid to first call then dig , no extra hotkey, no popup… just point and click) and it has visual identifiers: user custom or some default differentiation per brush preset type
The work coming:
This method above works with the existing API. Improving how a brush draws a default thumbnail in the library engine could be a great project. Working the asset browser to segregate each brush type per editor per mode per object (which is more than a handful of editors, modules, brush engines and more that would need to be refactored and worked on to make all brushes work otherwise) may be the shorter clearer less breaking route. I feel you’d have to re-write how the brush datablock would have to be read in texture paint, weight paint, vertex paint, sculpt, grease pencil sculpt, grease pencil weight, grease pencil draw and then in 3D view object variations: the hair curve object and armature object. You’d have to rework all the brush engines in all the modes and object types to be compatible, when in UX there are some brush settings that don’t translate per mode, per tool, per method per UX. As a user, how do you predict what setting is stored and translated when an expected brush is specifically built for a mode and workflow? How do you know what’s good per tool per mode per workflow? I can see this the most difficult to answer when the grease pencil brush engine needs to be compatible with the sculpt brush engine, two completely different paradigms. Even texture painting to grease pencil doesn’t translate, one is essentially a vector engine, the other is a raster engine. How do you smudge a grease pencil? You’d have to rebuild the entire greasepencil engine and brush paradigm.
It would be a HUGE engineering feat to consolidate all the brush drawing engines and global settings in all the object types, modes and brushes - and it’s not polish, it’s re-creating what’s already there and replacing what needs refinement. This may be the long route around. Starting this in master or experimental will make the project drag on, since you will have to go through all brush related modules to work together in the UX to set the ground work for brush assets! - and you all are already spread too thin for such an endevour. What about the rest of the modules you are head of? Pipeline? File Browser? Core development? Bug fixing and file I/O? The asset browser yeah… that could be finished. But yet another project on the many you’re all leads on?
The brush panel and listing at a top level with custom iconography and user overridden iconography is already doable. How we ship brushes now is the next question. How you generate brush textures and masks is the next question - or how to generate global property overrides - (big hint, the texture node editor could solve this with it’s own nodegroup category and property “output” or override node).
TLDR, feedback in list form
I would try boil it down to this to improve the texture painting UX:
- Brush thumbnails auto generation, yes (based on brush mode, or texture + random color or symbol signifier for unique auto iconography, or override with user thumbnail - how it draws doesn’t have to be literal, it could be symbolic)
- Brush segregation by mode and object type in the asset browser would be easier than re-writing all the brush engines to be compatible (instead of “all” global brushes as the same datablocks per mode, per brush - GUI segregation would solve this UX without re-writing everything)
- Drag and drop of brush categories from asset browser, yes, most definitely, can’t wait!
- Ship defaults, yes.
- Fullscreen access of brushes from header tool settings and property shelf, please keep important.
- Texture Nodes Editor, please revive it. 3D Textures and procedural masks is very useful there and the engine already is built in and useable as a UX. Shake off the dust and polish it. Don’t re-invent it.
- Access to brushes improvement? Think top-level. Think point and click. Anything in a pie, in a floating menu, in a floating grid, or other will require +50% more user action to use (1. call floating menu, 2. then search for brush, 3. then click) instead of search for brush and click. We addressed that with a custom top-level brush panel, that lists all brush presets in the toolshelf in a tab in a panel per brush type. It works and is a blast to work in. A pie menu still needs to be called and you save maybe 20-30% user time by saving real-estate in mouse movement and maybe 10-20% user thought on searching - but you still can’t list more brushes than 7 before being overwhelemed anyway, let alone many brush presets to toggle! - A pie useful for presets like this would be 2 layers deep and super flashy and heavy to navigate - it would solve nothing. A called grid to toggle… is still no improvement to existing methos: 1. call menu, 2. then search for brush, 3. then click, rinse and repeat to toggle a preset.
Other than the work to the asset browser integration and brush categorization,the texture node editor revival, the drag and drop of textures, texture editor nodegroups as assets, and brushes to and from the asset browser - and some auto-thumbnail generators (with symbolic iconography maybe) - everything can and has been done with existing API.
UX Goals I’d put to work:
A. Focus the brush GUI and UX improvement to be a top level access to a set of brush presets. Draw from existing examples (tabs and panels in a toolshelf), anything else is 50% more user work per brush preset selection and toggle. Be it a single click in the asset browser to toggle settings, sure. Go for it. Point and click. Ideally in a toolshelf would be better.
B. Work on a concept of using a pre-made/generated icons for a brush thumbnail, yes. We got this UX going with toolshelf brush buttons atleast, not in the brush library engine. It works as a good UX. You could work a similar concept for the brush library engine and brush thumbnail engine too.
C. Global brushes already is an existing datablock concept - but it shouldn’t be. Refine expected UX with categorization of brush types and modes. Know what preset is for what with what already exists. Reworking ALL the modes and methods to be compatible and consolidated to the one and same data block is the long painful route. Segregating the UX and brush GUI so it’s more an expected and segregated experience with datablock display and asset browser display may make it easier to know what you’re gonna get. (Work: 1. create datablock sub-category and iconography of brush types from outliner, 2. work Datablock handling of brush types by mode tag with the sub-categories 3. Work asset browser to list brush types with relevant icography - leave the other module brush code alone to get up and running and polished quickly, even for this year). Benefit: A user knows he needs sculpt brushes, he’d look for sculpt brushes and presets in the asset browser. A user knows he needs grease pencil brushes, he’s gonna look for grease pencil brushes in the outliner to mark, save, then call from asset browser. As it stands, there is no way to know which linked or appended brush is for which mode - this UX could be improved. Even if all brush settings are consolidated (which I doubt is possible per workflow paradigms) - don’t work it as it already is (it is “global” in the linking/appending paradigm already) but segregate it in the GUI without re-working all the modes and refactoring a MASSIVE chunk of the blender core code per brush type and mode, which may break backwards compatibility also.
D. Work on brush global overrides by using an existing editor (Texture Node Editor) and it’s UX paradigm so that a user could “chain” global setting overrides on brushes. (textures, properties, procedural attributes) from the texture node editor that link the same throughout all the interface, editors and modes, including geometry nodes, shaders, compositor, modifiers and more.
End goals to keep in mind:
- Visual Reconizability of brushes in library (symbolic iconography or quick thumbnail generators) that also works in the asset browser with user custom thumbnails
- Interoperability of brushes with asset browser and users pipelines (ship to and from files easily)
- Top Level Access of brushes (quick and easy selection of presets in the GUI, point and click)
- Categorization and Compartmentalization of brushes in the GUI: no-reworking a dozen modes and brush types to be the same, but work more GUI indication and segregation of existing brush types (faster development turnaround since it is mostly Outliner and Filebrowser GUI with the added benefits of a clarified and expected brush UX as required by vastly different brush workflows and pipelines in the existing software)
- Make what exists relevant, revive the Texture Node Editor (and allow calling the output in Shaders, Brushes, Compositor and Geometry Nodes)
- If we want global brush preset between brush types and modes that is un-invasive, this could be done with the Texture Node Editor (or “Brush Node Editor”) with “override property output” nodes set by a chained brush to the Texture Node Editor nodegroup set in the node editor and chained to a brush setting, a bit like “Use Nodes” in shaders, but for texture blocks or brush blocks. The old method was a good one.
User Case Study of why categorization is important and why the texture node editor is useful:
And also how you can have “global” presets per brush, but still categorize brushes without a massive refactor of the core architecture.
- I’m in grease pencil and texture based painterly project.
- I want a global override of my grease pencil to link to a texture paint brush settings. Since I’m using both GP and texture paint in the project.
- I make a node group in the Texture Node Editor with the painterly.
- I link both brushes to the node group from the Texture Node Editor
- Both brushes now inherit the nodegroups overrides.
- Now I want to save the node group for another project.
- I start a new scene, new mood. But I want a consistent setting both in GP and Texture paint, but personalized brush strokes both in texture and GP.
- I saved the Texture Node Group preset to the asset library.
- Now I can drag and drop (and link) this texture nodegroup and chain it to the two brushes in the two modes.
- I make GP changes to that brush for the mood, while still keeping the nodegroup settings from the node editor for consistency between brushes and looks.
- Now in animation, I don’t need texture paint mode, it’s all baked now - so now I just drag and drop the Grease Pencil brush asset and paint and animate fixes on the character as I animate. The Grease pencil brush is clearly easy to find in the outliner or asset browser (from icon) and the grease pencil brush drags in the linked project texture brush node group from the texture node editor too if it has overrides.
(Just a note: the texture paint presets with overrides and brush settings I don’t want on the grease pencil vector drawing mentality - only some things translate, but not all. So keeping categorization helps the art like knowing when to use what brush or tool with what paint type. Globalizing the paint tools and “materials” for the art is like… homogenizing paint and art techniques. It won’t work. Some things do need to be consistent between methods, but each differs… Blend it!).
- I paint custom strokes while keeping the linked overrides “global” per the project.
- A TD can modifiy or improve the “painterly” look of that node group any time, and linked brushes referring to that nodegroup will all update throughout the project.
Basically, replicate the Modifier stack but for brushes with the idea of Geometry Nodes “overriding” object data. The Texture Node tab and old editor… used to do this to a degree.
Bonus note:
The texture node editor in its day was useful: 1. It had node previews, super easy to work with. 2. It allowed consistent textures in brushes, compositor, shader nodes, displacement modifiers and more from the same source - those texture/brush blocks were HANDY. 3. A method to do 3D Brush textures that was easy to make interesting shapes both for sculpting and texturing was really useful and handy (and the power of Blender texturing back in the day). It has been many years without it… and I still miss it ever since 2.8 came out - I jumped in joy seeing that some code was being worked to MAYBE revive it. Here’s hoping! It was a rough blow seeing it no-longer relevant nor usable. Now it’s more potentially useful than ever since the same texture could be used both in GN and Shader nodes at once - since the workaround is really rough to keep both systems synced on a texture basis. This also can be true in sculpting and texture painting since they are now more performant and interesting, Procedural textures for 3D brushes are more relevant than ever.
Well that took a few hours from my time this morning, back to work! Thanks for reading the feedback up to this point. Thanks again for looking at the polish for the workflow with brushes. Looking forward to see what you do with it. Can’t wait till a brush is an asset.
T100479 Regression: Expand operator on open boundaries causes crash
D15025 Expose Face Sets In Python API
