Fields and Anonymous Attributes [Proposal]

[Hadriscus]

@LudvikKoutny

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 ?

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.

@LudvikKoutny

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?

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

[2905710881]

Smoke, fire, fog, fat solver, sweater solver, ocean solver, including particle nodes… is there a plan for these?

[zorro-weaver]

This was mentioned recently on blender developer blog:

Nodes Workshop – June 2021 — Blender Developers Blog

See: Simulation Solvers

[LudvikKoutny]

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:

Fields and Anonymous Attributes [Proposal]

I tried doing this type of effect, here’s my feedback: [image] I couldn’t use fields, because it was just missing nodes and attributes that I would have wanted to manipulate I wanted to use boolean operations, to clip the lines onto the mesh, but that wasn’t possible (I think), so I had to do raycasts (which aren’t available in fields yet) There is no way to smooth the normals of geometry generated in geo nodes, not even by trying to set the normal attribute (I believe?!) Boolean…

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.

[mattli911]

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.

[BD3D]

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

[zorro-weaver]

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.

[ikakupa]

@Hadriscus

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 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:

1. 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.

2. 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.

[DimitriBastos]

I don’t know what users will take as a habit, but trying to read all those node trees are really complicated for me, which makes me feel… dumb? Attribute store, get, set, all those vectors, etc, without a clear visual explanation/demonstration of what all those generic nodes are doing is really an alien concept. For anyone technical enough to fully understand all those concepts, the naming doesn’t really make a difference at all in my opinion. Thanks for the Principled BSDF (in comparassion).

[ogierm]

animation nodes has hidden attributes and it took me quite some time to find out that they exist, and I find them really annoying to use.
from what we are seeing now, most nodes are pretty small anyways and I have to agree with ludvik that if a node has so many options that some should be hidden per default, I’d rather see that node be split into multiple nodes.

[Eary]

https://developer.blender.org/rB6b0aa7ae156461310bfff7d19d8754b4b55409f0
Why does Attribute Remove node need to be hidden when field is checked? It is not in the list of nodes that need versioning, is it?
And here is the list:
https://developer.blender.org/T91049

[JuanGea]

@LudvikKoutny

I still feel like everyone keeps forgetting about the “Hide Unused Node Sockets” feature.

I think that’s totally true.

Some versions back we had a small screen icon on top of the nodes to use it as “viewer”, that icon, designed different, could be very useful to give importance to that feature and to make it accessible to users, this is an important feature that should be exposed in a better way, is very useful and unknown to many users.

[RiccardoBancone]

Agreed, It should really be more exposed, but not with that icon. Since you mentioned the old view icon, I don’t know what’s the general opinion, but I really think that we should go back to that instead of using the viewer node, Which i find to be very annoying to use.

[JuanGea]

I think one of the problems with the viewer node is that it does not reflect the tree status on viewport, it’s only for data in the data sheet, and that’s confusing.

The icon could be great to activate what should be the viewport output or final output preview, and the viewer could be used for the data sheet, but I agree that when I use the viewer I would expect to see the viewer result in the viewport, just like with the shader nodes.

[Eary]

@JuanGea

I think one of the problems with the viewer node is that it does not reflect the tree status on viewport, it’s only for data in the data sheet, and that’s confusing.

Well… Take a look at this:
https://developer.blender.org/D12554

It is going to have viewport preview very soon

My problem with the node is that I have to manually delete it after I am done using it, while in shader nodes I can just click on any BSDF node and it will disappear.

[JuanGea]

Awesome

Well, that’s a limitation of this way of working, it’s the same thing with the shaders, in the end you get used to it.

Maybe could be great to have an option in the node called “override output”, that way we could use if as it was until now, for data preview, or as it’s depicted in that patch, for output preview and data preview.

[LudvikKoutny]

A bit of OT; The feature itself looks great, but my god, that node network. I really wish that guy was aware he can duplicate group input nodes and hide unused node sockets. His node network looks like a microchip

I think we really need a way to get more people aware of these features

EDIT:

Could not help myself, and had to try it:
Before:

After:

The more people do not forget about the feature, the nicer node networks will be made

[RiccardoBancone]

@JuanGea

I think one of the problems with the viewer node is that it does not reflect the tree status on viewport, it’s only for data in the data sheet, and that’s confusing.

I don’t necessarily find it confusing once you realize what viewer does. My problem is kind of the same that @Eary mentions:

@Eary

My problem with the node is that I have to manually delete it after I am done using it, while in shader nodes I can just click on any BSDF node and it will disappear.

The node keeps getting in the way , even when you still need it on another node far away , it stays in the same spot creating annoying and not really necessary noodle that can cross the whole tree.

This of course can be a bit mitigated by just creating the viewer Always in the same position, like just near the output, or just integrate the viewer as an input socket of the output node, I think the former is the behavior of the shader node viewer.

But that’s not the only reason I’d like a system with icons/toggles on nodes.

The reason is that , besides viewing the info in the spreadsheet, sometimes you may want to see the output on one node in viewport as final, and maybe the output in another node , still in the viewport, but just not renderable and maybe in wireframe.

Example: boolean sphere that cuts a cube. I may want to se the final cut cube in the viewport shaded and renderable, and the sphere , not renderable and only wireframe, to move it and actually have a feedback of where the sphere is.

Having toggles on nodes to quickly set what’s shown in viewport as only wireframe would be handy. (Just as it was with the icon for the spreadsheet).

To sum up, what I’d like to have on nodes is :

-A spreadsheet view button (like the old one)
-A Wireframe view button (the nodes with this set to on are displayed as wireframe but Not renderable)
-Geometry Preview (Like what @Eary showed in here. https://developer.blender.org/D12554
-A Final Output Button (What the output node does by default now)

This would probably allow multiple output nodes, and tell blender what’s used for final render with the last mentioned button.

[RiccardoBancone]

@LudvikKoutny

After:

The more people do not forget about the feature, the nicer node networks will be made

Man That’s waaaaay better!

[LeonardSiebeneicher]

Thank you very much! I was not aware of multiple group inputs too.

Multiple nodes of same Field input work now! (Master branch)