Cycles: difference in texture position between OpenGL and Cycles render (CPU and OpenCL)
Closed, ResolvedPublic


System Information
all vendors

Blender Version
Broken: 2bb7a13

Short description of error
Texture position is different in viewport material viewmode and rendered viewport

Exact steps for others to reproduce the error
Open attached blend

, hit shift+Z in viewport to start border rendering. You get a visible position difference:

Can also confirm. I encountered the same bug today. After double checking, the OGL size and/or position is wrong, the cycles size and/or position is right.

it's the math divide node that trigger the bug:


If i re-type that 0.008 then the issue goes away. How did you put value to the node?

Here is a simpler file.

Increase the rotation Z value with shift click and you will see it only updates after a view click. In render mode it updated right away.
This is a precision issue.
The object is far from the rotation origin and the value on which you apply the rotation is very high / low.
I guess OGL has less float precision when dealling with this. It seems that all transformation are baked into a single matrix on the GLSL end. I do not know about cycles.

Mapping node is converted to mat4 on CPU side for both GLSL and Cycles. Shading system will perform point*matrix multiplication when evaluating shader.

There might be some precision loss there because we use different code on Blender and Cycles side to construct matrix (aka, we don't access matrix from Cycles via API but recontruct it).


If i re-type that 0.008 then the issue goes away. How did you put value to the node?

Same here, retyping the value removes the bug :D I copy pasted it from the original attached file I think.

@Clément Foucault (fclem) Not sure, but if it was a precision issue, retyping it wouldn't solve the bug?

Ok, another precision. Python doesn't suffer from this problem. So replacing the divide node at 0.0084667 with a multiply node at 1/0.0084667 workaround the bug. But it's really cumbersome. This view is at 39 unit from origin. I wouldn't call that far away, so precision shouldn't be an issue. Maybe constant folding could do this job and change the divide node to a multiply node? Or just rearrange computation to maximize precision?