Geometry Nodes

[BD3D (Dorian B.)]

@SteffenD

How simple life was back then.

Well it was way more readable, intuitive, and universal that’s for sure.
but i believe attribute as input node is superior

[SteffenD (Steffen Dünner)]

@BD3D

but i believe attribute as input node is superior

That’s what I was referring to actually
With “back then” I meant the time of the prototype version.

[Charles_Weaver (Chuck)]

Don’t forget:

@BD3D

Arguments against of removing the nodes:

"To define custom attributes, we are forced to use the modifier panel. This is counter intuitive to the philosophy of everything nodes. "

[BD3D (Dorian B.)]

@Charles_Weaver

This is counter intuitive to the philosophy of everything nodes.

I agree that it is cumbersome and it is yet to be added
why is so? Dalai seem to think that all these changes are better in the point of view of everything nodes

[Charles_Weaver (Chuck)]

We know that when nodes like “shade smooth” come, we will have more control and not have to use the mod panel. But custom attributes will always have to be defined in the modifier ui.

Furthermore:

Custom attributes must always be defined at the top. This means that nodegroups are not easily usable as a unit. Instead, we must use individual modifiers, which takes us back to where we started before geometry nodes. Share-ability? That’s what attribute remove is for.

Add that one to your list too.

[AlexeyAdamitsky]

@BD3D

• The major consensus is that the field prototype was great and approved by users compared to the other design, this might get considered as a false advertisement once this change is official.
• Interacting with attributes with Get/Set nodes is industry standard. They are expected by users coming from the industry.

I wasn’t following the fields concept discussion. As far as I understand it was supported/approved by the community except one key part where you can’t control attributes with get/set nodes?

I remember watching Dalai explaining the new concept in a video with Pablo. Two things worried me:

• When Pablo was confused about data flow and how to use hard coded attribute nodes eventually they agreed that “it works like magic”. It’s a bad sign when you can’t explain what is going on and how system works with simple concepts.
• Then when they went to explaining attribute inputs at modifier level it felt like both Dalai struggled explaining it and Pablo getting the idea and then they hastily switched to already fixed version of the scene.

Pretty worrying signs. I dabbled with geo nodes in 2.93 mainly for scattering and didn’t have much issues with it. But again my interaction was pretty limited.

I am really hoping they don’t decide to make it more confusing for less expirienced users. When you explain something with words “it works like magic” in this case might mean the design of the system is not as realized as possible.

[BD3D (Dorian B.)]

@AlexeyAdamitsky

I am really hoping they don’t decide to make it more confusing for less expirienced users.

Ha
Yet this can be seen the opposite way because the mistake of creating a non shareable nodegroup is a typical beginner mistake

Pretty worrying signs

These are abstract concepts to grasp
i think it’s quite difficult to get if you do not do programming or didn’t do a lot of procedural noodling

As far as I understand it was supported/approved by the community except one key part where you can’t control attributes with get/set nodes?

Prototype had the get/set,
it was part of the proposal, and got an overall approvement by the community by a large margin. some think it was unfair and that we didn’t gave a proper shot at the other solution, which i agree (ex processor node)

[BD3D (Dorian B.)]

@Charles_Weaver

Custom attributes must always be defined at the top. This means that nodegroups are not easily usable as a unit. Instead, we must use individual modifiers, which takes us back to where we started before geometry nodes. Share-ability? That’s what attribute remove is for.

• The new way of working with custom attribute can be seen as un-intuitive/cumbersome/slow:
  • Going in the modifier interface or in the N Panel to choose the attribute name or changing the written domain is not intuitive.
  • It adds considerable mouse travel and extra clicks, especially if users wants their custom attribute group input, near an area of his nodegraph or if the modifier editor is not accessible.
  • It’s a nice addition but can be considered as poor as a complete replacement of the fully nodal method.

Is this Clear?

[Charles_Weaver (Chuck)]

I would not use the argument that it requires more mouse movements and clicks. While it’s not intuitive, I think you already mentioned that.
What I mean, is that the system itself is not working, and results in a mess.

Here is what I would go with:

• The new way of working with custom attributes results in confusing trees.
  • To define custom attributes, we are forced to use the modifier panel. This is counterintuitive to the philosophy of everything nodes.
  • All custom attributes must be defined at the top. This makes nodegroups less usable as a unit and forces the use of the more linear modifiers.
  • Since modifier properties are linked to the object data, the modifier must be set up again every time it’s used. It is not possible to set an attribute as default value.

[BD3D (Dorian B.)]

Explanation of the removal via a simple use case:

Example: Displacing a subdivided plane with a procedural noise texture, exposing some parameters of the noise, using an UVMap attribute as input to define our texture projection, a Vertex-Group is used to drive the strength of displacement. The color of the noise and a new ‘Sunshine’ attribute is written as persistent custom attribute.

