Oh right, that makes complete sense. Appreciate it. I think this is the most important bit :
Technically I suppose capture attribute works by index, though? as in, it keeps existing attributes on existing indices.
1 Like
Edit: Sorry, Iām an idiotā¦ 
the flow was correct before, because for Attribute Transfer the index doesnāt come from the source it comes form the thing being transferred to.
But yes, you are correct, an Attribute Capture is like an alias for Attribute-Transfer-by-index. The geometry output socket in the Attribute Capture node just makes the index-linkage explicit (1 to 1).
Well, not exactly, actually. Because the anonymous attribute created by the capture node is actually stored on the resulting geometry, it can be interpolated properly when the geometry changes, even for topology-changing operations. Thatās something an index-based mapping wouldnāt be able to do.
Hereās an example. The capture node stores an anonymous attribute layer with a selection of just the top face. The extrude node then propagates that selection to the side faces of the top faceās extrusion. Then when the anonymous attribute is used later on, it uses the current values of the attribute at that point.
So, transfer by index is the same thing in a lot of situations, but not all of them.
11 Likes
Ooooohhhhh so the capture attribute node stores the attribute and then subsequent nodes (extrude mesh) interpolate that attribute ! We tend to forget that anonymous attributes are a thing, now that the fields workflow is in placeā¦ there can still be attributes stored on the geometry, itās just that theyāreā¦ less visible than they used to be.
Basically capture attribute works exactly the same as create attribute in Copperfield.
I wondered about that. But how does a node figure out how to interpolate a given attribute when it creates new geometry? Is this logic unique to each node that alters topology? How does the subdivide node interpolates captured attributes for instance?
Thanks for shedding light on this arcane contraptionā¦
I understand your general idea, but at the end of the day Blender can (I think) make the connections internally
To me the personally the current implementation looks more visual than functional (which might be a good thing). I have actually seen many make the mistake of not connecting the geometry output.
New āEven-Thicknessā Node-Groups with even evener evenness available here:
and here:
3 Likes
not really, or rather, only kind-of - only in cases where the underlying geometry domain is the same would that work.
E.g.
ā¦ that does nothing.
Yes, I think it is quite obvious it would do nothing. That is the same case in the current imlpementstion too
Then please be clearer about the point youāre failing to make.
I am of the opinion that you shouldnāt need to connect the geometry output of the attribute capture to the geometry flow, mostly for worrflow and cosmetic purposes. It does not add any new functionality.
By the way, here is my take on your āCyclic disconnectā node group
This one works in 3.0:
Or simply, if you donāt care about performance,
1 Like
Yeah, noā¦ that opinion makes no sense given that context always matters. I feel like youāre missing a fundamental bit of understanding in that all your examples only have one geometry flow when the rest of us were discussing multiple geometry flows.
Try your reasoning with multiple (differing) geometry flows, and see if it still holds up.
Good luck.
2 Likes
I too have been slowly getting my mind around when to use that node. It turns out that it is sometimes the only way to write usable attribute to a vertex color channel or to a weight map (for instances such as making it work with Cycles micro-displacement). It is the same story in terms of ensuring you have usable attribute data for trees that introduce geometry outside of the source object.
An example, writing the position of vertices to a vertex color channel and using that as texture coordinates in Cycles, it finally gives Blender the ability to have automated coordinates for procedural textures that deform when a deformation modifier is used (so long as the geometry node tree is evaluated before said modifiers). Together with micro-displacement, it has interesting implications for character and creature modeling.
1 Like
I canāt find any counter- examples because as far as I can see it is only a visual change. I would appreciate it if you could post an example along with the expected result, where the current system works and the new wouldnāt . 
1 Like
For me it makes sense, as one is carrying attributes along the flow while maybe skipping some nodes in between while the other is transfering attributes from one flow to another. I canāt come up with any examples, where the flow output would matter either, because you cannot transfer it to another system anyway (thatās your point, right?) but I think it makes sense to either combine both nodes or leave it like it is to better discern them.
What irks me much more is the autoconnect feature dropping the transfer node into the flow with an invalid output to the next node. (among others) This is so annoying. Autoconnect should just not be allowed to create red noodles. Damn! 
The autoconnect feature has not been checking for the socket type since its inception, it more or less just connects the first socket available in the node being placed. If I remember right, it was a quickly made patch to make extending a tree less annoying.
Since nodes are becoming far more important now, I do think it is time to make that feature a bit smarter.
1 Like
Well the capture attribute gets an input geom and defines an output geom.
The transfer attribute node on the other hand gets an input and delivers data to some other geom as sort of a dead end. It needs a transfer function to be mapped to an arbitrary geometry.
So eg a set position node gets attribute data transferred and mapped, and then again there is an input geom and an output geom.
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.
1 Like
Seeing again if I can understand what youāre suggestingā¦ is it something equivalent to this? (a bit from for a curve-to-mesh that has 2 āgeometry flowsā):
And instead of these āU/V-Transferā Node-groups youāll just have the Attribute Capture Node?
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ā.
Maybe it is a personal thing, but I really do prefer the current way of being explicit about the data-flow.
BTW, thanks for the disconnect tip.
racast + extrude + mesh to curve + resample curve ā curve to mesh ā set position(noise)
3 Likes
Hello,
Is there a way to set an attribute in GN to some instances and use it into the shader ?
Iām instancing some geometry from the geometry editor ( a generated cube ), Iāve got it working if I realize instances, but is it possible without ?
Working with Geo Nodes is quite an emotional rollercoster, but Iām amazed by the possibilities even at this stage of the development !
@Xeofrios : Thanks for the subdivide tip, this works well in 3.0:
ā¦ didnāt grok the significance of the cuts input being a field and it just opened up a whole lot of possibilities like auto-fillet of vertices that exceed a threshold angle, etcā¦
The Value at Field node looks great and I canāt wait to phase out all my clumsy āstoreā patterns that I have to do to work-around that for now.
Thanks!
1 Like