Besides C4D and Blender I used two other major programs for at least one year (most +3years at some point) as my main programs in daily use. I asked the question on other program forums as well yet to me it simply seems that this …
a) … never even crossed the minds of most people working with the program
b) … never crossed the minds of the devs either and they can’t see this being useful, unexplicably.
Mostly only people coming from C4D eever immediately agreed with me. XD
The only way I can explain it for myself is that you get so used to your daily workflow in (Program X) that you just accept every quirk and workaround as at least okay because you know your way around it. I can safely say from asking for this on more than one forum (where the devs also read) - it’s not just a Blender thing. It seems like it simply is one of those unexplicably overlooked simple yet crazy powerful features nobody notices for some reason.
What’s weird to me is that unlike other feature requests this seems to be also rather unintrusive - it doesn’t change anyones workflow who doesn’t need it. And also seems like rather low hangig fruit in terms of complexity.
It really only has to have two settings:
Global scale (the scale in raw scene values), Relative Scale (the scale relative to the object’s main scale)
Bonus for adjusting and showing the boundingbox rotation of the current selection based upon the gizmo setting for local or global transform. With that it would even already surpass C4D and be a Blender thing. The most important thing about practical usage is just: The transform values have to update and be editable in realtime like for any other transform Vector3 field.
A “user” term represents “a person who is got used for something”. A piano user is a person who is got used to playing piano, a guitar user is a user who is got used to guitar.
If there is absence of a some kind a functionality in some software, its user’s skills naturally grows to avoid that.
For example, Blender never had a basepoint snapping, so entire movies was made without it.
Any software that exists is a collection of a solutions and decisions which was made by some people at the time, some of them are successfull, some of them has critical flaws. For example, industry standards is something like Windows XP for hackers - a very well known platform which is easy to hack and outperform. This is why workflow designers, who analyse software for a wide range of a workflows, exists.
At the moment there are no wide range workflow designers to consult developers in Blender crew, and devs are consulted mostly by specialists who performs a limited workflows, like animators.
@mano-wii is it possible to add numeric input in the direction of a basepoint snapping?
For example, you start grab, set basepoint source, hover over target, then type “3 enter”, and it translates the selection at 3 meters in the direction defined by source-target vector? (In case if no other axis restriction added during operation)
Same thing could be possible for rotation for example - a source-target vector could represent a custom axis of a rotation.
Hi.
Thank you for updates)
I think that numeric input support in the direction of a diagonal which is set by basepoint snapping would be actually useful to have, especially for duplicating actions - at the moment there is no ability to edit the resulting distance in that direction, it is possible to edit only ortho (axis aligned) distances.
Maybe I missed, are there plans to make asset browser’s bounding-box snapping a general tool? The dev blog at that time said that there are, but I can’t find any task from the list or on the project site.
Navigation during transform is such a huge efficiency breaker. Being able to constraint movement just by quickly pressing G and middle mouse button was such a great feature in Blender. Please give us some option to preserve this because it was one of the best features of Blender when modeling or readjusting objects quickly.
As a user who is coming from Maya and Max, being able to do this so fast in Blender was a huge plus. I rarely needed to adjust the camera or rotate viewport while doing these operations, so setting viewport rotation to be priority slows down this workflow dramatically.
Previously, pressing G and quickly pressing MMB was super fast. Now, press G, find ALT key and them MMB, 4-5 times slower to do that operation.
I’m not a big fan of this change either. Fortunately, it is possible to disable it in the keymap editor/transform modal map. you just have to edit the shortcut and remove alt for the automatic constraints.
That is shame. Sadly a lot of workflows in Blender rely on combinations that clash with navigation keymaps, like using middle mouse button for axis constraints, scrolling for influence control (proportional edit, brush size etc). With a well designed keymap this should never have happened, but sadly navigation during transforms wasn’t supported initially, so now we have to fight years of habit.
Fortunately only the default is gone, the option to manually toggle it on remains so we can always change, which I certainly will.
Yea, the axis constraint is kind of a dealbreaker for me too. Although I use gizmos more and more… but then if you’re using gizmos you’re not using basepoint snapping ! so yes, some work on the keymap is necessary to make it all work together.
I really do hope navigation will be supported during transforms in 4.0. Even with a 3d mouse it was impossible, despite there being no keymap conflicts there.
I agree that user should be able to navigate during transform operation, and yes you can make everything standardized across the application when it comes to shortcuts, but the real question is what the most efficient and faster way of working with Blender and if you are willing to sacrifice that for consistency.
Personally, I started using Blender 3 years ago, I am coming from 14 years of Max and 20+ years of Maya and in those applications things tend to be more consistent. But, when I started using Blender its way of doing stuff, that is not “industry standardized” really opened my eyes of how things can be done in a different and much faster way. These days I barely use Transform gizmo in Blender, like in Max or Maya, I do all the transforms with G R S keys and this works amazing in Blender. Hundreds of times per day also, when I do transforms I lock it to certain axes, and this was so fast by quickly clicking G key and MMB + mouse move to lock to certain axes. It was one of the things that was so good and fast in Blender that no other 3D app could do it in this way. That, amongst other things, was what made me switch to Blender for a lot of modeling tasks I do on daily basis.
I think it is fine for 3D software to be inconsistent regarding shortcuts. I think it is perfectly fine to do thing different than other apps. As long as this makes user workflow more efficient, breaking the rules is good. I do 100 G+MMB axis lock moves per day, I barely do viewport adjustments during that operation because I already adjust viewport to accommodate my transformation. Yes, sometimes you do need to transform 3D view, but in my case that is very rare. So, sacrificing speed for consistency IMHO is a deal breaker and if these changes are coming then we should always give users ability to switch back to the old workflows.
I am actually very glad that other people complained, and they reverted this change.
I found using axis restriction by MMB rather limited than useful, especially with 3d cursor as a pivot.
Direct key-driven axis restriction provides a better viewplane-independent control which also includes flexible switching between global and local axis transforms (GX and GXX)
However, having navigation during transform as an option seems to be a safe step.
It is a bit more restrictive than pressing GX or GXX, but it is way faster and way more intuitive. When doing constrained movement with a G+XYZ shortcuts user needs to have awareness of the axis orientation, and this takes time and need to check view orientation icon in the top right, plus you need to do hand movement to press 2 shortcuts. With MMB constraint it is extremely intuitive because I don’t need to think about what axis should I lock movement after pressing G, I can just point it into direction I want it locked and that is it, and since I already started movement with my mouse in that direction it is a continuation of the movement which is amazing. As mentioned, during modeling, and I am doing it 8 hrs per day 5-6 days a week, this intuitive and fast version is a huge time saver.
I … I did not know this was possible.
Don’t know if it is able to override my GXX muscle memory but it is always interesting what basics one still doesn’t know about after all those years.
Honestly, I didn’t know about “MMB Axis constraint” either. Normally I use G-X-DRAG, or I drag the gizmo. Tried the MMB constraint for a bit yesterday; I like using that method the least. I find 2mouse-button operations to be physically uncomfortable after several minutes, and less precise to drag the mouse (due to extra parts of my hand locking down on the mouse.)
I can certainly see why others would like that method, but it’s not for me.
Yeah, me neither. It just goes to show how much of an impact learning something for the first time and then imprinting it into muscle memory really is. And why so many people can get to a point of unreasonable and emotional about not changing existing conventions even if they might be better.
The thing you’ve learned is going to be the thing you want to keep using. No matter if it’s just small things in your software or even the software itself.
