Geometry Nodes

[Xeofrios]

@ogonek

I think it makes sense to either combine both nodes or leave it like it is to better discern them.

I personally think removing the output would make it work in the same way as attribute transfer, raycast and statistics- thus a smoother learning curve. From what I have seen, that is the intuitition for non-advanced users anyways. For example-

Geometry Nodes

Can you show me how the nodes should be? That is the thought I had but I have no idea what it’s actually supposed to look like. [image] Nothing happens, no matter what I change in the Align Euler node. The mesh to points node puts the instances on all 4 corners of the faces. I need the instances in the middle of the faces only.

---

---

---

@Debuk

So generally you define the state the geom is in at a specific “time”. And from that moment on the attribute is there and also processed. While splitting it just off and lead it back at some arbitrary time would lead to all sorts of unsharpness in the definition.

@zeroskilz

In that case, the Attribute Capture would need to infer what to do with the index on the new generated geometry, which to me sounds much harder to implement than the current paradigm “tacking data on and letting it go along for the ride”.

The way I see it, everything would work the same way it is now. As I have said before, Blender can always internally connect the (hidden) output of the attribute capture just after the point connected to the input. So everything remains same as before.

To summarise, Attribute capture should work like a special case of attibute transfer where the source/target geometry is a previous version of the current geometry

[rawalanche]

I think the main problem is Capture Attribute itself, not how Capture Attribute works.

I really think that the Capture Attribute should be deprecated and eventually removed. It would be much better if we have explicit control of how attribute gets transferred each time the domain changes (Curve to Mesh for example), rather than hoping that the black box Attribute Capture node will just magically do exactly what it’s supposed to do along all the steps and possible domain conversions from the point where it’s used back to the point where it’s captured.

[Hadriscus]

I think the interpolation is actually handled by each node -but I could be wrong. Hans didn’t touch on this when he last visited, still I’d be curious to know.

[rawalanche]

Yes, but somehow I just don’t believe it will do exactly what you need each time. I’d imagine that on every domain conversion, I should be able to pick which domain to transfer the attribute to, and based on what.

So that you could chose to transfer your curve vertex attribute specifically to face corners or mesh vertices, and you could decide which parameter is the transfer based on, such as distance, and so on.

[zeroskilz]

I’ve found that when plugging an attribute (captured from a non outputting geometry) into a group’s output (a group which switches domains internally), you need to capture it again on a geometry that is part of the output also, or it won’t register outside of the group.
So, it is already pretty explicit…

[rawalanche]

Yes, but it’s explicit in a way which makes the node networks very ugly and messy.

[Hadriscus]

We are talking about capture attribute, not transfer attribute right ? If Hans’ extrude node is any indication, attributes present on the geometry at the time of a topology-changing node (such as extrude) will not change domain. I assume the rules of propagation would be different for every node, for instance bevel would probably interpolate adjacent faces’ attributes along the bevel geometry, etc.

In the case of curve to mesh, I can’t really imagine another way of transferring an attribute from the source curve to the resulting tube. Different interpolation between curve vertices for instance ?

[Xeofrios]

Do you have any mockups for how attribute handling should work? I think the balance between explicitly and auto-magically is pretty good right now. But I do also think there should be dedicated domain change nodes without any geometry input or output.

@Hadriscus

I assume the rules of propagation would be different for every node, for instance bevel would probably interpolate adjacent faces’ attributes along the bevel geometry, etc.

I think every node had its own way of attribute interpolation. I remember from Hans’ notes that the attribute interpolation for the extrude node took a lot of work and discussion.

[Debuk]

The problem with this kind of discussion is often, that the problem itself faces rather practical problems and not just semantic ones. And yeah its quite easy to state that it should simply connect to this and that node automatically. But in fact there is a lot of freedom built into how and where these connections are made. And eg there might be a big amount of nodes around that connection encapsulating the capture attr node and also on the geometry path. The parser will have to keep track of changes in split off subtrees at compilation time for attribute additions what have to be processed along the geoms path, what may hurt efficiency of the compilation and it leaves some definitory questions open, when exactly is the attribute present, when it is filled with dummy values, with attribute outputs. What happens if I try to capture an attribute that is created but not filled etc. But that shall not mean that your idea is not possible, I simply didnt take enough time to rule that out. So please dont take it as that.

