Page MenuHome

Industry Compatible Keymap
Closed, ResolvedPublic

Tokens
"Mountain of Wealth" token, awarded by merwin."Love" token, awarded by lkruel."Love" token, awarded by jbklug."Love" token, awarded by Njordy."Love" token, awarded by belmonthook."Love" token, awarded by Moctor."Love" token, awarded by Kartridge."Love" token, awarded by renatoi."Love" token, awarded by vitorbalbio."Like" token, awarded by Somnolent."Love" token, awarded by yrrnn."Love" token, awarded by solafide."Like" token, awarded by clawjelly."Love" token, awarded by d.viagi."Love" token, awarded by KartoonHead."Love" token, awarded by zaha."Love" token, awarded by TheFaceless."Love" token, awarded by oktawu."Love" token, awarded by Mitch."Love" token, awarded by pitom."Love" token, awarded by KloWorks."Love" token, awarded by fabioroldan."Love" token, awarded by elbox01."Love" token, awarded by wo262."Love" token, awarded by fiendish55."Love" token, awarded by undo."Like" token, awarded by Orv510."Love" token, awarded by juancahf."Burninate" token, awarded by shader."Love" token, awarded by sebastianmroy."Love" token, awarded by sopranoo."Love" token, awarded by zazizizou."Love" token, awarded by razgriz286."Love" token, awarded by jpthrash."Love" token, awarded by julperado."Love" token, awarded by Okavango."Love" token, awarded by johnsyed."Love" token, awarded by 0o00o0oo."Like" token, awarded by duarteframos.
Authored By

Description

This describes design of a new input map (keymap from now on) variant for Blender 2.8.

Motivation

In the past, we've included various alternative keymaps with Blender. While it has been of some use, we've had a few major problems:

  • The old keymaps couldn't properly mimic the way other apps use tools
  • The old keymaps were not well maintained. There were too many.
  • We used to include options for the Blender keymap, such as LMB select, which never worked properly for all tools and modes

In Blender 2.8, we want to improve this, by making one 'Industry Standard' keymap that we can keep well maintained, and in working order.

This new keymap will make switching back and forth between industry standard apps easier, and will provide a lower barrier to entry for migrating to Blender.


Note: Blender 2.8 includes various new features, such as Active Tools, which makes it possible to work a lot more like industry standard apps, if we choose. This enables us to mimic industry standard input more closely than we could in the past.


Approach

  • It will not replace the default keymap in Blender - this is an alternative keymap for users who use Blender as part of their pipeline, in conjunction with industry standard apps.
  • It should be a minimal, maintainable keymap. Not every command needs to be mapped to a shortcut like the Blender default keymap
  • The design of this keymap is based on an average of default input mapping layouts used in the mainstream computer graphics software

Who is this keymap for?

This keymap is for people who are already accustomed to other 3D packages, and who wish to use Blender as part of their pipeline, or who wish to switch to Blender outright. It is not aimed at existing Blender users, although they are free to use it if they wish.

Tie Breaker App

Not all apps in the 3D industry agree on which shortcuts to use. In cases where no standard exists, we want to rely on a 'tie breaker' app which decides the hotkey. When the tie-breaker app has no hotkey set, we can use one of the other apps' hotkeys then.

These are the tie-breaker apps we have chosen:

Modeling & AnimationMaya
Painting & SculptingZbrush

Brief Overview

This isn't comprehensive, but these are the main controls used in this keymap:

General
Mode/Element switching1-9 number row
Contextual MenuRight Click
Operator SearchTab
Quick FavouritesShift-Tab
DuplicateCtrl/⌘-D
ParentP
RenameReturn
RenderCtrl/⌘-Return
Viewport
NavigationAlt + LMB, MMB, RMB
ViewpointF1-F4
Frame SelectedF
Frame AllA
Tools
Transform ToolsW, E, R, T
Box SelectQ
AnnotateD
Cursor ToolC
Edit Tools
ExtrudeCtrl/⌘-E
BevelB
InsetI
KnifeK
Selection
SelectLeft Click (obviously)
Select AllCtrl/⌘-A
Deselect AllCtrl/⌘-Shift-A
Select InverseCtrl/⌘-I
Select MoreArrow Up
Select LessArrow Down
Select LoopDouble-Click
Select LinkedRight Bracket
Animation
Play/PauseSpace
Insert LocRotScale KeyS
Insert Location KeyShift-W
Insert Rotation KeyShift-E
Insert Scale KeyShift-R

DCC App Research Chart

This spreadsheet gives clear insight into which keys are used in which apps.

3Ds MaxMayaCinema 4DModoHoudiniUnreal EngineUnityWinner
Viewport navigation
OrbitAlt+MMBAlt+LMBAlt+LMBAlt+LMBAlt+LMBAlt+LMBAlt+LMBAlt+LMB
PanMMBAlt+MMBAlt+MMBAlt+Shift+LMBAlt+MMBAlt+MMBAlt+MMBAlt+MMB
ZoomCtrl+Alt+MMBAlt+RMBAlt+RMBCtrl+Alt+LMBAlt+RMBAlt+RMBAlt+RMBAlt+RMB
Center on selectionZFOShift+ASpace+GFFF
Switch viewportsL, F, BSpaceF1-F5Ctrl+SpaceSpace+1-5Alt+J, Alt+K, Alt+HN/A ?
Selection
Select mode/toolQQN/AQSN/AN/AQ
SelectLMBLMBLMBLMBLMBLMBLMBLMB
Deselect???Click in empty spaceClick in empty space????????????Click in empty space
Add to selectionCtrl+LMBShift+LMBShift+LMBShift+LMBShift+LMBShift+LMBShift+LMBShift+LMB
Subtract from selectionAlt+LMBCtrl+LMBCtrl+LMBCtrl+LMBCtrl+LMBCtrl+LMBCtrl+LMBCtrl+LMB
Box selectDrag LMBDrag LMBDrag LMBDrag LMBDrag LMBDrag LMBDrag LMBDrag LMB
Add to box selectionCtrl+Drag LMBShift+Drag LMBShift+Drag LMBDrag LMBShift+Drag LMBShift+Drag LMBShift+Drag LMBShift+Drag LMB
Subtract from box selectionAlt+Drag LMBCtrl+Drag LMBCtrl+Drag LMBCtrl+Drag LMBCtrl+Drag LMBCtrl+Drag LMBCtrl+Drag LMBCtrl+Drag LMB
Loop Select???Double-click edgeDouble-click edge????????????Double-click edge
Menus
Context Sensitive CommandsRMBRMBRMBRMBRMBRMBRMBRMB
Transform tools
MoveWWEWTWWW
RotateEEREREEE
ScaleRRTRERRR
Mesh Editing
Mesh element modes1-5F9-F11Enter1-31-4N/AN/A1-9
ExtrudeShift+ECtrl+EDShift+XN/AN/AN/ACtrl+E
InsetN/AN/AiB (bevel mode)N/AN/AN/AI
Loop cutCtrl+Shift+EN/AK (knife tool mode)Alt+CN/AN/AN/AAlt+C
BevelCtrl+Shift+BN/AM+SBN/AN/AN/AB
Animation
Play/Pause/Alt+VF6/Up ArrowN/AN/ASpace
Set KeyframeKSSK S
ZbrushMudbox3D CoatModo
Sculpting
Resize BrushSB+click and drag?????????
IntensityUM+click and drag?????????
Blob tool???????????????
Smooth tool???Hold shift or 2(default)?????????
Snake Hook tool???????????????
Grab tool???????????????
Clay tool???????????????
Etc???????????????
ZbrushMudbox3D CoatModoMariSubstance Painter
Texture Painting
Resize BrushS???ctrl+RMB+drag left/right???R+any Mouse buttonctrl+RMB
IntensityU????????????ctrl+LMB+drag left/right´
Paint tool????????????P1
Eraser Tool????????????E2
colour pickerC???V???CP
Display next channel???????????????C
Display previous channel???????????????shift+C
Show Material???????????????M
SymmetryX???S??????L
wireview??????W???shift+W???
Swap foreground and background colorsV?????????XL
rotate environment??????shift +LMB+drag left/right??????shift+RMB
Set Clone tool source????????????ctrlctrl+LMB
Stencil rotate????????????ctrl+LMBS+LMB
Stencil snap rotate???????????????shift+S+LMB
stencil pan????????????shift+LMBS+MMB
stencil zoom????????????ctrl+shiftS+RMB

