I’m not convinced that’s the case. First of all, it’s way more flexible and certain effects may be easier to pull off and some might be doable at all that currently just aren’t. The current brush engine requires you to go through long lists that don’t entirely fit into the menu so you gotta scroll and might not even notice some checkbox is checked and it’s actually quite cumbersome to troubleshoot. In a node editor, if there is no influence by something, there will not be a node. So for simple setups you can see at a single glance what might take some digging in the current menus. For more complicated setups either of them take time.
I don’t think a node editor would make this process slower. It might be about the same with some situations that take slightly more time and others that take less time.
But the added flexibility is a real benefit that the current design just can’t hope to match.
That might change with the Everything Nodes project that is currently in the works (but has only just begun) - and honestly I find Blender’s current approach in that department rather confusing despite being much simpler (in that there are as yet fewer features) than in Krita’s brush engine.
I also don’t think the general sentiment that 3D folks are just more used to nodes is entirely true either. Blender makes great use of nodes and so does, say, Houdini (Wherein that worflow REALLY gets to shine) but for the most part I’m not sure that they are that prevalent throughout 3D software. They are certainly on the rise though. So 3D folks had to settle in for this change. It had a learning curve associated with it, but it worked eventually.
And I think the same kind of trajectory can happen in 2D software.
Indeed, the entire node-tree for a given material also is visible in an automatically laid-out menu that handles all the nesting accordingly. It’s a really good tradeoff, imo, between simple and complex stuff. Really simple brushes won’t make it necessary to view the actual node tree at all, but complex stuff is gonna be confusing to look at in that menu, and it’ll be advantageous to look at all the nodes to get a better feel for what’s going on.
I think this is what’s meant:
This is two views of the same material. Once in the node editor, once in the materials tab. For really complex, deeply nested node setups it’s easier to just look at the node tree, but for simple stuff like this, all you need is in the materials tab, ready to be tweaked.
The right menu is entirely automatically generated based on the nodes.
I don’t think there is any situation where a proper implementation of these ideas would make that necessary. That being said, it’s already a problem due to different brush engines and stuff. Some options only work in certain engines, which can actually be confusing at times.
That’s fair. There are surely lots of details to carefully consider. The different brush engines among them.
I don’t think that’s really a problem. It’s more complicated to special-case things. A proper modular design might be technically complicated in that the combinatorial complexity is large, but actually it will be relatively easy to wrap your mind around as modules tend to make sense.
Yup, the order of operations is entirely fixed and no matter what choices you make there, there will be situations where the current choice is wrong.
The thing is I question that the current system is all that easy to read. I think in terms of that this will mostly be a wash.
