Sculpt Brush Management UI/UX [Proposal]

Your personal experience or hunch counts for less than the research that has already gone into this. A radial menu with random subdivisions serves no proven purpose that a regular menu doesn’t do equally well or better.
Don Hopkins has a lot of research on this, sadly his website is down. Here are some excerpts though: https://ux.stackexchange.com/a/154
Note the first response: Radial Menus have a poor perception because of bad implementations. This is what I’m trying to avoid!

More than 8: You wouldn’t! 12’s the accepted maximum. I haven’t seen studies on how effective a 12-slice pie is, but from personal experience I’d say it’s already less practical than 8. There’s a reason there can be a linear runoff menu at the bottom.
An odd number: simple. You start with filling the main ones (up, down, left, right), and then the ones inbetween. You decide how to logically group them.

2 Likes

Very interesting studies. Thanks!

Compliments for the mockups, they look great. Positive feedback: consider to help out on existing code projects we have to help improving UIs (asset browser, geometry nodes, etc). It’s rewarding to contribute designs to areas that are fleshed out already and will (likely) be accepted.

A radical change as you present with overlays here is not a topic we can quickly decide on. I think it’s overshooting on practical usability and it’s a big step away from core UIX concepts we use in Blender. I think it’s better to first agree on a general direction we should go to with overlays (pie menus, button panels) before going into detail as this. During the upcoming 3.x series there’s plenty of time and space for such discussion and design reviews.

I also want to see more developers/designers to join the team. We need to find people who bring in many years of experience in the 3d tools field, people who fully grasp the history of what we did (what’s good, what to improve) and develop a well supported vision where UIs in Blender will go to in the next years.

For that reason the UI module is kept on a short leash - they should first assist on existing projects and module teams, to work on generally accepted concepts, finish what’s not fully fleshed out, work on quality, do all the essential maintenance.

Thanks.

31 Likes

This concept can be easily be implemented as an addon with BGL drawing and a modal operator. However drawing images as Buttons or Menus in Panels is not feasible.

If you consider the two options that are “develop addon” or “develop in core c”, that are both experimental and time consuming, the only feasible solution is to re-use every possible existing infrastructure that Blender provides, thus you go with Pie menus or Panels (same as making custom addon though).

Plus the most important, to consider, if is really helpful to draw custom images on Operator buttons, other than setting the standard icon= parameter to use an existing internal icon.

So to recap, what can be examined:

  • Develop addon: easily done by anyone for research purposes, the most possible outcome is to consider the possibility of a BGL based GUI to emerge that it would be presented in more flexible and creative ways.

  • Develop core c: super difficult in terms of not-development.

  • Develop core c to support custom image drawing: if there are many uses cases and actual need to support such a feature, weighting the pros and cons, thus you can get Pie Menus or floating panels ( bpy.ops.wm.call_panel) with custom images that will make them look good. But the final point if actually #1 makes more sense.

4 Likes

Wow, I hadn’t seen your proposal yet, @silex . Very impressive and useful. It’s users like you who really contribute to Blender’s improvement. :+1:

6 Likes

It’s good (in docks on right). When imagine the other tools on right, next to menu after change sides (gizmo to left) then work can be more comfy and faster.
The brushes can be more easy understand with role, and adding new/own or custom can be comfy here.
The basic tools with icon on left can be as option if somebody want old style.
Maybe grouping new, or favorites can be more useful, this same “last used” list.
Not sure about implementation search by name here or filter (eg. with proposed groups), especially if many new. In plans “online brushes” as addon? Then management need more expetations.

The solution touching problem around material management from online asset addons, can be included in to this as some “template” to usage around UX/GUI. On RCS was propositions with this.

About “Fig.11 Another layout variant of custom Brush Settings pie-menu”

  • can be option to test, and after experiments user can grab new experience, this can be ok on tablets, etc. where screen can have changed orientation by angle not like on PC/Laptops. On 1st look reaction was “why”, but “maybe”…
  • this same on center… but imagine… some AR/VR solutions…

About custom parameters around brush in center… I think this sould be more “pure” as tool panel on right side GUI and next to whole menu (as ctr+t).

3 Likes

Can I see this ui/UX in version 3.1? I think the brush ui is very visual compared to the original Ui and functional role

When will this ui be available in blender?

1 Like

Blender 3.1 is well underway, i would like to ask if there has been any talk of developing discussing this further, any plans to tackle this proposal ?

1 Like

I just want to say this is such a WINNER in the mockup. This should be very much considered, if not, reconsidered. *All of the ones shown are great, but this one definitely encompasses what Blender has, and the users of Sculpt mode are already accustomed to. This just happens to appear more streamlined. Lovin it, I hope its being considered.

4 Likes

hii, tbh it looks more like a stylized Uix of a nice addon. It doesnt match with the current UI/UX of Blender. The proposal has to be more streamlined with blender’s UIX . The mockup’s UIX is good for an addon!

9 Likes

I disagree.
That does not go against Blender’s UI or UX.
That would make a great UI for a global menu in this mode.

Menus have to be in phase with the mode.
In object mode, right click menu can adjust a spot light size which is also available by gizmo.
In edit mode, right click menu is corresponding to specials of selection mode.
In currrent texture and vertex paint mode, right click menu is showing a color disk.

That is totally in phase with a new advanced sculpt&paint mode to have a right click menu showing basics of active brush and a quick way to switch to another one or go back to last one used.

That is what is represented in the mock-up that is important. Not the graphic style used by mock-up’s author.

2 Likes

Disagree or not, it looks out of place…

3 Likes

Well… Don’t ignore what Ton said guys

This is a very radical change for the current Blender UI.

