Bevel Improvements

Archive User Feedback
50

You’re absolutely right. Absolutely.
That’s why I tried to analyze what steps would need to be done with the standard way of creating a bevel.

  1. First:
    Offset value
    Segments
    Profile
    these three points are the embodiment of the bevel, they must be the very first and be together.

  2. Second. Where bevel should be? On all geometry, on corners, on weight, on vertex groups?

  3. Third, how it should work? Everything else here.

It seems to me this is the most common procedure for creating a bevel. Of course, there are other tasks, a different sequence of actions. But this, it seems to me, should be the most common, or not, this is just an proposal.

3 Likes
51

@So3Datel & @Howard_Trickey
I think you both are right. Personally I find myself very comfortable with last comment way of thinking

52

This conversation really should be in the Bevel Improvements thread, not the 2018 GSoC thread, but oh well.

I’ll explain the logic of how I organized the bevel UI, because I’m not convinced by all the changes you’re suggesting.

First, Offset Type is right below Offset Value (which is at the top of course) because that way it doesn’t need a title. It also makes sense to put the control for what a value means right next to the value itself.

Second, all of the check-boxes appear below that for a couple reasons.

  1. A few important settings are there: Only Vertices, Harden Normals, Clamp Overlap. These are some of the options I see people using the most.
  2. To break up the big block of gray that we get if we put all of the slider / number properties at the top. This is just a visual thing but I think it’s important.
  3. All the check-boxes are together because I don’t think there are enough of them to justify moving them to two different sections. When you’re looking for “some check-box,” it’s useful to know they are all in the same place.

Third comes the other most commonly used options, except for maybe Limit Method, which comes later because it’s an expanded enum which needs a title.

Last are all of the other options, which aren’t used as much, and the order is a little arbitrary. I would venture to say Face Strength Mode is the least used option, so that could probably come at the bottom, but I put Custom Profile at the bottom because it expands the panel, and that’s weird if it happens in the middle.

In the future, with constant radius bevel, the Custom Profile check-box will turn into a Profile Type enum. When that happens Face Strength Mode should probably move to the bottom.

Limit Method could probably be moved above Miter Type, because it’s used quite a lot.

1 Like
53

I tried to find the best thread for this, and chose the wrong one :slight_smile:
I will continue the dialogue here Bevel Improvements

54

Moved part of the GSoC 2018 Bevel Improvements thread to this one, by request of @HooglyBoogly.

Hi @Howard_Trickey! :slightly_smiling_face: Have a nice weekend everyone.

1 Like
55

I wanna also point out that:
-Limit/facestreng/interseection/offset are expanded and mitter type is selectable list - why?
-custom profile is linked to profile (when custom profile i checked regular profile should be disabled
same thing with grid/cutoff type and miter types
-responsive design is a thing in blender now

and plan ahead: if there will be bevel modifier UI redesign, planned/considered features could be also included in planning
like @HooglyBoogly is planning with method dropdown eg. decoupling limit offset from limit method / global offset/end mitter/inset/merge etc.

–

new options, ergo new features? Yes please do. UI can be panelized if there will be too many options
if have option to chose 1) new user had to for 5 min read bevel options or 2) user had to spend 5min on fixing issues every-time he uses bevel. I would definitely chose second option.

BTW why is bevel modal blocking viewport navigation?

56

Because it would lead to an overload of expanded enums, and I think takes up more space:

image
image692×998 91.8 KB

image
image694×1048 95.7 KB

The profile slider still influences the profile of the miters when custom profile is on, so I didn’t get rid of it, but that might not be worth it. Feedback would be helpful there.

Yep! Exactly what I’m planning with the constant radius mode when I finally figure out how to fix it.

57

Better / most used default settings would be nice too. Default limit method to angle, miter type - arc , turn off “loop slide”. No one is gonna use modifier to bevel the whole object, sharp miter is pretty much useless now.

58

is there any chance we get something like the Inset function of new 3ds Max Bevel (chamfer) modifier.

59

I made a new concept

Bevel mod_2
Bevel mod_21804×592 305 KB