Its just that its a strong argument for the user and the developer if there is a clean definition directly readable and built into these connection systems. Currently these attribute creations are placed quite clearly in a generally cyclefree tree that can be traversed from the leaves or root without implicit assumptions on changes done in bypassing splitted subtrees. To me thats a strong argument for it, also from a users perspective.

@Xeofrios

To summarise, Attribute capture should work like a special case of attibute transfer where the source/target geometry is a previous version of the current geometry

Attribute capture is an attribute create node, not just a getter. It modifies the geometry from the input socket. The attribute transfer itself does just offer a view on a geometries data to be processed in a completely different context. Its not modifying another geometry. That is done by another setter node in that split off geometry path. I really prefer this being transparent to the user.

[Xeofrios]

I still can’t really see where it can go wrong . In all the situations the connections seem obvious. It really is just a visual change and nothing is changing underneath. You might even be able to make an addon which connects the attribute capture output just after the input.

@Debuk

Attribute capture is an attribute create node, not just a getter.

That I think is a matter of perspective. You are just “getting” the attribute from a previous version of the geometry.

[Debuk]

@Xeofrios

That I think is a matter of perspective. You are just “getting” the attribute from a previous version of the geometry.

You can use it like that, but in general thats not true

The Capture Attribute node stores the result of a field on a geometry, and outputs the data as a node socket so it can be used by other nodes.

The result is stored on the geometry just like a regular attribute with a name, but instead of referencing it with a name, it is retrieved whenever the socket is connected to the input of a node. Later on when evaluating the node tree, the attribute will be removed automatically if it is no longer used.

[Xeofrios]

Internally, sure it is working differently. But form a user’s perspective, attribute transfer and capture aren’t really that much different. Both are bringing data from some other geometry, but by different transfer metods.

[Hadriscus]

There is a fundamental difference that you seem to be missing, it is that capture attribute stores the attribute on the geometry, so subsequent geometry nodes operating on the same geometry flow will work on that attribute, modifying it to fit the modified geometry (as explained in the extrude mesh task linked above). That, as far as I know, is not possible in any other way.

Using transfer attribute from a previous geometry in the same geometry flow would exclude all nodes in-between (extrude, inset, bevel, etc) and all the attribute propagation work they’ve done.

[Debuk]

Yes it is technically something very different, it has different limitations and performance implications. But yeah in the end every node is modifying data of some sort. So they are all the same in this regard not just these two. Not sure, why you prefer that they are not clearly readable in a nodegraph.

[Xeofrios]

@Hadriscus

There is a fundamental difference that you seem to be missing, it is that capture attribute stores the attribute on the geometry,

@Debuk

. Not sure, why you prefer not being aware of these differences.

I am not against knowing how these node work, but against having to sacrifice workflow and intuition for some information that is mostly useless for the user. As far as the usability is concerened, Attribute capture “captures” an attribute from a previous geometry state.

Which is more easier to imagine-

1. “I will write this attribute into the geomtery using the attribute capture so that I can use it later on in the node tree”
2. “I will use attribute capture to use this attribute from the previous geometry”

[Debuk]

Both are pretty simple. Its just that the second tells you nothing about what is really happening.

​But yeah we differ on the level of abstraction we prefer here.

[Xeofrios]

When working on large trees the second one saves a lot of brain power, mainly on trees where the flow becomes not-so-obvious

[Hadriscus]

It’s not about how they work, it’s about what they do. They don’t do the same thing ! I’m not sure how else to explain it. Hans’ post above is what helped me understand. (Geometry Nodes - #2920 by HooglyBoogly

[Debuk]

No this is just adding implications and assumptions that have to be known and so it makes graphs more difficult to understand. But I got your point, I just dont share it. Lets stop here. Its taking up too much time.

[Xeofrios]

Of course they are very different. I am just asking for a sort of shorthand where the evaluator just assumes th geometry output is connected . It will lead to much better better looking and readable node groups.