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?
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
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.
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.
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 .
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…
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.
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.
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…
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.