Testing

This keymap is now included with the Blender 2.8 beta.

Details

Type
To Do

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
  1. 1234 keys currently do not make sense. In almost all other packages, mesh element modes start from 1-vertex, 2-edge, etc... Yet in a typical weird Blender manner, 1 is object mode here, and vertex starts at 2.

Doing it that way is harder to support in practice, because of the fact that different object types have a different number of edit mode element submodes.

Also, because object mode is the default mode in Blender, setting it to 1 has the nice advantage is making it easy to go back to it.

  1. Inset tool doesn't appear to be working at the first sight, because there is no viewport gizmo. It appears as if nothing happened upon pressing I. Same goes for Bevel.

Not quite sure what you mean. You simply click and drag.

  1. Ctrl+Left clicking to deselect triggers a menu entry instead for some reason:

This was changed already.

  1. Ring select shortcut missing...?

Do you have a suggestion for it?

  1. Can I suggest adding 'Duplicate Linked' as Alt-D ? I think it is even more frequently used than regular Duplicate.
  1. Although It might be too radical to change, but I don't think that View switching on Numpad is very "industry standard". Considering a lot of people are using laptops or tenkeyless keyboards. Also it is not ergonomic - you have to lift your right hand from mouse or left hand away from all the other shorcuts. I would change to F1-F4 (Cinema4D) or regular numbers (and then selection modes to Alt + 1,2,3.. or F9-F12 (Maya)). At least in my experience changing views is more frequent operation than changing edit modes.
  1. 1234 keys currently do not make sense. In almost all other packages, mesh element modes start from 1-vertex, 2-edge, etc... Yet in a typical weird Blender manner, 1 is object mode here, and vertex starts at 2.

Doing it that way is harder to support in practice, because of the fact that different object types have a different number of edit mode element submodes.

Also, because object mode is the default mode in Blender, setting it to 1 has the nice advantage is making it easy to go back to it.

  1. Inset tool doesn't appear to be working at the first sight, because there is no viewport gizmo. It appears as if nothing happened upon pressing I. Same goes for Bevel.

Not quite sure what you mean. You simply click and drag.

  1. Ctrl+Left clicking to deselect triggers a menu entry instead for some reason:

This was changed already.

  1. Ring select shortcut missing...?

Do you have a suggestion for it?

@2: Yes, different object types have different number of sub modes, but they always start at 1, not 2, in every software. Max, Maya and Modo, they all came with the same issue, but none of them solved it by starting the sub modes offset by one number, so this doesn't really align well with industry standard. My own preference would be to have object mode in Tilde key, but the most standardized way to do this is to have numbers keys be toggles. That's how it works in the mainstream apps. So that if you press 1, you go to vertex edit mode, and if you press 1 again while in vertex edit mode, you get back out to object mode.

@3: What I mean is that once you hit I key, it appears as if nothing at all happened unless you click down and start dragging. If a newbie reads that I key is the inset tool, he will press I expecting something to happen, but nothing will.

@5: Well the most straightforward suggestion for this would be Alt+LMB, since Ctrl and Shift + LMB already occupy add/remove selection. But if you assigned ring select to Alt+LMB, you will run exactly in the problem I've outlined above, in:
https://developer.blender.org/T54963#658154


As long as you have view3d.rotate set to Left Press, you've closed yourself a door for using Alt+LMB click. If you change view3d.rotate to Click-Drag, you will be able to use Alt+LMB for orbit as well as ring select, but you won't be able to rotate the view in the knife tool because of https://developer.blender.org/T62154

@Gatis Kurzemnieks (kurzemnieks)
Set viewpoints to F-keys as you suggest.

@Ludvik Koutny (rawalanche)
In practice there are problems if you set it to vert, edge, face, object, in that order. For example, what to do if you have a curve object selected? Currently, it's no problem. 1 is still object mode and 2 is edit mode. But if we did it as you suggest, 1 would be edit mode and 4 would be object mode, while 2 and 3 would be unused. So in practice it's not so nice.

Considering 1,2,3,4 I am agreed with the @Ludvik Koutny
I am working in Modo.
1 - vert
2 - edges
3 - polygons
4 - materials(select polygons by assigned material)
5 - objects.

It is not that big problem for me to use number 5 for objects. and it works the same at 3dsMax and other software.
I would be happy to see
1 - vertex
2 - edges
3 - polygons
4 - objects
5 - materials

Considering 1,2,3,4 I am agreed with the @Ludvik Koutny
I am working in Modo.
1 - vert

And I work in Houdini, and "1" is the object. We already discussed it at length, and I believe there was were some logical issues at not having object first because other "tabs" have different numbers of modes, and object would jump around from number to number.

@Gatis Kurzemnieks (kurzemnieks)
Set viewpoints to F-keys as you suggest.

@Ludvik Koutny (rawalanche)
In practice there are problems if you set it to vert, edge, face, object, in that order. For example, what to do if you have a curve object selected? Currently, it's no problem. 1 is still object mode and 2 is edit mode. But if we did it as you suggest, 1 would be edit mode and 4 would be object mode, while 2 and 3 would be unused. So in practice it's not so nice.

I of course never suggested that object mode key should change. Object mode key should always be static. It could be Tab key, it could be Tilde key, it could be spacebar, it could be escape (if no tool mode is active), etc... Of course I do not propose the object mode key to be last number after arbitrary amount of sub object modes given object offers.

What I meant to say is that in 3ds Max for example, if you are in a certain numbered sub object mode, let's say edge mode activated by 2 key, then pressing 2 key again exits back to object mode, if you don't want to have a dedicated object mode key.

  1. Can I suggest adding 'Duplicate Linked' as Alt-D ? I think it is even more frequently used than regular Duplicate.

This is important

@2: Yes, different object types have different number of sub modes, but they always start at 1, not 2, in every software. Max, Maya and Modo, they all came with the same issue, but none of them solved it by starting the sub modes offset by one number, so this doesn't really align well with industry standard. My own preference would be to have object mode in Tilde key, but the most standardized way to do this is to have numbers keys be toggles. That's how it works in the mainstream apps. So that if you press 1, you go to vertex edit mode, and if you press 1 again while in vertex edit mode, you get back out to object mode.

Using toggles is a bad solution IMHO, numbers should ideally match to an absolute mode. 3DS Max uses toggles and you can never be sure where pressing a certain key will take you too. If it is not immediately obvious what mode you are in currently (object out of view or hidden) you have to press a key multiple times or look at the header to make sure. Also by pressing a key once it won't absolutely guarantee it leaves you in the mode you want to.

I also think 1 not being Vertex Mode can be confusing, at least initially, but pushing object mode to higher number would not be an acceptable solution, especially if it is not consistent between object types.

ideally using a separate key to toggle between Object and Edit Modes would be the preferred solution. Either bring back Tab key, or Tilde \ keys would be fine.

Considering a lot of people are using laptops or tenkeyless keyboards. Also it is not ergonomic - you have to lift your right hand from mouse or left hand away from all the other shorcuts.

Numpad number keys would be unused otherwise, so what is wrong with leaving the functionality there in addition to other available methods? You already have the View Gizmo in the viewport corner, plus the new Alt + MMB gestures.

To be realistic, no one is going to be 100% happy with every single hotkey, industry standard or not. However, having this standard means that those of us coming from other apps will only need to make minimal changes to be confortable with blender now.

Some things I will note just to see if others agree:

Inset tool doesn't appear to be working at the first sight, because there is no viewport gizmo. It appears as if nothing happened upon pressing I. Same goes for Bevel

