Page MenuHome

Wrong rotation input values when using shortcuts on keyboard like rx720
Closed, ResolvedPublic


System Information
Operating system: Windows 10
Graphics card: GTX 1080 Ti

Blender Version
Broken: 2.80 Release Candidate 1

Short description of error
Rotation values inputted after hitting "r" and then hitting an axis value like "x" are wrong.

If I select an Object and hit "r" then "x" then "720" then "return", the X-rotation will be set to 0.00002d
Or if i enter rx359 the x-rotation will be set to -1.

If I input them in the n-panel it works fine, if I input them in the properties panel it works fine, too. And if I use the widget to rotate the cube two times in that axis and let go it's also 720 degrees. The wrong values appear just when inputting them the way described above.
I think this should be consistent all over the place and it really makes no sense that it rotates my cube -1 on the x-axis when i clearly wanted it to rotate 359 degrees in the other direction on that axis...

Exact steps for others to reproduce the error
Select an Object and hit "r" then "x" then "720" then "return", the X-rotatioin will be set to 0.00002d
Or enter rx359 the x-rotation will be set to -1.

Event Timeline

Brecht Van Lommel (brecht) claimed this task.

This would be good to improve but it's not considered a bug currently.

The rotation value entered here goes through various transforms and representations which can't preserve the difference between 0 and 360. We could add a special code path for the simple case where the entered value equals the Euler value on the object, but that's outside the scope of this tracker.

Bastien Montagne (mont29) reopened this task as Open.
Bastien Montagne (mont29) claimed this task.

Hmmm… this is actually a sequel of T48998, looks like I fixed clamping of the drawn value then, but not the actual application of said value.

Applying rotation goes through matrix, which simply does not support rotation outside of the ]-180, 180] range. Thing is, with other transform tools, value gets applied often, so steps between applications are always below 360°. With num input, it gets applied in a single step, where the clamping gets visible.

Trying to find a fix currently (which is proving to be much, much more difficult than anticipated :( ), but would not recommend adding it to 2.80 release in any case, this can have unexpected side effects, and reported behavior have been there since the dark ages of Blender…

eeeh… was triaged in-between…

@Brecht Van Lommel (brecht) imho this is really a bug, and a rather annoying one, though nothing like a regression… This has to be fixed somehow, that’s a nasty usability flow making numinput essentially useless for rotations currently.