Page MenuHome

Transform Constraints: Respect transform orientation selection
AbandonedPublic

Authored by Benjamin Sauder (kioku) on Wed, Nov 21, 10:54 PM.

Details

Summary

The current behaviour of the transform constraint is that it always goes to global first, and on the second key-press goes to whatever the user selected in the transform orientation dropdown.

This patch basically inverts that behaviour, so it always chooses the transform orientation the user picked first, and on second hit it toggles back to global.

So it works like free -> local/normal/view/gimbal/cursor -> global -> free ...

The only edge case is global transform orientation itself,
here I set it up that it goes from free->global->local -> free...

While I had this on my mind for a while, a thread spawned on devtalk describing this issue as well:
https://devtalk.blender.org/t/transform-tools-in-freeform-mode-need-to-respect-transform-orientation/3351

As this changes the behaviour of a very basic command in blender, im curious how this will go...

Diff Detail

Repository
rB Blender

Event Timeline

We tried this already and found it had problems, see:

Do you have some suggestions how to handle this?

Campbell Barton (campbellbarton) requested changes to this revision.Wed, Nov 21, 11:17 PM
This revision now requires changes to proceed.Wed, Nov 21, 11:17 PM

@Campbell Barton (campbellbarton): Excuse me if I'm being dense, but I can't see the downside of this change. If someone really wants to always transform something on the global axis, they can just set the orientation to global then? What it the problem then?

It seems rather arbitrary to assume that users would always want to constrain to global, and it seems a lot more consistent and flexible to simply follow whatever the user has picked as their orientation.

ah, good to see you already tried that .. and good to see I toyed with the correct piece of code.

"After user feedback this has the downside of having no predictable
way of transforming in global space.
Since toggling between global/user is reversed when global is
the user axis."

Were there any other issues/side effects?

so the argument is , that the order is inconsistend in the case of the global space?
well thats true - and i cant really come up with a nice solution for that right now. One could argue that this mode switching is also quite arbitrary, and the space selection should come solely from the transform orientation selection. but I fear this will create some uproar...

But having this global over all other spaces decision really makes the other spaces unnecessary tedious to use in my opinion. professionally I do asset modeling for games for quite some time now - and global space shouldnt be chosen over the others - especially if we all make the 3d cursor even better :)

Thank you so much for taking care of this! :) If this was indeed based on my feedback on devtalk, could you please next time perhaps at least post the link to the task, so that I actually get to know it's being addressed? Otherwise I remain in the dark not knowing it's being acknowledged and worked on :)

Regarding reversal of the patch done previously. Was the feedback gathered from the sufficient amount of users? Or was it just one or two old timers who did not like to see things they are used to change?

Hi, any news on approving this? Beta is around the corner and it would be a shame if it was released without this.

Benjamin Sauder (kioku) requested review of this revision.EditedFri, Nov 23, 9:53 AM

@Campbell Barton (campbellbarton) @William Reynish (billreynish) hey I dont know how to go further with this, and what the intended way of handling things like this is on phabricator.

This seems now more of a design/UX issue than implementation - as we have an even nicer implementation from campbell too..

@Pablo Vazquez (pablovazquez) @Brecht Van Lommel (brecht) @Campbell Barton (campbellbarton) Can we reconsider this?

To me, it seems like this change makes sense. If the user has expressly chosen a given orientation, that is the orientation that should be used as the primary orientation when constraining to an axis. The user can still easily constrain to global by either setting the orientation to Global or by hitting the axis key a second time. To me this is the right thing to do, to prioritize what the user set before the hardcoded global constraining.

In 2.7x the old behaviour made a bit more sense, because the Orientation setting wasn't used a lot, but now in 2.8, the Orientation is respected a lot more, and is a lot more prominent. So I think now is a good time to change this aspect too.