Geometry Nodes

Whew, fingers crossed :slight_smile:

This will be the biggest step backward.
Useless names again
Incomprehensible links
Nodes for entering expression strings
full-fledged written programming languages
magic python generator for beginners

It seems like there is still no consensus between development and coordination… I hope this is agreed upon before any actual development happens. Jacques’ comment on the relevant task is completely right : long connections is a general problem, not limited to attribute usage. Named attributes are not a solution to this general problem. “Portal nodes” look like a better fit imho.
If attributes only need naming at the boundaries between systems (it does seem like this is the case) then the output attributes fields in the modifier interface are doing the job just fine…

1 Like

Extremism is always bad.

In politics (far right vs far left). In nature (too much of certain mineral or vitamin can kill you, and so can too little), in programming (being too extreme with object oriented or functional programming paradigms), just everywhere…

And that applies here as well. In 2.93 we had attribute name extremism, where geometry nodes were all about attribute names, to the extreme point of being unusably painful.

Now we have anti-attribute name extremism, where even idea of minor, reasonable use of named attributes is considered bad.

Every well working system, be it human constructed, or natural works well only when there is balance, not one or the other extreme. So I think most of us just want a balance. Introducing two nodes, one to store named attribute and one to retrieve it will in no way make the whole fields based GN system collapse. In fact, I’d argue that fields will collapse without it, because without named attributes, node networks beyond certain level of complexity will become so hard to manage it will limit the whole GN potential.

Sure, 2.93 design of geometry nodes was a mistake, but that doesn’t means we have to overcompensate for that mistake.

7 Likes

By the way anyone else frustrated by this?

Imagine how much prettier could the node networks using reroutes look if there wasn’t this reroute node vertical tangent nonsense :frowning:

10 Likes

I’d just like to give my view on named attributes as a python addon developer. Long story short, having to get attributes through the modifier is an utter nightmare with python. Here are some of the downsides I’ve encountered:

  • The modifier inputs/outputs are not full properties, so you have to access them using modifier.keys().
  • This is then a pain because there is no way of knowing which key relates to which input/output of the node groups (the names seem to be arbitrary as far as I can see)
  • The keys contain both input and output properties, so they have to be manually filtered every time you want to use them.
  • By having to distinguish them by only the name, you are then relying on an arbitrary naming convention, which could be changed at any point in a future version of blender.
  • If you actually do want to get the input/output property, the best way I’ve found is to find the index of that output in the node group, and then get the key at that index from the filtered keys. This is prone to bugs, and a terrible idea in general.
  • Because they are not full properties, you cannot directly draw the modifier inputs/outputs to a panel, which would be useful if you wanted to be able to use attribute search (which isn’t currently available to python).
  • Instead, you have to create an extra string property for every input/output you want to influence, that you can then draw to a panel.
  • As well as this, it also means you have to make a lot of extra node links, which adds more complexity to an addon, and makes it more prone to bugs.

I’ve found out about all of these while trying to port my Weight layers addon to fields.
In every other aspect, fields is a massive improvement, but now, what would once have been a few lines of code to draw a node socket, has been changed into a few hundred lines just to account for the fact that attribute in/out nodes have been removed.
It has caused a ton of bugs, instability, and headaches, and I would be very thankful if the devs added back attribute in/out nodes, as it would just make everything so much easier.

TL;DR The current attribute system using modifiers is absolutely terrible to work with using the python API, and a lot of pain could be avoided if named attribute in/out nodes were re-implemented.

8 Likes

And to any studios/individuals conceiving their own pipeline.
a lack of flexibility is a danger to sustainability

3 Likes

So you want, for the sake of external models, to improve the internal organization?

I think you need to upgrade your traductor. Try out Deepl :slight_smile:

1 Like

I didn’t realize the functionality was so “crudely” exposed to python (excuse the choice of words), but that’s not really an argument against the system itself is it ?

I haven’t personally felt limited by the absence of named attributes so far -even though I expected to when fields first arrived. (Granted I haven’t used the API side of it)
I feel like the main stumbling point so far is actually… the long connections ? which I see as a purely UX issue. The need to actually identify attributes is satisfied by named nodes, named reroutes, frames… it’s true that retrieving an attribute by name is somewhat more explicit, but not by much.

@LudvikKoutny I like the vertical tangents ! don’t take them away from me !

Do you have any example where they look better than the horizontal ones? I have yet to see a single screenshot where they don’t look worse than the horizontal ones. Vertical tangents don’t make any sense in Blender’s node editors as all the nodes are horizontal. None of the nodes have sockets on the top or the bottom edge. This frustrating exception for reroute results in disruption of the visual flow by ugly sharp corners which appear more or less randomly.

I like to keep my node trees clean and organized, so that the node connections don’t overlap or go under the nodes. Reroutes are exactly for that, but I would like to be able to use them without having to throw up into my mouth a little every time I see these:

It’s infuriating having to make a choice between the node link going over a node:


Or not going over a node, but looking like a dog***t:

I wish I could post screenshot from all other software with node based editor, which has curved node links, and doesn’t have this ridiculous exception completely ruining the visual aesthetic of node networks.

3 Likes

I think you forgot how incredibly slow and un-intuitive this new attribute interface via modifier+n panel is compared to the nodes that were available in the proto.

And yeah I agree, python api is a bad argument, full list of argument is available here : Named Attribute Nodes in Blender 3.0 - #4 by BD3D

Anyhow, afaik a comeback of these essential nodes is planned. Not sure why the conversation is igniting again, for the 100x already :laughing:

1 Like

Yes, I completely agree we’re losing some flexibility. Ideally I’d love to have both… I was under the impression there were technical concerns to mixing both, but maybe I’ve understood that wrong ?

Well, that’s not what I read on the task above. Last I heard Dalai opposed obviously to their inclusion, and he’s a developer and I’m not

I’m messing with you… :sweat_smile: I have no preference. As long as the connections shows, it could be in a W shape for all I care

Ye, that’s the thing. People either don’t seem to care or care for vertical tangents not to be there. I have yet to see anyone who makes a good argument for them.

I think you are referring to the discussion that lead the removal of these node, when they ported the prototype to main build back in august

I’m referring to this : ⚓ T90864 Persistent/named attribute nodes
Now I don’t want to speculate, that’s just what I read

1 Like

Yup, that’s very old information,
last info i got in the chat months ago, was that the attribute node would do their comeback.


Edit*

And the 3.1 goals confirm this

Capture d’écran 2021-12-29 192935

( Store Attribute = Set ; Name Attribute = Get )

7 Likes

Alright, good to know

1 Like

Another example of how bad the unreliable user intention prediction is. I was solving an issue where using Curve factor at some point in my graph broke the connections in the curves, as each curve segment has its own factor value. So I decided to replace it with Z bounds gradient. I spent good few minutes debugging why it did not solve the issue just to realize GN was throwing sticks under my feet again by reconnecting Curve Parameter factor to the other slot instead of replacing the connection :rage:

This REALLY needs to go away. Given how complex logic one can find themselves in when working with GN and how many things you need to keep in memory, such unpredictable anti-feature is really a big point of failure.

7 Likes

I does get a bit annoying, but to be honest, for me, I find it very useful when it actually does what I want it to do, so I don’t think it should be removed completely…
Also, it’s very useful in the shader editor quite often

1 Like