6 Likes
60

I like the use of menus to reduce the number of actual buttons in the modifiwe. And put all the main controls in first place.

61

This may be a topic for a larger thread, but I’m curious: Here we have two Blender developers working on the same feature, and one seemingly doesn’t know what users use the most, while the other does?

Is this a breakdown in communication or what is the background here?

62

Resorting controls

I am not against resorting it in general. But as @HooglyBoogly I prefer logical groups over how often something is used.
Just a thought on that. Blender could instead support userdefinable colormarks (like a thin colored outline) for ui elements in blender, so users who would like have more focus on some specific controls inside panels could mark it via a context menu entry “Mark Important”.

1 Like
63

Hans and I work together on Bevel. Sometimes we discuss in private messages, sometimes we discuss here. How is that a communication breakdown? The two things you quote are not in conflict with each other.

2 Likes
64

Just a clarification: I did not remove the Percent and Width options. I would never do that. They were just appearing in a wrong place, that’s all.

65

If they are still available I read your patch description wrong. Sorry for that.

66

It’s not how you discuss things that I was pointing out, but what. You did not seem to have information on what users use the most, while your coworker implied that he had that information.

I have not seen any details regarding what Blender features users use the most in publicly available information yet (but perhaps I just haven’t found it), so I was simply curious about that.

67

First of all, from all your posts on this website, I have never seen one that wasn’t either angry or inflammatory…
And again, in this case you are inventing conflict out of nothing.
In here, one person is talking about the most used options, which is easy to estimate, based on a small sample. You can look at some tutorials, some presentations, or at people working around you, and easily gather which options are used the most.
You cannot figure out all information this way. There are hundreds of different workflows in blender, each using the tools slightly differently. There is no tracking in blender to give such a detailed information. You can’t guess how the changes you make will affect all those workflows. It is not the case of devs having different information, but this information being sufficient for one thing but not the other.

68

Only the outliner makes me angry. :wink:

I’m not inventing anything, but trying to find out exactly what data Blender developers have when it comes to UI design decisions. Surely it must be centralized somewhat and not up to each individual developer?

Or is that one of the new standards and practices that Ton Roosendaal mentioned he wants to implement, now that Blender has had a huge influx of money?

I’m just looking for answers, because the UI design communication from Blender is so very, very quiet.

1 Like
69

Yes, I’m also interested in where the developers get their feedback from. Is it feedback from professional users, professional modelers, studios who are involved in complex modeling, rather than modeling simple things?
Do not take it as a mockery, trolling or disrespect, it is a discussion. It may look a little rude, but it’s true as it is. These questions sound as they are formulated by users in their heads.

I would like to share what principles I was guided by when creating the mockups of the bevel modifier.
Look here. Things like Offset Type, Only vertex, loop slyde, harder normals, miter type…how often will you click them when interacting with the modifier? These things are selected once or several times when the conceived method is not working, that’s all.
And things like bevel size, segments, profile (may be) you will be tweeking very often. Even when you decide that you are finished, you will make another object and decide the bevel on the previous object is small or large, and you will change it so that it looks better surrounded by new objects. You change the size, then you decide that there are too few segments for this size, add segments, maybe change the profile if the angle is sharp and the bevel looks elongated. And it is possible that you will come back to them very often. But they are scattered across the interface, you need to search them every time. In addition, each time you will need to read and weed out those buttons that you most likely will not use, and constantly stumble over them.

The decision to push the button somewhere, because now it will not need a title … this is a very weak excuse if this button just interferes.
Rarely used pieces can be shuffled as you like (of course not, but yes at this stage), but often used pieces should be assembled with a convenient design.

Of course, there can be a huge number of cases when a button becomes frequently used. But I proceeded from the principles of the STANDARD, consistent creation of a bevel, in the most ORDINARY case, which, as it seems to me, happens more often than rare and specific ways to create a bevel.

and again i say “often used / rarely used”, of course this is subjective. But I tried to simulate the most standard and simple, and effective!! way to create a bevel.

1 Like