for builtin attributes such as the radius in your example this nodes are being worked on: https://developer.blender.org/D12687
1 Like
Thatās exactly how felt when I realized where we are currently heading.
5 Likes
Ah yes! thanks for sharing. this is a relief.
But then again this makes me wonder about custom attributes as well.
with the current āattribute outputā system I cannot imagine it being as flexible as the legacy attribute or the hardcoded set and get inbuilt attributes. Since this is an āattribute outputā I donāt imagine you can do complex maths operations with them as I described above. I mean right now Iām still trying to manipulate the radius of a specific curve geometry that isnāt the final output of my set up and Iām already getting a headache figuring that out. heck, I donāt even think itās possible with this system.
Arenāt attributes (custom or not) supposed to be tied to specific geometry domains? It seems like this system throws that out the window. Also from my understanding fields does not necessarily need to replace attributes. they can coexist side by side. Or am I getting something wrong here too?
2 Likes
Iām not sure I understand your concern. What would be an example of a situation that wonāt be solved with those built in get/set nodes?
Anyway, from what Iāve read, this store named attribute is going to end up in master https://developer.blender.org/D12685
and the only disputed thing is weather there will be an attribute get by name node or not, which I thing it should but weāll see.
2 Likes
Fair point. Iām likely still imagining geometry nodes using the attribute system as I started learning fields today. if all the inbuilt attributes exist as get/set nodes then my concern is invalid. However that raises a new question. what then is the point of the named attribute stuff (I still donāt fully understand it)
A typical example workflow for the previous attribute system is this: say I wanted to make a wavy geometry grid from a flat grid, I first get the position attribute, separate the x,y,z into new attributes, find the sin of the new x attribute and set the position attribute such that its z component = sin(x). Now in fields I imagine all this intermediate attributes I created arenāt necessary anymore as I can just do maths operations similar to the shader nodes. If this is correct then what is the purpose of the output attribute or named attribute? are they any scenario where it is useful?
1 Like
Right, named attributes are are still useful to comunicate custom attributes to other systems, like shaders. They can also be useful in certain cases when you want to use an attribute further down the line but you donāt want to have such a long noodle.
1 Like
Thanks for the clarification.
I donāt consider sending attributes to other system as a major part of geometry nodes so I couldnāt care less about how that is handled. (Of cause its useful none the less)
However the second use case though sounds rather interesting. Are they any specific examples of this being done? How will it work? from the current implementation thatās probably the last thing I would guess to be the purpose of it.
Yeah, that use case would only be posible if they implement the get attribute by name node thatās being discussed. Then say at the beggining of a big nodetree you computed a value that you want to use in far places, instead of connecting it via long noodles you could store it with a name, and then, wherever you need it use a get attribute node and plug it. It only makes sense for very complex trees, and even then there might be better solutions, Iām not really sure.
2 Likes
I see. the recent conversations are beginning to make a lot more sense to me. Iām definitely in favour of it as itās similar to legacy behaviour. Who says we canāt have the best of both worlds. Letās just see what the developers decide.
2 Likes
Just want to say that the new system is way more friendly to me. Iām very happy they made the change to this new design.
Hi Guys
I created this node group as seen below for the result shown.
I find the boolean options slows down my weak pc a bit.
three more cylinders are instanced and connected to the boolean node.
I did this to have control of the individual radii.
Is there no better way to achieve a similar result.
Adding a join node and a realize instances node before the boolean node can make it much faster. Maybe itās not enough to make it usable for you, but it can make a huge difference.
EDIT: To be clear, I mean on the āGeometry 2ā inputs. Using multiple different meshes means the algorithm has to make many different BVH trees internally rather than just one or two.
2 Likes
Thanks man will give it a shot
Maybe I just hate drop-downs in nodes 
(In fact, I use Node Tabber to avoid using the dropdown in Math and Vector Math nodes). A comparison between dedicated and drop-down based nodes-
Dedicated Get / Set Nodes
- Find/search for the node
- Click on the node
- Place node at required location
- Done (most of the time)
Drop-down Get / Set Nodes
- Find/search for the node
- Click on the node
- Place node at required location
- Click on drop-down / text box
- Find attribute name
- Click dropdown name
- Done (most of the time)
Note that this just personal preference, and one of the steps takes more time, etc.
6 Likes
Right now, all the get / set attributes are independent, so it isnāt a problem. To be clear, I think some of them can be merged.
Actually, I personally think the Attribute names can be indepentdent of the node-tree. Sometimes I need to make shaders single-user just because the vertex colour names are different.
That is interesting, but I canāt understand if the attribute name is overridable like that in the shareable named attributes proposal (which seems to be the main root of debate). To be honest I am quite confused at this point what the devs mean by shareablity. Maybe we all should wait and watch for a bit.
1 Like
Because, i had to stop studying really early for earning moneyā¦ so now iām filling the gap with my non optimized logic. 
But i know how to weld metal, driving cherry pickers, putting out fishesāguts and a lot of other stuffs.
but anyway, thanks for the tip, it will feed me in my way of eternal student. 
Very interesting read. Up until recently I was very optimistic about geometry nodes.
I get arguments for get/set attributes node. Seems like a no brainer.
If Blender Foundation sticks to its current plan with geometry nodes we might get another hard turn before Blender 3 LTS. So the prospect of getting solid basic geo nodes functionality might be even more distant future.
3 Likes
L.O.D / Mesh subdivide
I 'm abble to create a L.O.D system with the new node fields system now, but my first attempt doing it ,was using mesh subdivide.
As a dummy i tryed a lot of different approach after the instance on point node to subdivide as i realize that, for the moment the subdivision can only be achieve for the whole composition of instances.
So i start adding subdivision modifier to my instanced objects, as they where in my used collection. Then i realize that the ācallā was not querying the object but the mesh itself. So, for the moment, iām using object duplications with there own meshes. thatāll be the right method to pass from billboard trees to real geometry. but for subdividingā¦ that 'll be expensive.
for an optimization it ll be cool to have an āinstance subdivisionā or a call at object level so the modifiers are taken in account when it comes to āpopulateā with.
But, perhaps Iām missing another method in GN?
As @SteffenD wrote, the second spaghetti nodes is way more readable, especially for blender users seasoned to cycles shader trees
Furthermore, donāt limit the thing the node count: in the old GN you have less nodes but more bits of information typed in
1 Like
yes! iām agreed, now after practising it more and more.
1 Like