I did not like this new behavior either. It took me a few minutes to find out why the tools wern’t working because there was no obvious indication they were active. It just makes using these tools more confusing, which is the opposite effect of what the industry standard map intended. Regardless of what app we come from, I think we can all agree that the original behavior of dragging the mouse and using the scroll to add segments (if using bevel) was more comfortable (no extra click necessary). To summarize, the new hotkey was good, changing the behavior of the tool was not.

1234 keys currently do not make sense. In almost all other packages, mesh element modes start from 1-vertex, 2-edge, etc... Yet in a typical weird Blender manner, 1 is object mode here, and vertex starts at 2.

From what I read in other posts (different elements having a different amount of modes) I understand why Object mode was moved to 1 and everything else was offset, but lets be honest, that choice seems less like the obvious solution and more like a lack of better options; so let’s discuss some options then. Both Max and Modo start with 1 for vertex and move up, so that one guy wanting object on the 1 key because Houdini... well, I think you’re the odd one out.

However, the toggle idea to use the same keys to switch between components and object mode like 3ds Max, while sensible on paper, is actually incredibly frustrating. It’s not just Max either, I know of other completely unrelated programs that use that same toggle behavior and it becomes such a displeasing chore to keep track of what mode or tool you’re in. You end up tappingthe same key 2 or 3 times while watching for changes in the viewport to see what icons light up or how the mesh changes. Absolutes are better (you press a key... only one thing can happen).

Okay, but where do we put the object mode in. The original TAB to toggle Object/Edit mode was a good idea, because you could take advantage of it and also toggle modifier visibility on/off at the same time with just 1 key (pretty neat and straightforward IMO). So, I can think of this question: What will users coming from other apps find more comfortable/useful? Keeping the original TAB as a toggle for Object/Edit mode or offsetting all the modes to the right and putting object mode on the 1 key?

Honestly I can’t say for sure myself. I come from Maya so we use a completely different method (gestures). But don’t forget, the industry standard is meant to cater to the majority, so in the end some adjustments will always have to be made to match our personal preference.

Oskar (Oskar) added a subscriber: Oskar (Oskar).EditedTue, Apr 16, 3:27 PM

I found a workaround that makes the navigation with Alt + LMB/MMB/RMB possible while using the Knife Tool.
In Keymap -> 3D View -> Knife Tool Modal Map you need to have Panning set for Alt+LMB, Alt+MMB, Alt+RMB.
And the Panning Alt+LMB must be set before Add Cut with Left Mouse.(the order is important)

Here is how it looks in my settings:

Maybe we can add this to the IC Keymap?

Why isn't there an option to keep the tab-button for switching in and out of edit-mode instead of binding each mode to 1-8?

@Juan Hernandez (ArmoredWolf) I am not necessarily against using 1 for vertex, 2 edge, 3 face, 4 object. But, as I mentioned earlier, the issue is that it doesn't work well in Blender because not all object types have vert/edge/face modes, meaning that using 4 for object then makes no sense if you have eg a curve object selected.

The way it is currently seems like the best way to support mode switching using the number row, unless someone can find a solution that works for non-mesh objects too.

@Oskar (Oskar) This should be how it works already.

@Nebez Kassem (nabaxo) because that's not how any other app does it, and so it doesn't make sense inside this keymap.

It's not practical to add an option for every single thing this keymap does differently compared to the default Blender keymap. Besides, Tab is used for operator search, so then in that case you would need to find a new home for that, and then we start having to re-arrange everything.

The issue with tab, apart from being non-standard, is that it's also just a bad fit. In Blender we have more than two modes, so a single key for toggling Object vs Edit doesn't map with all the modes inside Blender. It makes it so Edit mode is prioritised over other modes, which sucks if you are an animator who uses Pose mode all the time, or a sculptor who uses Sculpt mode.

The good news is that of course you can still create custom keymaps, so you always have the option of doing it exactly as you wish.

@William Sitton (william), how about keeping TAB and the current number keys untouched, leave them exactly like the Blender 2.80 mapping. It’s already similar to the standard anyway. It works great already and no need to offset all those keys. We only have to memorize that TAB is for toggling object/edit mode and that’s it.

Let’s not forget that the idea behind using an industry standard layout is to make the transition easier, but the current implemendation of offsetting everything and putting Object Mode on 1 is not copying the majority of other softwares and is not making the transition easier. In other words, it’s not following the original guidelines or making outside users comfortable, so maybe it shouldn’t be changed. At the very least it should be re-evaluated.

I feel that as a Maya user (we use gestures instead of hotkeys for the behavior we’re discussing) I’m a little less biased when talking about this, so I just wanted to share my opinion :p

@William Sitton (william), how about keeping TAB and the current number keys untouched, leave them exactly like the Blender 2.80 mapping. It’s already similar to the standard anyway. It works great already and no need to offset all those keys. We only have to memorize that TAB is for toggling object/edit mode and that’s it.

Let’s not forget that the idea behind using an industry standard layout is to make the transition easier, but the current implemendation of offsetting everything and putting Object Mode on 1 is not copying the majority of other softwares and is not making the transition easier. In other words, it’s not following the original guidelines or making outside users comfortable, so maybe it shouldn’t be changed. At the very least it should be re-evaluated.

I feel that as a Maya user (we use gestures instead of hotkeys for the behavior we’re discussing) I’m a little less biased when talking about this, so I just wanted to share my opinion :p

Full-heartedly agree!

On another note, Select Linked is set to Right Bracket ]. This is troublesome on german (and I believe many european) keyboards as ] is entered by pressing Alt Gr + 9 and is not an extra key (see here). Will there be a localized equivalent here? Otherwise that key is unusable for many people.

I still don't get it. What's wrong with the idea of using non number key for switching back to object mode? :|

I still don't get it. What's wrong with the idea of using non number key for switching back to object mode? :|

There’s nothing wrong with it, that’s what we’re saying. Bring the original way back!

@William Sitton (william), how about keeping TAB and the current number keys untouched, leave them exactly like the Blender 2.80 mapping. It’s already similar to the standard anyway. It works great already and no need to offset all those keys. We only have to memorize that TAB is for toggling object/edit mode and that’s it.

Let’s not forget that the idea behind using an industry standard layout is to make the transition easier, but the current implemendation of offsetting everything and putting Object Mode on 1 is not copying the majority of other softwares and is not making the transition easier. In other words, it’s not following the original guidelines or making outside users comfortable, so maybe it shouldn’t be changed. At the very least it should be re-evaluated.

I completely agree. It's not about different items or modes or any of that, but about the industry standard. And the majority of 3D software uses 1-3 for vertices, edges, and faces. So, in my opinion, the industry keymap for Blender should to. The reasoning is simple - regardless of what else you can work with in a 3D app, like curves, etc., for the majority of the people the majority of the time they will be modeling. And when modeling, the majority of your time is spent in item mode, switching between vertex, edge, and face mode. So, you want those to have the priority. As such, assigning them the first three numbers on the top row numbers is the common way to do this.

  • It's impossible to rotate view while knife tool is active
  • select more than one edge loop it's almost impossible, for vertex it's ok but for edge and polygons doesn't work properly.
  • there is no easy way to select edge rings

I've made a video about {F6952358}edge loop/ring selection, in my opinion we can set shift + double click as "Select Next Element" but we need something like INFINITE option in order to complete the loop/ring action. Ctrl + double click should deselect in the same way.

  • select more than one edge loop it's almost impossible, for vertex it's ok but for edge and polygons doesn't work properly.

To select more than one edge loop, you have to hold down SHIFT and then single-click to select ONE edge in the next loop you want. Then, still holding SHIFT, you double-click on the single edge you'd just selected and you should then get your new edge loop added to your selection. It took me awhile to figure out this is what needed to be done. I don't think it's ideal, but it does work. This works with polygonal faces, too.

@Ludvik Koutny (rawalanche) Which key for object mode?

Tilde is not a good option because it doesn't exist on many keyboards. 4 has the issue I mentioned many times already, which is that for non-mesh objects, there is no vert/edge/face mode, creating a gap in the keymap.

