I’m not a professional AAA video game weapon maker or friends with any. That is probably also true of every programmer at Blender org. I never imagined a workflow where a rough concept for a gun is thrown together in 40 minutes using 1,783 objects. I’ve watched a few thousand free youtube tutorials and never seen such a thing. I’ve downloaded hundreds of free blend files over the years and never seen such a thing. This is why I asked for videos from the people with the most complaints. We got ONE adequately detailed post out of all this yammering.
3 Likes
Hahaha! I know, it sounds ridiculous and the stack looks crazy but believe me it’s fast as hell.
It’s not surely an orthodox way of modeling stuff, a good chunk of modelers for games still do things with SubD because it’s an easy to teach workflow and it’s robust and reliable, something important when you need to pass models along several people and outsourcers but very slow for production.
Fair point. My suspicion here is because most people who do videos and tutorials and share files online don’t work professionaly in the games industry but are rather scattered across multiple different industries. This is not a negative comment, just my observation: seasoned professionals that work on games and share their full process, let alone their files are quite rare, most of them are quite busy unless teaching is their side job.
Overall workflows are quite varied, it depends a lot on the studio pipeline.
For example, when I used to model in Maya, I was doing everything in SubD. Incredibly slow but lowpoly and highpoly meshes were basically the same thing (just add subdivisions), minor changes aside.
In Max, I moved on to using boolean and ditched SubD unless there is a specific advantage to using it (EG some organic stuff or those rare cases where it’s faster for some very specific workflow implications, but it’s usually very rare for me to use it). When using Max, I used to make highpolys in Zbrush: smoothing groups were getting converted into polygroups, polygroups edges were driving the mask by features tool in Zbrush and with a bunch of mask blur and polish, boom here’s the highpoly.
It was faster than SubD in Maya but still quite cumbersome: bakes were slow because of the heavy HP meshes.
In Blender instead, the midpoly work is pretty much the same I used to do in Max, just faster because of Blender’s nature, while the HP and LP meshes are something i can do in a day each with the use of simple bevels and face weighted normals.
Combining all this together, it’s way faster than any other method I’ve used so far.
Modeling complex stuff in CAD is much faster in raw speed but making the CAD meshes usable for game assets require cleanup that most of the time eats away all the speed advantage for mountains of tedious work.
If I get the time I can record a video about the Rhino I posted to go over how I made it and elucidate the process, It won’t be a full on demonstration on how much this autosmooth changes affect this style of workflow (and hard surface modeling for games in general) because I won’t be recording the moment to moment hindrances but It might give a better picture of the scope of the slow downs and the workflow itself for those curious
9 Likes
If there is one thing I am not a fan of in Blender development it is the insistence of ripping out old functionality when the ground work hasn’t even been fully laid for replacing it.This isn’t the first time when the devs decide to rip out something that people rely on for modelling. Remember Face Maps anyone?
I can see why it is becoming a modifier and I support the idea of it, but I don’t support just ripping out the old method when it covers so many use cases that would require heavy reworks of how modifier data works and a UI that used to be done with a single button press.
There is such as thing as a transitional period. If tons of modellers still want to use the old method over the new one, then there is obviously something seriously wrong with the new implementation. Build the new system first and implement the necessary changes until it is just as good if not better than the old method.
7 Likes
Isn’t everything between LTS releases supposed to be the transitional period?
3 Likes
And there could be an instanced region too at the bottom of the stack to manage and display instanced modifiers, that’s actually quite clever!
1 Like
Just FYI, 4.1’s new recap vid is up, the new Autosmooth is covered from 2:12 to 3:12:
3dsmax Smoothing Groups is one of the reason people switch to Blender.
Being built around parametric paradigm, Max has different limitations in mesh editing flexibility.
I just released a free addon for 4.1 that among many things adds an auto-smooth operation that works more like it did before in 4.0. The addon also has a bunch of other functions, but all of them can easily be turned off if you only whant the auto smooth function.
Let me know what you think 
15 Likes
Yeah, as my friend says, this is because amateurs (even skilled ones!) don’t often do things the way professionals do; the reason is that they don’t have people around them showing them better ways, and they don’t have the time pressure to try new things. Speed just isn’t important. The way that WHOOLKAN describes is completely standard within the industry. It’s why professionals are sounding the alarm.
13 Likes
I might as well chime in on this because my addon has a small dependency on the Auto Smooth panel they removed. 
What I liked about it is that users could change the angle and instantly see the results, it was also easy to get the angle data.
Another thing is that visually it’s nicer to see sharp edges without the cyan colouring, which is distracting in my opinion. Sharp Edges also clashes with Seam Edges, Blender only paints the edge one colour (seams win).
Modifiers will also always be slower than clicking 1 button. Something I never liked about 3dsMax is how everything takes multiple button / mouse presses, and having to use the modifier stack for everything. Blender’s shortcuts and operators are a 10x faster workflow.
It’s simple maths: less clicking = faster.
At least that’s how I think about all my UI designs. I always look for the minimal amount of button presses / clicks possible.
Anything that adds more clicks than necessary is in my opinion a mistake in the UI design. Even worse when it’s an update that adds more clicks than there were before.
But that’s just my opinion. I’m hopeful we’ll find workarounds for all our issues.
7 Likes
You can change that in preferences, I set it to a slightly green colour but if you set it to a light-ish grey it will look like all the others.
i will add my grain of sand to this. lots of personal opinions and speculation but hey, all respectful : )
-not being able to modify the autosmooth of instances created with alt+d is not great, and having to copy the modifier is incredibly time consuming compared to just having to select one instance and setting the angle of auto smooth, not mentioning it presents lots of problems when wanting to update the angle for multiple instances
-i don’t understand why the new option of Shade Smooth by Angle is in the right click menu, it is a destructive workflow, creating Sharp Edges, and it seems to me more of an afterthought for people used to the old way. also that option doesn’t update, so it’s not practical for modeling
-the smooth by angle modifier is nice but being a modifier presents lots of problems for the modifier stack. for one, and i haven’t seen this being discussed here, i don’t want to clutter my objects with modifiers. even if it’s cleaner programmatically or even if there is more performance to gain, conceptually the idea of having to put a modifier in ALL my meshes (because i pretty much use autosmooth for everything in my workflow) doesn’t sit right for me
maybe it’s because i’m used to the old way of autosmoothing, but it doesn’t feel right for me having it as a modifier. for me, modifiers feel more like a way of transforming the mesh, the actual shape of it, or UVs or some characteristic of it. the new Smooth Shader modifier even had to be put under a new category, “Normals”, and sure this category will be expanded, and i’m not opposed to it, it’s great as an option, but having it there just represents how much of a test of a new idea it is, almost like a beta version, and replacing the old functional Auto Smooth with this doesn’t feel right
also it presents some extra problems for my workflow:
-i have several addons and custom scripts that deal with the whole stack of modifiers, copying it, deleting it, etc. and having the Smooth Shader modifier whipped out or duplicated when running these scripts is not great. i could redo my scripts sure, and wait for developers of the addons to update, but it’s also not great having to have that consideration for that specific and crucial modifier. will have to add an exclusion case for that one modifier for everything that i do from now on? i hope not
-also have a workflow where i add modifiers from scripts and don’t need to check the modifier stack. lots of addons do that, specially modeling ones, so you don’t lose focus on the mesh. having to go back and forth everytime to make sure the Shade Smooth modifier stays on the bottom of the stack. simply putting: before i didn’t have to even go to the modifier stack. now i have, for every mesh. that is so much worse
-even if i get used to the new modifier or adopt another workflow, objects from previous blender versions import with the modifier at the end, even if i don’t want to, so if i have to add any modifier, i have to go and change the Smooth Shader modifier in the correct order in the stack
to me (and this is the most speculative part so take it with a grain of salt) this feels is a case of trying to fit everything into all-encompassing desing principes for the sake of it. i think geometry nodes is great, i think no one can deny that, but trying to fit this crucial feature into it, i don’t know, doesn’t feel right. i don’t have proofs, i’m not from the dev team, i don’t follow the development of blender closely, but it feels like it, specially knowing the existance of the everything nodes project
and i think is good to have design principles for new features but maybe sometimes you can leave different options for the people that use the previous and perfectly functional previous feature
it reminds me of this video by tantacruel about Reason, a music software that at some point had to face the question of breaking their perfect logical system in favour of user experience. and they did it, they did brake it, and it did work. could this be the case for blender?
this is speculation! but here is the video, recommend it if you like software development: https://www.youtube.com/watch?v=7PFRyONURSo
to wrap it up, i write this with the most LOVE for blender and the development team! i live off of blender, day to day, i’ve been using it for more than 10 years, i have given money to the blender foundation, i recommend it to everyone and help my friends and anyone asking with it and have started to make tutorials and was super excited for the new features, specially the gpu denoiser in viewport, so dope! but this Auto Smooth situation is such a deal breaker for me
been putting so many hours into thinking how can i change my workflow to accommodate for this new feature and i haven’t been able to find an answer, so i wanted to contribute with this comment
hope everyone is ok! and shoutout to WHOOLKAN and nickberckley for also sharing their concerns and doing a great job of summarizing the important points, i just wanted to add to it
13 Likes
I don’t mean the colour itself, I mean that it overlays the shading and clashes with seams edges.
You can also disable overlay from Edit Mode overlays. This is non-problem. It’s actually improvement, I wish modifier also displayed those edges. I would disable them by default, but would always have the option to see which edges are sharp. Would be fantastic debug tool
1 Like
So … the next big problem to solve here would rather be to push another feature with a bit more emphasis, like being able to add one modifier to many selected objects at once or even edit the values for many selected objects at once, right? *hint *hint
Having the destructive modal in the shortcuts is also something I am really torn about. On one hand it’s good to have it quickly accessible. On the other hand it sits amongs non destructive settings and can easily be misclicked, which is something I always disapprove of if it can be helped.
2 Likes
The right click method has the advantage that alt D instances all use the same smooth by angle (without a unique modifier), the main disadvantage is that it does not auto-update while editing the mesh.
Also no need to worry about modifier stacks.
I would prefer to keep the option and add the possibility of auto update as a checkbox (for performance).
2 Likes
that function does not work like the 4.0 auto smooth, I just want the 4.0 auto smooth back
4 Likes
Me too.
its nuts that people call it improvement.
One YouTuber called it a new feature that you can set edges to be set sharp. Says a lot about how much they actually know the software.
One thing I noticed in 4.1 rc is that the autosmooth is now translated in a geometry node at the button of the stack, before it was above. So they are capable of improving things, however this is just a small fix as many on linked mesh often only one object get the modifier. Well, it’s nuts anyway, as it completely ruin the idea of linked geometry to save performance.
Just had the case, where I had to rerender an older scene, did it in 4.1. Got many normal errors and GPU failed do to lake of memory. The scene just needed much more RAM do to silly ‘performance improvement’ like its official called.
3 Likes
Of course they are able to improve things. Something else that would be helpful in that regard is if this community wouldn’t piss off the developers.
6 Likes
Do you mean they would purposefully refuse to consider issues, workflows or fix bugs out of spite?
I don’t believe that.
Although in general being civil is better, yes.
2 Likes