Different behavior of Vector Math Modulo node in Shading vs Geometry Nodes environments

Question

I'm trying to move part of the math involving UV maps from Shading to GeoNodes. Something unexpected happens when I try to move the Vector Module operation.

The simple Shader I want to replicate is this:

As you can see, I create the UV map in GN and pass it to Shader via Attribute nodes.

The migration of the math nodes to GN works up to the Scale node:

The result is the same, as expected.

The problem arises when the Module nodes get activated.

According to Blender docs, both Modulo nodes should operate the same way, so I could actually expect same results, if the inputs provided are the same, which I couldn't be sure of, even though the results are the same up to the preceding nodes.

How can that be explained?

Is there a different logic in Shading and GN environments about Math nodes?

Does the UV map change in some way when passed via Attribute nodes?

Do I miss something to achieve the correct Modulo node (and possibly other Math nodes) migration (if possible)?

Answer 1

Your attribute names seem to be correct; Both reference the uppercase UV attribute, though a little bit hard to read.

The problem here is very much explainable: Working in the Shader Editor, the node graph is executed for every pixel that's drawn. In the Geometry Nodes Editor, the node graph is executed only for every vertex, with the resulting values later on being interpolated between the vertices.

So; Since you are working with a plane of only four vertices, the math nodes only get executed for four sets of UV-values: $UV_1=(0,0), UV_2=(1,0), UV_3=(0,1), UV_4=(1,1)$. Multiplying those values by $4$ and modulo-ing them results in those same exact values, e.g.: $(UV_4 \times 4) \% 1 = (1,1) \times 4 \% 1 = (4,4) \% 1 = (1,1)$. Thus, after the Geometry nodes were executed on the geometry and the results are linearly interpolated for every point inbetween, nothing changed.

The same math in the shader nodes however leads to the expected results, since we aren't only calculating four points and interpolating between them, but taking every possible floating point $p = ([0..1], [0..1])$ and explicitly calculating the nodes for those. This is something we can only really do in the shader node, since the shader nodes are explicitly designed to do calculations for many pixels seperately, where the geometry nodes only work on a per-vertex level.

You may get similar results in the geometry nodes editor by radically subdividing your plane, but that would increase poly count, calculation time, and make your model unworkable, along with still having interpolation problems, so there's sadly not much of a solution here. For some things, fragment shaders really are better suited.