Blender 4.1 Auto Smooth is now a modifier ONLY!

Like I said , I love nodes with all these creative ideas.
but for me as game artist I don’t rely on it .

it will be pain if every time I model I need to open the nodes and start connect one by one. modifier still fast to handle.

its case by case like I mention, some are game artist other are creative with nodes etc…

1 Like

That’s why nodes are best used with Asset Browser and why we have this new modifier menu - they are just custom modifiers. Wait for someone to do it, or do it yourself once, and you have a modifier instead of a bunch of noodles to connect.
I doubt the “standard” modifiers will ever actually be removed - they’ll change under the hood, but it wouldn’t make sense to make them any less accessible :person_shrugging:

That said, I feel like lately there this irrational fear of geonodes spreading - as if it’s demanding anything beyond the knowledge that you need for everyday modeling and trouble-shooting :face_with_raised_eyebrow:

But on the bright side, we don’t need to wait forever for some dev to implement things like easy-to-use Radial Array modifier (no empties required) :+1: We have POWER now, that we didn’t have just a short while ago.

10 Likes

Exactly!
Recently I got the impression some modelers fear they would need to create geometry nodes for every model. I don’t know how this kind of impression appeared.
Just as you said, modifiers are here to stay. So far, if you wanted something slightly different from a modifier, you had to find workarounds and tricks to achieve the wanted result.
Now, geometry nodes might be a viable way to solve the problem. Even better, if the modifier is already a geometry node, it might require very few changes to achieve your goal.
Or if someone has a very unusual workflow that requires extensive use customized modifiers, that was not feasible so far without modifying the source code. Now, there is a real chance the results are achievable with geometry nodes.

4 Likes

What you are afraid of is definitely happening. But you should not be afraid of it at all.

The “bad news” is that there will be way more modifiers and they will be more powerful and easier to use. You don’t need to create them, they will be created for you, but you will be able to create your own if you want to. What’s so scary about that?..

Are you sure people in those areas are unhappy? I do archviz, and I am very excited about nodes. Do you think I am alone?

2 Likes

The goal is not to make the software, slower.

You can still use current edit mode tools.

If, in the future, some of them are replaced by node tools assets to be more powerful or performant ; you could have to launch the asset before being able to use the tool by default.
But, in that case, that would probably possible to save start-up file and preferences to avoid to do that for each new file, like what exist currently for addons.

Auto Smooth property was a property that had to be evaluated by modifiers.
As a modifier at the end of stack, a performance gain was obtained.
That is an issue, that user cannot force a modifier to be the last one.
But issue is specific to particular case of mesh properties converted into modifiers.

That does not exist for conversion of old modifiers into node modifiers or edit mode tools into node tools.

Nodes are there to bring a simplification.
One nodetree may replace use of multiple modifiers or multiple tools.
There is nothing wrong about not using them ; when it is simpler not to use them.

2 Likes

The fact you are posting this in THIS thread where we discuss THIS very problem (oh, the irony) is evident for the opposite.
People are rightfully critical of the mindset of the devs who prioritize GN over other aspects of Blender. Especially since modelling, UV’s and other asset creation disciplines haven’t seen a meaningful update in a while.
There are a fuckton of low hanging fruit problems in regards to UI/UX and general data management that causes a fuckton of extra work to the user that could be removed very quickly if there where was the will to tackle it.
Instead we get a regress in workflow because the implementation of GN functionality isn’t up to snuff (which could be easily avoided by implementing it in parallel while keeping the old workflow, like it is done in every other DCC).

What is the difference between waiting for someone to build the tools and waiting for somebody building tools so that other people can build tools?
The latter takes longer and does not give any assurance that you’ll get what you want. Worst case scenario, you have to wait for them to build the tools, so that you can learn how to build the shit you need yourself…
Great.
Why not switch to Houdini right now and have both the low level tools and the high level wrapper of the tools?

The idea that GN will magically solve all kinds of problems that exist in Blender is nothing but a dream right now.
It has become the de facto excuse to push things into the future instead of tackling them right now.
Given the proclivity of the BF to do things in a special way (instead of a standardized and proven way) and the track record of delivering things half-done, I see the near future as a potential nightmare of consistent mediocrity.
Yes, Blender is constantly improving, but it isn’t improving in the areas that would give it the biggest boost in productivity.
Blender is like a swimmer that constantly trains his arms and gets more muscular while he ignores the fact hat his feet are tied together.

7 Likes

The developers of Blender, though paid these days, seem to be mostly free to work on what interests them, and that’s exploring and developing new technical solutions. Solving soft value design issues (like UX paper cuts) seem entirely uninteresting to them and they seem quite unbothered if they accidentally introduce new ones if it makes their job easier, and maybe that’s the way it has to be in FOSS, but this is the BlenderArtists forum and… well… perhaps we should be using this instead (in fact, I’m curious to know how they will handle this).

1 Like

If it works for you - more power to you, but it goes against my personal preference.
From Bforartists:

This means a complete switch in the usage philosophy away from the hotkey centered UX towards a user friendly, discoverable and intuitive graphical UI.

I want my hotkey centered workflow, but I also want a user friendly and intuitive UI that gets shit done with the least amount of clicks or button presses.
For me BforArtists is a step backwards.

1 Like

Could you give some examples that would have a greater impact than movement towards everything nodes?

Also

Don’t you think nodes touch that?

It’s literally not about “greater impact”, and that’s the core issue! It’s a hundred small, boring changes which cumulatively add up to hours of saved time in the end, but that work is too time consuming for the devs to sift through (I think I already linked in this very thread to their previous shut down efforts a few years ago).

