Ah … ok.
Thank you for your feedback. I was not sure if I should file a bug report on this one.
Is it meant to stay that way ? if you want to use fields you should use set position, is that correct ?
Yes.
‘Set Position’ does evaluate a field and store the result into the position attribute of a geometry.
Atm, the dotted lines grow and shrink with the node editor zoom.
Wouldn’t it make sense to have a constant (rather window depending?) resolution of dotted lines, independent of the node editor zoom?
Imo, yes. The current method makes screenshots of entire node trees look terrible.
Hey folks,
I think it’s time to lock this topic and go back to the original main feedback topic perhaps?
The feedback discussion is now splitted in two for no reasons as this is no longer a proposal but integrated in main build
10 Likes
I was also wondering about this. I would second a merge. Or at least closing one.
I downloaded 3.0 and feel that the nodes can do much less than before
1 Like
Implementation isn’t finished yet.
Yeah, a lot is missing. We are in bcon2 now, I guess “improve” in “improve and stabilize”, means adding back all the missing nodes right? Like, still “no align rotation to vector” for example. Does anyone know if there is currently a new node with a different name to accomplish that or It’s going to be added back during bcon2?
That’s a good question, I thought since we’re in bcon2 no new nodes would be added, but maybe they’re considered “improve and stabilize” ? (What does bcon mean anyway ? is it a play on beacon ?)
New features are allowed in Bcon2, not major ones. Adding back in nodes that were removed, and new nodes, are considered a minor feature so they are allowed
This is exactly the same thing that I felt.
I know all features are important, but having the “Color Ramp” to affect “Col” attribute was the ONLY way I could see what I was doing (computing), before moving any vertex.
I have this fear that the current direction with fields, is going to be a long list of nodes that you have keep track of and know which node CAN interact with which, while until now, you could build your own solver, having the most basic of nodes and some math tricks.
Most likely not a fair assessment, but this is how it feels.
2 Likes
This was more of a hack then a proper attribute visualization feature. It was just fortunate it worked that way. The new implementation will eventually have a proper way to visualize things in the future I’m sure.
In my opinion the fields implementation will be “noodlier” and require more nodes compared to the previous way we had it. Typing in attributes circumvents a lot of UI nastiness that generally has to be done in fields, and I’d dare venture is even more flexible.
The reason I say that is for nodes like “instance on points” it accepts things like rotation, scale stable ID etc, but the UI of that node presupposes that there won’t be anything outside of those that you need. With writing attributes there is no presupposition, plug anything you want in there, it always feels more “future proof”. For example, now if I want to randomize the color of instances I can’t yet, because the attribute randomize node is a generic function node, and there is no node yet for changing color yet. This can me made, obviously, but that’s specifically what I mean when I say fields will need more nodes. You need a lot more nodes for specific scenarios as they turn up, where I feel the previous implementation is simply more general and avoids some of this (not all of it obviously, nothing is perfect).
In many ways I wish we had tried out the old workflow with the attribute processor, and avoided the 15+ attribute nodes that were made where all was needed was an attribute processor. I think that made the workflow seem really clunky, because it was.
I am biased because I work in Houdini as well, and I know how the previous attribute workflow plays out in larger scale, so I feel comfort in knowing that can play out very well. It’s scary to go into territory where you don’t know how it will go.
All that being said, just because I’m a grumpy pants and think the old workflow had more potential doesn’t mean fields isn’t good too. There are many benefits, like being able to share node groups easier since you don’t rely on typed attributes, fields don’t become incompatible when geometry changes (at least most of the time), and my favorite:
Immediacy
Just plug this into that, and that into this, no typing, like a lot of blender things are just at your finger tips. It’s the same qualities from shading nodes, the wonderful immediacy that I love, and the trade-off noodle disaster, if I do say so myself, which I hate. In that sense fields might feel more “blender” I think, for better or for worse. I just hope that we don’t lose flexibility compared to the old method.
My favorite comment in this thread has been form Brecht who said
This pretty much sums up how I feel. Fields will come with a new list of challenges to overcome for the devs, but I have a lot of faith in them. Right now fields is experiencing a lot of growing pains as its new and just getting it’s legs, so we gotta remember to be patient and have faith in the devs.
10 Likes
Nice Post! It is a shame that there was never a public build of the attribute processor branch to directly compare with the fields prototype branch. Would have been very interesting to see how they stack up.
As you mention, I think many fields setups will be messier, especially with all the individual set/get nodes for every attribute that will be required, as can be seen in this patch: ⚙ D12687 Geometry Nodes: Add Nodes to Get/Set Built-in Attributes .I would have thought that many of these could be combined into one node with a dropdown for each attribute.
I am already missing having named attributes in current master, and really felt that the fields prototype had the best of both worlds with the combination of fields and the set attribute node. I believe that Hans was against removing all named attributes, so I guess the decision was made higher up the food chain? Doing this just to avoid name collisions is a real mistake imo and a case of “throwing out the baby with the bathwater”. It should be up to the user to make sure there are no naming conflicts, with blender just throwing up an error with the existing node error system if there are conflicts.
I have been wondering how I will convert some of my pre-fields 3.0 setups to the new system, without any reliance on user created attributes. My fear is that the new geonodes will quickly turn them into spaghetti nightmares, with connections going all over the place, which could be easily mitigated with at least a basic set and get custom attribute node. The dashed node connections are also not helping allay my potential spaghetti nightmares 
1 Like
I’m not sure about the curve nodes
But set position, for example, do not make sense if we can set by attribute name and choose the ‘position’ attribute. This just add useless repetition in the add menu
Wait
These will come back right ???
2 Likes
I hope so!! I was trying to do some testing and I just wasn’t able to get built-in attributes like tangent and rotation of points, and create selections because of the lack of those nodes (and a “create named attribute” node).
I Just Hit a big wall and wasn’t able to do some basic stuff I was able to do with old system and/or with the prototype… like not even be able to align rotation of instanced geometry on a curve to its tangent… (though this was probably due to the lack of nodes that will be eventually implemented in bcon2)
To summarize, the best version of GN I ever used was the first Fields Prototype, It had selections implemented in a bunch of nodes and the anonymous + named attributes workflow, just the best of two worlds.
3 Likes
Well… IMO individual nodes are more handy to use.
Just imagine the video tutorials we are going to make, which of the two is less overwhelming for beginners?
-
Add a primitive cylinder node. You want to right click shade smooth but doesn’t work? Don’t panic, just add a
Store Named Attributenode, and type “sh”, do you see the pop up of the list of attribute? select “shade_smooth”. Then switch the data type to Boolean. As for what Boolean means I will explain later in the video. Then check this checkbox. -
Add a primitive cylinder node. You want to right click shade smooth but doesn’t work? Don’t panic, just add a
Set Shade Smoothnode and check that box.
Yes the two get and store nodes are still necessary, but more for geometries coming from object info I guess. Because you can basically get attributes from Group Input and store attributes with Group Output, but geometries coming from Object info cannot just get attribute from the Group Input, so the two nodes will still be necessary for this, if I am not mistaken. And the attribute set by the Group Output cannot be used within the node tree itself so the Get Named Attribute is sill needed.
The Store Named Attribute node actually has a patch so I am kind of sure the Get Named Attribute will be there as well. And the individual Get/Set nodes for built in attributes are nearly done, I am looking forward to them
2 Likes
Totally, and in addition to that, I think that they are necessary for Geometry created inside the node tree as well.
For example, Primitives.
I’ll make a concrete example:
I was trying to create a procedural bridge where the pillars length would adapt to the terrain using raycast.
I was planning to create the basic prototype pillar shape with a cube primitive node, and I needed to select the bottom vertices and store the selection.
Those vertices would be snapped on the terrain using raycast. Without a “Store Persistent (bool) attribute” I was just unable to store the selection for later use after copying the pillars on points.
This would be accomplished with an hypothetical select node that outputs an anonymous attribute field, now that I think about that.
But still, If I want to access built-in attributes on primitives created in the node tree like a cube primitive or a belzier segment… I still need the “get attribute”, otherwise how do I access say “Tangent”, from a specific curve creation node?
1 Like
I don’t mean beginners of Blender, I mean beginner of GN who is already used to the right click shade smooth .
Not hidden, but simple tasks like shade smooth just should not be this troublesome
1 Like