Since Blender is working towards everything nodes, if there’s some kind of Scene nodes functionality in the future where a node graph can be applied to all objects in the scene, we may see an eventual return to a one click, one place to manage solution.
This is what I’m observing, too.
And if @thorn meant the angle-value on the modifier itself, changing that while in Edit Mode updates just fine for me too. 
So the main problem seems to stem from the fact what used to be a per-meshdata thing is now a per-object thing.
Just for my understanding: You did need to tick the autosmooth option, and possibly ajust the angle threshold before.
So I guess the extra overhead mainly applies to a case where you’d used the same meshdata on several objects, thus being able to set that only once, correct?
I will have to agree to this. In my opinion, those who see the issues are a bit quick to assume they are obvious to everyone.
It is possible every issue has been talked about somewhere in this thread. Yet the thread approaches 500 posts and filtering out the info has been getting very hard a long time ago.
greetings, Kologe
1 Like
Hello everyone, I have been following this tread ever since it first started, I am also unsatisfied with how auto smooth works in 4.1 
I am currently working on an addon that tries to fix auto smooth in 4.1, it will be released once 4.1 is out.
The addon will automatically move the Smooth by Angle modifier the bottom of the stack and apply the same normals on all instances when the operation is used.
Also, it makes it easy to add/remove auto smooth modifier on many objects at once. Overall it should almost work the same way as in 4.0, it is even in the same menu and has the same name 
I hope it will make the transition over to Blender 4.1 a bit smoother. Let me know if I missed anything or have any feedback so I can fix it before its out
It can already be tested/download from the github-page
Edit - It is now officially released
13 Likes
That’s really cool. But how do you solve the internal problem on selecting instance that are not visible in the viewport? In my opinion a really difficult thing. The developer of ‘modifier list’ somehow managed to do an apply modifier command that works on instanced mesh. But I guess they use a trick with merge mesh.
1 Like
There are just 99 post for me showing like this. Unfortunately not all relevant posts are covered like this, while a lot of irrelevant ones are. If someone want to understand the actual issues at hand, this feature is not useful in my opinion.
Edit: Went through all the posts out of curiosity. The posts with technical details are not mentioned. Upvoted rants on the other hand are. If someone wanted to help out, this feature would be completely useless.
Thanks for bringing that up, I had not tried with the proper hidden function (not the eye icon) and indeed it seems to not work when adding the modifier 
So thats is disappointing, but weirdly enought it works fine editing the values of the hidden objects.
Will do my best and hopfully will find a workaround until 4.1 relases.
Edit - made a quick hack that seems to work, but it might have an impact on performance (not that adding modifier to every instanced objects is fast in the first place)
Edit - might have found a proper solution! Its a bit more complex, but seems to work
4 Likes
Have done more testing this morning. I was working in 4.2, and it appears that there’s some code in the 4.1 RC that hasn’t been pushed into 4.2 yet as the behavior and result is different. In 4.1, no mode change is required. So, as it’s likely the 4.1 behavior is desired, I can probably cross that problem off my list.
Lots of stuff to reply to, but first, to DeepBlender:
It’s been repeatedly said by people who use the old autosmooth system regularly that adding a modifier to every single object, where before one was not needed, is not a good thing. Telling me “Sorry, this is just dumb” is not only not constructive, but it’s completely ignoring the issue. Additionally, you don’t have to go to the data tab, tick a box, and adjust an angle. You just right-click and select “Shade Auto Smooth”. 30 degrees, the default, works 99% of the time. Additionally, this does not interfere with anything else I’m doing with the object, unlike a modifier.
It’s true that Blender’s management of modifiers needs work, but making that better doesn’t actually solve this problem. The fact is, adding a modifier, moving it around as you work, is more work. Making modifier management better doesn’t solve the problem, which is: adding a modifier to every single object, where before it was not necessary, increases the workload of the artist.
To those saying that this is true of things like subdivision, subdivision is not something you have on every mesh in a scene. Autosmooth is. Additionally, it’s not uncommon to have to work with subdivision with respect to other modifiers. Smoothing is just something you want to work automatically, so having a modifier isn’t necessary. It’s useful, but it shouldn’t be the only way to do this.
I would also like to reiterate that the majority of models in a videogame are not baked props that use subdivsion for a high poly. They are straight low poly models with tiling textures applied. Movie stuff isn’t the only thing Blender is used for, so as cool as they are, the movie projects shouldn’t be the only source of innovation or direction for the program.
I’d like to repeat, also: every other program in the space has this feature. It’s very useful that it’s separate from any sort of modifiers or history. Blender had this too, for as long as I’ve used it (which is almost 10 years now). This is a necessary feature, and everybody in my industry uses it. Removing it adds complexity to a workflow that wasn’t there before, because now it’s a modifier that I need to deal with.
8 Likes
This is not really true. For example 3Ds Max has AutoSmoothing in form of a Modifier. And in Houdini, it’s also a node which you place somewhere before or after other procedural operations.
Blender is no longer destructive modeling package. It’s moved to procedural modeling, which is much more powerful. There’s ton of important flexibility benefit from being able to precisely specify at which point the smoothing happens along the procedural model generation, and ability to even do it multiple times on one object, utilizing different smoothing data along the way.
Both Houdini as well as 3ds Max do have option to simply bake the resulting smoothing data into the mesh data, and so does Blender:
…but in terms of dynamically changing AutoSmoothing angle, Blender was in a really weird spot here, as it had procedural modeling modifier stack but AutoSmoothing was destructive option on the base mesh datablock. It didn’t make sense. Majority of the other mainstream 3D packages which have procedural modeling capability had AutoSmoothing implemented as procedural operator you can dynamically change the order of in context of other operators.
The solution here is not to return back to monke but to fix the underlying Blender’s legacy design issues which update to procedural AutoSmoothing revealed. The reason neither Houdini nor 3ds Max users are demanding implementation of simpler, Blender-like alternative to modifier based smoothing is that neither of these 3D packages suffer from lack of object instancing or proper multi-object parameter editing.
9 Likes
Technically, it was not destructive since turning it off or on did not irreversibly change the mesh. In fact, nothing that would be considered a mesh attribute that could be enabled or changed technically counts as destructive.
The drawbacks though are a different story, as the order of application for such attributes have to be hardcoded and the user also did not have any control as to whether they be applied before a list of modifiers or afterward. It even affected developers as HowardT talked about the outdated normal handling code getting in the way of a couple of his projects (which includes the very promising bevel algorithm with automatic merging).
Ye, true… I used “destructive” as opposite to “procedural”. But the better term would be just non-procedural.
2 Likes
See my reply above, your addon will fail to apply the smoothing if the object has shapekeys.
That was one of the reasons why I made a patch to move the shapekeys to modifier level a decade ago, but it was dismissed. The shapekeys and the modifiers are all nice but we are going to hit that wall again and again with the modifiers due to the nature of the shapekeys in Blender.
8 Likes
One UX issue is that you can’t toggle flat and auto-smooth from right-click to observe changes. You have to toggle modifier visibility, it’s a bit of a pain.
@kkar if you’re using shape keys and want to bake smoothing you’ll have to use right-click operator that destructively sets edges as sharp to give same result. It will only work on base mesh and not on modified result, but I’m assuming if you’re working with shape keys and baking you’re already avoiding other modifiers. It’s a cynical world we have to live in, but you do have that option.
You’re right, I totally spaced on Max, which uses smoothing groups. My bad! I haven’t used it in so long, I’d forgotten.
Nonetheless, Maya, Modo (uses materials), XSI, Lightwave, and Cinema4D all have this. I’ve used the first three, and did some research to double-check on the other two. Also, being more procedural is great, but making the user experience worse is not. Ideological purity shouldn’t trump usability, especially when it’s something this fundamental.
If I’m putting the same modifier on every single object in my scene, without exception, then it seems to me that such a feature (which again, is part of basically every other popularly used software besides Max) should not be possible only via a modifier.
6 Likes
Yeah, even the Blender-Studio admits to using geomtry node to do shape keys because of limitations of the current shape keys. I hope eventually that shape keys officaly will be integrated to geometry nodes.
3 Likes
Now you are mixing what I wrote about modifiers with the right click version. That’s a great way to have a conversation! Apparently you meant the right click option, but didn’t feel like mentioning it was important?
Even more important, completely ignoring my question whether the multi object thing would be useful and solve your workflow issue. And the first time explaining to me about the right click select option that does not work.
There are many different workflows that for sure are impacted. I don’t think anyone is denying it. Why on earth can’t you guys just summarize those workflows, such that there can be a discussion about those workflows?
Every time I am trying to steer towards that direction by trying to understand the workflows and the issues that now exist, people start to criticize me for asking questions.
Unfortunately, one seems to be praised by complaining here. Maybe we could add a rant tag to this thread, where productive discussions are not welcome.
We have, repeatedly. You’re being deliberately obtuse here if you choose to not see that
3 Likes
The debate being modifier vs not, I’m not being snarky, but it was … self-evident?
1 Like
Feel free to point me to workflow descriptions and not to some general descriptions of what is not working and where one has to figure out how those problems obscure.
Of course, it was so self-evident that everyone who didn’t get it or asked questions, didn’t deserve an answer.
We asked for video demonstrations how long ago?
Have the developers said they would never bring this back in is original form? I see no reason for it to not eventually return in its original form after the other issues it was blocking have been fixed.
If we could get some real world video demonstrations I imagine many would be solved by object instancing, which means some of them could be solved now via collection instances or geometry nodes. For the rest they’ll just have to suffer the same experience as someone with subdiv on every object in their scene for the next 9 months or so.
1 Like