This has been the case for quite a while now, not specific to dash line, the old solid line also has the same behavior, this is intended.
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
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
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.
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.
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
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 ???
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.
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 Attribute
node, 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 Smooth
node 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
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?