I never understood that problem. What is the problem that a brush can simply change the type of tool it is at any time? And all those values are default.
Add a field in the brush options that is a menu that allows you to choose the type of brush and you’re done. At UI and UX level, internally I don’t know the implications.
The user could delete all the ones he has, stay with zero tools, create one and configure it as he wants. And go configuring all of them and recover them without problems.
i see, im not fond at all to that system since i used 3dsmax ten years ago, i didn’t like it when i test it industry compatible for nine months or the shift+f3 cycling for changing the editors to different node editors.
My main issue with it, and this could be only me if that is its fine i can always use the UI, is that when there are lets say four options its required to memorize the items the order of the items and at the moment of changing it need to be a slow switch or could easily press the key one more time than required and then need to cycle all the option again to reach the one needed, this is not the case with two options that it would simply be a toogle or the for example GG that its a compound shortcut that always enable the same thing when press.
Again this could be only me but if it was my choice (and this is an exaple not a feature request) i would put the editor switch(Shift+f3 shift+f12 etc anything that has more than two options less than eigth) into pie menus, same with the W to switch selections and for the brushes i would go for a “quick favorites” kind pie menu, eight slots that could be assign any presset of the current tool being used, stable place of the tool selectec by the user, something that (also as an example) wouldn do with the shift+f3 because editors are fixed by the developers users usually don’t add more editor but brushes could have docens of pressets, imagine cycle trough docens of presets memorized and skip the one that want to use because of pressing the key one extra time and need to cycle all over again.
Not exited by this but since i wont use it i won’t go against it either some other users may for some reason like the cycle system, i can allways pick the preset in the interface
I agree. Pressing the same key to cycle through brushes of a particular type would introduce uncertainty to the user and thus slow down the workflow. A pie menu would be better and would not require memorization of what brush is where in a linear cycle of brushes within a brush type.
A “hide default brush” option could fix this. Then a “restore default brushes” to get them back. Or a toggle to hide and unhide brushes, with the default only being able to be hidden and not deleted.
I believe that the combination of a brush pop-up displaying a simple rectangular grid view of all the available brushes + permanently displayed icons for a set of user specified brushes is still the most ergonomic solution.
@JulienKaspar I wanted to ask if the Module Meeting has allready discussed the ergonomics of the viewport navigation? In the Developers Portal I have read (I hope that i am not mistaken) that the blender developers are assuming the use of input-pens that have at least one button - but this is increasingly rarely the case (capacitive displays, apple sidecar, surface devices, etc.). It would therefore be great if blender provided the option to rotate the view by clicking + draging in empty spaces of the viewport and to pan or zoom by aditionally pressing the respective modifier-keys.This would increase the accessibillity of blender: more people could use blender with the devices they have. And also this would enable a multitude of ways of working with blender.
This is an excellent demonstration how well a design proposition can be only to be brushed off as “too radical” ( i might have overdramatized this a bit ),
while yes i understand on one hand but on the other the Blender UI/UX is lacking is so many ways or certain things are needlessly overcomplicated its confusing why such proposal’s aren’t taken more seriously,
by than i mean the “Fake user data” nonsense from the age of dinosaurs and the terrible UI arrangement of the brush system that’s stuck in a horizontal bar where you dont really have the most important settings in the front.
On top of that we sadly lost and excellent tool designer/writer Pablo Dobarro which wrote certain tools like a year or more ago that are not in blender yet which is kind of sad.
BUT i hope that the current team could patch things up and add all those things and more in a sensible way and that they would accept certain suggestions which are really well laid out which are clearly better than what core Blender offers, with the idea to make using tools easier for the user and that makes a more efficient workflow that’s catering a bit to the professional industry
Interest of active tools in sidebar is to use toolbar as a brushes palette.
It does not hurt to group Scale tool and Scale Cage tool under same category.
Because usually, a user will have a preference for one of the tools and will not conjugate them in same sequence of manipulations.
And that is corresponding to a short sequence of 2 tools.
That does not work any more for Annotate tools. You will use Eraser and a tool to draw sequentially.
That does not make sense to group those tools under the same button.
That make sense to make a group of buttons. But that does not make sense prioritize one against the others.
Grouping is not just problematic for Sculpt mode but also to other modes.
I talked about Annotate tools. That is also the case for Add Cube, Add Cone, Add Cylinder, Add UV Sphere, Add Ico Sphere.
In Edit mode , Loop Cut and Offset Edge Loop Cut can be used sequentially. But there, Brush Cycling can be a good option because that is a small category of 2 tools.
It does not really make sense to group only 2 transform tools like Shear and To Sphere.
There is a Bend active tool for curves or GPO, but none for Meshes. And those tools should be present in object mode, too.
So, work to improve toolbar is not limited to brushes. It should be thought to be propagated elsewhere.
Nobody wants a toolbar that displays tools categories and only brushes that are variations of same tools available in sidebar.
People wants a global palette of all brushes and custom brushes sets.
Brush assets categories are supposed to be those custom brushes sets.
The logical place to display a custom brush asset category is toolbar.
Sidebar has already too many uses. Item settings, Tool settings, View settings, Addons
Nobody wants to have to switch more between Sidebar tabs and have a useless Toolbar.
Asset Browser could be use to replace toolbar. But in that case, it has to be responsive and be able to load a brush by a simple click.
User will aggregate hundreds of brushes. Number shortcuts will not be sufficient.
What is important is to let user being able to customize shortcuts for its preferred brushes and have a efficient way to display and click on specific less used ones.
I completely agree with your sentiment, the toolbar should house the global brush palette. It could be upgraded to be more like a “generic tool preset palette”.
There are two main things needed for texture painting fundamentally that I think should take precedence before multichannel painting etc. Which is Flow and much, much better performance. BoroCG illustrates why flow is needed very well here: https://youtu.be/12VMMSgZtPg
As of today, 3D Coat is king supreme for hand-painting artists but I’m very certain Blender easily could surpass it with the two fundamentally important bits mentioned above. I was very excited when I saw this ⚙ D5697 Texture paint: 2D painting improvements followed with sadness that it seems it won’t be happening as soon as I thought.
This might be the wrong place to ask this, but in the Blender 3.x roadmap blog there was mention of upgrading the procedural texturing system. Is there any update on that, or anywhere we can see the progress of it?
Also:
The most recent module meeting was held on Wednesday evening instead and was purely about the planning of the Texturing project. A full blog post on the scope/roadmap of the project will be released soon.