Maniphest T48998

"Rotate" disrespects rotation-direction and path
Closed, Resolved

Assigned To
None
Authored By
martin me (martinme)
Aug 1 2016, 9:41 PM
Tags
  • BF Blender
  • Modeling
Subscribers
Bastien Montagne (mont29)
martin me (martinme)
Sergey Sharybin (sergey)

Description

System Information
Win7 64bit
GTX 960

Blender Version
Broken: Blender 2.77.1
Worked: (optional)

Short description of error
I tried to create a sort of spiral by rotating an subdivided edge with "Proportional Editing" on. ( I got a blend file prepared and attached)
Rotating by hand/mouse works fine, but when I tried to type in the rotation angle per keyboard, e.g. 360° or 180°, it doesn't work so well.
Looks like the Rotation always tries to take the shortest way to it's end position. For 360° it seemingly doesn't move at all.
If I type in the rotation angle afterwards, in the tool options, in the lower left, it works fine again.
Only the keyboard input for the rotation angle seems to be buggy, somehow.

A similar problem exists when I try to rotate an object for animation, for example.
Then it's also not so easy to get it rotating in the right direction and for the wanted amount of degrees, sometimes, and the object also has the tendency to rotate the shortest way to it's "final location". But since here the path and direction of movement is what matters, this behaviour of shortening the path is somehow inadequate, I would say. To me, this seems to depend on the same rotatation-tool-weekness as the problem mentioned above.

Revisions and Commits

rB Blender

Event Timeline

martin me (martinme) created this task.Aug 1 2016, 9:41 PM
martin me (martinme) updated the task description.Aug 1 2016, 10:15 PM
Sergey Sharybin (sergey) lowered the priority of this task from 90 to 50.Aug 2 2016, 9:54 AM
Sergey Sharybin (sergey) added subscribers: Bastien Montagne (mont29), Sergey Sharybin (sergey).

@Bastien Montagne (mont29), any idea why header input will behave differently from toolshelf properties settings?

Bastien Montagne (mont29) added a comment.Aug 2 2016, 10:28 AM

Wellll… Rotation header input is clamped in (-180, 180) range on purpose it seems - cannot figure out why though… Seems to come from the Dark Ages (a.k.a. 2.4x area, see initial 2.5 commit).

Fixing this is as trivial as removing the clamping line, we can try that and see whether it breaks something else - unless someone remembers why it was added. ;)

Bastien Montagne (mont29) changed the task status from Unknown Status to Resolved by committing rBfb94f4b88424: Fix T48998: 'header input' of rotation transform was clamped in [-PI, PI[ range..Aug 2 2016, 12:44 PM
Bastien Montagne (mont29) added a commit: rBfb94f4b88424: Fix T48998: 'header input' of rotation transform was clamped in [-PI, PI[ range..