But I don’t think the low level aren’t important. I think you’re not understanding me correctly. I’m just saying that focus only on low level, at the moment, letting the community help with high level but at the same time taking control of the low level nodes is a bad decision. In my opinion, the devs are the ones who should ship Blender with some high level nodes/groups as well, not only the community.
I don’t think the target is to let the community the work for high level, but the development team is limited, and they have a ton of work, so I think the priority is to have the low level nodes, to be able to construct high level nodes without hardcoding them, high level nodes users may last a bit more or may rely in community solutions to use GN, but it will be worth the wait IMHO
And yes, at some point the main dev team should create those high level nodes, but in a way that they are just compound nodes, or node groups, to be used, but you will be able to enter inside the node and modify it’s behaviour or learn how it was created, that’s the true power behind all this for the future.
Hardcoding high level nodes would remove a TON of time from GN new functionality and stability, and it’s something I would not sacrifice right now, when GN is starting to look good and powerful, in some time, for sure, but not right now IMO
1 Like
I agree with everything you’re saying. I just don’t think that the we should rely on an expectation for the future. There is no warning on Blender that GN isn’t for begginers, intermetiate and advance users who aren’t into logic/programming/math… so people just get frustrated. It’s a good idea we stop talking about only begginers. GN is hard for anyone, of every level, who aren’t into logical, programming and math. I talk everyday with Blender users because that’s my job (I’m a Blender instructor) and the amount of people who find GN easy to work is really low. Most people can’t do anything beyond a simple scatter and that’s it.
Can’t find a way on why some simple high level node groups can’t be shipped with 3.0 for instance to make life easier to anyone who don’t know how to build things with low end nodes. Yeah, I know, development team is limited, but I’m talking about just some node groups to help users.
3 Likes
I agree with this, but this is something that maybe some users can do, no need for the dev team, and I refer to them as something to be provided with the release, so possibly @Erindale or other advanced users could arrange some group nodes to be implemented.
In fact for the first time the plan is to have an asset library with different things, and If I’m right, it can have also some GN Node Groups, so that’s a brilliant idea
And I feel your pain, I’m an instructor too, in several schools and for private companies, and I always explain GN as something quite advanced, exciting for new users, but that require some knowledge, specially about the logic behind 3d, but with fields I feel that it has became a bit easier TBH, even with it’s caveats and the small problems that still have to be fixed.
I repeat, I’m talking about a community proposal, maybe if the team considers it @pablovazquez can make a call for high level node groups, like has been made other times for environments and similar things.
4 Likes
A call for content is indeed a good solution. I’m looking foward to that and I really think it’s a good idea.
1 Like
I repeat, I’m talking about a community proposal, maybe if the team considers it @pablovazquez can make a call for high level node groups, like has been made other times for environments and similar things.
that’s a job for the community
the official devs should not waste their precious time on this while there is a highly motivated community to do it!!! 
3 Likes
Unrelated shower thought : how would a “blur attribute” node even work with fields ? it’s dependent on topological information so it can’t exist in a void can it ? it would have to be a “geometry” node ? am I making sense
Something like a gaussian blur node could definitely be implemented but it would have to be sampling local points in 3D and you’d want to be able to limit it to connected geometry / following surface / completely free 3D space blur. The big H has one that works really nice.
We can already do noise dithering just the same as we do in shaders but that’s not always appropriate.
2 Likes
That’s very important node to have, I assume it will come later on.
1 Like
That’s one hell of a summary! 
You’ve tackled both perspectives really well.
I thought some more and either it’s a geometry node or the user has to be able to query neighbouring vertices to average their values (or whatever blurring does)
It would make sense to be a node in itself. And blurring could have many parameters.
Blurring position, for example:
- Evenly re-distributing points, based on a threshold and using a selection as the starting point
- Blurriness strength
- Falloff strength
I’m sure it’s gonna be a complicated node, so I’m hoping it will be a standalone node.
3 Likes
Thanks for the recap man, put it here too, it’s very useful.
BTW I agree with the danger of working with Global variables, but if the scope is the scene, I think it’s ok, Scene variables don’t have to be dangerous, and since the Scene is just another Data Block, it should not be a problem to have variables tied to it and to retrieve them.
Of course the user can always break things, but that’s not going to change, a user can easily break a rig with shape keys or an armature removing some modifier, etc… we should not design things thinking that users will have to learn how to use things.
1 Like
Also, why not have a possibility of having node group scoped variables? Such workflow already exists in some other node based systems out there. That would go another step in direction of avoiding name conflicts? Users could decide whether the given attribute/variable should be available outside of the group or only in the scope of given group.
3 Likes
I suspect, and keep in mind that I may be totally wrong, that the node group it’s just a small “hack” that isolates a group of nodes, but it’s not actually a real scope.
So it’s not a real “composite” node, where things inside are at a different level, can be pre-compiled for performance and such things.
To others who know this better: am I right?
1 Like
Right now it may be, but in case of GN, it’d made a lot more sense if node groups functioned as actual programming/scripting language functions that take certain data, then process and return certain data, instead being sort of macros.
3 Likes
I’ve been asking this since Day 1, and I still hope this is the case or this will be the case…
1 Like
Local variable are anonymous attributes I believe
Note that everything in geometry node in encapsulated in node group, there’s no “main layout”
For example in shading
The “main layout” is material data type
Here there is not such concept, everything is a node group
I think the arguments against sharability concept & the removal of the get/set nodes are overwhelming at this point…
Ok here’s the recap of all I could read
Note that it is still a draf
Real debate is Monday I guess
Arguments In favor of removing the nodes:
- Guaranteeing share-ability of nodegroups, should be the key focus.
- Named attributes can be replaced with fields in most cases.
- The major consensus in the community was that writing attributes is bad, using fields is better.
- From a programming paradigm point of view, accessing
globalsvariables (encoded attributes) is a bad practice. Access to globals from the realm 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 procedural software’s, flexibility should be the main attention.
- User is now more restricted in his workflow choice and organization.
- Making nodegroups shareable should be the responsibility of the user.
- Solution to possible share-ability issues is proper guidelines/teaching. Advance users shouldn’t have their flexibility restrained to protect beginners.
- 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 restrain implementation of new nodes to respect this paradigm.
- Cycles already have the “get attribute” node, what about double standard ?
- Current share-ability concept is already not consistent to begin with: object or collection pointers completely break the nodegroups share-ability paradigm, both in cycles and geometry node.
- Nothing is preventing adding these nodes back except a concept. Users who do not understand the concept can end up confused, feeling it’s an arbitrary regression.
- This removal is ignoring users personal preferences, it could lead to frustration:
- Some users liked having the universal way of getting/setting custom or built-in attribute values by typing their name instead of using the new interface or using the dedicated assortments of built-in attr nodes.
- Some users liked/needed the ability of reading&writing custom attributes without being forced to expose attributes as parameters.
- The major consensus is that the field prototype was approved by users, this change might get considered as a false advertisement.
- This decision can be felt like a significant changed compare to 2.93, old habits are now completely broken. Perhaps the transition should be less drastic, it would limit the obsolescence of online content.
- Stored attributes are a significant part of blender future proceduralism:
- There should be more than one way to interact with them.
- This logic of removing access by name of both built-in/custom attribute within nodetree can hurt the development of geometry node in the long run: for example when a scripting language will be introduced, it seem quite clear access by name will be a requirement.
- Interacting with attributes via get/set nodes is industry standard. These nodes are to be expected.
- There shouldn’t be a mandatory separation between built-in or custom attributes in the nodegraph, both could be read/written similarly as they are both data encoded in the spreadsheet.
- The new way of working with custom attribute can be seen as cumbersome or slow:
- Going in the modifier interface or in the N Panel to choose the read/written custom attribute name or changing the written domain is not as intuitive.
- It adds considerable mouse travel and extra clicks ( especially if users want their input near an area of his node graph, or if the modifier editor is not open ).
- it might become complicated on some cases:
- where a lot of custom attributes inputs/outputs are needed.
- where nodegroup functions are nested, and custom attribute argument are forced to be passed from nodegroups to nodegroups.
- It’s a nice addition but can be considered as a poor replacement of the simpler to understand get/set node.
- Using modifiers interface is required and is at the center of attention, wasn’t the goal to replace modifiers with geometry node ?
- “In order to test this design properly we need to enforce it” → What about deciding before bcon3? there is still time to decide.
- “globals from the realm of a function should be forbidden to users.” → Yet globals are very powerful, and featured in many programming languages for good reasons (and also in a very famous procedural DCC).
- Access to globals are essential when writing unique scripts with no re-usability in mind. Nodetree can be made in this context.
Ps:
-some argument might represent subjective feelings/opinion users or designers might have
-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.
-if you do not fully understand an argument, please ask below.
14 Likes