3 Likes

The way I see it, there are many workflows and those have hundreds of little inconveniences that are different between those workflows. Fixing regular tools can only do so much, isn’t a system where users can address the issues a better approach? Geometry Nodes Tools seems to be a good idea in this context. Besides, keeping in mind the rate of development in the past, do you think it has slowed down for those boring changes that you are talking about?

1 Like

Imo, geometry nodes can only do so much. :wink:

No, I guess it’s always been slow for as long as I’ve used Blender. When we went from 2.79 to 2.8 I thought they’d woken up to the importance of UX, but it was just a one time event. Pablo Dobarro got my hopes up again for a period, but then he left.

Well, obviously blender will keep having all the main functionalities of every DCC.
Furthermore node tools should integrate as seamlessly as possible just like addons to a point where users shouldn’t care if it’s C, python, nodes…
Finally it’s less about more common tools but it’s more about specific tools / functionalities that nodes could be really useful.
I can give few examples out of my mind :
1/ tension maps : they were never implemented in Cycles/Eevee, and now it’s pretty easy to emulate that functionality until it’s finally implemented.

2/ hair tools : Blender ships some nodegroups to do grooming. And we can easily expand on that, creating specific workflows : Mesh to Hair with Geometry Nodes , nodes allows rapid evolution / prototyping of tools that are likely to be artist friendly and production efficient since it’s made by people who will use the tools.

3/ particles systems : I don’t know how long do you do blender, but the current particle system is pretty old (IIRC ~2010), a bit cryptic in some places unfinished in others, and it was left like this until now.
Even if it was rewritten now it would probably end up in a similar situation, as it’s a complex tool that needs to cover many use cases and it need a lot of time and feedback to be polished perfectly.
Obviously at some point we’ll have particles nodegroups shipped in that will replace the old system. But it doesn’t really matter if this new system is perfect/complete or not as it’s now much more easier to make one tailored for a particular task.
In this new way of working, BF / Software engineers make sure the core tools show as less limitation as possible, they focus also on optimizations and so on.
And us artists that works on production environment can take care of the final interface and functionalities. And if a problem occurs most of the time it’s just a matter of adding a few nodes which is much easier than updating a monolithic tool.

These use cases might not be interesting to you, and maybe you are more into modeling, but in these area too there is a broad range of specific tools that are possible. Maybe something where you select a edge and convert it into a zipper ? Adding procedural damages to a mesh, building pipes, ropes, roof tiles …

2 Likes

This is not necessarily about nodes or no nodes (I am actually in favor of nodes) but more about what you can archive with the tools.
I had expected that the BF would concentrate their work with GN at some point on more systemic data structures like Instances, groups, collections, linked assets, (mass) material assignments, overrides, group/collection modifiers/GN networks etc.
All of that needs to work properly via UI, and all of that needs to be turned into nodes.
Having GN only as an object modifier is a very limiting idea, it needs to be scene wide too.
The BF is still trapped in a single object workflow mindset and it’s slowing everything down to a snail’s pace.

Building a scene with 3000 assets and having to manage 300 materials with Blenders retarded material assignment is an constant and never ending nightmare.
Material assignment and management of materials of multiple objects was invented 25+ years ago, all of the competing DCC’s have a better solution than Blender right now and this doesn’t even need to be done with nodes (but can be).
It’s quite pathethic if you think about the amount of man-hours wasted because of this alone.

Giving the user the ability to build tools inside of Blender is great, the node tools are a great addition, but this doesn’t make up for the flaws in other essential areas.
Even if all of the physics tools for example where available via GN it would change nothing about the quality of the actual solvers.
I’d rather have a better solver in a blackbox tomorrow than the potential for a better solver in GN in 3 years.

Do GN nodes provide a better unwrap algorithm? Or a better UI for the UV tools…?
Better handling of UDIM’s?

I hear the argument that GN will make Blender as a whole so much better all the time, but I have a hard time seeing the trickle down effects on my productivity nor do I see any movement when it comes to the core problems.

7 Likes

I think keeping the modifier stack makes a lot of sense, having current modifier using nodes internally too.
Users shouldn’t be forced to use the node editor, but it’s amazing to be able to improve modifiers or create new ones.
Or do everything within one GN modifier, I think the goal is to expand the possibilities rather than enforcing one workflow.

2 Likes

My perspective is very different. I see significant improvements in my own work and all around because of Geometry Nodes already.

3 Likes

Usability wise, I have compared them, and the built-in default bend modifier is atrocious. I have two or three bend node setups, and all of them are better. Ditto for twist and taper.

3 Likes

Geometry Nodes are already solving problems which existed before. Not sure why this should be a dream…

They are literally not focused on Geometry Nodes at the moment, to push other areas…

2 Likes

I think they’re just gun shy after the first version of Geometry Nodes flopped so hard(from a technical standpoint). Now they’re taking everything really slow and being deliberate with what they implement to make sure that doesn’t happen again.

But yeah, I want to see Geometry Nodes expand into scene level and beyond too.

Scene nodes is planned, but there is no date to start work on that at the moment.

As for the rest of the debate, I think everyone can come to an agreement that the traditional toolset will also need to see continued updates. Geometry Nodes is very powerful, but last I checked the idea of Blender becoming a highly complex and technical app. with a high learning curve to do anything contradicts the BF’s own statements talking about how “Blender is for artists” and that “Blender is putting the fun back into 3D”.

The traditional workflows and the new node-powered workflows do not need to be exclusive, so the idea they cannot live side-by-side is a myth at best. That said, the team is not all GN now, as for starters you have the work on sculpting and the plan to finally fix all of the major workflow issues.