Not necessarily saying that you are wrong, but I personally find it more or less impossible to organize my node trees in Blender.
I’m a nuke artist by trade and have dabbled some in Houdini, so it’s not that I’m not used to working with nodes. The problem, as I see it is mainly that the nodes in blender are horizontal only. In Nuke and Houdini, your main tree is vertical and when you combine nodes you do it horizontally. That means that you have three directions to use when you organize.
Theoretically, you can also do that in Blender, but I find that it’s more or less impossible to do that in practice, and have the node connections be easily readable.
To illustrate. Here is a quite simple network in Blender, that I structured to the best of my abilities. However, I still find it completely unreadable and if I were to do something similar again, it would probably be faster for me to rebuild it rather than reuse this one and tweak it.
Difference between top-down and left-to-right is not a thing. It works the same way, you’re just used to one way, which is much worse in my opinion.
And only difference I see in your comparisons is that Nuke node-tree uses straight-lines, so connections are more visible. Why not do that in Blender with reroute nodes?
Nuke uses colored frames to differentiate between networks, why only black frames in Blender?
Why giant spaces in Blender variant?
That node tree can be optimized MUCH better, that is not best of your abilities if you’re that familiar with nodes. Why Blender not like other software isn’t an adequate criticism
I’m curious, why do you think its worse with a vertical network compared to Blender?
I’m very much open to that it’s me not being used to horizontal networks. However, I do believe I have a point that a vertical and horizontal tree allows three distinct directions for organization. Where a horizontal one can’t really do it as neatly.
Sure, you can “physically” place your nodes the same, but since the connections are only allowed to enter from one direction it does not work in pratice. Also, you have to spend a lot of time cleaning your network.
I gave a bad example with my screenshots. The Blender network was only used by me, so I tried to make it readable for me only.
The “groups” are spaced apart to avoid having the connections overlap. Sure, I could add more reroutes, but then I would have to spend a lot of time just moving the reroutes whenever I added nodes.
I had to tidy up the nuke-project a bit more, because other people where gonna use it. Normally I don’t ever use frames to group the nodes
Can’t send you the Blender file, as I it was used for a commercial project. But I would really appreciate if you could point me to a blender file that I could use for inspiration.
Sure, that is a great looking tree. I still think it’s quite hard to read with diagonal lines rather than only vertical/horizontal. Especially when they sometimes move backwards. But maybe that’s down to me not being as used to Blenders networks compared to nuke.
That being said, it must’ve taken ages to organize that network. You hardly have to spend any time at all doing that in nuke.
My node trees are very nested and I can’t give you good example without multiple screens of multiple levels, and all of them are short in themselves.
Groups aren’t just useful for reusing and splitting, they can be whatever you want. For example if I know that certain input expects a texture, I make node group for that texture and do as much nodes I want in there. I only need one output, so whatever I plug into that output, or whatever is evaluated before that can be in node group. I almost never make very big node trees.
Recently I updated my gn modifiers as I found multiple things I was reusing over and over and could’ve been separate node, or modifier even. This is what it looks like now:
This shows why I like left-to-right. It follows the direction I’m reading. I know some languages are top-to-bottom, but mine is left-to-right. And I can setup node trees that follow the reading pattern, that way I can “read” the node-tree in a logical way follow the pattern easily.
In your nuke tree some things make it much harder for me to read. For example, all links are black. In Blender color is very easy way to identify what data is flowing where. See how easily you can find geometry-flow in my example. You can find input checkboxes with short pink lines easily. Add to that different ways lines are drawn to differentiate between different stuff. As well as different colored headers, frames, everything. You can even put entire text data-block there and put a poem if you wish.
Yeah nuke’s design is great and blender nodes works better with simpler graph.
I think it wasn’t built with big trees in mind, anyway, with a bit of practice it’s still possible to manage IMO, nodegroups can also help to organize things to avoid too big graph.
But anyway, here are a few tree of mine as examples :
I guess I have to be better at using groups, and I definitely can do a better job at organizing my networks.
I’m still convinced that Houdini and nukes node trees are superior, but I’m not going to convince anyone.
My one argument is, yes, you read left to right, but you also read from top to bottom. So having a node network being built around top-down, left right is essentially a 2 dimensional network, where as a more left to right network is 1 dimensional. While 1D works great for small networks, it’s to limiting for complex ones.
For completion : if I remember correctly Nuke does not enforce a direction, it’s a matter of convention, right? I haven’t touched Nuke in a decade and Houdini uses horizontal graphs for vopsops, of which Blender’s function nodes are the closest equivalent.
Ultimately Blender’s nodal interface is not yet quite as refined as either of those two, and it’ll take some polishing to get it to the same level. Rest assured this is being worked on as you can see here for instance
I shared this before, it’s a tree generator. Honestly it’s not complicated to make it readable. Basically take your Nuke tree and turn it on its side…
Groups and frames along with reroutes is the way to do it!
Houdini has higher level nodes generally, so less nodes but you can dive into them (just like groups)
Geonodes is lower level so you have to make yr own reusable groups, then that abstracts away all the stuff that would otherwise confuse you (and me) later.
My point was, I don’t need to use frames in nuke in order for me to understand what I’m doing. In blender it’s essential. It’s possible that’s because I’m more used to Nuke, but I don’t think it’s only because of that.
You do have a point with Houdini however. You generally don’t use that many nodes, since there are so many premade groups, and if you (at least I) dive in to those groups, they are also very confusing.
The trees in geonodes should be a lot more readable when you don’t need to build everything from scratch.
Could be.
However, I’m fairly comfortable using a lot of different applications and I would like to think I have no issues adapting to different workflows and seeing the strengths and weaknesses of each app in a somewhat “unbiased” way.
It also seems that everyone else that have used both nuke and Blender and have commented here agrees that nukes nodegraph is superior.
That combined with the fact that nuke is both vertical and horizontal compared to Blender being only horizontal is enough for me to think that I MIGHT have a point.
egad, I see a lot of repeating patterns, meaning some things could have been sub-graphed. Tsk-tsk. But the routing is looking decent, at least on the larger scale. Could use more color coding perhaps, too.
I do have to say that I agree with @yewn on certain things. Nodes could be made omni-directional. And I would like to have a user settings option for ortho-directional node connections(3 segments, straight axis-aligned lines only) with the idea being that no connections should ever overlap line segment over line segment or corner over corner. They should only ever cross middle-some over each other.
All it does is evaluate a tri’s vertex positions for a given tri. Sure, you can put the four framed nodes into a group and expose the Offset -parameter from the Offset Corner in Face -node.
But what difference does it actually make besides saving nodetree-real-estate?
As things are standing, you’d just end up with this instead:
Yes, it saves screen-real-estate, but how is it not still a repeating pattern?
Underlying problem here is we have (to date) no way of making something which evaluates to those numbers 0-2, other than some beyond-ugly hacks like if you packaged it into a Repeat Zone and had it evaluate one vertex position per iteration.
Blender nodes do require a bit more user intervention to keep tidy, but so do like, bedrooms and kitchens and stuff. You can be very tidy, or a total mess, it’s up to you.
a big one for me is keeping the data types orderly, particularly in GN, I generally keep all the green geo lines at the top of the tree:
you can see the float and vector data flowing in from below, but generally the geometry is what matters so keeping that straight is the most important
in shaders, I try to sort my data operations from least complex to most (floats > vec/col > shader). This was initially an optimization procedure, I would see a lot of people mixing shaders just to mix color, if you can just mix the color, your shader will perform much better:
I’ve also seen some intentional obfuscation via muddying up the node group to protect IP. One node group I got from somewhere was packaged up in a group, and inside that group, they had removed all sub groups and scaled all the nodes to zero, so there was like 100 nodes mashed on top of each other. Technically all the wiring was intact, and it worked, but if anyone wanted to edit that group, they’d need to spend a week un-fscking it.
That is the point tho, and the repeating patterns(perhaps I should have said complex or noisy repeating patterns) were an indication that they could have been sub-graphed.
Is great to see that trees others make, are exactly the same as mine in terms of design choices and principles:
bezier line connections are lame and serve no real benefit (they only make line connections look nice – but they generate more vertex points that essentially slow down the viewport)
straight connections are better and efficient, however you need to do a lot of micromanagement to place intermediate points and reflow the connections properly (form square-diagrams or metro-diagrams)
using groups is reasonable if you want to reuse node-clusters, but the real problem is that groups always hide their contents and you loose the ease of looking at the graph and edit contents of groups
using borders as containers to put clusters of nodes makes things more clean and tidy and bring proper sense of flow to your diagrams – however the problem is that you can’t reuse them (see problem of groups)
perhaps at some points you might have a connection starting from the beginning and after 1km of length ending on the end of the nodegraph – this is just brings clutter – essentially you would have to spawn the same input nodes closer to where you need them instead of making long connections in order to reuse the same sockets everywhere (perhaps there are other solutions as well, such as creating some sort of BPY variables or something?)
I have very similar gripe. It’s a shame that frames do not enough attention UI-wise.
Some time ago I started to look into design principles for merging frames and groups into one feature but I never fleshed it out properly.
and Houdini uses horizontal graphs for vopsops, of which Blender’s function nodes are the closest equivalent.
