Today I tried to recreate the spiral modifier.
(I have not found a way to upload this video here without youtube)
Download here (free)
Problems finding the original edge / vertex normal and applying them to new geometry.
But for now, you can not think about it.
Also, there is no way to create lists of values yet. (There is a topic about this here, but so far it is no news). Otherwise, due to the data about the edges, it is realizable.
Does anyone know how to disable node auto offset by default? When changing it in the startup file, the setting is per-editor, so when you create new GN editor panel, it comes with auto-offset enabled. This means that I always realize it’s been enabled only after it does damage to my node layout, and only then I disable it, and it wrecks my node layout anyway when I create new GN editor.
This should be in the user preferences, not in the editor itself. This is a workflow preference of an individual. It’s hardly something the same person wants to have enabled in some of the node editors and disabled in others, ESPECIALLY not having different state of this toggle in multiple editors of the same type (for example two GN node editors in different workspace tabs).
Also:
I am trying to generate some twisted tree roots:
Is this a bug? I don’t see any logical reason as to why I could not use Curve Parameter Factor before realizing the instances. Originally, I thought the problem is that before realizing instances, I am transforming (rotating) just a single curve in it’s own space, therefore twisting the curve around it’s infinitely thin radius, but this would mean if I use location of some static point instead of curve center, then the rotation around Z using Curve Parameter Factor as the amount should still result in the spiral, but it still doesn’t:
Until realized, all your instances are just points, with a reference to geometry.
You can NOT modify geometry.
For this reason, I first copy everything as an array, given the index attribute. And then I use it to randomize the real geometry.
Ah, that makes sense 
I am curious about couple more things.
How would I go about transferring the curve factor to geometry when turning curve to mesh? The Capture Attribute node seems to do exactly that according to the docs: Capture Attribute Node - Blender 4.4 Manual but in practice, it doesn’t seem to work despite being set up the same:
If I successfully managed to capture an attribute, how do I store it for later use? I mean how do I name the attribute to use it down the stream. I can’t imagine having to make complicated cobweb of super long node links just to use that captured attribute in the rest of the node tree.
That would be a job for transfer attribute, but it doesn’t work on curves in 3.0 you have to use master
I thought you were part of that discussion a few weeks ago, when named attributes were removed ? Yes you do have to make long links if you need to capture attributes from early in the tree and use them much later.
That being said master has hidden links now I think ? which mostly solve that problem
Oh…
I don’t believe that will solve the problem. you will still have ugly cobweb going out of the output socket to numerous destinations somewhere:
And you will still have node links arriving to some random input socket from miles and miles away, requiring you to trace the link back over long distance to find out what’s actually plugged in there:
I can’t see how that could ever be an alternative to storing capture attribute output under any custom name and then simply getting it in a form of get node down the stream. You won’t have dozens out outputs going out from somewhere, and on inputs, you will immediately see what’s plugged there, instead having to track down the source following long wires 
Yes this is why I said “mostly”.
I also don’t consider hidden links alone as elegant or practical as get/set nodes, but with a few more improvements, maybe ? (named hidden links, portal nodes, etc)
Yeah, unless there is some concept of naming of the links, it won’t solve the problem. And once there is a concept of naming of the links, we’ll just have worse, less explicit ways of doing the named attributes
what do you think would be more compact?
Sorry, but that makes no sense. There is a big difference between evaluating function at each step and storing a result of evaluated function as a data in the topology.
For example imagine you have a tree, and you calculate a vertical gradient from top to bottom based on the geometry bounds. Then you bend the tree, and then you want to access that vertical gradient again. If you create a function that generates vertical position gradient and evaluate it on the bent tree, then the result will obviously be wrong. You no longer have a gradient from the bottom of the trunk to the tip of the tree, but bent. It’s not longer a gradient along the bent tree height.
That’s just basic programming concept. The step at which you evaluate the data matters, that’s why group encapsulation is not a solution to many things.
I really didn’t understand what you mean, but for me there were no problems in estimating the thickness of the barrel
The problem is interesting. Is it possible to immediately inherit interpolated attributes from the domain when distributing points?
it would be possible to inherit the polygon number and uv to move between polygon points, but …
I have another question. When I generate something using curve to mesh, the resulting mesh correctly generates UV mapping along the direction of the spline on the generated mesh. But how do I modify this UV mapping?
EDIT:
Found it. I have to capture attribute of the U spline and V spline factor making up the spline mesh. But it’s still crazy I can’t just store this as a named “mapping” attribute, and instead, every time I want to reference this UV mapping I’ve created, I need to drag out crazy long line from that one socket.
Some time ago someone asked about an example of how lack of named attributes limits the workflow. This is exactly how: If I want to use the UV mapping of the spline generated meshes I have now generated multiple times down the tree, this is how my node tree is going to end up looking:
I don’t see how something like this:
The idea of a scripting language where you can’t name your variables is insane 
What’s even more worrisome is the idea that this will be he solution: https://developer.blender.org/D13675 I can already see the horror of hundreds of wires going all over under the nodes. All that effort spent to reinvent the wheel of variables with names.
I very much don’t understand this approach.
YOU MUST EXPLICITLY SAY WHAT YOU ARE USING WHERE, otherwise you are making unreadable and unsafe code. If you NEED this geometry everywhere, then it is logical that the attributes are also REQUIRED. But there is also an idea of attaching attributes behind the grid.
Reformat the understanding of the grid as a tree of types (polygon, vertex, edge) and assign each type by attribute (position, normal, …).
Now, you should be able to pass geometry that has a position to an input that takes a position.
It looks like interfaces. And if the user can independently customize the receive and exit interfaces, then this will be a structured-typed data transfer in the nodes of one creator.
That circles back to the “named attributes” debate… I was also in favor of keeping named attributes for this very reason.
Yes, I know there was the debate, but I remember that the last time, the conclusion was that the named attributes were just postponed for 3.1, not axed as an idea. Now when I see things like hidden links and named reroutes, I am worried that those are supposed to replace name attributes.
Yeah, I’m also becoming concerned about this.
That being said: it is holidays season right now, and things are a bit slow at the moment.
I would give 3.1 a chance to mature, before sounding this alarm.
3.1 is mostly just a +1 version at the moment. It doesn’t have many implementations yet.
EDIT:
I’ll leave this here for now: ⚓ T90864 Persistent/named attribute nodes
It’s the named attribute task linked to the 3.1 Targets.
The task also has a link to a further conversation on the topic.
I’m hoping that since then (August), when the task has been created, until now (December), is sufficient time and evidence that the entire community is really really REALLY asking for this one to be added back.
It is still planned. Hans just mentioned in the weekly notes that he is working on it next week:
working a bit on the named attribute nodes