@BD3D

What the community think

This proposal has created a lot of discussion in the community lately, since we were wondering when these prototype nodes come back in alpha. There were messages over this subject on 3x devtalk topics, the blenderchat, Blender Artist, and Twitter. The opinions were almost unanimously against it.

Below is a recap of all arguments I have read so far.
Before reading, be aware of the following:
- Some arguments might represent subjective feelings/opinions from users or designers.
- If you do not fully understand something, please ask below.
- I am not objective in this debate, yet i try to be, if you feel like there’s an unfair representation of your opinion, please signal it below.

Arguments In favor of removing the nodes:

• Guaranteeing share-ability of nodegroups, should be the key focus.
• Named attributes can be totally replaced with fields.
• The major consensus in the community was that writing attributes is bad, using fields is better.
• From a programming paradigm point of view, accessing globals variables (encoded attributes) is a bad practice. Access to globals from the scope of a function should be forbidden to users.
• In order to test this design properly we need to enforce it, we could implement the nodes later if the users need them.

Arguments against removing the nodes:

• Prioritizing share-ability over flexibility is a mistake :
  • In a procedural software, flexibility should be the main attention.
  • User is now more restricted in his workflow choice and organization.
  • Making nodegroups shareable is the responsibility of the user, not the developer.
  • Enforcing the share-ability paradigm upon every single use case is a false assumption, nodegraphs set-ups designed for one-time usage in specific contexts are common.
  • Comparing with cycles shading nodes:
    • Cycles do not avoid the implementation of new nodes to respect this paradigm.
    • Cycles already have the “get attribute” node, what about the double standard?
  • The imposed share-ability concept is not consistent: Object or collection pointers completely break the nodegroups share-ability paradigm, both in cycles and geometry nodes.
  • The solution to possible share-ability issues is proper guidelines/teaching. Advanced users shouldn’t have their flexibility restrained to protect beginners who didn’t read the manual.
• Nothing is preventing adding these nodes back except an abstract concept. Users who do not understand the concept end up confused.
• This removal is ignoring users personal preferences :
  • Some users liked having the universal way of accessing custom or built-in attributes by typing their names within the nodes.
  • Some users liked/needed the ability of reading&writing custom attributes without being forced to expose them as parameters.
• This decision creates significant change:
  • compared to 2.93, old habits are now completely broken.
  • the transition from 2.93 to 3.0 would be less drastic if the node were kept, it would limit the obsolescence of online content and reduce user frustration.
• This workflow is a far cry from what was anonymously approved by the community when they chose the prototype design.
• Named attributes are a significant part of blender proceduralism:
  • There should be more than one way to interact with named attribute. Not interacting with them from the nodetree feels wrong “Named attributes are just a fundamental part of geometry to me, not being able to work with them in geometry nodes feels very limiting.” -Jacques Lucke.
  • Not accessing named attributes within nodetrees can hurt the development of genode in the long run, for example, when a scripting language will be introduced access by name will be a requirement.
• Creating/reading custom attributes nodes are industry standard. They are to be expected.
• Universal methods of working with attributes are important:
  • Both built-in or custom attributes could be read/written indifferently as they are both data in spreadsheets. It was the case in the prototype by typing an attribute name when using the get/set node. It is no longer the case now.
  • The new logic for built-in attribute access is to create input/get nodes for each possible built-in attribute. This will scale very badly with time when will be a lot more built-in attributes. Generic nodes are a simpler alternative.
• The new way of working with custom attributes can be seen as cumbersome or slow:
  • “Personally I’m not convinced that the complexity of this over the method we used to expose attribute names to the modifier in 2.93 is worth it” -Hans Goudey
  • Going in the modifiers interface/ N Panel is not intuitive compared to searching for a node.
  • It adds considerable mouse travel distance and extra clicks (even more if users want their input near an area of his node graph, or if the modifier editor is not open).
  • Some situations might be tricky to handle:
    • When a lot of custom attributes inputs/outputs are needed.
    • When nodegroups are nested, custom attributes are forced to be passed from nodegroups to nodegroups until reaching the destination.
  • Using modifiers interface is required and is at the center of attention, wasn’t the goal of geometry-node to replace modifiers?
  • It’s a very welcome addition to the interface! but is a poor replacement of the node design.
