# Combine two position nodes from different mesh primitives inside a geometry node tree

I'm trying to understand how to use two positions nodes relative to two different meshes. In the following example, I thought that the grid would be translated relative to the coordinates of the one vertex output by the mesh line node. But this is not happening. Am I missing something? • You're missing that the Position node always refers the the geometry that the modifier is attached to. You need to use an Object Info node to get geometry information from other objects. Jan 22 at 22:18
• What are you trying to do? Jan 22 at 22:35
• @MarkusvonBroady I'm trying to use geometry node for scientific visualization of a field (namely the velocity vector for a fluid inside a pipe) doing all the calculation work within a geonode tree. That's pretty challenging but really interesting ;-) Jan 23 at 14:40

You have to read the geometry nodes from right (end) to left (beginning).

Your example doesn't make a lot of sense, because the positions of vertices in a Mesh Line are very predictable (linear interpolation between start and end), and so rather than sampling it, you can just mix RGB two vectors... So let's say we want to drag a cuboid across all vertices of an icosphere: 1. Group Output has a Geometry Input, so that's where the execution goes.
2. Set Position has a Geometry Input as well, so that's where the execution goes...
3. Cube node generates a cuboid mesh, and the execution returns to Set Position.
4. Set Position iterates over all vertices, for each vertex it needs to evaluate the Offset, and so it sets context to vertex #0 and goes left to TA.
5. Transfer Attribute has geometry attached...
6. Icosphere nodes generates an icosphere mesh, and the execution returns to TA.
7. Transfer Attribute now evaluates Index, so it goes left through two math nodes to the statistics...
8. Round goes to Multiply
9. Multiply goes to statistics ⬅
10. Attribute Statistic has geometry attached...
11. As in 6. Probably the geometry is cached and not generated each time, but it doesn't matter, as each time it would be generated in the same way (it's deterministic). The flow returns to statistics.
12. Attribute Statistic samples the input (the index) for each vertex of attached icosahedron, by going left through the Attribute input.
13. Index node gives an icosahedron vertex index, because the context changed to the icosahedron. 1. Attribute Statistic goes to the next icosahedron vertex, and repeats p.13 Eventually it reaches the last icosahedron vertex and sends forward the largest of the samples (41) to the Multiply node. The context returns to the cuboid vertex.
2. Math > Multiply still needs another term, so execution goes left to evaluate it.
3. Multiply Add needs a value.
4. Separate XYZ needs to read the Vector attached.
5. Position node yields the location of currently evaluated context - the cuboid vertex.
6. Separate XYZ
8. Multiply
9. Round
10. Transfer Attribute finally can do the work. It evaluated the index, so now it knows which icosphere's vertex to access. This ico-vertex now becomes the context, as Attribute input is evaluated.
11. Position of the current context = icosphere's vertex is passed forward ➡
12. Transfer Attribute changes the context back to the cuboid's vertex, but passes forward the position of icosphere's vertex ➡
13. Set Position offsets current context = cuboid vertex, by icosphere's vertex position. Then it changes the context to the next cuboid's vertex, and goes back to p. 4. Eventually all cuboid vertices are evaluated, and the changed geometry is passed forward ➡
14. Group Output gets back the requested geometry. The end.
• Thanks for this detailed answer and for your time (+1). I really thought the capture attribute would be the way (I must have somewhat misunderstood default cube ice cream tutorial). Jan 23 at 14:46
• @cjorssen Capture attribute makes a copy of an attribute and creates a new field (that you need to propagate through reroutes to wherever you need them, or the the Group Output to save it in geometry for later), but the context stays the same. Transfer attribute does the same but creates a new context. Hope this helps. Jan 23 at 14:57
• Yes, this really helped! Thank you again. Jan 23 at 15:11

As the manual entry for Position Node makes perfectly unclear:

The Position node outputs a vector of each point of the geometry the node is connected to.

That is, the position node only provides information on the object that the GeometryNodes modifier is attached to. They're not relative to the two meshes you've created.

You can't use the position node to access data about meshes you create within the node tree.

If by "two different meshes" you mean two meshes you created within the node tree, as in your example, just use their geometry data directly. If you mean meshes that are externally created, then use an Object Info node to get the data from the others.

If you want to translate the mesh using an input, something like this would do it: Replace the Vector input node by whatever nodes you need to generate the translation you want.

• cjorssen is referring to two different meshes within the node tree, not a different object. Jan 22 at 22:24
• cjorssen is referring to several things, including the Position node. Jan 22 at 22:25
• cjorssen is referring to several things, excluding multiple objects Jan 22 at 22:29
• "Perfectly unclear" is sarcasm or a Freudian slip? Jan 23 at 0:16
• Thanks for your time and for your answer (+1). Indeed, I thought that the Position input node was relative to the geometry used in the node where it is plugged in. But, it seems that I was wrong. And by "two different meshes", I meant two meshes you created within the node tree: so how would I use their geometry directly (how to access the X, Y and Z of each of their vertex)? Jan 23 at 14:51