# How can I combine geometry with captured attribute?

Say I have a 2 meshes and I want to capture some attribute for each mesh (Same Attribute Different values). Then I want to join the 2 meshes and only after joining, I want to reuse the attribute to drive something else, like so:

How can I combine the two captured attribute?

The Solution I've found that works perfectly well, was to use the Store Named Attribute instead of the "Capture attribute" node, like so:

Since everyone here seems to be against using this node, and that the documentation clearly states that they basically do the same thing, I was wondering if there is an alternative solution.

• Thanks for the post. While answering your own question is entirely possible and even encouraged, yourself, it should be done respecting the site structure. Could you break this up into two posts, rephrasing the problem to read like an actual question or expose a problem to be solved, while the solution to the issue is presented as separate answer in the proper section below? Perhaps add a few images illustrating the workflow and final results. See How do I write a good answer? Commented Aug 30, 2022 at 10:08

The examples below both come to exactly the same result:

## Capture Attribute

Here I use Capture Attribute to capture a vector.

Since the node Set Position works on the basis of points, and after joining with Join Geometry only one geometry has the corresponding values stored (the other one has $$(0,0,0)$$ at the non-existing points then), you can simply add them with Vector Math.

## Store Named Attributes

Here I use Store Named Attribute to store a vector.

If you store the values with Store Named Attribute, an additional value is permanently stored in the geometry.

This has advantages if you want to process these values after the geometry nodes modifier (for example in the shader).

However, it also has the disadvantage that these permanently stored values can be additional ballast that you don't really need. This can reduce the performance of very extensive geometry, which is why this variant is only recommended if you know exactly what you are doing with the stored values.

However, with the node Remove Named Attribute you can delete the values that are no longer needed at the end, so that they do not represent any further ballast.

• Indeed, so simple thank you @quellenform:)
– MrW
Commented Aug 30, 2022 at 11:45
• What difference in performance is lets say I have 100k instances, I am wiring 10 attributes OR I am storing these as named and removing them exactly when I do not need them? I cannot see any noticeable performance (timings) hits in my tests. Storing named attributes and removing them gives me more tidy workflow and acctually less work during creation. Any reccomendations please? (I do not need to expose these attributes later, they are using just inside the node tree) Commented Aug 25 at 22:01
• @filanek As far as I know, it only has a marginal effect on the measurable performance (depending on the setup) in the standard case. Nevertheless, the more data you permanently store in the geometry, the more you may occupy the RAM. Of course, this can have negative effects in many cases. Therefore, the general rule is: within a node tree it should make little difference, but only store permanently the information that you really need at the output. Commented Aug 25 at 22:03
• @quellenform Finally with further testing seems to me avoiding the named attributes has some performance advantages in my nodetree situation - 61k curves points with three ID integer named attributes vs wires 3000ms vs 2500ms Commented Aug 26 at 13:38