It’s ok to have specific set/get nodes for some things, but a generic Get and Set node should be created, we cannot depend on developers giving access to every specific parameter or attribute an object could have in the future, we will end up with thousands of nodes, IMHO it’s a non-sense.
A sub-set of them could be created, on behalf of high level users, but the generic nodes must be present, they are key.
P.S.: BTW those high level nodes could be present as simple groups pre-generated with the generic set / get nodes, it should be that way if the original spirit of GN is still present:
High Level for users
Mid Level for Tech Artists
Low Level for TDs
Correct me if I’m missing something, but how are we supposed to talk to shaders without being able to explicitly set data?
Removing names seems like an anti-pattern, especially if the plan is to implement tree shaking anyway. The idea seems to be letting the computer manage what is saved and for how long, but there is no reason to get rid of names to do that, and sometimes I do want to insist that something is kept for later use (and I’ll need a name for later). Following data flow is easier with nice lines, but names are the primary documentation, especially for ‘distant’ references. The ideal for me would be being able to give any output field a name, and being able to type that in a box where I want to use it, and then the computer draws the line (as well as just dragging). The underlying implementation could completely ignore the name, but names are extremely important to making understandable code.
Some things should be named, many intermediate values should not. Deciding what should be named and what should be inline is one of the few places where the python ethos of ‘only one answer’ fails miserably, and even python doesn’t try to enforce it. A graph without names is effectively a giant line of code without comments or any named intermediate values. That is regarded as horrible practice in any language, and should not be the default never mind the only option.
Sorry this is so negative, you guys are doing a great job with it and fields are a massive improvement. I just strongly believe naming things should be expected, and that we need breakouts (which attributes are). Removing them is a major design error that needs to be dealt with early.
Forgive me if I miss the point of your post, but you can still create attributes that can be used in Cycles shading (this is in the rendered view for Cycles).
By all means, this is actually less cryptic and more straightforward than figuring out what the ‘attribute convert’ node is and how to use it (as conversions here are automatic). The way to get and use the new attribute in Cycles meanwhile is identical to 2.93.
Perfectly fine. But now imagine that same node tree with hundreds of nodes, where the color conversion writing the “Color” attribute is all the way to the left of the tree. Hundreds of node in between. You have to drag a cable all the way across to the output of the tree to get this attribute to be present on the geometry and accessible in shading.
Now imagine that not only “Color” but several attributes are written.
I know I can duplicate the “Group Output” node as many times as I want BUT it always contains and shows ALL of the outputs. If there are dozens of outputs this will look awful and clutter the whole tree with huge nodes. A simple “Set Attribute” will do the same job, take no space, would be clearly named and the attribute will of course show up in the modifier interface so no one ever forgets about it and everything is fine.
This is just a portion, for full context please visit the blender chat “geometry-nodes”. That being said the developers have clearly seen feedback from here. This does not necessarily mean changes will be made towards this, merely that the comments here have been noticed and understood.
I support the addition of the get named attribute node (the set named attribute node afaik isn’t in discussion and will definitely come), but anyway I just wanted to point out that the group output node also supports the ctrl+h shortcut to hide unused sockets
Some devs want to restrict us from creating, getting and setting custom typed attributes in nodetrees because they are worry of nodegroups share-ability issues. ( example of issues : some beginners might lack the common sense of exposing the right parameters in order to create a shareable node group, if they are lost and do not fully understand what they are doing they might get hurt in creating nodegroups )
But please do not forget that using nodegroups is required in order to do anything in with the geometry node modifier! Therefore this restriction is imposing share-ability upon every single use case, which do not make sense.
For example, the use case of creating procedural assets, where no inputs are needed at all, not following the traditional nodegroup logic.
We’ve been using H in the studio for a long time, I can tell you that H also have the exact same «problem» in their grouping systems, yet they did understand that privileging flexibility is the right thing to do in order to have a grouping system that can both fit one time usage effect such as « modifiers » or share-able function like « nodegroups ».
Not exposing the right attributes in nodegroups will create issues in these kind of procedural workflows regardless of the DCC because the solution to this is common sense! I personally never had any problems creating geometry nodegroups useable in multiple context in 2.93, let’s hear what the community think about this
share-able geonodegroups in 2.93 IS NOT a problem
share-able geonodegroups in 2.93 IS a problem
0voters
Please do not make the mistake of chasing a ghost.
See how H is doing their nodegroup, they do not restrict for the sake of protecting users from their own demise.
Is there a Fracture node plan, preferably after the physical collision generated by the real-time broken, rather than early on the broken and then do the dynamics
It seems that this decision is mainly done to guarantee systematic share-ability of nodegroups.
This design is explained by an insistence on the fact that data-block should be always re-usable.
In 2.93, for example, it was possible to create nodegroups that were not shareable, the status quo is that this is an important problem to be resolved, and create/get/set named attribute nodes are problematic from this point-of-view, thus explaining the removal.
This subject will be addressed officially tomorrow in a new topic (with a poll it seems),
in the meanwhile, Dalai would like to know what kind of limitation this system is creating, if some of you have examples it would be welcome.
It’s worth noting there can be solutions for the shareability; the resulting argument is that getting an attribute doesn’t have a wire connection, while being forced to use anonymous attributes ensures there are always wired connections.
But I’m looking forward to tomorrows post where it can be explained in detail.
Thanks for the update! Maybe it will be helpful to link the poll/thread here when it will be available.
There’s one thing I don’t fully understand. What does share-ability mean? Or rather, how is it hindered by named attributes. I trust the devs when they say that this is the case, I just don’t have the full picture of how this causes an issue.
There’s even some people here stating that H had the same issue in the past, so maybe someone can give a general idea?
The sheer amount of confusion this change is creating is an argument against it in my opinion
I just don’t have the full picture of how this causes an issue.
Let me give an example
In 2.93, you could create or get an attribute value from a nodegroup.
for example you could create a nodegroup that will change the value of “duck” attribute, meaning that your nodegroup could be used only if “duck” is present in the spreadsheet, the paradigm of nodegroups should always be re-usable is then broken, therefore writing and getting typed attributes values need to be forbidden from nodetrees, under this logic.
Note that it could have been easily avoided by exposing the name of the attribute as a parameter…
Ooooohh, so in this context we’re talking about making it easy down the road.
Like for really complex node trees (made into a group) it would be very difficult to go into the Node Group and check where the problem comes from.
From some comments, it seemed that not exposing the right parameters would render the NodeGroup unusable or broken and I couldn’t understand why. But now it’s clear.
if you are familiar with python, it was similar to accessing a global from inside of the realm of a function.
that’s considered as a bad practice, thus i can understand why the developpers wanted to avoid users to play with globals
I may be wrong, but all this is already invented, isn’t all this related to the concept of variables, being local or global?
Wasn’t logical to be able to create/remove variables somewhere in the UI, at a tree level and at a scene level, and the use Get / Set nodes to use them / handle them?
About the attributes/shareability “issue”, I think the team is unfortunatelly ignoring something real important on this matter. The Nodes concept is complicated enough by nature. Most people just use Principled BSDF with downloaded/generated textures from anoter app. Geometry Nodes, on another way, isn’t friendly enough to beginners as well due the lack of an equivalent of a Principled BSDF. Expecting the community to solve the issue with shareable nodes is just plain wrong IMHO, because we have just a partial contemplation of possibilities this way.
So a begginer just download Blender, can’t do anything beyond distribute instances on faces, needs to learn about third parties sharing/selling nodes and add-ons, just to find out that the node/addon is focused on one thing… an easier/quicker way to distribute instances on faces. So instead of having a system with lots of possibilites, a general user will need to rely on several parties who may be or may be not interested in creating shareable content. Then, the general user will need to go out for someone interested in sharing nodes for Text, nodes for Displacing, etc, looking out on the internet without knowing if there is a solution to their needs.
What I’m trying to say is that creating a system that take away the control of hardcore users to prioritize an expectation of begginers to have their needs solved is, in my opinion, a wrong decision.
What I think it’s a better solution: make GN as hardcore as it can be without, of course, being totally alien and just ship with all built in “principled bsdfs” as it can be shipped for begginers and let the sharing/community step on very specific needs, not expecting them to create daily, easier and quicker workflows for begginers and general users.
So, this way, a begginer can rely on Blender, not on third parties, and the community can improve upon what is shipped with better workflows or specific user cases.
Agree, it has been said several times that GN is not for beginners
Disagree, first low level nodes, later high level nodes.
There is no “Principled BSDF” for GN, you can have a distribution system, or many other systems, but there is no right or wrong there, just differents point of view or better or worse performance or usability, the Principled BSDF is way more than an Uber Shader, it takes into account MANY things that are VERY complex to do in a node per node basis, and unifies something that was very important, general shading, and even with it, many users don’t know how to properly use it, and put white 1.0 when they want a white material… which is plain wrong.
GN has never been for new users, new users could use a modifier, or a node group, but that user will have to learn GN to properly use GN, this has been the idea all the way down, evend repeated to my self by @dfelinto some times
Well, I’m not myself a begginer by any means, and even for me GN is somewhat hard. I’m not a technical/programmer person in any way, so lots of logics and maths and vectors are something complicated to understand. That’s why I think the focus of the team is wrong. Beacuse even intermediate and advanced users, who are not technical, have a hard time using GN.
So, using the word beginner doesn’t fell correct when talking about GN.
Because it has been always targeted towards highly technical artists and TD’s, it has been said in the past
That does not mean that a plain user can’t use it, but for the more advanced things high level nodes will be required for non technical users.
That’s not a problem, and the target has always been to have at some point those high level nodes, but first we have to have low level nodes, to be able to create functional high level nodes, any TD or technical user will be able to create those high level nodes for the users, and at some point, some will have to be created by the main dev team for sure, but first… the basics
