My material behaves differently in material preview than in rendered view

Question

I have a material which looks different in material preview than it does in rendered mode or in final cycles output. I'm using cycles for rendered mode. Blender 2.92.0.

You can see below that the horizontal parts of the fireplace brick are brick on the left hand side of the image (material preview) but is instead a flat gray on the right hand side (rendered mode). The gray color is the color of the "mortar" input in the brick texture node that I'm using.

In order to make the brick wrap around my object (the entire brick structure is a single mesh), I used some vector math and texture coordinate mapping stuff to make it all work. It seems to work fine everywhere except for horizontal surfaces, because some of the cross-products performed in the shaders nodes end up being degenerate. The face normal is parallel to the Z axis, so cross product is 0 on horizontal surfaces. So I have some special cases in my nodes to check for that and handle that special case. It seems to work fine in material preview. So why would the rendered preview and the final rendered product (both cycles renders) appear differently?

I've tried adjusting the brick height or translating the textures to see if it just happened to fall right near a "mortar line" and maybe that's why cycles is putting mortar there, but nothing I do seems to have any impact.

EDIT: So I tried looking at the same scene on my windows machine, and it renders fine there. So perhaps this is a driver bug? The screenshots are from my linux machine, running Kubuntu 20.10, with an nVidia GTX 1660 graphics card. Note that the 3D render view, however, is CPU computed (if I understand how blender works) and that final render is where the GPU is used.

I'm using the nvidia-driver-460 package, which is the standard package for my linux distribution.

Answer 1

So, many months later I solved this problem.

The issue is related to some vector math done in my procedural texture. The procedural nodes calculate a cross product with the Z axis to figure out which direction the surface normal is and uses that to rotate the 2D brick texture to align with the face. In the case of a normal which is parrallel with the Z axis, the cross product is zero. This led to some strange behavior because the cross product vector was used as a rotation axis for aligning the 2D brick texture to the face. I suppose the difference in behavior in Windows vs. Linux is due to how the different drivers handle the undefined behavior of rotating around a zero-size vector axis.

The solution is simple - I added some nodes to check if the cross product is zero, and in that case use either of the two vectors (Z-axis or normal) as the rotation axis instead of the cross product. The attached screenshot shows the correction as the 3 circled nodes. The dangling node wire is the "uncorrected" calculation. Attaching that node wire to the "normalize" node on the right causes the problem to reappear.