Geometry Nodes

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 :slight_smile:

I am curious about couple more things.

  1. 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 Manual but in practice, it doesn’t seem to work despite being set up the same:


    The output attribute has no effect. I’d like to bake the Curve Parameter factor into the vertices of the mesh as a float attribute.

  2. 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:
image

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 :expressionless:

1 Like

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)

https://developer.blender.org/T93293

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 :slight_smile:

  1. You need to capture the curve attribute ON the curve.
    edit:
  2. Group individual actions into nodes! It is important! These are functions! If you can’t group them, then don’t complain about the sizes!
    edit 2:

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


inheritance

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?


I mean, if I can define the attributes only on the group input, in case of the root GN node tree on the GN node tree input, how do I access the UVmap attribute which has been generated by the Curve to Mesh node so that I can transform it? Because obviously that attribute is not present on the input, it’s generated inside of the network. O_o

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:



Could ever be considered a threat to GN fields design, or substituted by this: ⚓ T93293 Hidden links

The idea of a scripting language where you can’t name your variables is insane :confused:

What’s even more worrisome is the idea that this will be he solution: ⚙ D13675 Nodes: Support linking to named reroute from link drag search. 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.

4 Likes

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.

1 Like

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

5 Likes

Whew, fingers crossed :slight_smile:

This will be the biggest step backward.
Useless names again
Incomprehensible links
Nodes for entering expression strings
full-fledged written programming languages
magic python generator for beginners

It seems like there is still no consensus between development and coordination… I hope this is agreed upon before any actual development happens. Jacques’ comment on the relevant task is completely right : long connections is a general problem, not limited to attribute usage. Named attributes are not a solution to this general problem. “Portal nodes” look like a better fit imho.
If attributes only need naming at the boundaries between systems (it does seem like this is the case) then the output attributes fields in the modifier interface are doing the job just fine…

1 Like