@Dan Silverman (ArgentArts) I feel like a broken record already. I don't mind doing it in the order of vertex, edge, face, object, sculpt etc, *however* it creates some critical issues with non-mesh objects. Blender is not only for manipulating meshes, so the keymap has to work for curves and other object types too.

@Daniele Viagi (d.viagi) wrote:

  • It's impossible to rotate view while knife tool is active

This should be fixed already.

  • select more than one edge loop it's almost impossible, for vertex it's ok but for edge and polygons doesn't work properly.

I will fix this.

  • there is no easy way to select edge rings

Suggestions on how to solve are welcome.

@Dan Silverman (ArgentArts) I feel like a broken record already. I don't mind doing it in the order of vertex, edge, face, object, sculpt etc, *however* it creates some critical issues with non-mesh objects. Blender is not only for manipulating meshes, so the keymap has to work for curves and other object types too.

If you feel like a broken record, it may be because it is an important issue to may of us. At least that's my guess. However, having said that, Blender 2.8 using 1-3 as the DEFAULT for vertex, edge, and face WITHOUT the industry keymap. So, even standard Blender realizes that this is the way it should be. You just need to press TAB to switch between object and item mode. And since this works already in standard Blender 2.8, and since this matches the majority use outside of Blender as well, why change that at all? Just keep it as it is and you solve the issue. Also, as a side note, Blender 2.8, without the industry standard keymap, still has to work with curves and other objects, too. Even so, they still have mapped 1-3 to vertex, edge, and face (as long as you are in item mode).

@Dan Silverman (ArgentArts) Blender's default keymap does not use the number keys for mode switching, so that's why it's different. Yes we could use the order of 1 vert, 2 edge, 3face, 4 object, but in practice it doesn't work for curves and other object types.

@dan den (dan) Silverman (ArgentArts)
This is why I wrote almost impossible, I thought this was a bug :)
I don't think it's ideal too

@William Sitton (william) Reynish (billreynish)

Suggestions on how to solve are welcome.

In my opinion we can set shift + double click as "Select Next Element" but we need something like INFINITE option in order to complete the loop/ring action. Ctrl + double click should deselect in the same way. Video==>Loop/Ring Select

  • select more than one edge loop it's almost impossible, for vertex it's ok but for edge and polygons doesn't work properly.

To select more than one edge loop, you have to hold down SHIFT and then single-click to select ONE edge in the next loop you want. Then, still holding SHIFT, you double-click on the single edge you'd just selected and you should then get your new edge loop added to your selection. It took me awhile to figure out this is what needed to be done. I don't think it's ideal, but it does work. This works with polygonal faces, too.

I’m not sure why those acrobatics are necessary. Back in my first attempt at creating my own industry standard loop select, I don’t remember having these issues. I managed to set up shift + double click to add loops and ctrl + double click to deselect loops without problems. The one drawback to my solution was that double clicking without shift or ctrl still selected loops, which may or may not be desireable (some people prefer double click to select the the entire mesh instead).

@Dan Silverman (ArgentArts) Blender's default keymap does not use the number keys for mode switching, so that's why it's different. Yes we could use the order of 1 vert, 2 edge, 3face, 4 object, but in practice it doesn't work for curves and other object types.

And what if it would? One suggestion in the comments has been:

For Meshes:
Tab - Switch to Object Mode
1 - Switch to Edit Mode, Select Vertices
2 - Switch to Edit Mode, Select Edges
3 - Switch to Edit Mode, Select Faces

For Curves:
Tab - Switch to Object Mode
1 - Switch to Edit Mode

@Dan Silverman (ArgentArts) Blender's default keymap does not use the number keys for mode switching, so that's why it's different. Yes we could use the order of 1 vert, 2 edge, 3face, 4 object, but in practice it doesn't work for curves and other object types.

Currently, if I switch out of the industry keymap in Blender, I use TAB to switch between item and object mode. Once in object mode, pressing 1 on the top row puts me in vertex mode, 2 puts me in edge mode, and 3 in face mode. That's what's happening on my end.

@Juan Hernandez (ArmoredWolf) The loop select extend issue was simply a bug in the keymap. It is now fixed.

@Michael Klement (zaha) It could work but is also non-standard and then leaves no good place for the operator search. The current behavior matches Houdini more and happens to work well with Blender's various object types and modes.

This might sound dumb, but why can't we have a preferences panel like in the regular keymap where, amongst some other settings, we can switch between tab as toggle and the 1-8 system we have?

@Dan Silverman (ArgentArts) Blender's default keymap does not use the number keys for mode switching, so that's why it's different. Yes we could use the order of 1 vert, 2 edge, 3face, 4 object, but in practice it doesn't work for curves and other object types.

And what if it would? One suggestion in the comments has been:

For Meshes:
Tab - Switch to Object Mode
1 - Switch to Edit Mode, Select Vertices
2 - Switch to Edit Mode, Select Edges
3 - Switch to Edit Mode, Select Faces

For Curves:
Tab - Switch to Object Mode
1 - Switch to Edit Mode

That's how Blender 2.8 works for me out of the box, so to speak. And even if it didn't, this is a good solution. It's how I currently work in Blender every day.

@Nebez Kassem (nabaxo) For the reason I already said. We can add options here, but a keymap is like one of those games of small squares. If you move one item, then it conflicts with another item, so then you have to move that, and so on it goes. Adding options for alternatives gets very messy, so initially I would like to avoid it, and keep this keymap lightweight and maintainable.

At some point it may be added but first I want to make sure the basics work well with no fiddling.

Honestly, the operator search is a great thing to have, but it's not nearly as useful as being able to toggle between edit mode and whatever other mode you're currently in considering Blender's workflow. At least give us the option to bind the toggle somewhere and deal with the conflicts ourselves. I wouldn't mind moving the search to somewhere else of my liking.

So I guess what I'm saying is that make the 1 key a toggle and let me rebind it however I wish myself.

@Michael Klement (zaha) It could work but is also non-standard and then leaves no good place for the operator search. The current behavior matches Houdini more and happens to work well with Blender's various object types and modes.

@William Reynish (billreynish) Well, having Vertices, Edges and Faces on 1-3, as has been mentioned a lot lately, would be more standard than having them on 2-4. The only odd end would be object mode on TAB, which would be "Blender Standard". One could argue this as a nice compromise between both worlds.

Regarding the key for the operator search, I have been playing with the idea today that it could be put on CTRL + SHIFT + P as is often done in Code Editors (like Atom or VS Code) for the command palette. One downside is that this is a more cumbersome shortcut than simply TAB. On the other hand I've been using CTRL + SHIFT + P everyday at work for quite some time now and don't mind it anymore.

There's one thing I would like to bring to your attention as well: I think there is currently no shortcut for the Add Mesh menu in the Keymap, isn't there? (VIEW3D_MT_add, Shift + A in Blender). I use this shortcut a lot, could this please be rectified? SHIFT + A is free from what I can tell.

@Nebez Kassem (nabaxo) Of course switching modes is important. It's essential. That's why we use the number row with the most used modes furthest to the left on the keyboard.

If you would like to do it differently, you can do whatever you like already inside the keymap editor or by copying the keymap and customising.

When making a keymap you must make certain choices to make all the parts fit together.

Regarding the key for the operator search, I have been playing with the idea today that it could be put on CTRL + SHIFT + P as is often done in Code Editors (like Atom or VS Code) for the command palette. One downside is that this is a more cumbersome shortcut than simply TAB. On the other hand I've been using CTRL + SHIFT + P everyday at work for quite some time now and don't mind it anymore.

This would be an amazing choice for us used to coding.

@Nebez Kassem (nabaxo) Of course switching modes is important. It's essential. That's why we use the number row with the most used modes furthest to the left on the keyboard.

If you would like to do it differently, you can do whatever you like already inside the keymap editor or by copying the keymap and customising.

When making a keymap you must make certain choices to make all the parts fit together.

Alright, so, when I'm in sculpt mode, I press 1 to go to edit mode to quickly fix something and then I try to press 1 again to switch back, and I'm SOL. I know have to remember that sculpt mode is on 5, if I don't, I have to manually cycle 1, 2, 3, 4 and then 5 to finally find my way back. Also worth considering is that if I'm in key mode 8, whatever that is, it's pretty far away from where my hand is and it gets pretty tiring to go back and forth between 1 and 7 or 8.

Here's another solution: Make the 1 key a toggle, just like how tab works in the default keymap.

@William Reynish (billreynish)
Currently with the ICKeymap it seems like the Knife Tool works as if the LMB is always pressed. (build date: 2019-04-16 06:07, hash: edc1b0167518)
It creates a point every time you hover over an edge (without clicking).


But it works fine with my settings, don't know why. If you like I can try to reproduce how I set it up.

+1 for keeping TAB as object/edit mode toggle, and 1, 2, 3 for vert, edge, face mode etc, as it currently works in the Blender 2.80 default. I think that works quite nicely, and is more "industry compatible" than the current implementation in this keymap. We can find another key for Operator Search.

Dan Pool (dpdp) added a comment.EditedWed, Apr 17, 7:11 AM

I created an addon and a keymap to make the QWER keys work in a more industry standard way.

https://github.com/dpdpforlife/QWER

Basically, the idea is instead of the QWER keys being mapped to box select, move active tool, rotate active tool, and scale active tool, respectively, the Q key toggles selection modes (like the W key in the default keymap) and the W, E, and R keys toggle the move, rotate and scale gizmos, like in the new Viewport Gizmos menu. This is the way most people coming from other software would expect these keys/tools to work. For example, they don't want box select to be unavailable, just because the move tool is active, they expect the translation mode to remain active despite what mode they're in, and they want this to be changed in all 3d views, not just a single one at a time.

I also added the possibility to have multiple gizmos active at the same time by using the CTRL+Alt+Shift modifiers. For instance if the move gizmo is currently active, you can press CTRL+Alt+Shift+E to have both move and rotate enabled.

Things that would make this work better:

  • If gizmos didn't interfere with selection it would be great. I know this is something that is being worked on, but this should be a high priority. The Rotate gizmo is particularly bad about blocking selection.
  • If the move, rotate, and scale gizmos could be enabled from the tool bar instead of these enabling the active tools. Transform tools are not a good match for the active tools workflow and just seem to new users like they're blocking you from making box selections. This method of interaction is incredibly slow.

Here's how I have the keys configured. The importable keymap is also available in the github link.

Here's the operator portion of the addon:

import bpy

class Qwer_OT_Operator(bpy.types.Operator):
    bl_idname = "view3d.qwer_controls"
    bl_label = "qwer Controls"
    bl_options = {'REGISTER'}
    bl_description = "qwer Controls"

    mode = bpy.props.StringProperty()
    moveBool: bpy.props.BoolProperty(name="Move")
    rotateBool: bpy.props.BoolProperty(name="Rotate")
    scaleBool: bpy.props.BoolProperty(name="Scale")
    
    def execute(self, context):        
        areas = bpy.context.workspace.screens[0].areas

        if self.mode == "Move":
            for area in areas:
                for space in area.spaces:
                    if space.type == 'VIEW_3D':
                        space.show_gizmo_object_translate^= True
                        space.show_gizmo_object_rotate = False
                        space.show_gizmo_object_scale = False
        if self.mode == "Rotate":
            for area in areas:
                for space in area.spaces:
                    if space.type == 'VIEW_3D':
                        space.show_gizmo_object_translate = False
                        space.show_gizmo_object_rotate^= True
                        space.show_gizmo_object_scale = False
        if self.mode == "Scale":
            for area in areas:
                for space in area.spaces:
                    if space.type == 'VIEW_3D':
                        space.show_gizmo_object_translate = False
                        space.show_gizmo_object_rotate = False
                        space.show_gizmo_object_scale^= True  
        if self.mode == "AddMove":
            for area in areas:
                for space in area.spaces:
                    if space.type == 'VIEW_3D':
                        space.show_gizmo_object_translate^= True
        if self.mode == "AddRotate":
            for area in areas:
                for space in area.spaces:
                    if space.type == 'VIEW_3D':
                        space.show_gizmo_object_rotate^= True
        if self.mode == "AddScale":
            for area in areas:
                for space in area.spaces:
                    if space.type == 'VIEW_3D':
                        space.show_gizmo_object_scale^= True 
        return {'FINISHED'}

I created an addon and a keymap to make the QWER keys work in a more industry standard way.

Based on this description (haven't tried your changes), this sounds like it would perfectly address the issue I brought up earlier. Nice work!

@Ludvik Koutny (rawalanche) Which key for object mode?

Tilde is not a good option because it doesn't exist on many keyboards. 4 has the issue I mentioned many times already, which is that for non-mesh objects, there is no vert/edge/face mode, creating a gap in the keymap.

My vote goes to either Tab key or Esc key. Tab key is a bit arbitrary, as it's not used in any other DCC I think, but it's still justified, as it's close to the number keys.

Esc key would be ideal, as it's natural instinct of anyone to press it to exit out of any mode. Esc also exits out of the modal operators, but I hope there would not be any conflicts (for example Esc exiting modal operator and edit mode at the same time).

By the way Ctrl+LMB in the industry keymap is still broken. Blender uses some heuristic to select closest element to mouse cursor when selecting. In this keymap, it works for Shift+LMB to Add to selection, but does not work with Ctrl+LMB to remove from selection. Deselecting edges using Ctrl+LMB for example is nearly impossible now, as one needs to click pixel-precisely on the edge. It works in my custom keymap though...

Also, it's still not possible to drag-select objects when in Move, Rotate or Scale tool. That definitely goes against industry standards. So rather than hotkeying tools, industry keymap should either directly hotkey the gizmo toggles while staying in select tool, or should change the LMB behavior of Move/Rotate/Scale tools so that selection instead of transform happens.

I would rather not use Esc, which is both odd and hard to reach. Will keep as-is because none of the other alternative proposals will work well.

Tab is more useful for other things like operator search.

Using 1 for object mode is used by some other apps, and it’s also the default mode in Blender. Plus, it mirrors the same order you see in the Mode drop down menu. So I’ll keep it this way.

I would rather not use Esc, which is both odd and hard to reach. Will keep as-is because none of the other alternative proposals will work well.

Tab is more useful for other things like operator search.

Using 1 for object mode is used by some other apps, and it’s also the default mode in Blender. Plus, it mirrors the same order you see in the Mode drop down menu. So I’ll keep it this way.

I am confused now :) Why are we justifying things with ergonomics now? If Esc is not a good option because it's hard to reach (which I disagree with), then why do we have I for Inset and half of the easier to reach keys remain unassigned? >:|

I thought the original idea of this keymap is to be as similar to other apps as possible, even at the sacrifice or ergonomics. If ergonomics are now a factor, then why not make the best possible keymap instead?

  • I know of no other app that use Esc for object mode.
  • 1 is used by some apps
  • it works well for Blender’s various object types (no keymap gaps or inconsistencies)
  • It mirrors the mode drop down
  • it’s the default mode

I know of no other app that use Esc for object mode. 1 is used by some apps and it works well for Blender’s various object types.

Yes, but out of all the things people complained most about Blender's input mapping was that the most expected things, like 123 for Vert/Edge/Face were not there. If we do it the weird way again, then it won't be much of an improvement.

I would rather not use Esc, which is both odd and hard to reach. Will keep as-is because none of the other alternative proposals will work well.

Agreed that Esc is not really all that ergonomic. I'd definitely prefer it to not be Esc.

Tab is more useful for other things like operator search.

Maybe this is true in other modes but the number of times I need to search for an operator versus going in and out of Object/Edit mode isn't even a comparison. Perhaps other people model by using the search feature but I think I've used it twice since 2.80 came out, while going in and out of Edit mode is something I do hundreds of times a day. Literally. Having fast access to the search feature versus easily going in and out of Edit mode is a no-brainer to me.

Using 1 for object mode is used by some other apps, and it’s also the default mode in Blender. Plus, it mirrors the same order you see in the Mode drop down menu. So I’ll keep it this way.

I thought the purpose was not to be the way Blender is by default but instead to mimic what other apps do? I was part of the discussion earlier in this thread with regards to 1/2/3/4 for Edit mode and I think the argument was made that only one other app uses 1 as an Object mode and it was Houdini or something (which is hardly known for having a robust modeling toolset).

I would gladly use the order or vert, edge, face, object, but it creates problems with objects other than meshes. That is the main reason.

Then there are secondary reasons:

  • object mode is the default in Blender
  • the Mode drop down mirrors this order
  • Some apps use this order

Also, it doesn't appear to be working in other modes with multiple sub-modes. Such as hair edit mode. Hair edit mode has 3 submodes yet 234 buttons do not switch them but instead switch back to mesh edit mode.

Of course. Particle edit mode is not the same as Edit mode. 2,3,4 go directly to Edit mode

Ouch... I'd assume that the number keys will always toggle edit submodes of any mode you are in in the same order. At least that's how it works in all the other apps that use number keys to switch edit submodes :)

That cannot work in practice. Then there would be no way to switch to Edit Mode if you are inside Particle mode. The whole idea with using the number row for modes is that you can switch immediately and directly to whichever mode you wish. So the keys must keep working.

Yeah, I think Blender's default keys (Tab to enter/exit edit mode) are the best choice here. From my experience, most packages don't really use a quick search like Blender, so it seems logical to me to have something as commonly used as edit mode on a nicely accessible key like Tab.

So in that case, search could also stay on the spacebar. That seems like a logical button to press when you're about to start typing. Having animation playback on spacebar doesn't seem that critical to me, and I say that as an animator. I'd rather have playback mapped to something right near my framestep keys.

Escape is used to cancel running jobs (like shader compilation, render, baking), using that for object mode switching would conflict.

Particle mode will disappear, so I wouldn't worry about inconsistency there too much. Hair will become an object type with an edit mode and then it becomes consistent.

The selection modes thing is tricky because we want to match the industry standard, but then also the opinion seems to be that none of the main apps actually get it right?

  • Maya and C4D don't use number keys.
  • Modo in latest versions does not use it either as far as I can tell from the docs?
  • 3ds Max uses 123 but the way it switches to object mode with toggling is considered bad?
  • Houdini is the one that makes sense logically and ergonomically but is not considered standard enough.

To me 1-2-3-4 for vert-edge-face-object wouldn't be the worst thing, but it is odd to put object mode in the middle between edit and paint modes. I guess it would be mainly to help those familiar with 3ds Max, or am I missing someplace where this convention exists and is considered to work well?

Yep, another vote for the Tab key for object mode toggle. If quick search is an issue, then that one is equally as much found on Ctrl+Space or F1 keys in other apps. It'd made general sense, as 1-9 keys would be to enter different modes, and Tab key would be to exit any mode, so it's kind of a different type of key.

Otherwise, Tilde key is a good candidate. If Tilde is not available on all keyboards, then the Object mode key can be simply mapped multiple times for the other keys in place of tilde in other languages.

Escape is used to cancel running jobs (like shader compilation, render, baking), using that for object mode switching would conflict.

Particle mode will disappear, so I wouldn't worry about inconsistency there too much. Hair will become an object type with an edit mode and then it becomes consistent.

The selection modes thing is tricky because we want to match the industry standard, but then also the opinion seems to be that none of the main apps actually get it right?

  • Maya and C4D don't use number keys.
  • Modo in latest versions does not use it either as far as I can tell from the docs?
  • 3ds Max uses 123 but the way it switches to object mode with toggling is considered bad?
  • Houdini is the one that makes sense logically and ergonomically but is not considered standard enough.

    To me 1-2-3-4 for vert-edge-face-object wouldn't be the worst thing, but it is odd to put object mode in the middle between edit and paint modes. I guess it would be mainly to help those familiar with 3ds Max, or am I missing someplace where this convention exists and is considered to work well?

MODO does, indeed, use the the 123 keys (actually uses 1-5) in the latest version (and has since several previous versions). I have a perpetual license of MODO and I use the number keys all the time. Their number key map is 1 - vertex, 2 - edge, 3 - face, 4 - material, 5 - object mode.

Using 1 for object mode is used by some other apps, and it’s also the default mode in Blender. Plus, it mirrors the same order you see in the Mode drop down menu. So I’ll keep it this way.

I am not sure where you get this but for me (and at least one other person who has commented here), in Blender 2.8, the app opens in object mode (because you normally begin by creating an object to work with). While in object mode, pressing 1, 2, or 3 on the number row does nothing. You press TAB to exit object mode and enter into item mode. At this point, pressing 1 brings you to vertex mode, 2 brings you to edge edit mode, and 3 is to select and edit faces. This is the default I get in Blender 2.8. Other than using TAB to switch between object and edit mode, it is already very close to how programs like MODO work (a key to get into edit mode and 1-3 keys, once in edit mode, to switch between vertex, edge, and face).

At the top, you have this chart that shows what other industry apps use and based on the majority, a winner (key combo) is declared. If you look at this chart under Mesh Editing, Mesh Element Modes, you will see that you have Max using keys 1-5, Maya using F9-F11, C4D using Enter, Modo using 1-3 (it actually uses 1-5), and Houdini using 1-4. The winner you declare? 1-9! Yet NONE of the apps use 1-9! In the process of trying to create an industry standard, with the emphasis being on helping people that use these other programs migrate over to Blender more easily, you decide to do something DIFFERENT instead of the "industry standard" From looking at the chart, it is clear that most everyone is doing things a bit differently. But three of the apps use at least the 1-4 keys (Max, Modo, and Houdini) and two of them (at least?) use 1-3 the same (Max and Modo). So, why go against the majority in favor of doing something different?

My proposal (and, apparently, that of many others here) is to simply leave it at the current Blender 2.8 default - TAB toggles between object and edit mode. When in edit mode, 1 - vertex, 2 - edge, 3 - face. It's simple. It follows what Blender already does. And it (mostly) matches the industry standard according to your own chart.

As @Brecht Van Lommel (brecht) nicely summarized the situation, there seems to be no commonly agreed standard here. I get the feeling that any change to the default Blender keymap does not add anything worthwile to improve the situation, so I wonder if this change is needed in the first place? This discussion starts to remind me of this xkcd: https://xkcd.com/927/

Please do not forget there are some users for this keymap that are already Blender users who work alot with complementary industry-standard tools like Substance Painter, Unreal Engine 4, Unity, Houdini, ZBrush, .... I am one of those people and what I hope to get from this keymap is an easier switching between programs since Blender is the big outlier here (except for ZBrush maybe :D). This is mostly achieved by using Maya-style Navigation in the viewport and using the QWER keys for transformations. Most other Blender shortkeys would be fine for me, to be honest. I don't care whether mode switching is on TAB or 1-4 in whatever order, as long as it allows for a good user experience. What I need is an efficient keymap that is not too disrupting to the complementary applications making it easier to switch between them. It also has to offers a convenient shortcuts for everything that is needed for daily work (the industry compatible keymap is currently lacking in that regard IMHO).

Do you consider such users a target audience for this keymap @William Reynish (billreynish) or is it only focussed on making the transition easier for non-blender artists who want to switch application coming from MAX/Maya/C4D and so on? Maybe we should first get the target audience straight before discussing any further.

Do you consider such users a target audience for this keymap @William Reynish (billreynish) or is it only focussed on making the transition easier for non-blender artists who want to switch application coming from MAX/Maya/C4D and so on? Maybe we should first get the target audience straight before discussing any further.

Right at the top of the page it states the following:

"In Blender 2.8, we want to improve this, by making one 'Industry Standard' keymap that we can keep well maintained, and in working order.

This new keymap will make switching back and forth between industry standard apps easier, and will provide a lower barrier to entry for migrating to Blender."

So, it looks like they have the target audience(s) already figured out. ;)

Do you consider such users a target audience for this keymap @William Reynish (billreynish) or is it only focussed on making the transition easier for non-blender artists who want to switch application coming from MAX/Maya/C4D and so on? Maybe we should first get the target audience straight before discussing any further.

Right at the top of the page it states the following:

...

Ha, right. Thanks for pointing that out, my bad! 😅

Well then that shortens my argument to: Is it really worth to change this from the default Blender keymap?
There have been arguments that it is already close to the industry standard (1-3 keys for vertex to face selection, whether pressing any of those should also switch immediately into Edit Mode is open for discussion. Both are possible.) and people seem to like that more than going for something completely different.

The issue of where to put the operator search then should be handled separately and not mixed up in this discussion IMHO, as the benefit of a good mode selection far outweights the operator search. Could be put on CTRL + F which is THE industry standard for search anyway.

@Dan Silverman (ArgentArts), note we are talking about the Industry Compatible Keymap here, which is not the default Blender keymap. We have no plans to change mode switching in the default keymap.

@Dan Silverman (ArgentArts), note we are talking about the Industry Compatible Keymap here, which is not the default Blender keymap. We have no plans to change mode switching in the default keymap.

I've only been talking about and making suggestions about the industry keymap. I've only brought up the default Blender keymap as an example (and to say that even in the industry compatible keymap that we should keep the Blender default for object/edit mode (tab) and 1-3 for item editing modes).

As an outsider user (I love learning new software, Maya, Modo, Max) I agree that Blender’s mode switching implementation worked fine and was already very similar to the standard so maybe we should just keep it.

I’m just now trying to learn Blender because of the 2.80 hype and I can see the benefits of keeping it unchanged. I like that in Edit mode the number keys switch components, but in object mode you can use them to switch collections instead (reminiscent on how you can reuse keys in Modo depending on the context).

Another use for TAB being a toggle is that you get to turn modifiers on and off with a single key to see before and after (unsubdivided/subdivided for example)

I would encourage people to test these things out a little first, you might end up agreeing.

If you’ve ever tried learning different software you will know that a few keymap changes work wonders for learning it, but some defaults should be embraced because of how the software was designed to work. You might win a little comfort by changing those but you lose a little functionality too.

NOTE
Don’t forget that we can always change or add our own personal hotkeys, so don’t be sad if the hotkey you suggest doesn’t make it into one of the presets. We can make our own presets and share them and, if they’re good enough, they might end up as part of the built in presets one day, WHO KNOWS?

Dan Pool (dpdp) added a comment.EditedWed, Apr 17, 5:40 PM

I found a great way to have the keybindings w, e, and r trigger the active tools (I won't restate my opinion of why this is bad if you're trying to attract users of other software) as well as the traditional blender way of doing transforms. Set move to W with a Click Drag value. This way tapping the W key activates the tool (this should really just toggle the gizmo imo) and moving the mouse while the w key is pressed goes directly into moving the object. I think a lot of new users will like this behavior since it's so much faster than working with gizmos, but will likely not stumble on it with the industry compatible keymap as-is.

Edit: I'd like to chime in on the edit mode keybindings. I think Tab is a better choice, but see the drawbacks that billrey brings up as being valid. It would be nice if the Tab key was context aware.

@William Sitton (william) Reynish (billreynish)

Edge Ring Selection comparsion and suggestion.
As I write before the way to go for edge ring select should be like maya, mainly because we chose the same navigation shortcut.
In my opinion we can set shift + double click as "Select Next Element" but we need something like INFINITE option in order to complete the loop/ring action. Ctrl + double click should deselect in the same way.

Maya

My proposal

To me 1-2-3-4 for vert-edge-face-object wouldn't be the worst thing, but it is odd to put object mode in the middle between edit and paint modes. I guess it would be mainly to help those familiar with 3ds Max, or am I missing someplace where this convention exists and is considered to work well?

We could easily do it, but it’s just awkward for other types that don’t have vert/edge/face modes.

We maybe could make it so that if you have a curve selected, either 1,2 or 3 will simply go to edit mode, even though that would be rather strange.

I really think It's a good start, but ...

  1. TAB to enter in edit mode and exit edit mode it's ok to keep it .
  2. I think 1, 2, 3 for Vertex, Edge, Faces selection it's ok to keep also. ( or if you want to do it like in maya, do a pie-menu for Vertex, edge, faces selection bind it on right-click )
  3. Ctrl + B for Bridge, X - for Knife, - I know it's K ... but it's usually ok to keep the most used keys where you are keeping your hands when you model. ( coming for a right hand on mouse, left hand on keyboard ) ... X comes more natural then K .

I will probably tune the IC Keymap to my liking anyway but for what it's worth this is my take on the keymap.

I vote for this setup:

1 ... vertices
2 ... edges
3 ... faces

It kind of makes sense and is easy to remember (especially for beginners) because:

1 ... a vertex is defined by just 1 point
2 ... an edge is defined by 2 points
3 ... a face is defined by at least 3 points

Hitting any of these keys should also take you automatically to the Edit mode regardless of the mode you are in. This is how it currently works in the IC Keymap, which is good - so please don't change it.
(I think the default Blender keymap would benefit from this behavior too but that is for another discussion.)

As for the Object mode key, the Tab key would be fine with me. Or the key before the 1 (the first key in the row).

I probably wouldn't like the 1, 2, 3 keys to also be toggles (they should not take you to the Object mode) like in 3ds max. But I am not entirely sure, I would have to test this for a period of time to be sure.

And as far as other objects like NURBS curves are concerned, hitting 1 or 2 or 3 would take you to the Edit mode. I see no problem with this behavior.

Then, of course, the current Mode-drop-down-menu (in the viewport) will not make much sense. But I think this whole system should be redesigned (now I am talking about Blender's UI and UX as a whole, not just the IC Keymap). For example in the Blender default keymap if I am in the Object mode and want to quickly manipulate vertices why do I have to go to the Edit Mode first and only then I can switch to vertices? Why not to go directly to vertices in one key press? Why two steps instead of one? This kind of switching is needed very often and should be as fast as possible. Quickly switching to say Weight Paint Mode is not as important as this.

@Jaroslav Brudna (r4p7or_3D) (sorry for offtopic) Hey, if you want the functionality you propose straight away, without waiting, then this may help you: https://blenderartists.org/t/a-proper-keymap-for-blender-2-8/1145406

@Ludvik Koutny (rawalanche)

Thanks a lot, Ludvik! I definitely plan on diving into keymap (and Blender) tuning very soon. It is the only way to have full control (apart from doing your own builds :)). I am aware of your great work in this area. I have some of your (older) keymap threads bookmarked. Thanks for a link to this new one, I will certainly take a good look at it. If I have anything to say I will make comments over at blenderartist.
(End of offtopic from me too.)

@William Reynish (billreynish) Over easter I got around to really test the industry keymap on project. While overall okay, I quickly got the feeling it's slow and cumbersome compared to the default Blender keymap. I had to resort quite often to the search for some things that did not have shortcuts. Here are some suggestions to improve this for pro users:

Name Action Proposed ShortcutNotes
Edit & Object Mode Tools
AddVIEW3D_MT_add, VIEW3D_MT_mesh_addShift + A
Toggle SnapToolSettings.use_snapXTaken from Maya according to Google research
Transformation Tool Toggling
Toggle Move gizmoshow_gizmo_object_translateShift + WIt would be nice to toggle the visibility of the transform gizmos by adding Shift to the keys
Toggle Rotate gizmoshow_gizmo_object_rotateShift + E
Toggle Scale gizmoshow_gizmo_object_scaleShift + R
Selection Tools
Circle selectbuiltin.select_circleCtrl + QThe standard key for quitting the application should be Alt + F4 (which already works, too). If not possible Shift + Q could be used instead.
Lasso selectbuiltin.select_lassoAlt + Q
Cursor Tool
Reset/center cursor?Shift + C
Set 3D Cursor?Shift + RMBSince it's not conflicting with anything I recommended keeping this for speed reasons.

I like the active tools, but sometimes they are slow or no good fit for the job at hand. Therefore it would be super handy if you would allow direct usage of mesh editing tools by adding a modifier key to the shortcut. That would allow to keep the best of both worlds. My proposal would be Shift:

Name Action Proposed Shortcut
BevelMesh -> BevelShift + B
InsetMesh -> Inset FacesShift + I
Loop cutMesh -> Loop Cut and SlideShift + Alt + C
ExtrudeMesh -> Extrude and Move on NormalsShift + Ctrl + E
KnifeMesh -> Knife Topology ToolShift + K

Issues:

  • "Deselect All" is really strenuous to press with all keys being very close to each other.
Name Proposed ShortcutNotes
Deselect AllCtrl + Alt + A
Alternative
Select AllShift + AEven better, going with the convention of Shift is adding to a selection.
Deselect AllShift + Alt + A
  • Knife tool is acting really weird: As soon as you placed the first cut, it automatically adds more cuts whenever you cross any edge but if you click in the middle of a face it does not do anything. Might be that's intended? But IMHO it's really weird. Should work that it cuts whenever you left-click.

@Michael - (michael) Klement (zaha) Max uses "q" to just toggle all transform gizmos, it's pretty good.
Ctrl Q is a standard for quit for a lot of programs.
Ctrl A is an undisputed standard for select all everywhere.
I think Photoshop has the most comfortable deselect - Ctrl D

Dan Pool (dpdp) added a comment.EditedTue, Apr 23, 10:20 PM

@Michael Klement (zaha) Instead of adding a modifier key, try using the Click Drag behavior for the operators. For instance, you can keep Ctrl+E (Press) for the extrude active tool and Ctrl+E (Click Drag) for the Mesh -> Extrude and Move on Normals operator. It works really well and is pretty intuitive it also gives the best of both worlds.

This is especially nice with the QWERT shortcuts, but wouldn't work as well with knife or loop cut.

@Cezary Szadejko (cez) the q key is select in 3ds Max. This is just like the q key in the industry compatible keymap except you can also hit q multiple times to choose your drag behavior in Blender.

i want to ask what id the real difference bewteen these two?, wouldn't be ideal to replace the Transform tools with the pop-over ones ,so they can be used with the industry hotkeys and work with other Active Tools epsecially selection tools and i beleive it will even bring 2.79 functioanlity to be easily toggleable....and the pop-over can remain for the other options.

@Michael Klement (zaha) Instead of adding a modifier key, try using the Click Drag behavior for the operators. For instance, you can keep Ctrl+E (Press) for the extrude active tool and Ctrl+E (Click Drag) for the Mesh -> Extrude and Move on Normals operator. It works really well and is pretty intuitive it also gives the best of both worlds.

This is especially nice with the QWERT shortcuts, but wouldn't work as well with knife or loop cut.

@Cezary Szadejko (cez) the q key is select in 3ds Max. This is just like the q key in the industry compatible keymap except you can also hit q multiple times to choose your drag behavior in Blender.

Oh wow, this is really nice! This achieves what I had in mind quite well, thanks for pointing it out.

Now getting this to work with Loop Cut and Knife would be really nice, because the active tool Loop Cut and Knife is really lacking for me right now. Using the tools panel to increase the segments but not seeing them live in the editor view is leagues away from the direct operator in terms of speed and usability. Adding the ability to increase the number of loop cuts with the mouse wheel while LMB button is down would be good already. @William Reynish (billreynish) Can this be done? It's not conflicting with mouse-wheel zoom since that's not possible when LMB is pressed down in that mode anyway.

@Cezary Szadejko (cez) I don't like toggles that much, I'd rather know exactly what I get when I press a key, regardless how many times I press it.
Can't remember any program that uses Ctrl + Q to close on Windows. Might be different on other platforms of course.
Ctrl + D for deselect would also be pretty nice from an ergonomic perspective but I that is used for Duplicate.

i want to ask what id the real difference bewteen these two?, wouldn't be ideal to replace the Transform tools with the pop-over ones ,so they can be used with the industry hotkeys and work with other Active Tools epsecially selection tools and i beleive it will even bring 2.79 functioanlity to be easily toggleable....and the pop-over can remain for the other options.

Yes, that would be the main Ideea, now we only need @William Reynish (billreynish) to change those :) .
I think Pablo said that the " move, rotate, scale - TOOLS " will be obsolete and be removed .

i want to ask what id the real difference bewteen these two?, wouldn't be ideal to replace the Transform tools with the pop-over ones

No, they are different, With the "real" transform tools you can click and drag anywhere to transform, which is a top feature. The "overlay" gizmos are great to help the tools that doesn't have gizmos, like the selection tools, so you can for example box select and still have the gizmo available etc... They both need to exist.

Zino Guerr (Zino) added a comment.EditedWed, Apr 24, 2:32 PM

i want to ask what id the real difference bewteen these two?, wouldn't be ideal to replace the Transform tools with the pop-over ones

No, they are different, With the "real" transform tools you can click and drag anywhere to transform, which is a top feature. The "overlay" gizmos are great to help the tools that doesn't have gizmos, like the selection tools, so you can for example box select and still have the gizmo available etc... They both need to exist.

why would u need click drag if you are using the gizmos in the first place? also isn't that the job of the select tool? so simply changing only the selection type will do the job.....i think it's redundant to have two options like this, and jumping between Active tools and pop-over, the system can be much more simpler and less confusing, this way you can combine both the transform tools and selection tools without hitting too many keys...anyway if there is no plan to change this, then at least the pop-over gizmos should be able to be bound to hotkeys so we can use them instead of the Transform tools.

i want to ask what id the real difference bewteen these two?, wouldn't be ideal to replace the Transform tools with the pop-over ones

No, they are different, With the "real" transform tools you can click and drag anywhere to transform, which is a top feature. The "overlay" gizmos are great to help the tools that doesn't have gizmos, like the selection tools, so you can for example box select and still have the gizmo available etc... They both need to exist.

But...If you choose the "Select Tool" the click and drag behavior is still there. So if drag anywhere is what you want, switch to that tool. Also if you set a shortcut for the move, rotate, and scale operators (2.79 method) to click drag, you get this behavior as well.

why would u need click drag if you are using the gizmos in the first place?

Clicking on the gizmo widget is not always the best way of working. It lacks precision and can be a slow workflow. That's why we need both.

But...If you choose the "Select Tool" the click and drag behavior is still there. So if drag anywhere is what you want, switch to that tool. Also if you set a shortcut for the move, rotate, and scale operators (2.79 method) to click drag, you get this behavior as well.

The select tool can't do "drag anywhere" for scale or rotate. And assign shortcuts for modal tools doesn't make sense when using active tools.

Zino Guerr (Zino) added a comment.EditedThu, Apr 25, 3:29 AM

@TheRedWaxPolice (TheRedWaxPolice) personally i use box select on RMB click drag and hotkeys for transform tools even have cycling transform tools with a hotkey , this way not only i can select but also click drag with manipulators on LMB and they don't interfere with selecting components pretty much like "Right click select".... i know this is unorthodox way but i found it much more intuitve and fast the only thing is missing is to be able to toggle transform tools that's all what i am looking for either from the Active tools or the pop-over ones if we can map anyone of them to our own hotkeys then they can both stay since not all of us find this little problem annoying.

The problems with those tools is that, they don't behave like " standard " DCC apps. So :

  • When I'm in move tool mode I should be able to box select and deselect everything, keeping the move Tool On.
  • The same is in rotate and scale mode .

Right now the behavior is :
I go into vertex/face/edge mode and when I'm in MoveTool Mode I can't deselect, because moving It's always on . I have to get back into box select mode to deselect. This is unwanted behavior in "standard" DCC apps .

The only way now that I've figured out that behaves like in all the DCC apps is not using the Move/Scale/Rotate Tools. And use the newly added Transform Gizmos .

That should be able to be supported like so:

When any of the transform tools are enabled:

  • drag LMB anywhere to box select
  • drag MMB anywhere to transform
  • drag LMB on gizmos to transorm (obviously)

Maya works something like this, and it should be easy to addresss here.

You can now box select while the transform tools are active, just like in Maya.

Left-click and drag to box select. Middle-mouse drag to use transform tool outside the gizmo.