Can you give any objective examples why the new system is bad other than subjective opinions such as “many don’t like it”, “it’s slower”, “it’s restrictive”?
The only objective point I found that a huge number of get/set attribute nodes are being added. I kind of agree that many of these can merged into unified nodes, for example get/set curve attributes. But arguing that all these built-in attributes should be accessed by typing the attribute name is awkward because I remember people grumbling that they have to remember all the attribute names (with case) and that it’s not user friendly (when Geometry nodes was first introduced). The whole point of fields is to make Geometry nodes more user friendly.
Now let me give an example why the new system is superior. Lets say you make a GN network that deletes geometry based on a vertex group. Now you want the same GN modifier on two objects with different vertex group names. In the older system you have had to make both the networks single-user meaning the changes made in one of them would not reflect in the other and it would take more memory in general (trust me, I have faced this problem).
In the new system, you can simply type in the vertex group names in the modifier itself, therefore the networks remain linked. I believe this what the developers meant by “shareability” and not people downloading node-groups off the Internet.
In general I see people arguing two completely different things-
Connecting the attributes to input/output nodes is a pain (I don’t understand why)
Attribute names should be exposed in the nodes themselves.
The funny thing is that 90% of the time I see people adding nodes (to the Shader Editor, the Compositor and now GN) I don’t see them crawling through the “Add” menu but using the fuzzy search
Same would work with attributes… ALL of them, even custom ones. All with a single node.
That is False,
that’s up to the user to make his nodegroup work on all contexts!
Yes, it was possible to create nodegroups that are not re-usable, but it was a only but a possibility and is avoided easily by users know what they are doing? this is a beginner mistake
(trust me, I have faced this problem).
wel i’m sorry to say but you faced this problem because you didn’t understood how to create a proper shareable nodegroup / had proper logic on what parameters to expose or not
the vast majority of users who understand this fact should not be punished because of few beginners that didn’t ?
Add to the fact that it is required for us to use a nodegroup to create a one time usage modifier, so this concept of sharability should simply not be debated at a first place
Note that this « problem » is also in Houdini!
Yet they have made the smart decision of privileging flexibility in their grouping system. Why? Well because a group in Houdini is much more than just a re-usable function that transforms inputs into outputs, it can create fantastic procedural objects from one single input or not inputs at all, which is completely the case with geometry node ! Sticking with this sharability concept is absurd
That’s it I just broke the only argument in favor of this arbitrary restriction, now give us back our get/set nodes please then let’s get forward on creating a proper procedural workflow shall we
Sorry for interjecting this very heated debate with a rather silly question. How would one instance a collection using the new Distribute point on faces and instance points node? What I assume is to drag a collection info node in and connect its geometry output to the instance geometry input of the instance on points node. However, this behaves like the whole collection option in the previous point instance node. I expect the separate children option in the new collection info node to behave like the reverse of the Whole collection option in the legacy node. However, this is not the case. Am I missing something here? can someone please point me to maybe the differential commit so I can read it up? thanks
Maybe I’m just being hasty but isn’t it a bit redundant to have to click two toggles to do just one thing? I mean is there any other use case for separate children option in the collection info node other than for instancing? or maybe the Pick Instance option does more than just this? I should probably go read it up in developers commit actually.
Wait a second. Have you forgotten about the attribute search dropdown feature?
When have people been grumbling about having to remember attribute names? If I recall correctly, people disliked the system itself. Having to use attribute math, attribute randomize, with no clear idea of where that attribute is going.
Separate nodes to access attributes and setting only in the modifier panel means:
Tons of extra nodes
Attribute type separation
Limited ability
Forced to use the properties panel when everything nodes is designed to replace it
Get/set nodes means:
One node fits all
Setting within groups
Vert groups and colors can be used inside tree
I don’t have to set up my modifier in the property panel every time
That’s not quite right, you could just wire a group input into the attribute name socket, exposing it to the object. Am I making this up ?
I think the attribute list that popped up when you went to name an attribute, as implemented previously, did a good job of helping the user discover the different builtin attributes. That’s why I don’t think special “attribute set” nodes are necessary : just have that same list pop up when I choose an attribute I want to get or set.
@Charles_Weaver I missed your post, yes that’s what I am talking about
I placed that line is bold because I know for sure that is not true (that is once you figure out how to use the group input and its attribute toggle in the stack UI).
See the image I posted earlier, which uses a vertex group to create a color attribute for use in Cycles, the thing to note though is that you can also use that input bringing in the weight painted data for any purpose involving field sockets (including vertex transforms and masking).
There is still the controversy over whether or not we should be expected to use the stack UI to begin with, but the idea that vertex weights and vertex colors can’t be used is more the result of this being new with no clear documentation.
Ah, I should have been a little more descriptive. What I should have said, is vertex groups and colors can be defined within a tree and exposed to a group without having to use the modifier ui.
And what about intermediate caching of parts of the the node graph for performance or other reasons that needs to be implemented in the future.Not everything will be just displacements , scattering or simple vector math.There will be remeshing nodes , Vdb nodes probably solvers or for loops in the future and this is not fast as a displacing a sphere or animating some cubes.And not to forget about particles and fluids. With the current implementation that we read the attributes from the group input and setting them in the group output this will be a problem in the future.I’ve got the feeling that geometry nodes are going in the wrong direction.
Even with the drop-down, I still think the typing system is not user-friendly. Would you then also argue that the inputs in shader nodes be replaced with a typing-based inputs?
Another rather simple question in the heat of the debate again… I hope. Maybe this is more related to the topic actually.
Say I have a curve geometry and in the legacy system it has a radius attribute. if I wanted to change or increase this radius attribute I would just add an attribute add node. simple! but with the fields system, I’m kinda lost honestly! How should I go about this?
That’s your opinion, and I will respect that. But is it a “typing system”? Or is it more of a search system?
Unless you are really terrible at naming things and all of your attribute names are one character apart, you shouldn’t have to type more than a few letters to find your attribute.
Do you ever use the search button in the add node menu? What about the outliner? Do you name your objects and collections?
Correct me if I’m wrong, but I don’t remember anyone complaining about the attribute search feature. I remember people complaining about a lot of other things (No visual connections, linear trees, attributes themselves being unintuitive ) but this is the first time I’ve heard this.
Actually, that’s not a bad idea. I kind of want to be able to access those read only nodes in shaders with a generalized node. It would be a lot cleaner than having your texture coordinates noodles go everywhere using one node.
None of the attributes shows up in any menu or search. Not very user friendly.
And in GN there will be many times more of them, as soon as “Everything Nodes” becomes reality.
Yes, we’re mostly talking about getting / settings custom attributes. If it’s OK in the shader tree, why not in GN? And if you can fetch custom attributes this way, why not the built-in ones, too?
Noone will be forced to use the two simple nodes where you have to type / search attributes. I would just love to have them to get work done.
The “nice” thing many people here are currently complaining about in this case is that you don’t even see the attribute name “radius” mentioned anywhere in the node tree. You have to go to the modifier and type (yes, manually ) it in there… correctly. No search helps you.
I’m sorry WHAT? why the unnecessary complexity? Am I missing something because this looks literally backwards! I always see attributes as input why the heck does it has to be accessed as output? Also why not right inside the node? how will I for example do some complex calculations where i need to ‘get’ its default value in between the calculation and 'set ’ it later? I’m so confused! this is far from user-friendly to say the least. maybe I will get used to it but the previous way made more sense in my opinion
then let’s get forward on creating a proper procedural workflow shall we
) it in there… correctly. No search helps you.