2
$\begingroup$

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).

Screenshot 1 - Geometry nodes tree

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.

Screenshot 2 - Output of the 4 viewer-nodes with unexpected different values by the two center nodes c1) and c2)

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:

Screenshot 3 - Overview screen with geometry output

Thank's in advance!

Improve this question
$\endgroup$
1
  • $\begingroup$ 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. $\endgroup$
    – jachym michal
    May 11, 2022 at 6:04

1 Answer 1

Reset to default
1
$\begingroup$

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.

enter image description here

By the way, this is how I would solve your specific example:

enter image description here

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.

enter image description here

Improve this answer
$\endgroup$
3
  • $\begingroup$ 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! :) $\endgroup$
    – SvenW
    May 12, 2022 at 23:48
  • $\begingroup$ @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. $\endgroup$
    – quellenform ♦
    May 13, 2022 at 0:04
  • $\begingroup$ I just did (first time), hope I pressed the right buttons. $\endgroup$
    – SvenW
    May 14, 2022 at 1:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .