I think that some users prefer to destroy other users workflow with gaining nothing, only to have a more easy to understand tool.
1 Like
I know well … and many of these come from other applications and are used to them and that use … and therefore not knowing the depth of blender that was already well organized to work at best, they quietly trample this workflow for ignorance …
Of course, that’s why I clearly said when 2.8 is finished. Of course there will be iteration and testing out of ideas. Or would you be happier if they always used the very first idea they got, and considered it final?
1 Like
Yes, the EXACT same thing happens with the new tools. Just select move tool in the toolbar, hold down left mouse button, and then press all those hotkeys you mentioned, and you will see it works the exact same way. What I proposed is that you could choose if the hotkey just switches to the tool, or directly activates it. I have no idea what’s so hard to understand about my “it would be indistinguishable from the old behavior” statement.
To me, it appears that the main problem here is your lack of understanding how the transform tools on the new tool system work combined with hostility towards learning new things.
1 Like
I would be happier if they listen users, like other devs do, and they implement ideas with iterations in the design, not in the code.
Implement two or three times the same until it works is one of reasons, probably the least important, because code quest will end in april when the official planning was October.
Re. Using the hotkeys to switch tools:
The main idea here is that we will do this by default in the Industry Compatible keymap. Most other DCC apps work this way, and it can become quite fast when the common hotkeys are bound to switching the tools. Most large, big budget pro animation feature films were produced with tools working like this, so it’s not prohibitive to being productive or creating top quality results.
One of the main things that make them slower currently is the fact that switching between them is slower.
In any case, the alternate keymap will work this way, and there could be an option for the default keymap to work this way too.
2 Likes
I think that explains many of the usability changes in blender2.8 and the lack of affection for T-shelf and the workflow in blender2.79.
Yes, we’ve all worked in companies that use that software, and we’ve all seen our colleagues work perfectly at half the speed. And no, it’s not a joke, in my last project I had to see a colleague even accusing me of subcontracting people because he couldn’t believe the speed with which I worked.
2 Likes
Bill…
I used Max Xsi Maya and Lightwave … because to work in productions I had to use these for strength …
so I know their “standardizations” well …
yet I always preferred blender when I had to model and get results as fast as possible … because objectively it was always better and faster … compared to other applications …
ok you want to standardize everything to get the widest possible users … I understand … but please … do not destroy the speedworkflow …
as the veterans are accepting the compromise, even the newbie must harness their compromises.
it is not blender veterans’ fault if the standard industry is going to ■■■■ off with these stupid “license at times” that vampire their users or put entire communities into failure overnight making some applications obsolete for purely strategic and economic reasons…
the nice thing is that many of these users … for years they made fun of it that blender was a toy …
and all because they were pumped by the promotions of their wonderful beautiful programs … and they were lazy as a ■■■■ to try to deepen something that in their eyes seemed “free = not good, or toy”
ironically now some of they continue with the teasing and want to brainwash an entire culture of workflow …
and just to make things clear …
the true standard … it’s blender … not “the standard industry” …
whole generations know first blender … and then “the industry” …
1 Like
true story … I had similar situations …
@nokipaike I think you misunderstood. Please don’t misquote me. I didn’t say we should do this in the default keymap. We deliberately chose to make the default the way it is: use shortcuts for blocking, immediate transforms, and the more visual toolbar for a more visual workflow with active tools and gizmos.
What I did say, is:
1, it’s a fallacy to say you can’t be productive with using tools, as many many films and productions have shown
2, it would be faster to use them if the hotkeys were bound to the tools.
3, the whole concept of the standards-oriented keymap came from the idea to create a way to use Blender that is useful for users who use Blender in heterogeneous environments, as part of a larger workflow. Maybe those users jump back and forth with Unity or Unreal, or they use Substance or Maya for other parts of the pipeline. In these types of scenarios, a more standardized approach to tools is appropriate.
Just be aware that there’s a certain inherent circular logic fallacy in saying “we should not add shortcuts to X, it is too slow to activate”. Clearly, X would be faster to activate then.
1 Like
Let’s just have one, good keymap 
I mean, a few months ago, it looked like that switch from right to left click will start World War 3, or that at very least, the userbase will be divided for years to come. The change has been done now for just a couple of months, and I can already see such a large proportion of Blender userbase stopped to care about right click select, that it may not even need to be maintained in future, because right click userbase will likely dwindle down to nothing within a few months.
I think if we get a single, good, modern keymap, same thing will happen. Let’s just make the current one optional, let’s make a new, proper one, based on common sense, and I can guarantee you that within a year, the current one will end up so forgotten no one will care about it being kept up to date.
5 Likes
Overall I am sympathetic to this point of view. It’s generally the right approach - quality over quantity.
But completely eschewing Blender’s previous keymap and concept is a really drastic change - we even did experiments with removing the tab key for a more logical use of the number row to invoke any mode, which a lot of Blender users found too hard to swallow. And that was just a single key!
So, for now, we decided to go with this strategy:
- Keep the Blender keymap as-is but cleaned up and improved (pie menus, more minimal etc)
- Add a separate keymap for users who use Blender in heterogeneous workflows, or for occasional users etc.
An alternative strategy would be something more like a merging of the two keymaps, moving to QWER for the basic transform tools, and then having a preference to choose if they should invoke immediate/modal tools or active tools. This way there really is only a need for one keymap, but still with two ways to use the tools.
This would still require Blender users to completely throw out any muscle memory, but has some nice advantages too. Even if you like the immediate/modal tools, the WER keys are more ergonomically placed on the keyboard compared to GRS.
1 Like
Yes, I agree. But the issue I have with the approach is that both Blender’s current keymap as well as the proposed Industry Standard Keymap are lacking in terms of ergonomics, especially with modeling tools. There is a certain basic set of modeling tools, or tools in general, which should be easily accessible all the time, such as extrude, inset, loopcut and bevel.
In both current Blender’s keymap as well as the proposed Industry standard one, for example shortcut for Inset is set to I key, which is quite inconvenient to reach, and at the same time, there’s quite a few unoccupied keys much easier to reach.
This was a practical example of a broader issue, which is that both “industry standard” hybrid keymap, and Blender 2.7 style keymap are keymaps which fail at ergonomics. Yet there is no third keymap planned. None of these two planned keymaps address the issue of hand gymnastics currently required in Blender to do even the most basic of things
EDIT:
I’ve made a graphical example of how I think the keymap creation should be approached, in all modes and editors. Basically, the more frequently the feature is used, the easier it should be to reach
5 Likes
Maybe this would be a good use case for Campbell’s new and improved keymap options, a quick toggle between QWER invoking the old direct use operators or the new active tools
1 Like
Users have always bet on a unique keymap with options, we have even openly defended the use of WER (we only lost E key actually). Because as many of us have already said, if the Maya/max keymap has not worked, a keymap that is a remix of max, maya, cinema and houdini will not work better.
That’s not true, the problem was not moving between editing modes using numbers, the problem is that it eliminated showing or hiding collections (that use numbers) which is something that is used thousands of times a day, to exchange editing modes, which is used very few times every day and 99% of the time is to move between object mode and edit/pose mode. And for a secondary function 10 main keys of the keyboard that made a primary function are lost.
The solution that has been discussed several times
Tab - Edit Mode/last mode
Tab+drag - Show list of modes.
It is much more useful, functional and easy to understand.
We tried this but it was too error-prone. If you use tab while moving the mouse, you’ll get different results that if you stay still.
But it was tested internally or openly with beta?
In the moment that users know that hotkey and hotkey+drag are different things he will know to avoid problem. Same happens in other softwares. Obviusly old users will need more time to learn new way, but I use it after 10 years of using blender and I only needed one hour to use it without problems.
Prone to error is the facedots off by default, where is hard to know what are you editing. Or the new pie menus, that are really hard to read and you can’t change by old menus with a option.
1 Like
What I would love is a preference to globally turn off all the modal tools and use only their active tools equivalents.
4 Likes
As has been mentioned already, there is a way to use the keyboard to switch tools.
Use the key-map preference for space-bar to switch tools.
Then you can use the Spacebar as a tool modifier: Space-G for grab, Space-R for rotate, Space-K for knife… etc. Pressing space isn’t any harder then Shift or Control, so this can be done fairly quickly.
Interested in feedback, do people who like to switch tools via key bindings find this handy?
I think its weak we don’t support convenient key-bindings to switch tools by default, but artists in the studio preferred using space for animation, so we went with that.