0
$\begingroup$

Don't know a ton about geo nodes so this may end up being a dumb question but here goes:

I've got a situation here where a geo node node tree I've assembled, when used in a modifier stack, will only work if it is the only instance of the node tree used in the stack or it is the last instance of the node tree used in the stack.

In this geo node node tree, I do not convert the input geometry to an instance at all nor do I convert it back into geometry again for obvious reasons. Additionally, I do not create or destroy any geometry, just move some vertices around. To me, this stands to reason that the output geometry would be 100% acknowledged by later instances of the node tree in the modifier stack in which this example instance of the tree is used, but that is not the case. Instead, what happens is that the effects of any use of the node tree before the last instance of the node tree are forgotten about by that last instance and the last instance operates as if the earlier ones never existed.

I tried Googling all this for about 20 minutes with some careful quotation mark work, but all I'm finding is questions on the opposite issue of people actually DESIRING this behaviour when in fact I want anything but this behaviour right now! Additionally, below is a screenshot of the node tree itself. I doubt it is a good tree for many reasons beyond my understanding, but I don't see at the least why it wouldn't work assuming all input fields are populated:

The erroneous node tree in question.

Any help guys? TYVM for reading : )

$\endgroup$
10
  • 1
    $\begingroup$ Hi Spring, it would be nice if you provide a node tree which isn't blurry but easily readable. Second i would recommend providing a blend file so we don't have to manually rebuild it. thx. $\endgroup$
    – Chris
    Feb 11 at 9:48
  • 1
    $\begingroup$ @Chris is your eyesight OK? :D I don't think the image is blurry. Yes, could be of higher res and I always try to screenshot at a much higher res so the image can be easily zoomed, the text is nice and thick and antialiased if zoomed out etc. but "blurry" is not the word I'd use here. $\endgroup$ Feb 11 at 9:52
  • 1
    $\begingroup$ Spring, the simplest thing to do here is to disconnect the field from Set Position: Offset and just set some value here. Does adding more geonodes modifiers in the stack with this node tree accumulate the offset now? I bet it does. Therefore the problem is not where you describe it, but it lies in the calculation of the offset. Mathematically speaking, for numbers $a$ and $b$, you can find such $b$ and operator $◦$ that $a ◦ b = b$, that is, if you set $b$ to the result of $a ◦ b$, it won't change, and therefore the value of the expression won't change when you update $b$ to its result... $\endgroup$ Feb 11 at 9:57
  • 2
    $\begingroup$ @Chris OK, if you zoom in the image, it is blurry due to the scaling algorithm, I guess that's what you did, I should have figured it immediately but it's Sunday morning OK?? :) $\endgroup$ Feb 11 at 9:59
  • 1
    $\begingroup$ @MarkusvonBroady: go back to bed... :D $\endgroup$
    – Chris
    Feb 11 at 10:23

1 Answer 1

1
$\begingroup$

Your "Compare" node evaluates to $1$:

It does so because it's connected to two "Domain size" nodes, comparing its own number of vertices to the target object. Since they match at the beginning, and there's no node that would change the number of verts, it will always be $1$, and so it can be replaced with the "Value" node, and the dead ends (Domain sizes) removed.

The scalar value $1$ converts to a vector by triplicating as $<1, 1, 1>$, and passing that as a 2nd input to the Vector Math: Multiply effectively makes it a no-op, so it can be removed (⎇ Alt-dragged):

The "Factor" input of the geonodes modifier is set to to $1.0$. I changed it and then discovered the mentioned behavior of stacked modifiers acting as a single modifier (every next modifier changing nothing) disappeared. Therefore I'll assume it is set to 1. Like with the Vector Math: Multiply, here passing the $1$ as a scale of Vector Math: Scale also makes it a no-op. So this too can be removed. We're left with:

Set Position, for each point, evaluates the vector field connected to "Offset". It reads the position of the vertex with same index from the target geometry. Then it subtracts the position of currently evaluated vertex. This becomes the offset. Let me present this in 1D:

$a$ is the currently evaluated object, $b$ is the target object. $b-a$ is what you do, and you get the offset from $a$ to $b$. If you now apply this offset on $a$, it moves to $b$. Now $a = b$

On 2nd iteration, since $a = b$, the offset is 0. So No movement happens. And since no movement happens, the situation doesn't change on the 3rd iteration and so on.

$\endgroup$
3
  • $\begingroup$ Thanks for the thorough answer! So all the stuff you removed is neccessary to my specific needs. For example, I only want to geometry node to do anything if the target object has the same number of vertices as the evaluated object. Also, the target object of the 2nd geometry node modifier is different to that of the 1st geometry node modifier. How is it possible that the offset is zero on the 2nd geometry node modifier when that modifier has a different target with different geometry? I'd be more elaborate (and polite), but I'm running out of characters! $\endgroup$ Feb 11 at 20:43
  • 1
    $\begingroup$ @SpringE.Thing maybe ask a different question: what you actually want to do. It's hard to answer your question as currently posed: "Node Tree Ignores Its Own Output If Repeated?" - The answer is "No. It doesn't". $\endgroup$ Feb 11 at 21:49
  • $\begingroup$ Fair enough, the quesiton has evolved beyond what it used to be. I'll leave this as-is and start a new one sometime soon. TY all the same! $\endgroup$ Feb 11 at 22:34

You must log in to answer this question.

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