Blender UI paper cuts

user-interface

#1431

is quite annoying when you want to move something or sculpt in that area and you interfere with the vertical line imagined in your work.
The problem:

I propose the following solution (mockup):


That you can only resize the panel by clicking on this new border, specific for this purpose.
The new border is located on the outer contour of the panels.


#1432

Shouldn’t Default be named sRGB fr consistency?
But this might confusing, in case it is understood as managing of icc profiles.
Btw, afaik “Default” just applies a 2.2 gamma curve on the linear data. Maybe the name should reflect that in order to be more clear?


#1433

As mentionned here:

Bones can’t be displayed as wireframes. Doesn’t work through the object’s display options, nor using the viewport’s wireframe display mode,


#1434

Fake user still uses the F in Outliner


#1435

Let me fix that for you: “Is there a reason why autosmooth is not always on by default for all objects?

Maybe it is just my particular workflow, but rarely have I found a situation where I’d want it off, even on flat shaded objects.
I would even like to see this available for other object types like Bezier Curves, so one doesn’t always have to add an Edge Split modifier to get correct shading


#1436

I agree to this. But I can think of cases where people may not want Auto Smooth enabled. So there may be an argument or discussion about the design of it, while there are definitely no cases where someone would add a modifier without wishing for it to have an effect. So there can be no argument about the need for Auto Smoothing to be turned on by adding the modifier the way I see it. This really bothers me since I will most definitely have to go on a clicking quest every single time I add a Weighted Normal modifier while I do not care that much about Auto Smooth since I don’t ever use hard edges - they always have a bevel on my models(I rarely model razor blades).

What I am saying is - in my opinion Auto Smooth should be enabled by default. It makes much more sense, but that is an opinion. However, adding a Weighted Normal modifier should also turn Auto Smooth on automatically, if it requires Auto Smooth to work, because that is always the intention of the user adding it and that is a fact.


#1437

Yes, I understand there maybe other use cases.

For my personal workflow though, more often then not I want it on, and since it doesn’t seem to have any negative effects on flat shaded objects, maybe we would save more clicks globally if it were enabled by default, and we only needed to turned off when it caused issues.

We’d have to get some sort of consensus on which is more often used to make the change justified.


#1438

That would be cool. I have seen many people complaining about it. I even wrote a hacky script on Blender Stack Exchange that checks for new objects with scene update handler and enables Auto Smooth on them. That should not exist :smiley: .


#1439

Coming from c4d where the “auto smooth” is on by default, I’d vote to have it on by dafault in blender too. The less clicks the better. :+1:


#1440

I suggested this too, but apparently it’s quite a lot slower. A lot of objects don’t need Auto Smooth and would pay a performance penalty because it would be needlessly turned on for all new objects.


#1441

What about the modifiers that use it then?


#1442

I think an axis that got locked in scale/rotation/location should be also greyout:

Blender_Greyout_If_Locked


#1443

How about a “preferences” setting under general preferences for Auto Smooth always on?


#1444

When? I can’t really think of any, outside of rather unreasonable cases and I suspect a few of the cases you might reply with could potentially be considered buggy behaviors in need of fixes, perhaps… :thinking:

I’m not sure it’s that big of a performance hit but then again there are still some people running blender on late 90’s hardware it would seem. More importantly if auto smooth really is that expensive I suspect it gets polled/reevaluated too often. Shouldn’t it only happen upon a change to the mesh, ideally only upon actions influencing surface normals/shading?

edit: I’ve stated this before and I’ll state it again, the real issue is that we don’t need 2 things to do the same thing, make/shade flat/smooth should be removed. Objects should be smooth by default and if you want edges sharp you can mark them explicitly sharp.

The automatic angle based edge/normal splitting could still remain a separate option however the reason we are all requesting auto-smooth be on by default is that edge split marks/tags only currently take effect with auto-smooth enabled, or the edge split modifier, but honestly that is yet another way of doing the same thing and I’d rather see the modifier removed to make space for more useful modifiers since one of the main reasons that has been given for not adding many new modifiers is that generally speaking the developers don’t want the list to grow too long(I’m sure theres more to it though). So I’d rather see the edge split modifier go if theres already another, potentially better way to handle/do this.


#1445

No because you can still change values from the sidebar despite being locked, just not directly in the 3D view.

While I’m all for cleanup and unification the Edge SPlit modifier has other use cases besides shading control unfortunately, so it could not simply be removed.

Wasn’t aware of the performance issues Auto Smooth could cause, that is an unfortunate set back for having it on by default.


#1446

I’m guessing you mean in cases of procedural modeling using other modifiers? In that case I’d argue similarly how many of them can set creasing they could set edge splits too, or indeed now that we will have proper catmull-clark SDS with OpenSubdiv creasing of 1.0, 1.0 will itself automatically split edges.

Yeah, I reckon it’s up to the angle based edge/normal splitting that is causing a need for constant re-evaluation. That should IMO be separated out of it as I essentially stated above.


#1447

Which is a weird behavior if you want to lock something. If I want to change some values I wouldn’t lock it anyway.


#1448

I have created another solution from python without having to compile blender, but each user will have to run the code or activate an addon if it is done in addon format, it would be very easy to adapt it to addon but ideally this included in the official addon blender…

(Edited) Now in Addon version:
https://pastebin.com/p7Pei0z7


#1449

This should be in by default, not as an add-on in my opinion. It is a lot of help when trying to help someone with a problem from their screenshots. I think this has a bigger impact on Blender’s community than it might seem.


#1450

I agree should come by default, hopefully, in fact the first version that I did something similar was modifying blender in c the core, but that’s where the thing stayed.