Hey guys, I used this workflow a lot in 2.79, where I would use the varieties of key combos for G and an axis to lock out axis, swap between global and local space, etc. They all seem to have been carried over into 2.8, except the double axis hotkey to swap to local space mode. Is this an oversight, or have you changed the hotkey combination for this? Would love to see it back in the builds. Thanks!
2 Likes
Now when you press the double axis it goes to whatever Transform Orientation you currently have selected, which is by default global.
So you must change to local transform orientation from the header and then it will use the local axis.
Hm. could you explain some of the motivation behind that? That seems like a bit of a step backwards. in 90% of cases you’re going to be using Global or Local, so for speed of workflow isn’t it better to keep the swap that way? You will use more specific transform orientations in some cases, but since they’re rare enough the slowdown to use a dropdown makes sense. I did see for single face extrusion at least, alt+s performs basically what I want, but if you have multiple faces that have the same extrusion direction, it’s going to spread, so I’d have to use the dropdown.
3 Likes
I’m not one to whine about 2.7->2.8 changes, but this one in particular really stung when it was added. It turned an action that used to be intuitive and straightforward into a dance of drop-down menus. Really wish we could get it back as an option, or at the very least an inactive modifier to the transform modal operator that people like me could map a hotkey to.
1 Like
The only difference that I can tell is that it defaults to the currently selected orientation first. So, if you’re in local orientation you press G+Z and you’re moving in the local axis. Press G+Z+Z and you’re in global axis.
If you’re in global orientation and press G+Z+Z you move in local whereas a single press moves in global orientation.
It’s not that bad once you get used too it, it doesn’t have the fast muscle memory as before, but you shouldn’t have to use the dropdown.
1 Like
That is technically true, but for my type of work I feel like I’m in a no-win situation. I need the global axis probably 80% of the time, and normal axis 20% of the time. That’s just enough that if I leave the axis at global so that normal transforms aren’t irritating double-taps I have to constantly go back and change the axis to “Normal” from the dropdown. If I just leave the axis at “Normal”, 80% of all my transforms have to be double-taps. It’s SUPER annoying, especially when the old workflow was extremely intuitive… double-tap for those infrequent times I needed to move on the normal axis.
Conversely, I have never (not even a single time) found a use for the local axis while working in edit mode. Most of the models I work on (while in edit mode) have no local transformation, so the default in 2.8 is completely useless to me.
This is why we have a pie menu (comma key by default) to set the orientation to whatever you like.
Previously, users would set the orientation to something, but constraining transforms would ignore it and always go to Global. If you were working at an angle or custom orientation, this was a major issue.
If you want to constrain to the global orientation, set the Orientation to Global.
1 Like
I see the issue now. I usually use local and global, which doesn’t cause issues. Usually the only thing I do on the normal axes is move along the z of the normal, so I use alt+s. It might be good if the devs decoupled the edit mode and object mode orientation setting.
I totally understand and accept why the change was made, and I’m all for change if it benefits the greater good. I can empathize with someone who worked in object mode almost exclusively (on an animated feature like Spring, for example). In that use-case, having it default to Normal is completely pointless, but for people who live in edit mode making models it’s the opposite. It’s a bit like robbing peter to pay paul or whatever that expression is- we just shifted the burden to a different set of users rather than solving the problem for everyone.
That would be a godsend, actually- if edit mode defaulted to Normal on double-tap and object mode used Local.
I don’t get the issue. In any mode you can set the orientation to whatever you like, so you don’t have to double-tap anything.
For modeling it’s advantageous to be able to easily constrain movement to axes other than global, which is now way easier. But if you prefer to keep the orientation set to Global you can still do that.
You are correct, setting the mode is something anyone can do. I’m not saying it’s not- my point is that in 2.79 it was a fluid workflow that was incorporated into the modal transform keymap, and now it requires either a drop down or a pie menu to access. For people who are constantly going back and forth between global and normal (ie: 3d modelers who work in edit mode primarily) this back and forth is extremely tedious. I’m not sure how to explain what the issue is if you don’t do this type of work. I’m not saying that it’s not possible to do it, I’m saying it used to be effortless and now it’s irritating.
Consider the following example:
In my work, I pretty much only ever use Global or Normal (or custom) axes. I could be using the global axis one minute, and need to momentarily switch to Normal. In 2.79 this was as simple as starting a transform, and then pressing ZZ. moving along the face normal instantly!
In 2.8 I have to go to the drop down (or use the pie menu, it’s all the same to me- equally slow) and select “Normal”, then start a transform, then go back and change it to “Global” again. The only OTHER alternative we’re left with is to just leave it on “Normal”, but now all transformations will default to Normal (as expected) and you have to press the axis key twice to move in Global space. Every. Time.
As I mentioned in an earlier post, I use Global about 80% of the time, so you can (hopefully) see where this would be extremely tedious. The worst part is that “Local” is basically useless for a modeler while in edit mode- nobody does any modeling with a transformed mesh, it’s 3d modeling 101. This means that “Local” will almost always do nothing at all for a 3D modeler working in edit mode. And yeah, I could set a hotkey to change to Normal and then back to Global. I can work around it, it’s not the end of the world- it’s just annoying because it used to be in the transform modal map- so the hotkey wasn’t squatting on prime real-estate. Now I have to dedicate a button on my keyboard to this one thing that used to not require it at all.
Also- I’m not trying to whine and say “change it back” or anything like that. In fact, I’m only commenting on the issue because someone else made a thread and it provided me a convenient place to dump a gripe that I’ve been carrying around. I’m just trying to say that there’s a large group of users who were using that feature quite effectively and it got snatched out from under them when there was probably a better solution that was never really discussed anywhere besides a thread in diffusion between a handful of devs. We solved a problem for one group of users by gimping a different group of users.
2 Likes
Solution would be to add transform hotkeys to switch to any orientation while transforming.
Yep, that’s basically what I’m advocating for- an additional property in the transform modal keymap that we can assign to a hotkey and change orientation
Is there any way to get this swapped back or included as a legacy setting? This new way is really strange. I’ve gotten used to the switch, but I find that I must double tap for the bulk of my transform operations, rather than the odd, but useful, exception.
The slowdown is marginal, but I can’t understand why something that was so fluid and useful got swapped around to the point where it’s probably slower than using the dropdown menu over the long term. It feels like quite an unusual betrayal of Blender’s workflow oriented design principles.
Alternatively, if anyone can point me to the source files or ticket where this change was made, I’m to the point where I’m willing to compile my own build to have this feature back.
Thanks