cycles mapping node rotation order #43120

New Issue

Cezary Kopias · 2015-01-04T13:42:05+01:00

Cezary Kopias commented

2015-01-04 13:42:05 +01:00

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}

**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](https://archive.blender.org/developer/F135089/xyz-custom-uv-rotate.blend)}

Cezary Kopias commented

2015-01-04 13:42:05 +01:00

Changed status to: 'Open'

Antonis Ryakiotakis was assigned by Cezary Kopias

2015-01-04 13:42:05 +01:00

Cezary Kopias commented

2015-01-04 13:42:05 +01:00

Added subscriber: @kopias

Cezary Kopias commented

2015-01-04 13:45:32 +01:00

Win7x64 GTX660M 337.88

Antonis Ryakiotakis was unassigned by Sergey Sharybin

2015-01-05 14:24:38 +01:00

Sergey Sharybin self-assigned this 2015-01-05 14:24:38 +01:00

Sergey Sharybin commented

2015-01-05 14:24:38 +01:00

Added subscriber: @Psy-Fi

Sergey Sharybin commented

2015-01-05 14:24:38 +01:00

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.

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.

blender-admin commented

2015-01-22 10:12:22 +01:00

This issue was referenced by a1ffb49e49

This issue was referenced by a1ffb49e494deac6cf6d3bcca45c046d9acdfad1

Sergey Sharybin commented

2015-01-22 10:14:59 +01:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2015-01-22 10:14:59 +01:00

Sergey Sharybin commented

2015-01-22 10:14:59 +01:00

Closed by commit a1ffb49e49.

Closed by commit a1ffb49e49.

blender-admin commented

2015-01-28 09:00:12 +01:00

This issue was referenced by blender/cycles@69a14ff147

This issue was referenced by blender/cycles@69a14ff1477752df59c492eb752a1a53b5c3a241

Tom Benedett commented

2015-01-29 09:31:21 +01:00

Added subscriber: @moak

Tom Benedett commented

2015-01-29 09:31:21 +01:00

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.

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.

Sergey Sharybin commented

2015-01-29 11:41:53 +01:00

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.

Sign in to join this conversation.

4 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#43120

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

cycles mapping node rotation order #43120