• Following this proposal logic, the “attribute remove” ability should also be removed from nodetrees. It is now impossible to remove an attribute procedurally.
• There’s a good compromise: informing users about globals being read/written from the modifier interface. see D12685 ‘Store named attribute node with visible mapping’.
• Counter-arguments:
  • “In order to test this design properly we need to enforce it, we could implement the nodes later if the users need them.”
    • No, it can be tested and decided before bcon3, port from prototype to master is still allowed in bcon2, time is not a problem, the nodes are ready to be pushed to master.
    • Testing won’t help, the design has too many flaws.
    • This argument suggests that users/industry’s patience should be tried once more.
  • “globals from the scope of a function should be forbidden to users.”
    • No, globals should be discouraged, not banned. Globals are powerful and featured in many programming languages (and also in a very famous procedural DCC) for good reasons.
    • An access to globals is essential when writing unique scripts with no re-usability in mind. Nodetrees can be built in this context, it is very often the case.
  • “The major consensus in the community was that writing attributes is bad, using fields is better.”
    • False, The major consensus is that the field prototype was better.

In Conclusion
Arguments against the removal are very convincing, keeping these nodes will not interfere with this proposal. It’s is also important to specify that Jacques and Hans, the two creators of the field concept are openly against the removal (see quotes).

Personally, I do believe that the future of blender proceduralism will be negatively impacted by the removal of the get/set attr nodes, right now it might seem that this is only but a change in the UX, but if you look closely this change has profound implications on a core concept that have been established since the birth of the project and confirmed by the industry’s top procedural DCC’s, which is the interaction with named attributes. I did spend a lot of time collecting and reformulating all community’s arguments, I hope that Dalai will consider each of them seriously.

any comments?
anything unclear?
anything to add?

[SteffenD (Steffen Dünner)]

Thanks for your work! I totally agree and hope they reconsider the removal of the nodes.

[BD3D (Dorian B.)]

Note that they are completely right on the fact that playing with globals variables is dirty work and it should be avoided when possible.

I completely got their point. it’s a more philosophical debate of “Security vs Freedom” emaning. Personally, i’m all for freedom, but i’d don’t want to see plenty of beginners hurting themselves with globals because of this too.

we should find a compromise perhaps? usually this is done by teaching and experience

[Experience (Kolby Bradshaw)]

Thank you! It worked, except it was going up for some reason so I had to change from add to subtract. Not quite sure why that is.

[SteffenD (Steffen Dünner)]

There are so many possibilities in Blender (and basically any other software I know) to do wrong things, break stuff, hurt the feelings of new users, etc.
But what is worse is to limit the possibilities for all users because something might go wrong for a few others, especially if there are plenty of other areas that deserve warning signs.

It’s a bit like putting you in a rocket made from broken cars, powered by explosives, held together with duct tape and barbed wire to send you in space and as a safety measure they cuff your hands to keep you from pushing “the wrong button”

[obsurveyor]

Another argument against: Breaks the current mindset not to do new things with modifiers that they’ve been enforcing for a couple years now. They’ve shut down so many new modifiers because of everything nodes, this shouldn’t get a pass. It needs a solution that doesn’t use modifiers, if modifiers aren’t going to be a thing in the future.

[Xeofrios]

Hah dumb me! I work with gizmos off so I do not know which way is up or down!

[Xeofrios]

I in general agree with all your points, while I can personally have counter-arguments against some.

A good point against the removal of nodes I found was that the current system becomes a hassle when you have nested node-groups (I think?)

[kkar]

This kind of property passing (or exporting) makes perfect sense in Houdini, where the custom attributes are defined at will and can be used as an input in the Vop containers, which is a fully procedural working paradigm with top-down node flow. I agree that needing to pass known (which are already defined in the mesh context) attributes will most likely create friction on the user side and will require scripted solutions when it comes to distributing them. On the other hand I can see that it is not out of the Blender’s design philosophy.

I just wished that I was able to add as many input and output attributes on the modifier panel instead of going inside the node network to do that. Maybe they will add that at some point.

[BD3D (Dorian B.)]

@Xeofrios

A good point against the removal of nodes I found was that the current system becomes a hassle when you have nested node-groups (I think?)

It’s true that the argument need to be passed from group to group

Breaks the current mindset not to do new things with modifiers that they’ve been enforcing for a couple years now.

Dalai seem to think that this is part of the plan of everything node down the line (chat) i don’t get it either

@SteffenD

But what is worse is to limit the possibilities for all users because something might go wrong for a few

Ha yeah i missed this argument, adding it…

“Advance users shouldn’t be punished to protect beginners who still have to learn.”
right below learn is the solution to resolving potential share-ability problem

edit*
news:
Dalai post is on Monday in the end

[thinsoldier]

@BD3D

Get attribute is available in cycles already

So November comes along a few years ago and all magicians, wizards, space aliens, time travelers, and math ninjas started posting the most gobsmackingly impressive stuff made with displacement and adaptive subdivision of geometry in Cycles. A few years go by and we start hearing about Geometry nodes. It sounds like all that stuff that was confined to Cycles is going to be let loose and made applicable to real geometry in the live 3D viewport. Sounds awesome. Now the more I read about it, the more it seems they’re trying to do stuff very different from what people are familiar with from Cycles. Why?