2
$\begingroup$

I have an image that I want to pixelate down to a certain resolution. The uv mapping magic for this is done within a node group:

Inside node group

Then outside of the node group I want to be able to select the image (I am also making it monochrome using a less than math node, but I don't think that is relevant here). I tried to do this by exposing a pixelated (snapped) uv map (vector) output outside of the group, and then putting the output image back into the node group:

Outside node group

But as you can see in the image: the noodle turned red, indicating there is something wrong with this setup. As far as I can see they are both vector data types, but the noodles seem to disagree?

So my question, what is going wrong here? And aditionally, is there any way to get some debug info about why a noodle is red from blender?

$\endgroup$

1 Answer 1

3
$\begingroup$

The cause here is a circular reference. The node setup is evaluated from the right:

  1. Material Output - in order to evaluate the shader for the output, the connected nodes have to be evaluated - here just one, the NodeGroup connected to Surface input.
  2. NodeGroup has to be evaluated. But this node requires a few inputs, one of which is Color1 - which is connected to Less Than node.
  3. Math > Less Than has to be evaluated but it has an input connected to an Image Texture node, which has to be evaluated...
  4. Image Texture node evaluates color for currently evaluated point, but it needs to get the position - its Vector input. So the node connected to that input needs to be evaluated - the NodeGroup.
  5. NodeGroup again - go to p. 2.

So it's an infinite loop...

As for your actual goal, you can achieve it like this:

You can see the pixels move a little, because flooring is biased, so here I'm recreating the snap that effectively rounds instead of flooring:

It seems the OP's problem is that the node layout inside the NodeGroup (which we don't see fully) would work if it wasn't grouped - however the node validator treats a node group as a single entity (and it seems reasonable to not think of it as a bug) - I reproduced the problem with a simple setup:

The solution then is to use the same node group multiple times:

So for the specific setup posed by the OP:

$\endgroup$
5
  • $\begingroup$ That makes sense, I didn't know the nodegroup was evaluated as one monolythic thing, instead of the separate nodes inside of it. I know how to achieve the effect I want. But the thing I was trying to do was to have the effect be a node group, where you could select the image outside of the node group. While keeping the vector math inside of the node group. I guess this just isn't possible. $\endgroup$
    – TT-392
    Commented Jun 6, 2022 at 12:55
  • 1
    $\begingroup$ @TT-392 you mean that if you ungroup the custom group then it works? Interesting case... See edit. $\endgroup$ Commented Jun 6, 2022 at 13:31
  • $\begingroup$ Yep, it wasn't grouped before, that worked. I guess using the same group twice is a solution, though a bit hacky. $\endgroup$
    – TT-392
    Commented Jun 6, 2022 at 13:57
  • $\begingroup$ @TT-392 wouldn't making a node group reference self be even more hacky? :) $\endgroup$ Commented Jun 6, 2022 at 14:08
  • $\begingroup$ Like, the ideal option would be to have texture as an input data type, like, just the image, with no coordinates, but I guess that is not a thing for shader node groups. $\endgroup$
    – TT-392
    Commented Jun 6, 2022 at 17:30

You must log in to answer this question.

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