Page MenuHome

cycles mapping node rotation order
Closed, ResolvedPublic

Description

System Information
Operating system and graphics card

Blender Version
Broken: 2.73.2

Short description of error
cycles mapping node rotation order is reversed for viewport and for render

Exact steps for others to reproduce the error
opend attached blend{F135089}

Event Timeline

Czarek Kopias (kopias) raised the priority of this task from to Needs Triage by Developer.
Czarek Kopias (kopias) updated the task description. (Show Details)
Czarek Kopias (kopias) set Type to Bug.

Win7x64 GTX660M 337.88

This is pretty horrible one actually. it's caused by the wrong logic in Cycles itself: https://developer.blender.org/diffusion/B/browse/master/intern/cycles/util/util_transform.h;89b654dc56b38a332e5bc4f82109152e21f0a5b6$219

Will look into some ways to make it proper behavior without introducing regressions for existing files here.

Sergey Sharybin (sergey) lowered the priority of this task from Needs Triage by Developer to Normal.Jan 5 2015, 2:24 PM

Question: in most situations (objects, bones) where the rotation order is ambiguous, there's usually an option to let the user set the rotation mode. Would that have not worked here?

From my (non-developer) perspective, it seems like the cleanest solution might be to provide a drop-down menu on the mapping node, with all of the six permutations of XYZ-Euler available (maybe not quaternions and axis-angle if changing the number of inputs would be a problem.) Then the user could know (and define!) exactly how the mapping node is going to behave without having to, say, guess how adding a new mapping node to an old-version file will work.

I mean, the mapping node already has four modes depending on what type of vector is being used as an input. I don't think adding a "rotation mode" option would make things too much more complex on the user's side.

Rotation order is not ambiguous, it is expected to be XYZ-euler by BI and viewport. Just by accident Cycles used flipped order. It is possible to support different orders, but it ends up in totally hairy code because of specifics how this mapping works internally for glsl. Just sticking to XYZ-euler is easier for everyone.