I’ve been going back and reviewing some of the complaints and this one jumps out at me.
Hans has already stated in this thread that the Auto Smooth modifier is identical to the current Auto Smooth setting(and from my testing once I understood what the modifier needed, this is true), which means that if this was an accurate statement, then you couldn’t have Auto Smooth on for these heavy meshes in current Blender either. Modifiers on or off is not a binary setting in Blender. In future Blender you turn off the Bevel modifier and leave the Auto Smooth modifier on for these heavy meshes, just like you have to do now except Auto Smooth is a setting instead of a modifier.
Well, just a post with a few screenshots can do too !
Obviously this might occur when people will switch from 4.0 to 4.1 and start using it for real.
Then we’ll probably see if that’s just a matter of adapting to the feature or if it’s really a major slowdown in the workflow.
This could be done just now so devs can start thinking of a solution but it’s unclear who is really suffering from that change and who is expecting to suffer… That’s quite different
That query is vague and any answer worth considering requires proper context. Within the scope of this discussion, it blurs the line into discussing “how should software evolve” while disregarding the core issue at hand.
We can criticize the feature but claiming devs dont take feedback in the thread where two devs are literally talking feedback from you is wild. Taking feedback doesnt mean they have to agree to us. Thats not what feedback is.
When 4.1 is released I expect swarm of complaints about this and I think Blender might feel pressure then to account for peoples workflows, whether they agree with that workflow or not. But well see. Similar thing happened with new point lights but they’re standing firm on their decision.
And performance is worse sometimes yes as Hans confirmed in one of the bug reports which was closed with advise to simply not use modifier in that case and insteas you one-time operator.
Though in this case it does not concern a change that is a direct result of core architecture upgrades. I still think the core of the issue is that the modifier stack itself has never been a datablock type that can be shared among objects (even though objects can share Geometry Node trees, but only through a modifier that is unique to the object).
You can absolutely hotkey an objects modifier visibility. The issue now is with shading tied to a modifier, its going to look busted when you toggle that, which makes seeing what you’re working on difficult… which makes working more difficult.
The separation of these is a strength. The forced combination is a weakness, and a regression in usability.
It’s so easily described it’s literally not necessary. There’s no if and or but about it - they’re adding friction so it’s easier to develop features they want to add, while breaking a critical core component of modeling.
As I’ve already said, a video would just be modeling a hard surface asset and having to spam “auto smooth by angle” a thousand times throughout the process every time you make any mesh change to see the latest smoothing. Or, toggle all modifiers off, but specifically go back and turn on an Autosmooth modifier just to get to a state where you can see an asset with proper shading info on it.
We are criticizing the feature, which is being added by the devs. The change is being made by the devs in spite of significant usability concerns, and it’s going forward regardless of what anyone says because it makes other features they’re developing easier to develop. Not because it’s better for artists.
I appreciate that the thread is being seen, but disagree that feedback is being taken here.
At this point we should be so lucky for this scenario to play out, but imagine if it didn’t have to because… devs took feedback.
Sorry, I should have said “All modifiers on or off is not a binary setting.” You can toggle individual modifiers on and off too and just not turn off Auto Smooth. I don’t know if there’s an addon that adds this functionality to a hotkey but it wouldn’t be difficult if not.
Well, it’s necessary since for now they didn’t change it, which is very likely to be the case if you can prove it’s a real regression beside just having to adapt to change.
A video is indeed not likely to be very helpful but doing some test, coming with some number or simple proof on your everyday life workflow, that’s something that will probably convince more, and on top of that it shows a bit of commitment rather than just complaining…
Latter you seemed concerned about the modifier performances, and from what I get that’s why you’d be forced to use the operator rather than the modifier or there are other obvious reasons ?
Only if you have an aversion to workarounds that require 20 clicks up front and then no more clicks after you’ve set it up. But the workaround I have in mind is specific to a scene just containing a hero asset you’re actively modeling and not a full blown scene full of thousands of objects and hundreds of linked duplicates.
An unnecessarily long and complex workaround requiring 400 clicks too many and applied to an overly simplified scene that likely has nothing in common with your real workflow and projects:
I want to model ironman and need to toggle all modifiers on and off frequently but need Smooth By Angle modifer to always be on and always be the last modifier applied.
Assuming all parts of the model look ok at 30º (unnrealistically dumb assumption probably)
Make a linked duplicate of iron man parts and put all modeling related modifers on them. Put them in a collection. Use an instance of that collection in Geometry Nodes to apply smooth shading.
Now you can see and work simultaneously on either the original mesh without modifiers or the mesh with modifiers and see the smoothed result (and the eevee rendered result, and the cycles rendered result, and the wireframe view, etc because Blender doesn’t crash just because you have a dozen different viewports open )
I’m sorry, but in like 17 years I’ve never found myself in a situation where modeling a hard surface asset would somehow have been crucially dependant on a functionality such as autosmooth.
You’re maybe used to working a certain way, that’s fine. But the confidence in assuming it’s somehow a strict prerequisite to hardsurface modelling… that’s just… oh well… what am I even supposed to call that kind of ignorance?
I can’t help it, but the way I work, I kind of know beforehand, what the result is supposed to look like and what is or isn’t meant to be smooth. Especially so if it’s a hardsurface model.
My experience is very similar. For the last 17 years I do 3d modelling(it just so happens to match ), I have never found myself in need to constantly switch hard or smooth shading nor am I ever really bothered which one is on at the time of modelling. Even if I did, I would make myself a shortcut or a script and forget about it, but hey I see there is a modifier, so what are you guys even talking about?.. Everything works fine, doesn’t it?
I believe this has to be emphasized once again, because this is happening in all genres of software from word processing to video games. This is why I often promote what FOSS offers even in gaming because of how those organizations appear to now be among the last remaining entities that actively work against bloat and against the code becoming a steaming pile of spaghetti. A lot of companies and studios will usually not do this because it is not considered marketable material and code cleanup tends to be a lot of work (as evidenced by the BF having paid developers to do just that).
This also means you escape the cycle of switching apps. for tasks like photo editing every decade or so out of necessity, because what was once pristine is now a buggy mess filled with hacks and band aids, and to make it worse it later becomes a crash box that likes to corrupt data.
Finally, you also save a lot of money as it eliminates the need to constantly upgrade your machine to maintain your productivity levels (because again, way too many vendors would rather take the easy way out and let Moore’s Law optimize things, not realizing that performance regressions often go hand in hand with the things I mentioned earlier).
It is true that this will lead to people being inconvenienced and having to learn new workflows, but the BF does not force people to update, and it is better than the horrors people would experience otherwise.
)
)?