Page MenuHome

Mapping node not working correctly
Closed, ArchivedPublic

Description

System Information
Operating system: Ubuntu 18.04
Graphics card: Nvidia Geforce GTX 1050

Blender Version
Broken: it's broken, under Cycles and later Eevee, since 2.79b to 3.22.
Worked: never, as far as I know.

Short description of error
An Image mapped on a UVsphere or on a Roundcube as "Generated - Sphere", is correctly mapped; it should be accordingly rotated, let's say, on the Z axis, instead it gets distorted, no matter if you try by tweaking the Rotation or the Location values.
Note that under Blender Internal in 2.79b, it works correctly, by tweaking the Offset values.

Exact steps for others to reproduce the error
Open in last versions the attached blend file and try to translate on the X or Y axis or to rotate on the Z axis the mapped image. Then try the same in Blender Internal.


Event Timeline

Well, you are comparing two different things.
One is the position of the texture, the other is the transformation of the generated coordinates to be used in a spherical projection of the texture (remembering that the center of the rotation is 0,0,0. In the case of the generated coordinates, this center is not exactly in the middle of the sphere).

For help using Blender, please try one of the community websites: https://www.blender.org/community/

Closing as this bug tracker is only for bugs and errors.

Community websites, are you kidding me? I think you didn't get the issue: in Blender Internal it was possible to map an image texture as Generated - Sphere and rotating it on the mapped object, in Cycles and Eevee, that is with the Mapping node, is no more possible because all you get are deformations.

In the example, for the rotation "pivot" to be in the middle of the sphere, you can add a temporary offset:

Nice, I stand corrected then; thanks a lot for the image, it clarifies a lot (honestly, the doc aren't that clear for average users).

Btw, forgive me but I still think that temporary translating the origin cannot be the right behaviour... this way, the scaling doesn't work anymore, it assumes a single value of 1.000.