Intuitively, I think of Capture Attribute as remembering (data from) the previous state of a mesh, before being changed. Or just “Capturing” certain vertices to only Raycast from those vertices alone, instead of the whole mesh.
Capture Attribute manual kind of says the same thing:
This node is essential because field input nodes like the Radius Node work in the context of the node they are connected to. Meaning that in order to pass data like radius to a geometry that doesn’t have radius, an explicit node link with the output of this node must be used.
According to Hans it seems that Capture Attribute will work further down the node tree only if at the point you are using it, that object has that specific Anonymous Attribute that you want to manipulate. (i.e. if you Capture a Radius to use on a geometry that doesn’t have a Radius, then nothing will happen, contrary to the manual).
Solution proposed by Hans in the bug report is that I use Transfer Attribute, but I don’t want to transfer or map/interpolate any data between any objects. I want to use data that exists at some previous point in the tree, and use it later.
Conclusion:
This brief interaction left me with many questions:
If that is the intended way of working for Capture Attribute (in 3.0), then why does it work like I expected it to work, in 3.1, which is different? (download the example file from the bug report and see with 3.1 it behaves differently)
Why have Capture Attribute at all, if you can just use Transfer Attribute then? (difference of use case?)
What should change? The Node, the Manual, or my understanding of these 2? (I can be hilariously wrong)
PS: I hope Hans won’t hate me for this thread. I’m not trying to point fingers at anyone or anything. I just feel that something, somewhere, isn’t clear as to what it should do and I’m hoping this thread can shed some light, and I don’t want to post this kind of discussion on the bug tracker…
I am not sure but I guess it has to do with Capture Attribute in 3.1 supports instances while the one in 3.0 does not. Or maybe it’s just because of 3.1 supporting Instance attributes in general. In your case your small icospheres are instances so I believe this should be the reason.
I am guessing here, what happened is that in 3.1, the position field got captured into an attribute in point domain, and later got correctly converted to instance domain. This didn’t work in 3.0 because the captured attribute cannot be converted to instance domain since instance does not have attribute support in 3.0. So if you select “Instance” in the domain drop down of the Capture Attribute node in 3.1, you should see the same behavior as 3.0.
They are different. Capture Attribute is evaluating a Field (not actual data, just a function, the position field node is not any geometry’s position, just a “reference” to the actual position data), into an Anonymous Attribute (the type of attribute that you don’t need to type names to use), the actual Anonymous Attribute is being passed down through the green geometry lines, the dash lines are still just fields references. So you get the idea here, Capture Attribute creates an attribute from scratch while Transfer Attribute conveys one existing Attribute from one geometry to another.
Here is how Capture Attribute can be useful:
First if I directly plug the field (dash line) into the Mesh to Curve node:
The field is now evaluated at the Capture Attribute node before subdivision, and the created attribute is passed down through the green geometry connection and the selected edge persists after subivision. This does not work if you use Transfer Attribute bucause they are simply not the same thing.
This is a very clear explanation. At some point in time (thought) I understood how ‘capture’ worked, and then I got confused again. The problem is that the name ‘capture attribute’ feels like it takes (the values of) an attribute at that point in the tree and sends it through the ‘attribute’ output. But that’s not what it does at all, as you clearly stated. It creates an attribute in the geometry (which is still the only place an attribute can exist) and the attribute output is just the ‘name’ of the attribute which you can use to referenc it later on.
Maybe ‘create attribute’ would be a better name?
edit: I actually think a better name would be ‘Capture Field as Attribute’.
Sorry for more or less rephrasing your already very clear post. It’s just that this made it click for me and I hope it will do the same for others.
First of all, I hope that I can get an important idea across (this is my main concern):
The same node, SHOULD act the same way, across all Blender versions, down to the most recent LTS version.
Exceptions are understandable, but they should be rare. Therefore, if 3.1 Capture Attribute has new behavior caused by instances now accepting attributes, shouldn’t that be ported to 3.0 beta? It’s not a feature per se, can be called a patch.
@Eary This is extracted from a tut I made on YT. I am trying to capture the vertices of the floating planes, and use them as source, to cast a Ray (Raycast) down onto those points, so that I can place some statues on those corners.
The planes have been Realized. So my question is, should this work? Should it matter if it’s 3.0 or 3.1?
It is a feature. If something wasn’t supported before and wasn’t suppose to, then adding it in next version is a feature.
Trying to expand definition of a bug is a slippery slope to calling any feature a bug just so people can get their favorite feature in “stable” version. It is very easily abusable, just watch:
“Hey, this node wasn’t supporting instances properly before, we should backport it!”
“This node wasn’t supporting curves before, we should backport it!”
“Attribute statistics node wasn’t supporting selection before, we should backport it!”
“Spreadsheet editor wasn’t supporting volume grids before, we should backport it!”
“Hey, this node wasn’t so fast before, we should backport it!”
…
“Hey, when Cycles X will be backported to 2.93 LTS?”
You might think I’m overreacting, trust me I’m not, I saw before people asking if Cycles X will be backported to 2.93 LTS.
Additionaly consistent behavior in one particular stable version >>> consistent behavior across all other versions. People work in 3.0 right now, changing behavior of existing and used in a project node by adding support for certain data type and marking it as “3.0.1 release - bugs fixed” is not really nice idea. Even moreso for an LTS on stability and consistency of which studios build pipelines.
Frustration due to changed behavior is understandable. Hovewer you can’t make an omelette without breaking eggs, and given how fast various developers add improvements and additions to Geometry Nodes I expected a lot more breaking eggs.
Your point about inconsisted behavior is valid but should be addressed in a different way. Clear communication of changes. All changes should be documented on release page and manual for 3.1 should be changed accordingly. I’d say it’s good so far but I haven’t really inspected it in detail.
From community (which is inseparable part of Blender) - updates to tutorials, help on forums, showcasing changed behavior. And just like here: raising concerns, starting discussions.
Seeing how there are more in favor of this being the norm, I won’t pursue it further.
I do want clarify some things though:
Not really a fair comparison. Cycles X is a whole project and a feature. The equivalent here would be me asking GN to be supported in 2.83 or 2.79.
Please understand that what I’m asking for is consistency, NOT feature additions.
An example:
3.0 has Compare Floats, which does just that.
3.1 has Compare, which can compare ALL data.
I’m not asking to backport THAT, because that is a feature.
The Capture Attribute that was untouched across versions, but having different behavior… If that is to be called a feature, then I see no reason to continue this conversation.
Definitely not. I was aiming for the opposite: 3.0 to have the “intended” functionality.
But it seems that I’m aiming too high.
I’m aware of this.
This is actually the reason why it’s very hard for me to argue whole-heartedly for the thing that I’m asking, because it’s not a problem with the node itself.
