FYI:
Geometry Nodes: Hide values for selection inputs
Toggling the selection off in the node is the same as muting it, so exposing it there doesn’t help, and makes it less clear that it’s meant to be used as a field.
2 Likes
Thanks for the link. Now I see.
But I still think it can be useful. For example, in the “Shade Smooth” node I suggested, not checking the box would be flat shading. If you have a mesh that is alredy shade smoothed, uncheck this box can make it flat shading. (although the logic might not be selecion now in this case) I still believe the checkbox can be useful.
Another thought. Maybe the current nodes can stay without it, only those nodes that need it will have the checkbox, like the “shade smooth” in the future. The delete geometry node would need to change its behavior from deleting nothing by default to delete everything by default, etc. to satisfy the condition of “the same as muting it”.
There’s a “Hide unused node sockets” shortcut which makes the multi-output node look identical to the individual ones we have right now.
2 Likes
Yes but people still tend to use the big node and long connections with it, it’s more psychological I think. And don’t forget we have this compact node design: ⚓ T87009 Compact Nodes
So this big chunky node UI is an officially admitted problem. Although I would argue instead of having the N panel opened all the time workflow, I would prefer to just have collapsible parameters on the nodes. I am part of those who only open the N panel when I have to.
No one considers that a problem in the shader editor. Plus we are literally talking about just grouping geometry info nodes together like object info and collection info. It makes sense from the consistency standpoint.
The lowest common denominator for the design should not be people who don’t know how to use nodes properly. You will get the exact same problem with the Group Input node, where people tend to use one group input with many long wires instead of multiple group inputs with hidden unused sockets. Yet you don’t see anyone talking about group input node redesign.
3 Likes
I did a little experiment a while back with the prototype branch. I have two versions of the same node tree.
The first one tried to use less nodes but have some long connections.
The second one tried to eliminate long connections by using duplicated nodes.
And I took these two screenshots and ask people which of them they think looks less messy. Most people around me picked the “more nodes but shorter connection” one.
I started to duplicate the group input node around ever since.
So I would lean towards the smaller nodes, I beilieve having them in their own shift A category is already enough for organizing, now they feel all over the place just because they are mixed together with other types of input nodes. It would feel nicer after they are in their own category.
EDIT: I just recalled this, the reasons why Attribute Processor was abandoned:
So it is an officially admitted problem, and new nodes should avoid stepping in the same problem as the old nodes I think.
2 Likes
I think you are mixing up two different problems. Your solution just offloads the clutter somewhere else. If we have one unique node for each input then the total amount of nodes available in the add menu will be much higher and it will be harder to get started with GN just due to sheer amount of nodes.
I am still not sure you understand what I mean. The result will be the same:
And also keep in mind that the GN version of the Geometry Info node would have way less inputs than the Shader Editor one, but if some inputs needed to be added to the GN, we would not see a spike in the amount of clutter in the Add menu.
Furthermore, the Compact Node design you mention is from a significant part consequence of early inefficient Attribute based GN design which required many nodes to have excessive amount of inputs for the individual attribute operations as well as additional inputs for an attribute to store the result in. I reckon that with the Fields system, this issue will be way less pressing, and we will probably get around without needing such heavy machinery for customization of the slot display at all.
To me the compact node design really feels like a solution for a problem which has been artificially created by the initial, string attribute based GN design.
2 Likes
Having a Geometry Input node also seems like a good idea to me…
Currently one of my biggest hurdles with Geo Nodes is access to information that isn’t available yet, like Polygon Size (even though the old instancing already supports that):
We’re going to need to access a lot of data in the nodes, and this would really clutter/overwhelm the creation menu if each one is an individual node.
On the other hand with too many ports it would be an uber node so that could also cause problems, so I’m not 100% sure which is best here.
Maybe separate Point, Polygon nodes would be ok if each one of those would have several useful ports.
1 Like
The “compact nodes” idea has been around for longer than that. In some versions of it, it completely rids most nodes of all “non-essential” sockets and moves all settings, including those that are not exposed as sockets, to a different place (a different editor or the sidebar). It’s a change in paradigm rather than an interface cleanup (see Nuke or Houdini).
It was indeed a good candidate for helping see clearly through the rather complicated attribute nodes, but those were never the only targets.
That being said, I agree that different geometry variables should be accessible through the same node. We could even have a version of “compact nodes” that only pops output sockets on demand, by dragging from an otherwise empty node (that’s just an idea).
I am not convinced on compact nodes. I mean who decides which node sockets are essential and which not? As long as the node socket deserves to actually be implemented in the node, it means it has a reason. Then, the decision which node sockets are essential basically becomes (usually faulty) assumption of user intention, which no one can properly do in advance.
So if that really becomes implemented, then the easy workflow of “Add a node and start using it” becomes slower, more frustrating workflow of “Add a node, tinker with some UI panel to actually expose the inputs first, and only then start using it”.
You can already see it with the “feature” which automatically reconnects a node wire into the next input socket below if you drag a new wire into already occupied socket. The simple “Drag a new node connection into occupied node slot to replace it” workflow became more frustrating “Drag a new node connection into occupied node slot to replace it, then disconnect unintentionally created node link below”. Assuming user intention in advance almost never works.
If there are nodes so complex that they actually require some node input management system, then perhaps those should be broken down into smaller, more atomic functions. But I mean, throughout all those years we have complex nodes such as Principled BSDF shader, not many people have really considered this to be a problem. It feels like a solution in search of a problem, exactly like the automatic occupied slot node wire reconnect mentioned above.
2 Likes
The user, through deliberate inclusion. It doesn’t mean that sockets should be hard to access, though. Like I suggested earlier there could be a way to drag out a noodle from the compact node interface, choosing which node property to connect and making the connection all in one go.
I completely agree with this. I don’t like side-effects either. I mean not the company, they’re ok. But trying to predict user intention pretty much always gets in the way imho.
I have seen it brought up many, many times. The principled bsdf is too big for many, including me, and some nodes in gn are bound to get equally tall if not taller. I agree that in principle nodes should stay simple, and complex setups should be made into node groups. However that probably won’t be the case for all : the raycast node is a prime example of that. How do you even break it down ?
Are you familiar with M ? all its node editors including the legacy ones have a way to connect attributes in a very non-intrusive way. I used to not be fond of this, because it’s a little more hidden than having all sockets exposed right away, but now that I know my way around the node systems much better, I like having this little “plus” icon that expands and gives me a list of available sockets to drag from.
I should mention why I think there is a problem. Node trees can become extremely large, as you know, and even my best efforts to pack every utility into a node group, the use of frames, reroutes, etc. doesn’t get the tree to nearly the level of readability of, say, a Nuke node tree.
I guess this could be improved through simple visual changes, such as the node title size, and so on. but I think the issue goes deeper : scanning a node tree is harder when you’ve got plenty of properties and checkboxes in the way, at least it is for me. This is why I think a compact node design is worth pursuing.
AFAIK there’s no raycast node in the Fields GN version that’s currently in master, and the raycast node in the old, attribute based GN was actually a prime example of the string attribute workflow being the cause for excessive amount of nodes.
If you look at it actually:
https://docs.blender.org/manual/en/dev/modeling/geometry_nodes/geometry/raycast.html
You can’t really perform a raycast without source and target geometry, ray direction and ray length. So for you to be able to use that node, all those 4 inputs would have to be immediately available anyway. Otherwise you would always have to manually expose additional inputs to even be able to use the node correctly. That would not make sense. All the inputs prefixed with Hit would actually be outputs in case of Fields solution. That leaves us just with the “Target attribute input being the one that could not be exposed by default”. If even one of the most complex GN nodes would have only one of its inputs hidden by default, would that be really worth it?
I still feel like everyone keeps forgetting about the “Hide Unused Node Sockets” feature. I mean the resulting state we all want is exactly the same in both cases. We just want more readable node trees by not seeing visual clutter caused by unused node sockets and their values. Something like this:
But there is significant difference in way this can be achieved:
A. Existing “Hide Unused Node Sockets Feature”
- You create nodes with all the sockets
- You connect all the sockets you want to use together
- You can select one or multiple nodes, press one hotkey (H in my case) and instantly get the result on the left looking like the result on the right.
- If you want to revert it, you can just press the hotkey on the same selection again.
B. Using the Compact Nodes proposed design
- You create nodes which may or may not have all the sockets you need exposed.
- In some case, you need to go to some UI panel and expose the sockets yourself
- You need to do this individually for each node, you can’t perform this operation on multiple nodes at once.
- If you want to revert/adjust it, once again, you can’t do it in a batch easily.
In the solution A, there is no room for error by assuming how users want to use the given node in advance. Solution A also does not require adding whole new functionality to Blender, with it’s own relatively complex user interface. Both solution A and B will in the end result into node network trees of the same readability.
I am not familiar with M. I suppose it’s something similar to Compact Nodes, but something that addresses this issue better than the ⚓ T87009 Compact Nodes ?
Anyway, I encourage you to try following: If you have any complex GN node tree which uses fields, try to just select literally all the nodes and use the hide unused node sockets operator. I use custom keymap but I believe the stock keymap hotkey is Ctrl+H. You should see a cleaner node tree instantly. Then, after you try this, ask yourself, how much different would the final result be to what you’d get with the proposed compact nodes?
(It won’t work with the string attribute one, as if I remember correctly, the attribute field with a string in it is still considered unused because the node socket doesn’t have any wire going into it)
2 Likes
I was talking about the software named after a famous south american civilization, lol
The case of raycast node was just an example, and I think it does work : out of the five (!) returned attributes (is hit, hit position, hit normal, hit distance, and custom attribute), the user may need only the first one. The use cases for this node are so wide it doesn’t seem worth debating about them, but this seems like a good example of where the user may want to leave out certains output sockets.
Hiding unused sockets is nice, and I do use it ! but it prevents the user from interacting with them at all. I would be fine with it if there was a way to access hidden sockets. Having a compact view is bound to make socket-connecting somewhat more indirect, of course… but it shouldn’t be that much more difficult : right now we have to ctrl+H once again over a “hidden” node if we want to connect any one of its properties.
I would prefer that toggle to be made into a nodetree property, so that we don’t need to select all nodes before we can make them compact.
Unless we really want to keep a hybrid system ? where some nodes are completely exposed and some others are not ? I don’t know about that.
Another thing to keep in mind is, ctrl+H hides unused sockets but it also hides properties you might want to keep handy for tweaking by hand, instead of connecting them.
edits for formatting
Smoke, fire, fog, fat solver, sweater solver, ocean solver, including particle nodes… is there a plan for these?
This was mentioned recently on blender developer blog:
See: Simulation Solvers
1 Like
I don’t deny that the Compact Nodes solution does have some small advantages, but I still think we’d be better off by improving the hide unused node sockets functionality rather than reinventing the inverse version of the wheel with the Compact Nodes. We could just have some UI element next to each input in the side panel to “pin” the node sockets, which would then resist being hidden. This would still be less hassle because it would be small improvement to an existing functionality compared to a large new feature set directly competing with the existing functionality, leaving the user confused when to use which.
I really think that the current socket hiding solution (perhaps with just a few minor tweaks and addition) is sufficient at achieving what we desire - the cleaner, more readable node trees.
I took a liberty of grabbing the file @ogirem has provided above:
And just clean it up using the combination of using hide unused node sockets feature, and a good practice of duplicating multi output nodes instead of trying to utilize all their sockets at once.
In just a few minutes, I’ve arrived at this:
The math at the start is still a bit messy, and could be done a bit cleaner, but I did not want to touch his solution. I wanted to leave it as is and make it cleaner.
We all want cleaner node trees of course, but I don’t think we need something as drastic and complex as what the Compact Nodes task proposes, which could have negative impact on workflow speed in some cases.
3 Likes
The way our shaders at my game company work. Is kind of how some of you are saying it should work , I think…
However, experiencing it for years now, I don’t know that I like it. We basically have nodes as you’d expect, but also each node can sometimes have sub graphs or hidden ranges and other values / attributes.
Additionally we have a side bar that is an overview / flattened view. Which definitely can be useful or the most useful sometimes. To find those hidden colors or values. Etc.
The most confusing to me is always those hidden sub menus / etc. It’s powerful. But you can have literally 6-8 hidden splines or animated values via attributes / periodics in 1 node.
So it gets very hard to immediately tell what’s going on. It can require a lot of digging.
So visually it’s not always messy at a glance. But in reality it’s got a ton of crap hidden inside and makes it messier/ harder to wrap your brain around it in some situations.
6 Likes
Hey, about the names of the attribute extract and store persistent; Is there a reason they are not simply called “attr get” and “attr set” ?
Just wondering if it was explained somewhere because it seems that users will take a habit of using the term get/set regardless of the default label ? Not the first time I saw users referencing these as “get/set” I must say 
13 Likes
I totally agree. Sounds so much more simple, intuitive, and the thing a new user would search for. Makes the names shorter and easier to find.
I also use the above mentioned M program at work. In my opinion nodes with hidden sockets are not quite as efficient to use. Mainly because of the following reasons:
-
It takes a lot of time to memorize all of the different parameters on all of the different nodes when they are hidden by default. As you mentioned, you have to “know [your] way around node systems” for Compact Nodes to be usable.
-
Compact nodes are a bit slower to use: When using something like “plus” icon to search for hidden parameters you now have to dig in to hovering menus sometimes even sub-menus, they sometimes disappear if you miss the curser by a pixel.
I almost never use compact view, instead I always switch to “full and show all attributes” mode in the above mentioned program, so I can see all af the sockets and swiftly change the connection, when prototyping.
2 Likes