This means “Let’s first have an agreement on the overall design principles first before making such a overwhelmingly different UI”.

I agree that it looks out of place. It doesn’t look like “Blender” to me. I think we either discuss this proposal’s design principles and see if the entire Blender UI design can adapt, or have this design be modified to be more like “Blender”. Otherwise I don’t think we are getting anywhere.

5 Likes

Well it is not a change to ALL of the UI, its a very “module/component” like function, like pie menu’s for instance, at least it looks that way.

In the beginning we dont need it to be feature complete, lets start with the basics and go from there.

I’m all for including developers in to this and there needs to be a discussion, but i think a community involved with developers discussion is a must.

What Eary said is 100% correct, and you arguing against it isn’t going to get this implemented.

The first step to getting something into Blender is studying the software’s design and seeing where they could be improved without breaking its rules. Tacking something like this on (with all the issues that I bring up a few posts above) just isn’t going to be accepted for anything other than an addon.

And: an addon is still an option, in fact there are already several that resemble this one

You’re phrasing all of this too forcefully too. ‘A community involved with developers discussion is a must’… you had developer interaction already, in fact the person in charge of the Blender Institute responded.
None of that means that developers need to ignore all the problems with a mocked-up image and just… what, implement it or the community gets upset?

As for all of the disagreements happening. Here’s what I want to drill down on, because nobody here who disagrees with the mock up I re-uploaded that was posted earlier is stating anything in simple terms for myself as a Artist to get a grasp as to why this should not be implemented.

Right now, I’m reading there are Blender “rules” to design and UI.

  1. What are they?
  2. Why do they matter?
  3. What is the intention of the long-term design of Blender, and its feature-set and functionality?

I totally get the opinions of those who are compiling code here, who have fixed views on what they would rather do, and not do. But if I may… As a veteran in the games industry who is proactively seeking to voice as much as I can see benefiting those in it, and out of it. As to where Blender can and would shine brighter. These disagreements that are in the tune to shutdown discussion are not helping anybody understand things better, and certainly those of us whom are doing our best to stray away from the Autodesk side. Because we see the potential Blender can be that other DCC software chooses not to.

In my opinion, If I were able to write a DCC software and allow sectional tabs that are labeled as editable mode types from Model, Retopo, UV, Sculpt, Render, etc.
I would try to write that software in a way that shares the common language across all sections, but distinctively respects that each of those tabs does things much different at their bests which would entail them uniquely having their own user Interfaces of functions that are best suited for the type of work they entail the user to do. One size fits all doesn’t work, and in real-life this is true on every fundamental level. If applied that way, I see more problems that are just in queue for the future to resolve. Less is more would do, if Blender was a solely sculpt focused only application, but it isn’t. What I think serves great about the mock-up UI, is that I don’t have to navigate the rest of blender when sculpting at any capacity. When I can sculpt, I only want to focus on creating and refine at a rapid pace. Fine tuning things should be focused in the brush presets, and if there was a brush property section to be more tenacious with brush behavior, etc. Great! Overall, Artists in the 3D space who sculpt want to see as little UI in their way as possible, and ZBrush does this well by having a right-click pop up menu as this Mock-up serves, plus it adds onto the existing Blender theme with UI buttons already there, uniquely to sculpt mode of course. Whether that breaks the Blender UI rules or not, it will have to be addressed in future at some point.

What I would like to understand from those who don’t agree (devs included) is what the top ^ 3 questions raised would be, and what is your intended design?

3 Likes

If you’re going to ask people to convince or debate you, maybe first address the point that were already made: Sculpt Brush Management UI/UX [Proposal] - #19 by michaelknubben

UI design isn’t just ‘imposing rules for the fun of it’, but if someone’s designed the wheel and someone else comes running up with a square wheel, the question needs to be posed: what does this improve over the existing design?
If that guy then says ‘prove that yours is better’ you get locked into a dysfunctional pattern.

Edit: also, don’t assume devs are stubbornly ignoring the opinions of artists, and further: don’t assume everyone here’s a dev, I’m also a game artist.

1 Like

That citation of Ton is globally applying to Silex’s proposal.
IMHO, that is not pertinent about Doowah’s praising of jfmatheu mock-up.

It is not a pie-menu with fancy buttons, thumbnails and sliders.
It is a mix of a toolbar + a right click-menu + a texture asset browser.
It conveys the idea to call them all at once, next to pointer.

The way toolbar, color picker in right click menu or texture asset browser looks like is secondary.
What is important is the idea to group settings necessary to a tool switch in a condensed UI.
<< _ I used a tool to do that.
_Now, I need this brush with this color and strength and this texture.
_ Let’s go !>>
The idea is really to be quick and only modify basic settings of a custom favourite brush.
Ideally, content of right click menu should be customizable per brush, be part of brush settings.

But the satisfaction of a need of an efficient tool switch does not solve other problems of regular UI.
The way it presents brushes sets and brush advanced settings.

This is why mockups are done in wireframes, so people can see through the fancy stuff and only focus on functionality. I agree that Jfmathieu’s mockup isn’t bad. A few points that worry me:
-the curved sides don’t make sense. They don’t massively complicate selection something, but they don’t offer any advantages either so there’s really no point to them aside from styling, and function should come before form.
-The middle radial menu is sadly tilted off of the cardinal directions. It would only need to be rotated a bit to make sense again. I don’t know how useful it would be in this situation given there’s so much around it, but some people might like having it there.
-The disconnect between the pages and the content, and the choice for letters rather than numbers.

edit: also, if you’re going to argue in favour of something, make sure it’s the proposal this thread is about, and not the one Doowah brought up. That’s not by Silex, and it was specifically requested that you ignore the layout: it’s only to show the tools that are needed.

1 Like