# Blender Viewer Nodes showing different values for the same vectors depending on the geometry attached to them?

I posted a question on StackExchange directly 4 days ago (link), being unaware of this specific Blender-StackExchange. So please appologize my double-post. Here is my question that meanwhile keeps me from sleeping at night because I don't get were my fundamental error of thinking is.

In Blender (3.1.2) I tried to connect the "corresponding" points of two curve-circles with the same center (at world-origin) with cones, like the beams of a symbolic sun with the inner circle being the circumference of the sun-disc and the outer circle being the circumference of the tip of the beams. This is just an exercise to later do the same with curves of different shape, for instance between an inner circle and an outer ellipse.

Therefore I want to calculate the relative vectors between corresponding inner and outer points to scale the cones accordingly to these vectors' length. However, I found that my simple vector math don't work as I expected.

I created a simplified scenario without the cones to demonstrate the issue I'm facing. The upper and lower half of the Geometry-Nodes tree attached as screenshot #1 below are identical. The upper part is for the outer circle with radius 2, the lower part for the inner circle with radius 1. Both circles have only 4 points for simplicity (so they appear as rhombs as seen in screenshot #3). In the 5 boxes I do the following:

1. Create the circle-curves, convert them to points and capture the point positions.

2. Subtract the positions of corresponding points to get the relative vectors pointing from the outer to the inner circle's points. The result should consist of a list of the 4 vectors [(1,0,0)(0,1,0)(-1,0,0)(0,-1,0)] with all having length 1 due to the radius difference of 1.

3. Put small Ico-Spheres to the points of both circles by Instance-to-Points nodes. Here is where also the cones would be instantiated, but on just the inner circle.

4. Group-output the geometry of the circles and ico-spheres.

5. Here comes my issue, displayed by 4 Viewer-Nodes (see points a-c below):

a) The geometry-sockets of the top two viewer-nodes are attached to the ico-sphere instances on the outer circle, with the top one showing the positions of their points captured in step 1. The positions are shown correctly.

b) The geometry-sockets of the bottom two viewer-nodes are attached to the ico-sphere instances on the inner circle, with the one on the very bottom showing the positions of their points also captured in step 1. Also here the positions are shown correctly.

c) The value-inputs of the two viewer-nodes in the middle are attached to the same vector array calculated in step 2. So I would expect their outputs showing identical vectors in the corresponding spread-sheets, independent of the geometry the viewer nodes are attached to. But these two viewer nodes show different vector outputs. Why is that?

My expectation would have been the following outputs:

a) From the top-most viewer node (points on outer circle): (2,0,0)(0,2,0)(-2,0,0)(0,-2,0) <-- shown correctly

b) From the bottom-most (points on inner circle): (1,0,0)(0,1,0)(-1,0,0)(0,-1,0) <-- shown correctly

c) From the two at the center (attached to the same vector-subtract node): (1,0,0)(0,1,0)(-1,0,0)(0,-1,0) <-- NOT working as I expected

The outputs of the center viewer-nodes differ depending on whether the geometry of the inner or outer circle is attached to them (see screenshot #2). This leads to also different length calculations, while all 4 vectors should be of length 1 in my opinion. Where is my fallacy of thinking, and how can I actually calculate the distance-vectors between corresponding points on the inner and outer circle for later scaling of cones positioned between them?

For completnes here screenshot #3 with my entire Blender screen: • Hi :). I'm sure our GN afficionado @Chris will help once he gets here :)). You can also hit him up in the chat. Good luck. May 11, 2022 at 6:04

Why different output for the same vector?

Because here you try to compare a certain position with the position of another mesh, which you don't have access to in this context. Therefore the second vector will always return $$0,0,0$$.

In other words, you are not using the right node here. Simply put, the node Capture Attribute stores information in a mesh. You can use this information in the same mesh/context. But you have no access to this data from another mesh. This is exactly what the Transfer Attribute node is for. It transfers information from one mesh to another.

So if you want to capture and compare the vectors of two different meshes, you would just have to use the node Transfer Attributes instead, then all the necessary information will be available to you and your vector calculation will work as you would expect it to. By the way, this is how I would solve your specific example: With this you actually have all the possibilities you need for your project. For example, if you scale the circles with the node Transform, you will also get the elliptical shape for the outer circle.  • Wow, perfect explanation and very nice "how I'd do it" example and annimation! Thank you very much! With a programming background of 42 years I'm still thinking too much in classical arrays and references to them when it comes do GN. But a noodle to a node in GN isn't necesarrily a reference to a previously calculated constant array. It's a reference to either a context-aware function or context-dependend multiple arrays, and, a bit counter-intuitiv, the context of nodes which have no geometry input themselves is provided backwards from the target to the source node. Guess I have it now! :) May 12, 2022 at 23:48
• @SvenW You're welcome! And yes, you got it right: With Geometry Nodes everything is context specific ;-) If your question could be answered, click on "Accept Answer" and consider an upvote. This way you show your gratitude and signal to others which answers are helpful. May 13, 2022 at 0:04
• I just did (first time), hope I pressed the right buttons. May 14, 2022 at 1:26