1
$\begingroup$

enter image description here

These 36-segment concentric rings are formed from node-generated, circular edge loops. The planes between them aren't — I've bridged the edge loops myself — but the edge loops are procedural. Below are the geometry nodes which have generated them:

enter image description here

  1. The upper left three blue nodes take each ring's index number and raise it to the power of ${\sqrt 2}$, then plug the result into the "instance on points" node's "scale" socket, thereby making each bottommost, outermost ring ${\sqrt 2}$ times wider than the previous one above.
  2. The three red nodes provide each edge loop's index number, the number of rings desired ("integer"), and the spacing between each ring ("value").
  3. The big block of nodes below/to the right of the red nodes builds a vertical mesh line whose number of vertices equals the number of rings desired. Rings are later built around these vertices.
  4. "Instance on points" installs the first set of edge loops — in the image, these are the second outermost ones in each ring. The instance being used is the original geometry, an empty, circular edge loop. These edge loops act as templates for (5).
  5. The big block of nodes above "instance on points" — the line which starts with "subtract" and ends with "realize instances" — copies the edge loops produced in (4) a certain amount of times, then displaces them downwards. Said amount is -0.1 multiplied by the template edge loop's index number, meaning that higher, smaller rings are copied more and shunted downwards more. All edge loops created up until now serve as the inner boundaries of the rings.
  6. The two nodes below (5) and to the right of (4) interpret all the edge loops up until this point as a single instance, duplicate them all, then expand them by a factor of 1.1 in the X and Y directions. These edge loops form the outer boundaries of the rings.
  7. The products of both (4)/(5) and (6) are merged and the geometry is output.

This model is intended to represent a building which is essentially a stack of increasingly-smaller circular sections. The rings represent the footprints of its walls. The innermost rings must be thicker to represent that the innermost walls bear more weight, but, as you can see, they aren't — as a matter of fact, the rings get thicker the greater their radius, not the other way around. I would like it to be the other way around.

My best guess is that doing this would involve the nodes in step 6 somehow changing the amount each edge loop is scaled by based on the radius of the edge loop. I have no idea how to actually do this. I believe the closest I've gotten was when I tried something similar to step 1, where I first converted the duplicate instances from step 6 to curves, then took their radii, then plugged them in where step 1 uses the index number instead, but nothing happened.

I've looked at these questions but they haven't done much for me.

I believe the problem here is that the only way to determine how large an edge loop is in comparison to the ones around it (ergo, how much it must be scaled in or out for the ring it's part of to be thicker or thinner) is to take its radius, and I have no idea how to do that. Anyone trying to answer this might want to start from there.

This should link to the file:

$\endgroup$
7
  • 1
    $\begingroup$ Hi Key_abrade, i would recommend providing a blend file, because this attracts more people to help you, so a) we can test our solution proposal and b) we don't have to rebuild everything on our own $\endgroup$
    – Chris
    Feb 18 at 8:28
  • $\begingroup$ @Chris Done. Let me know if the computer gremlins stop the BlendExchange link from working for you. $\endgroup$
    – KEY_ABRADE
    Feb 18 at 9:05
  • 1
    $\begingroup$ You describe very well what your current node tree is doing. But I'm unable to understand what the issue is and which result you expect... : ( $\endgroup$
    – lemon
    Feb 18 at 9:19
  • 1
    $\begingroup$ @lemon The issue is that the inner rings are thinner than the outer rings when I want the inner rings to be thicker than the outer rings. $\endgroup$
    – KEY_ABRADE
    Feb 18 at 9:40
  • 1
    $\begingroup$ it is because you're scaling the duplicate elements. You should scale with some factor with inverse of their radii. $\endgroup$
    – lemon
    Feb 18 at 9:58

1 Answer 1

2
$\begingroup$

(Using Blender 3.6.8)

Wall thickness function of ring index

Using Named Attribute, the original index of each concentric ring can be transferred by Duplicate Elements nodes, to be used as argument of a function scaling duplicated rings:

GN Graph

Resources:

Wall thickness function of ring radius

The rings radius is computed from the original circle bounding box, multiplied by the scaling factor function of the rings index. For the demo, a constant wall thickness is modelled.

GN graph based on radius

Resources:

$\endgroup$
6
  • 1
    $\begingroup$ The question is addressing the issue of determining the radius of rings. As radii are function of the scaling factor computed by the three top left blue nodes, and that these factors are function of the rings index, this proposal stored the index as primary parameter. If the radius is required nonetheless, it can be computed from the bounding box of the input geometry and the scaling factor, and stored as named attribute instead. $\endgroup$ Feb 18 at 14:17
  • $\begingroup$ Well, I do need the scale to base off the radius, not the index number — otherwise the outer part of each ring will scale based on how far down the ring is in the stack, not how far towards the middle it is. What geometry would be input into the bounding box for this, and is the scale factor those blue nodes in the green-highlighted area? $\endgroup$
    – KEY_ABRADE
    Feb 19 at 0:15
  • $\begingroup$ I now recognize Bounding Box must come after Duplicate Elements (i.e. taking the bounding boxes of the duplicated instances) and that there'll be Separate and Combine XYZ nodes between Bounding Box and Scale Instances so the X or Y value can be separated from the overall position vectors of the bounding boxes. However, when applied to any instances in the model, Bounding Box's Min and Max outputs are always position vectors whose X/Y components are 0, despite the mesh clearly being larger than 0 in those dimensions. This means it only scales the instances to 0 in those dimensions. $\endgroup$
    – KEY_ABRADE
    Feb 19 at 4:56
  • 1
    $\begingroup$ About "otherwise the outer part of each ring will scale based on how far down the ring is in the stack, not how far towards the middle it is": the Spreadsheet editor shows that the duplicated index is actually indicating "how far towards the middle" a ring is. There are 3 rings numbered "0" with Z going from 0 to -0.2, 2 rings numbered "1" with Z going from -0.1 to -0.2, 1 ring numbered "2" with Z equal to -0.2. $\endgroup$ Feb 19 at 6:12
  • 1
    $\begingroup$ About "is the scale factor those blue nodes in the green-highlighted area": no, it is a reference to the original graph (described as step (1) in the question). $\endgroup$ Feb 19 at 6:16

You must log in to answer this question.

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