Unfortunately, we cannot control every step of the developers, participate in all discussions. Under ideal conditions, we should not do this at all, sorry :). Developers should have experience or access to comprehensive information about the subject they are working on. For example, when the developers decided to replace the TAB hotkey with switching from the editing mode to something else, the users had to very long and persistently dissuade the developers from this step. This situation should not have been.
And this is everywhere. Here are some more dubious decisions:
replace hotkey ctrl+1,2,3… for edit mode (subdiv lvl)
subdiv modifier. viewport subdiv lvl follows after render lvl.
Object transformation sliders are on the Item tab, 3d cursor transformation sliders are on View tab, although the objects and the cursor work together.
This list is endless.
Blender UI paper cuts shows it very well.
About removing labels. You are right, but forget about the other side of the coin. The label does not provide complete and comprehensive information about the button next to which it is located. A new user, after reading the label, will not understand how the tool works.
For example. Limit Method: None, Angle, Weight, Vertex group. Limit for what? For bevel size, for segments, for profile, for what?
The label does not provide information to the new user. He still has to read the prompts and remember what this label means. These labels do not explain anything; they serve to create a unique name for a series of buttons. In my example, they are not needed because uniqueness is ensured by the position of the buttons, this position is very easy to remember.
In addition, you easily placed 4 buttons in a row (None, Angle, Weight, Vertex group etc.). Devs have done this three times in this modifier.
This is similar to another “Blender Paradigm” which harms more than it helps
I am not saying that any of my concepts is unanimously correct and should be accepted. These are just ideas. An idea with a number of drop-down menus is just an iteration of the idea.
For example, here I tried to explain how and why buttons should be placed in that order.
Hi, I like the proposition 1 because it’s clear and well organized. Also there is less dropdown menu which is a good thing for a faster direct access to properties. @Wazou I like the first image for the same reasons.
Sure! Comprehensive is easier said than done though : P
I’m going to disagree that people can easily remember the order of different items. In my experience people usually refer to a setting by its name or its label rather than its order among the others.
I agree that “Limit Method” is a bit ambiguous, but I do think any context rather than none is useful.
That’s different, they’re just selecting from the same enum!
I do appreciate your in depth mockups. I do like aspects the proposals posted here, although I would change a few things.
I’m nearly finished with a patch to change the way modifier UIs are drawn. After that I’d like to make a pass over the UI for all modifiers (or as many as I have time for), starting with bevel. I’ll make a thread to collect feedback first.
That patch, ironically, will make it much, much, much more difficult to generate such mockups in the future as well as prevent some forms of customization without recompilation won’t it?
Sorry that we’re getting off topic from bevel improvements, that’s my bad…
It would be simple to make it possible to override the layout in that python file so the layouts can still be custom, maybe I can add that. If you already compile Blender it’s not much harder.
I meant that having some label to provide context for the items is more useful than having no label at all, even if the label doesn’t provide a perfect description of the property.
I tried this a bit.
It looks cool, it feels comfortable. Unexpectedly, the new interface takes up less space than the old
Drag and drop is cool.
Subdivision viewport level located first than the render - thanks, that’s the way it should be.
But the bevel settings are again scattered.
Always when i use itit is like steeplechase.
Maybe this design will be more convenient?
It looks like you have an old build. The experimental buildbot build probably hasn’t been updated in a while. I can update it soon. The design currently puts more things in subpanels, so it should be more organized.
you should submit this to pablo dobarro I think he would understand the interest of this adaptative subdivision like in Modo. I already shared a publication around this in the previous topic the guy doesn’t get it.
Adaptive subdivision for curves isn’t really related to bevel, so I’m not sure this thread would be the place to discuss it. Although it would be a great improvement.
As for bevels, I’m not really what you mean by adaptive subdivision in this case. If you mean varying the number of segments throughout the bevel, I’m not sure that would be worth the added complexity.
adaptive subdivision related angle of curvature is not linked to bevel. you don’t get it too… @Kranos I think this is linked to normals. if difference between normal and next > value ->subdivide. but of course this more complex in details
