Industry Compatible Keymap #54963

Closed
opened 2018-05-05 11:37:46 +02:00 by William Reynish · 545 comments

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.

The main use-case is switching quickly between many apps. Some users jump between Blender, Maya, Unity, Substance and other apps, so making Blender’s controls adhere more to these kinds of apps makes it easier to jump between them seamlessly.

The other use-case is for users of those other apps, to make it easier to learn how to use Blender. They may not wish to learn all Blender’s non-standard idiosyncrasies, but still take advantage of some of Blender’s features in their pipeline.

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 & Animation Maya
Painting & Sculpting Zbrush

Brief Overview

Refer to the manual for a brief overview of how this keymap works:
Industry Compatible keymap in manual

DCC App Research Chart

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

3Ds Max Maya Cinema 4D Modo Houdini Unreal Engine Unity Winner
Viewport navigation
Orbit Alt+MMB Alt+LMB Alt+LMB Alt+LMB Alt+LMB Alt+LMB Alt+LMB Alt+LMB
Pan MMB Alt+MMB Alt+MMB Alt+Shift+LMB Alt+MMB Alt+MMB Alt+MMB Alt+MMB
Zoom Ctrl+Alt+MMB Alt+RMB Alt+RMB Ctrl+Alt+LMB Alt+RMB Alt+RMB Alt+RMB Alt+RMB
Center on selection Z F O Shift+A Space+G F F F
Switch viewports L, F, B Space F1-F5 Ctrl+Space Space+1-5 Alt+J, Alt+K, Alt+H N/A ** ?**
Selection
Select mode/tool Q Q N/A Q S N/A N/A Q
Select LMB LMB LMB LMB LMB LMB LMB LMB
Deselect ??? Click in empty space Click in empty space ??? ??? ??? ??? Click in empty space
Add to selection Ctrl+LMB Shift+LMB Shift+LMB Shift+LMB Shift+LMB Shift+LMB Shift+LMB Shift+LMB
Subtract from selection Alt+LMB Ctrl+LMB Ctrl+LMB Ctrl+LMB Ctrl+LMB Ctrl+LMB Ctrl+LMB Ctrl+LMB
Box select Drag LMB Drag LMB Drag LMB Drag LMB Drag LMB Drag LMB Drag LMB Drag LMB
Add to box selection Ctrl+Drag LMB Shift+Drag LMB Shift+Drag LMB Drag LMB Shift+Drag LMB Shift+Drag LMB Shift+Drag LMB Shift+Drag LMB
Subtract from box selection Alt+Drag LMB Ctrl+Drag LMB Ctrl+Drag LMB Ctrl+Drag LMB Ctrl+Drag LMB Ctrl+Drag LMB Ctrl+Drag LMB Ctrl+Drag LMB
Loop Select ??? Double-click edge Double-click edge ??? ??? ??? ??? Double-click edge
Menus
Context Sensitive Commands RMB RMB RMB RMB RMB RMB RMB RMB
Transform tools
Move W W E W T W W W
Rotate E E R E R E E E
Scale R R T R E R R R
Mesh Editing
Mesh element modes 1-5 F9-F11 Enter 1-3 1-4 N/A N/A 1-9
Extrude Shift+E Ctrl+E D Shift+X N/A N/A N/A Ctrl+E
Inset N/A N/A i B (bevel mode) N/A N/A N/A I
Loop cut Ctrl+Shift+E N/A K (knife tool mode) Alt+C N/A N/A N/A Alt+C
Bevel Ctrl+Shift+B N/A M+S B N/A N/A N/A B
Animation
Play/Pause / Alt+V F6 / Up Arrow N/A N/A Space
Set Keyframe K S S K S
Zbrush Mudbox 3D Coat Modo
Sculpting
Resize Brush S B+click and drag ??? ??? ???
Intensity U M+click and drag ??? ??? ???
Blob tool ??? ??? ??? ??? ???
Smooth tool ??? Hold shift or 2(default) ??? ??? ???
Snake Hook tool ??? ??? ??? ??? ???
Grab tool ??? ??? ??? ??? ???
Clay tool ??? ??? ??? ??? ???
Etc ??? ??? ??? ??? ???
Zbrush Mudbox 3D Coat Modo Mari Substance Painter
Texture Painting
Resize Brush S ??? ctrl+RMB+drag left/right ??? R+any Mouse button ctrl+RMB
Intensity U ??? ??? ??? ??? ctrl+LMB+drag left/right ´
Paint tool ??? ??? ??? ??? P 1
Eraser Tool ??? ??? ??? ??? E 2
colour picker C ??? V ??? C P
Display next channel ??? ??? ??? ??? ??? C
Display previous channel ??? ??? ??? ??? ??? shift+C
Show Material ??? ??? ??? ??? ??? M
Symmetry X ??? S ??? ??? L
wireview ??? ??? W ??? shift+W ???
Swap foreground and background colors V ??? ??? ??? X L
rotate environment ??? ??? shift +LMB+drag left/right ??? ??? shift+RMB
Set Clone tool source ??? ??? ??? ??? ctrl ctrl+LMB
Stencil rotate ??? ??? ??? ??? ctrl+LMB S+LMB
Stencil snap rotate ??? ??? ??? ??? ??? shift+S+LMB
stencil pan ??? ??? ??? ??? shift+LMB S+MMB
stencil zoom ??? ??? ??? ??? ctrl+shift S+RMB

Testing

This keymap is now included with the Blender 2.8 beta.

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. The main use-case is switching quickly between many apps. Some users jump between Blender, Maya, Unity, Substance and other apps, so making Blender’s controls adhere more to these kinds of apps makes it easier to jump between them seamlessly. The other use-case is for users of those other apps, to make it easier to learn how to use Blender. They may not wish to learn all Blender’s non-standard idiosyncrasies, but still take advantage of some of Blender’s features in their pipeline. ## 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 & Animation | Maya | | -- | -- | |Painting & Sculpting | Zbrush | ## Brief Overview Refer to the manual for a brief overview of how this keymap works: [Industry Compatible keymap in manual ](https://docs.blender.org/manual/en/dev/interface/keymap/industry_compatible.html) ## DCC App Research Chart This spreadsheet gives clear insight into which keys are used in which apps. | | 3Ds Max | Maya | Cinema 4D | Modo | Houdini | Unreal Engine | Unity | **Winner** | | -- | -- | -- | -- | -- | -- | -- | -- | -- | | ***Viewport navigation*** | | Orbit | Alt+MMB | Alt+LMB | Alt+LMB | Alt+LMB | Alt+LMB | Alt+LMB | Alt+LMB | **Alt+LMB** | | Pan | MMB | Alt+MMB | Alt+MMB | Alt+Shift+LMB | Alt+MMB | Alt+MMB | Alt+MMB | **Alt+MMB** | | Zoom | Ctrl+Alt+MMB | Alt+RMB | Alt+RMB | Ctrl+Alt+LMB | Alt+RMB | Alt+RMB | Alt+RMB | **Alt+RMB** | | Center on selection | Z | F | O | Shift+A | Space+G | F | F | **F** | | Switch viewports | L, F, B | Space | F1-F5 | Ctrl+Space | Space+1-5 | Alt+J, Alt+K, Alt+H | N/A | ** ?** | | ***Selection*** | | Select mode/tool | Q | Q | N/A | Q | S | N/A | N/A | **Q** | | Select | LMB | LMB | LMB | LMB | LMB | LMB | LMB | **LMB** | | Deselect | ??? | Click in empty space | Click in empty space | ??? | ??? | ??? | ??? | **Click in empty space** | | Add to selection | Ctrl+LMB | Shift+LMB | Shift+LMB | Shift+LMB | Shift+LMB | Shift+LMB | Shift+LMB | **Shift+LMB** | | Subtract from selection | Alt+LMB | Ctrl+LMB | Ctrl+LMB | Ctrl+LMB | Ctrl+LMB | Ctrl+LMB |Ctrl+LMB | **Ctrl+LMB** | | Box select | Drag LMB | Drag LMB | Drag LMB | Drag LMB | Drag LMB | Drag LMB | Drag LMB | **Drag LMB** | | Add to box selection | Ctrl+Drag LMB | Shift+Drag LMB | Shift+Drag LMB | Drag LMB | Shift+Drag LMB | Shift+Drag LMB | Shift+Drag LMB | **Shift+Drag LMB** | | Subtract from box selection | Alt+Drag LMB | Ctrl+Drag LMB | Ctrl+Drag LMB | Ctrl+Drag LMB | Ctrl+Drag LMB | Ctrl+Drag LMB | Ctrl+Drag LMB | **Ctrl+Drag LMB** | | Loop Select | ??? | Double-click edge | Double-click edge | ??? | ??? | ??? | ??? | **Double-click edge** | | ***Menus*** | | Context Sensitive Commands | RMB | RMB | RMB | RMB | RMB | RMB | RMB | **RMB** | | ***Transform tools*** | | Move | W | W | E | W | T | W | W | **W** | | Rotate | E | E | R | E | R | E | E | **E** | | Scale | R | R | T | R | E | R | R | **R** || | ***Mesh Editing*** | | Mesh element modes | 1-5 | F9-F11 | Enter | 1-3 | 1-4 | N/A | N/A | **1-9** | | Extrude | Shift+E | Ctrl+E | D | Shift+X | N/A | N/A | N/A | **Ctrl+E** | | Inset | N/A | N/A | i | B (bevel mode) | N/A | N/A | N/A | **I** | | Loop cut | Ctrl+Shift+E | N/A | K (knife tool mode) | Alt+C | N/A | N/A | N/A | **Alt+C** | | Bevel | Ctrl+Shift+B | N/A | M+S | B | N/A | N/A | N/A | **B** | | ***Animation*** | | Play/Pause | / | Alt+V | F6 | / | Up Arrow | N/A | N/A | **Space** | | Set Keyframe | K | S | | S | K | | | **S** | | | Zbrush | Mudbox | 3D Coat | Modo | | ***Sculpting*** | Resize Brush | S | B+click and drag | ??? | ??? | ??? | | Intensity | U | M+click and drag | ??? | ??? | ??? | | Blob tool | ??? | ??? | ??? | ??? | ??? | | Smooth tool | ??? | Hold shift or 2(default) | ??? | ??? | ??? | | Snake Hook tool | ??? | ??? | ??? | ??? | ??? | | Grab tool | ??? | ??? | ??? | ??? | ??? | | Clay tool | ??? | ??? | ??? | ??? | ??? | | Etc | ??? | ??? | ??? | ??? | ??? | | | Zbrush | Mudbox | 3D Coat | Modo |Mari | Substance Painter | | ***Texture Painting*** | Resize Brush | S | ??? | ctrl+RMB+drag left/right | ??? | R+any Mouse button | ctrl+RMB | | | Intensity | U | ??? | ??? | ??? | ??? | ctrl+LMB+drag left/right |´ | Paint tool | ??? | ??? | ??? | ??? | P | 1 | | Eraser Tool | ??? | ??? | ??? | ??? | E | 2 | | colour picker | C | ??? | V | ??? | C | P | | Display next channel | ??? | ??? | ??? | ??? | ??? | C | | Display previous channel | ??? | ??? | ??? | ??? | ??? | shift+C | | Show Material | ??? | ??? | ???| ??? | ??? | M | | Symmetry | X | ??? | S | ??? | ??? | L | | wireview | ??? | ??? | W | ??? | shift+W | ??? | | Swap foreground and background colors | V | ??? | ??? | ??? | X | L | | rotate environment | ??? | ??? | shift +LMB+drag left/right | ??? | ??? | shift+RMB | | Set Clone tool source | ??? | ??? | ??? | ??? | ctrl | ctrl+LMB | | Stencil rotate | ??? | ??? | ??? | ??? | ctrl+LMB | S+LMB | | Stencil snap rotate | ??? | ??? | ??? | ??? | ??? | shift+S+LMB | | stencil pan | ??? | ??? | ??? | ??? | shift+LMB | S+MMB | | stencil zoom | ??? | ??? | ??? | ??? | ctrl+shift | S+RMB | ## Testing This keymap is now included with the Blender 2.8 beta.
William Reynish self-assigned this 2018-05-05 11:37:46 +02:00

Added subscribers: @WilliamReynish, @ideasman42

Added subscribers: @WilliamReynish, @ideasman42
William Reynish removed their assignment 2018-05-05 12:03:57 +02:00
Ludvik Koutny was assigned by William Reynish 2018-05-05 12:03:57 +02:00

Added subscriber: @Mantasku

Added subscriber: @Mantasku

{F3275947}Dopesheet_keys.png

Industry Standard way to Marquee/ Border select and move items using left mouse button:
In most 3D industry applications, animation packages, even in file managers, LMB click and drag on empty area= initiates Marquee/ Border select.
LMB click and drag on active area = Gives user ability to Move selected items by dragging

Problem with current Blender implementation there is no API functionality to detect if user clicked on empty area or on active area. This makes big conflict when selecting and moving items with same LMB is needed, and impossible to assign keys like in other apps. It would be nice to have checkbox option for example in action.select_border shortcut assignment dialog : "Detect empty area", which could be fast way to solve the issue. Of course global "Use industry standard border selection" would be even better...

Standard way to deselect items with LMB
Single click on empty area is an industry standard for deselecting all selected elements. In 3D view we have quite hidden function which is used in Maya and 3ds max keymaps ”View3d.select_or_deselect_all “ but there are no similar functions in other editors.

Draggable current time cursor
Almost all commercial applications have draggable current frame cursor. To make this option available in Blender would reduce the need to assign right or middle mouse button to change current frame position and would make it more ready for strandard LMB workflow.

{[F3275947](https://archive.blender.org/developer/F3275947/Outliner_keys.png)}![Dopesheet_keys.png](https://archive.blender.org/developer/F3275402/Dopesheet_keys.png) **Industry Standard way to Marquee/ Border select and move items using left mouse button:** In most 3D industry applications, animation packages, even in file managers, LMB click and drag on **empty area**= initiates Marquee/ Border select. LMB click and drag on **active area** = Gives user ability to Move selected items by dragging Problem with current Blender implementation there is no API functionality to detect if user clicked on empty area or on active area. This makes big conflict when selecting and moving items with same LMB is needed, and impossible to assign keys like in other apps. It would be nice to have checkbox option for example in action.select_border shortcut assignment dialog : "Detect empty area", which could be fast way to solve the issue. Of course global "Use industry standard border selection" would be even better... **Standard way to deselect items with LMB** Single click on empty area is an industry standard for deselecting all selected elements. In 3D view we have quite hidden function which is used in Maya and 3ds max keymaps ”View3d.select_or_deselect_all “ but there are no similar functions in other editors. **Draggable current time cursor** Almost all commercial applications have draggable current frame cursor. To make this option available in Blender would reduce the need to assign right or middle mouse button to change current frame position and would make it more ready for strandard LMB workflow.

Yes, we probably will have to add the ability to drag the timeline playhead, and detect that separately from a regular LMB-drag.

Yes, we probably will have to add the ability to drag the timeline playhead, and detect that separately from a regular LMB-drag.

@Mantasku what if there is content filling the full height of the area, does that mean you can't move the playhead?

How to move the playhead when there is no empty space?

@Mantasku what if there is content filling the full height of the area, does that mean you can't move the playhead? How to move the playhead when there is no empty space?

You mean in case like this... ?
Blender_timeline.png
I imagine that user could drag only red outlined part which is above all content... and clicking on frame numbers below could jump to frames...or maybe you could attach an image about the case you mean ?

You mean in case like this... ? ![Blender_timeline.png](https://archive.blender.org/developer/F3276087/Blender_timeline.png) I imagine that user could drag only red outlined part which is above all content... and clicking on frame numbers below could jump to frames...or maybe you could attach an image about the case you mean ?
Contributor

I agree with @Mantasku 's suggestions. Many of other pieces of software solve this issue by having an UI element specifically for dragging the timeline. In Video editor it's usually a small arrow on the top or the bottom of active frame cursor. It would be nice to simply be able to left click and drag the green frame number indicator. It's a bit slower than right click, since you first need to move your cursor at that exact spot and then drag it, but it's what users are generally used to.

I agree with @Mantasku 's suggestions. Many of other pieces of software solve this issue by having an UI element specifically for dragging the timeline. In Video editor it's usually a small arrow on the top or the bottom of active frame cursor. It would be nice to simply be able to left click and drag the green frame number indicator. It's a bit slower than right click, since you first need to move your cursor at that exact spot and then drag it, but it's what users are generally used to.

Yes, indeed.

We could even make it so users can click anywhere in the editor to move the timeline playhead. So that click = set playhead, drag = box select. Dragging the playhead handle will drag and move the playhead, and so on. Just like Final Cut Pro or other apps with timelines, which mostly all work this way.

Yes, indeed. We could even make it so users can click anywhere in the editor to move the timeline playhead. So that click = set playhead, drag = box select. Dragging the playhead handle will drag and move the playhead, and so on. Just like Final Cut Pro or other apps with timelines, which mostly all work this way.

Added subscriber: @Ghostil

Added subscriber: @Ghostil

This will be the standard layout now in 2.8 as in many applications?

This will be the standard layout now in 2.8 as in many applications?

Vyacheslav: What do you mean by 'standard layout' ?

Vyacheslav: What do you mean by 'standard layout' ?
Contributor

I think Vyacheslav meant if it's going to be default. And it is explained near the top in the "Approach" paragraph that it won't :)

I think Vyacheslav meant if it's going to be default. And it is explained near the top in the "Approach" paragraph that it won't :)

Adjusting playhead by clicking anywhere in the editor is really fast and cool, but by doing it this way we loose ability to deselect items by single clicking on empty area which also is the thing that users are used to. I would suggest to click on the frame bar... In other applications timeline scaling and frame selecting are on different lines, in our case it's merged in to the single line, so it has complications ...timeline click.png In Cinema 4D there is "J" sticky key which you hold pressed then move mouse left or right this way navigating timeline very fast, almost same as pressing this j.png and moving mouse left and right.

Adjusting playhead by clicking anywhere in the editor is really fast and cool, but by doing it this way we loose ability to deselect items by single clicking on empty area which also is the thing that users are used to. I would suggest to click on the frame bar... In other applications timeline scaling and frame selecting are on different lines, in our case it's merged in to the single line, so it has complications ...![timeline click.png](https://archive.blender.org/developer/F3276561/timeline_click.png) In Cinema 4D there is "J" sticky key which you hold pressed then move mouse left or right this way navigating timeline very fast, almost same as pressing this ![j.png](https://archive.blender.org/developer/F3276683/j.png) and moving mouse left and right.

The layout that will default to the blender.
1.jpg

The layout that will default to the blender. ![1.jpg](https://archive.blender.org/developer/F3276885/1.jpg)

Added subscriber: @DuarteRamos

Added subscriber: @DuarteRamos

Added subscriber: @AlbertoVelazquez

Added subscriber: @AlbertoVelazquez

One of the best things I saw in blender when I started using blender six-seven years ago was the search bar. You find her almost by chance, just by pressing space. In two seconds you understand its purpose. Thanks to it I had direct access to absolutely all the functions of blender at the time, completely unaware of the program, only needing to know what I wanted to look for. I learned half the program thanks to this. Is it good to remove it from its current location on a keymap for new users? it's hard for me to see it.

It is almost a wizard for fools, which unleashes the power of blender to any user.

One of the best things I saw in blender when I started using blender six-seven years ago was the search bar. You find her almost by chance, just by pressing space. In two seconds you understand its purpose. Thanks to it I had direct access to absolutely all the functions of blender at the time, completely unaware of the program, only needing to know what I wanted to look for. I learned half the program thanks to this. Is it good to remove it from its current location on a keymap for new users? it's hard for me to see it. It is almost a wizard for fools, which unleashes the power of blender to any user.

Alberto: the purpose of this keymap is to comply with ‘industry standards’

Alberto: the purpose of this keymap is to comply with ‘industry standards’
Contributor

In #54963#500012, @AlbertoVelazquez wrote:
One of the best things I saw in blender when I started using blender six-seven years ago was the search bar. You find her almost by chance, just by pressing space. In two seconds you understand its purpose. Thanks to it I had direct access to absolutely all the functions of blender at the time, completely unaware of the program, only needing to know what I wanted to look for. I learned half the program thanks to this. Is it good to remove it from its current location on a keymap for new users? it's hard for me to see it.

It is almost a wizard for fools, which unleashes the power of blender to any user.

What you see here is nowhere near finished :) There will be lot more, and do not worry, I do not plan to leave the quick search out. It will probably be mapped on Tab key, since it's commonly used key for quick search in software that supports it (Maya uses Tab key for quick search in Node editor, and so does Nuke).

> In #54963#500012, @AlbertoVelazquez wrote: > One of the best things I saw in blender when I started using blender six-seven years ago was the search bar. You find her almost by chance, just by pressing space. In two seconds you understand its purpose. Thanks to it I had direct access to absolutely all the functions of blender at the time, completely unaware of the program, only needing to know what I wanted to look for. I learned half the program thanks to this. Is it good to remove it from its current location on a keymap for new users? it's hard for me to see it. > > It is almost a wizard for fools, which unleashes the power of blender to any user. What you see here is nowhere near finished :) There will be lot more, and do not worry, I do not plan to leave the quick search out. It will probably be mapped on Tab key, since it's commonly used key for quick search in software that supports it (Maya uses Tab key for quick search in Node editor, and so does Nuke).

But no other software have a search function like blender and no other software use spacebar to the proposed switch mode, it's not a standard. The only program that use spacebar is maya and it use that to give a lot of funtions directly to the user. And spacebar is linked to the search bar idea in a lot of assistants, for example OSX.

But no other software have a search function like blender and no other software use spacebar to the proposed switch mode, it's not a standard. The only program that use spacebar is maya and it use that to give a lot of funtions directly to the user. And spacebar is linked to the search bar idea in a lot of assistants, for example OSX.

In #54963#500016, @Rawalanche wrote:

In #54963#500012, @AlbertoVelazquez wrote:
One of the best things I saw in blender when I started using blender six-seven years ago was the search bar. You find her almost by chance, just by pressing space. In two seconds you understand its purpose. Thanks to it I had direct access to absolutely all the functions of blender at the time, completely unaware of the program, only needing to know what I wanted to look for. I learned half the program thanks to this. Is it good to remove it from its current location on a keymap for new users? it's hard for me to see it.

It is almost a wizard for fools, which unleashes the power of blender to any user.

What you see here is nowhere near finished :) There will be lot more, and do not worry, I do not plan to leave the quick search out. It will probably be mapped on Tab key, since it's commonly used key for quick search in software that supports it (Maya uses Tab key for quick search in Node editor, and so does Nuke).

Since it's not mandatory I'm not worry. But I don't see why to change something that no other program use like standard and make harder to all new users use tutorials based in default keymap.

> In #54963#500016, @Rawalanche wrote: >> In #54963#500012, @AlbertoVelazquez wrote: >> One of the best things I saw in blender when I started using blender six-seven years ago was the search bar. You find her almost by chance, just by pressing space. In two seconds you understand its purpose. Thanks to it I had direct access to absolutely all the functions of blender at the time, completely unaware of the program, only needing to know what I wanted to look for. I learned half the program thanks to this. Is it good to remove it from its current location on a keymap for new users? it's hard for me to see it. >> >> It is almost a wizard for fools, which unleashes the power of blender to any user. > > What you see here is nowhere near finished :) There will be lot more, and do not worry, I do not plan to leave the quick search out. It will probably be mapped on Tab key, since it's commonly used key for quick search in software that supports it (Maya uses Tab key for quick search in Node editor, and so does Nuke). Since it's not mandatory I'm not worry. But I don't see why to change something that no other program use like standard and make harder to all new users use tutorials based in default keymap.

You have a point there. Maybe the space bar should follow an industry standard of some sort? What do you say, Ludvík?

You have a point there. Maybe the space bar should follow an industry standard of some sort? What do you say, Ludvík?

Really like the direction this is going. If I may add, I'd like to suggest a consistent use of modifier keys.
Currently in Blender the Alt key has become sort of a "reverse" or "opposite" key for many operators; like H hides Alt+H unhides, P Parents, Alt+P unparents, R Rotates, Alt+R clears rotation etc., you get the idea.

I really like this system; it is consistent and easy to remember, and I think it should be maintained and even expanded to other areas.
Particularly selection modifiers for example, if left click selects I think Alt+LMB should remove from selection, if border selection as a certain key, then Alt plus that key should remove too. Same applies to whichever keys are mapped to say Circle Select, and any other operators, selection related or otherwise.

No more middle mouse button for deselection, potentially releasing this key for viewport navigation at all times, which is probably out of scope here but would really really love to see become a possibility. Allowing viewport navigation during operators or at least tools

Really like the direction this is going. If I may add, I'd like to suggest a consistent use of modifier keys. Currently in Blender the Alt key has become sort of a "reverse" or "opposite" key for many operators; like `H` hides `Alt+H` unhides, `P` Parents, `Alt+P` unparents, `R` Rotates, `Alt+R` clears rotation etc., you get the idea. I really like this system; it is consistent and easy to remember, and I think it should be maintained and even expanded to other areas. Particularly selection modifiers for example, if left click selects I think `Alt+LMB` should remove from selection, if border selection as a certain key, then `Alt` plus that key should remove too. Same applies to whichever keys are mapped to say Circle Select, and any other operators, selection related or otherwise. No more middle mouse button for deselection, potentially releasing this key for viewport navigation at all times, which is probably out of scope here but would really really love to see become a possibility. Allowing viewport navigation during operators or at least tools

Alberto: just to be clear: this is different from the default Blender keymap. This will not allow for following regular Blender tutorials which refer to the default keymap at all

Alberto: just to be clear: this is different from the default Blender keymap. This will not allow for following regular Blender tutorials which refer to the default keymap *at all*
Contributor

@AlbertoVelazquez
Actually, this was adopted from Softimage XSI/Autodesk Softimage. It's a dead software now, but it had some very good concepts, with spacebar for object mode being one of them. It's written in the reasoning paragraph. Check the attached video example. You will see that edit mode exit/toggle action is frequent and useful enough to deserve key such as spacebar. Sure, search could be on spacebar, but as I already mentioned, when there is a quick search in CG software, it more often tends to be on Tab key.

@WilliamReynish
The issue is that there is no industry standard for Spacebar. Every mainstream app seems to use it for something very different. In Max, it's used to lock current selection (prevent you from selecting something else). In Maya, it's a monstrous hotbox/pie menu, in Houdini, it's viewport navigation key, in Modo, it cycles mesh element modes, in C4D, it's toggle between select mode and last used tool, etc...

I think that out of all the options of what Space could do, the object mode exit/toggle is the easiest and most universal concept for a new user to grasp.

@AlbertoVelazquez Actually, this was adopted from Softimage XSI/Autodesk Softimage. It's a dead software now, but it had some very good concepts, with spacebar for object mode being one of them. It's written in the reasoning paragraph. Check the attached video example. You will see that edit mode exit/toggle action is frequent and useful enough to deserve key such as spacebar. Sure, search could be on spacebar, but as I already mentioned, when there is a quick search in CG software, it more often tends to be on Tab key. @WilliamReynish The issue is that there is no industry standard for Spacebar. Every mainstream app seems to use it for something very different. In Max, it's used to lock current selection (prevent you from selecting something else). In Maya, it's a monstrous hotbox/pie menu, in Houdini, it's viewport navigation key, in Modo, it cycles mesh element modes, in C4D, it's toggle between select mode and last used tool, etc... I think that out of all the options of what Space could do, the object mode exit/toggle is the easiest and most universal concept for a new user to grasp.
Contributor

In #54963#500020, @DuarteRamos wrote:
If I may add I'd like to suggest a consistent use of modifier keys.
Currently in Blender the Alt key has become sort of a "reverse" or "opposite" operator for many keys like H hies Alt+H unhides, P Parents, Alt+P unparents, R Rotates, Alt+R clears rotation, you get the idea...

I really like this system; it is consistent and easy to remember, and I think it should be maintained and even expanded to other areas.
Selection modifiers for example if left click selects I think Alt+LMB should remove from selection, if border selection as a certain key, then Alt plus that key should remove too. Same applies to whichever keys are mapped to say circle select, and any other operators.

No more middle mouse button for deselection, potentially releasing this key for viewport navigation at all times, which is probably out of scope here but would really really love to see possible: Viewport navigation during operators or at least tools

I agree that consistency is good, but I am not sure there are that many users associating deselection key with modifier key for inverse of the action. My reasoning for this is that Shift key is very commonly used for addition to selection, not only in CG software, but in common mainstream software, operating systems and even games in general. Ctrl is then the modifier key responsible for deselection or selection toggling. For example 3ds Max uses Alt key for subtraction from selection, and Ctrl key for addition to selection, however, it's a minority. I tried to satisfy the majority here.

> In #54963#500020, @DuarteRamos wrote: > If I may add I'd like to suggest a consistent use of modifier keys. > Currently in Blender the Alt key has become sort of a "reverse" or "opposite" operator for many keys like `H` hies `Alt+H` unhides, `P` Parents, `Alt+P` unparents, `R` Rotates, `Alt+R` clears rotation, you get the idea... > > I really like this system; it is consistent and easy to remember, and I think it should be maintained and even expanded to other areas. > Selection modifiers for example if left click selects I think `Alt+LMB` should remove from selection, if border selection as a certain key, then `Alt` plus that key should remove too. Same applies to whichever keys are mapped to say circle select, and any other operators. > > No more middle mouse button for deselection, potentially releasing this key for viewport navigation at all times, which is probably out of scope here but would really really love to see possible: Viewport navigation during operators or at least tools I agree that consistency is good, but I am not sure there are that many users associating deselection key with modifier key for inverse of the action. My reasoning for this is that Shift key is very commonly used for addition to selection, not only in CG software, but in common mainstream software, operating systems and even games in general. Ctrl is then the modifier key responsible for deselection or selection toggling. For example 3ds Max uses Alt key for subtraction from selection, and Ctrl key for addition to selection, however, it's a minority. I tried to satisfy the majority here.

Added subscriber: @YAFU

Added subscriber: @YAFU

I completely agree with Alberto.
But, does this pretend to be behavior by default? If so, I'm a little confused right now. I understood that there would be changes to improve consistency between all the modes/editors within the same Blender, and make things easier for new users who use Blender as the first 3D program ever, not to satisfy users coming from other programs. I entered/know the 3D world with Blender as firts program. Then I have tried other programs and I think Blender has the best behavior for viewport navigation with mouse button wheel (and for the pen on a graphic tablet). Only noticed the problem of the LMB select that we all know.

Anyway, please do not touch shortcuts that are really intuitive because they are related to the English name that have tools/elements in Blender.

I completely agree with Alberto. But, does this pretend to be behavior by default? If so, I'm a little confused right now. I understood that there would be changes to improve consistency between all the modes/editors within the same Blender, and make things easier for new users who use Blender as the first 3D program ever, not to satisfy users coming from other programs. I entered/know the 3D world with Blender as firts program. Then I have tried other programs and I think Blender has the best behavior for viewport navigation with mouse button wheel (and for the pen on a graphic tablet). Only noticed the problem of the LMB select that we all know. Anyway, please do not touch shortcuts that are really intuitive because they are related to the English name that have tools/elements in Blender.
Contributor

In #54963#500024, @YAFU wrote:
I completely agree with Alberto.
But, does this pretend to be behavior by default? If so, I'm a little confused right now. I understood that there would be changes to improve consistency between all the modes/editors within the same Blender, and make things easier for new users who use Blender as the first 3D program ever, not to satisfy users coming from other programs. I entered/know the 3D world with Blender as firts program. Then I have tried other programs and I think Blender has the best mode for viewport navigation with mouse button wheel (and the pen on a graphic tablet). Only noticed the problem of the LMB select that we all know.

Anyway, please do not touch shortcuts that are really intuitive because they are related to the English name that have tools/elements in Blender.

As the first paragraph states, you don't need to worry. This will be the alternative keymap, but Blender's current keymap will stay the same, or very similar for 2.8. It will even remain default. This will just be another, non-default variant. But the purpose of this keymap, again, as the description at the top clearly states is mainly to make it easier for Blender to be used by people who will use it alongside other 3D app, or those who will want to migrate to it from other app. Just make sure to read the introduction (Motivation, Approach and Preface paragraphs) at the top, it's pretty clear at explaining this keymap's purpose :)

> In #54963#500024, @YAFU wrote: > I completely agree with Alberto. > But, does this pretend to be behavior by default? If so, I'm a little confused right now. I understood that there would be changes to improve consistency between all the modes/editors within the same Blender, and make things easier for new users who use Blender as the first 3D program ever, not to satisfy users coming from other programs. I entered/know the 3D world with Blender as firts program. Then I have tried other programs and I think Blender has the best mode for viewport navigation with mouse button wheel (and the pen on a graphic tablet). Only noticed the problem of the LMB select that we all know. > > Anyway, please do not touch shortcuts that are really intuitive because they are related to the English name that have tools/elements in Blender. As the first paragraph states, you don't need to worry. This will be the alternative keymap, but Blender's current keymap will stay the same, or very similar for 2.8. It will even remain default. This will just be another, non-default variant. But the purpose of this keymap, again, as the description at the top clearly states is mainly to make it easier for Blender to be used by people who will use it alongside other 3D app, or those who will want to migrate to it from other app. Just make sure to read the introduction (Motivation, Approach and Preface paragraphs) at the top, it's pretty clear at explaining this keymap's purpose :)

This comment was removed by @WilliamReynish

*This comment was removed by @WilliamReynish*

Sorry, I misinterpreted (may bad English helped for this). Thanks for the clarification.

Sorry, I misinterpreted (may bad English helped for this). Thanks for the clarification.

Added subscriber: @Leukbaars

Added subscriber: @Leukbaars

This is really awesome, I have gone to great lengths to set up my current blender install to similar shortcuts already. This should make blender very appealing to new users.

I would really reconsider the Maya viewport controls though, many consider them industry standard by now. It's used in quite a few game engines and editors. You mentioned unreal, but unity, source2 and substance painter/designer use it as well, and many others. In fact it's available as an option in 3dsmax after popular demand and pretty much every industry professional using max I've talked to uses the maya standard.
I really think industry standard camera controls should probably take priority over other shortcuts, it's the primary interaction you do in Blender.

This is really awesome, I have gone to great lengths to set up my current blender install to similar shortcuts already. This should make blender very appealing to new users. I would really reconsider the Maya viewport controls though, many consider them industry standard by now. It's used in quite a few game engines and editors. You mentioned unreal, but unity, source2 and substance painter/designer use it as well, and many others. In fact it's available as an option in 3dsmax after popular demand and pretty much every industry professional using max I've talked to uses the maya standard. I really think industry standard camera controls should probably take priority over other shortcuts, it's the primary interaction you do in Blender.
Contributor

In #54963#500030, @Leukbaars wrote:
This is really awesome, I have gone to great lengths to set up my current blender install to similar shortcuts already. This should make blender very appealing to new users.

I would really reconsider the Maya viewport controls though, many consider them industry standard by now. It's used in quite a few game engines and editors. You mentioned unreal, but unity, source2 and substance painter/designer use it as well, and many others. In fact it's available as an option in 3dsmax after popular demand and pretty much every industry professional using max I've talked to uses the maya standard.
I really think industry standard camera controls should probably take priority over other shortcuts, it's the primary interaction you do in Blender.

Yes, I am actually still considering that. However, how about the reasoning for current choice? For example consistency with 2D editors (MMB without any modifier key for panning) as well as comfort: When you are in orthographic view, for example front or side view, you usually want to stay in that view for a while and pan around while you are working. When you can pan just with MMB, it feels IMHO a bit more comfortable, as you don't need to constantly press modifier key for panning constantly. People don't realize enough what a luxury that is. Imagine that for example in node editor, you could not pan node view until you hold down Alt key first.

Sure the consistency is not as important here, as people have gotten used to inconsistency of this behavior in other packages too, but I still think that more comfort when working in orthographic views is a strong argument :)

If you read the reasoning paragraphs under those viewport navigation controls proposals, are there any arguments you specifically disagree with or find that they do not make any sense?

> In #54963#500030, @Leukbaars wrote: > This is really awesome, I have gone to great lengths to set up my current blender install to similar shortcuts already. This should make blender very appealing to new users. > > I would really reconsider the Maya viewport controls though, many consider them industry standard by now. It's used in quite a few game engines and editors. You mentioned unreal, but unity, source2 and substance painter/designer use it as well, and many others. In fact it's available as an option in 3dsmax after popular demand and pretty much every industry professional using max I've talked to uses the maya standard. > I really think industry standard camera controls should probably take priority over other shortcuts, it's the primary interaction you do in Blender. Yes, I am actually still considering that. However, how about the reasoning for current choice? For example consistency with 2D editors (MMB without any modifier key for panning) as well as comfort: When you are in orthographic view, for example front or side view, you usually want to stay in that view for a while and pan around while you are working. When you can pan just with MMB, it feels IMHO a bit more comfortable, as you don't need to constantly press modifier key for panning constantly. People don't realize enough what a luxury that is. Imagine that for example in node editor, you could not pan node view until you hold down Alt key first. Sure the consistency is not as important here, as people have gotten used to inconsistency of this behavior in other packages too, but I still think that more comfort when working in orthographic views is a strong argument :) If you read the reasoning paragraphs under those viewport navigation controls proposals, are there any arguments you specifically disagree with or find that they do not make any sense?
Contributor

Actually here's some more reasoning:

Let's say we'd go with Maya style navigation. This means Alt+LMB would be occupied for viewport orbit. I wanted to have Alt+LMB reserved for selecting edge loops in edit mode, since it's very frequent action and deserve to be accessible.

If Alt+LMB is occupied, Shift+LMB and Ctrl+LMB are out of question too, since those are for adding and subtracting selection. What Maya navigation style would free up would be the MMB and Ctrl+MMB. But both MMB and Ctrl+MMB would feel very weird for edge loop selection. I don't think anyone would be expecting to select something by pressing middle mouse button.

The thing here is that MMB and MMB+Modifier key combination do not tend to feel weird for viewport navigation, but they tend to feel weird for pretty much everything else. Utilizing MMB-centric viewport navigation leaves Alt+LMB for something more fitting. Alt+RMB is already meant to be cursor placement, which should not feel that unnatural either.

Actually here's some more reasoning: Let's say we'd go with Maya style navigation. This means Alt+LMB would be occupied for viewport orbit. I wanted to have Alt+LMB reserved for selecting edge loops in edit mode, since it's very frequent action and deserve to be accessible. If Alt+LMB is occupied, Shift+LMB and Ctrl+LMB are out of question too, since those are for adding and subtracting selection. What Maya navigation style would free up would be the MMB and Ctrl+MMB. But both MMB and Ctrl+MMB would feel very weird for edge loop selection. I don't think anyone would be expecting to select something by pressing middle mouse button. The thing here is that MMB and MMB+Modifier key combination do not tend to feel weird for viewport navigation, but they tend to feel weird for pretty much everything else. Utilizing MMB-centric viewport navigation leaves Alt+LMB for something more fitting. Alt+RMB is already meant to be cursor placement, which should not feel that unnatural either.

Oh I think the reasoning is sound, and it's a good control scheme! But it's not exactly industry standard, which would be the goal of this keymap :)

Oh I think the reasoning is sound, and it's a good control scheme! But it's not exactly industry standard, which would be the goal of this keymap :)

in 3ds max Selection Lock Toggle turns selection locking on and off. Locking the selection prevents you from inadvertently selecting something else in a complex scene. KeyMap Space.

in 3ds max Selection Lock Toggle turns selection locking on and off. Locking the selection prevents you from inadvertently selecting something else in a complex scene. KeyMap Space.
Contributor

In #54963#500035, @Leukbaars wrote:
Oh I think the reasoning is sound, and it's a good control scheme! But it's not exactly industry standard, which would be the goal of this keymap :)

Yes, I have a bit of schizophrenia here. I want it to be close to an average of industry standard, but at the same time, I want it to be the best it can be. Not just average of everything else, but using that average as a basis and then improving it with some new, more efficient concepts :)

> In #54963#500035, @Leukbaars wrote: > Oh I think the reasoning is sound, and it's a good control scheme! But it's not exactly industry standard, which would be the goal of this keymap :) Yes, I have a bit of schizophrenia here. I want it to be close to an average of industry standard, but at the same time, I want it to be the best it can be. Not just average of everything else, but using that average as a basis and then improving it with some new, more efficient concepts :)

Added subscriber: @Okavango

Added subscriber: @Okavango

@Rawalanche How about doubleclik for entering / exiting edit mode? I have it in my keymap, it is fast and intuitive as an eyeblink and it could free spacebar for something else important...

@Rawalanche How about doubleclik for entering / exiting edit mode? I have it in my keymap, it is fast and intuitive as an eyeblink and it could free spacebar for something else important...
Contributor

In #54963#500039, @Okavango wrote:
@Rawalanche How about doubleclik for entering / exiting edit mode? I have it in my keymap, it is fast and intuitive as an eyeblink and it could free spacebar for something else important...

I plan to have doubleclick for selecting entire mesh element, similar to mesh element mode found in 3ds Max, since blender does not have any such mesh selection mode, but it has "Select Linked" operation, which I intended to be mapped on double click, in the same way Modo has it. I would argue that double clicking is about equally as quick as pressing spacebar. :)

> In #54963#500039, @Okavango wrote: > @Rawalanche How about doubleclik for entering / exiting edit mode? I have it in my keymap, it is fast and intuitive as an eyeblink and it could free spacebar for something else important... I plan to have doubleclick for selecting entire mesh element, similar to mesh element mode found in 3ds Max, since blender does not have any such mesh selection mode, but it has "Select Linked" operation, which I intended to be mapped on double click, in the same way Modo has it. I would argue that double clicking is about equally as quick as pressing spacebar. :)

Ah, ok. Thanks for the explanation.

Ah, ok. Thanks for the explanation.

Added subscriber: @TimurAriman

Added subscriber: @TimurAriman

I find the proposed alternative Keymap intriguing and clever for the most part but since majority of those which do Sculpting and Texturing tend to use Tablets, It would be nice if that big chunk of users could be taken into consideration too for the Viewport Navigation.

//3D View:
Object mode:
Viewport navigation://

ZBrush has this as its primary keymap;

  • Panning: Alt+Click & drag Background
  • Orbit: Click & drag Background
  • Zoom: Alt+Click, Release Alt, drag Background
  • Center on selection: F

While I agree for the most part with the proposed Keymap, it would be quickly fatiguing and imo counter intuitive for tablet users to have to use alt+MMB and Ctrl+MMB, mouse wheel with a tablet pen.

I find the proposed alternative Keymap intriguing and clever for the most part but since majority of those which do Sculpting and Texturing tend to use Tablets, It would be nice if that big chunk of users could be taken into consideration too for the Viewport Navigation. //3D View: Object mode: Viewport navigation:// ZBrush has this as its primary keymap; - Panning: **Alt+Click & drag Background** - Orbit: **Click & drag Background** - Zoom: **Alt+Click, Release Alt, drag Background** - Center on selection: **F** While I agree for the most part with the proposed Keymap, it would be quickly fatiguing and imo counter intuitive for tablet users to have to use alt+MMB and Ctrl+MMB, mouse wheel with a tablet pen.

I'm sorry if I explained it wrong, but I didn't mean at any point that I understood that this was going to be the default template. In case someone got confused. Even if you personally think that it should be the default template (to make it more visible)

I was just saying that I didn't understand the idea of the spacebar and the tab, when it is something so personal about this program and I didn't think it was necessary, or indicated, to change it because the rest of the programs don't use both keys, there's no reason for such a change and the new users will be better placed.

I'm sorry if I explained it wrong, but I didn't mean at any point that I understood that this was going to be the default template. In case someone got confused. Even if you personally think that it should be the default template (to make it more visible) I was just saying that I didn't understand the idea of the spacebar and the tab, when it is something so personal about this program and I didn't think it was necessary, or indicated, to change it because the rest of the programs don't use both keys, there's no reason for such a change and the new users will be better placed.
Contributor

In #54963#500085, @TimurAriman wrote:
I find the proposed alternative Keymap intriguing and clever for the most part but since majority of those which do Sculpting and Texturing tend to use Tablets, It would be nice if that big chunk of users could be taken into consideration too for the Viewport Navigation.

//3D View:
Object mode:
Viewport navigation://

ZBrush has this as its primary keymap;

  • Panning: Alt+Click & drag Background
  • Orbit: Click & drag Background
  • Zoom: Alt+Click, Release Alt, drag Background
  • Center on selection: F

While I agree for the most part with the proposed Keymap, it would be quickly fatiguing and imo counter intuitive for tablet users to have to use alt+MMB and Ctrl+MMB, mouse wheel with a tablet pen.

I am a bit confused here. For example even Maya requires tablet users to employ MMB. Zbrush model is very specific to sculpting, not necessarily suitable for general 3D software where you interact with many objects inside a single scene. But generally, people tend to find Maya navigation style more universal, so I will probably change that.

By the way not sure if you understood it correctly - on tablet, you would of course not need to touch mouse wheel. Zoom on tablet would be Ctrl+Whatever MMB is mapped to on your pen. Orbit would be Alt+MMB button your pen, and Pan would just MMB button on your pen without holding any additional key.

> In #54963#500085, @TimurAriman wrote: > I find the proposed alternative Keymap intriguing and clever for the most part but since majority of those which do Sculpting and Texturing tend to use Tablets, It would be nice if that big chunk of users could be taken into consideration too for the Viewport Navigation. > > //3D View: > Object mode: > Viewport navigation:// > > ZBrush has this as its primary keymap; > > - Panning: **Alt+Click & drag Background** > - Orbit: **Click & drag Background** > - Zoom: **Alt+Click, Release Alt, drag Background** > - Center on selection: **F** > > While I agree for the most part with the proposed Keymap, it would be quickly fatiguing and imo counter intuitive for tablet users to have to use alt+MMB and Ctrl+MMB, mouse wheel with a tablet pen. I am a bit confused here. For example even Maya requires tablet users to employ MMB. Zbrush model is very specific to sculpting, not necessarily suitable for general 3D software where you interact with many objects inside a single scene. But generally, people tend to find Maya navigation style more universal, so I will probably change that. By the way not sure if you understood it correctly - on tablet, you would of course not need to touch mouse wheel. Zoom on tablet would be Ctrl+Whatever MMB is mapped to on your pen. Orbit would be Alt+MMB button your pen, and Pan would just MMB button on your pen without holding any additional key.

Added subscriber: @LloydAlmeida

Added subscriber: @LloydAlmeida

Standard Selection in most packages

Drag > Selects

After some Objects / Elements are selected .

Shift + Drag > Toggles to the Selection

Alt OR Ctrl + Drag > Subtracts from the selection

This should be consistent every Editor

Standard Selection in most packages Drag > Selects After some Objects / Elements are selected . Shift + Drag > Toggles to the Selection Alt OR Ctrl + Drag > Subtracts from the selection This should be consistent every Editor

In #54963#499959, @Mantasku wrote:
Outliner_keys.png
In most 3D industry applications, animation packages, even in file managers, LMB click and drag on empty area= initiates Marquee/ Border select.
LMB click and drag on active area = Gives user ability to Move selected items by dragging

^^ I think this is extremely important to get an "industry standard feel", especially in 2D spaces like the Node Editor, but also in the 3D view.
Blender should behave accordingly when dragging from over a selection (move it), dragging from empty area (border select), or dragging from a color box (drag copy color value), etc.

> In #54963#499959, @Mantasku wrote: > ![Outliner_keys.png](https://archive.blender.org/developer/F3275947/Outliner_keys.png) > In most 3D industry applications, animation packages, even in file managers, LMB click and drag on **empty area**= initiates Marquee/ Border select. > LMB click and drag on **active area** = Gives user ability to Move selected items by dragging ^^ I think this is extremely important to get an "industry standard feel", especially in 2D spaces like the Node Editor, but also in the 3D view. Blender should behave accordingly when dragging from over a selection (move it), dragging from empty area (border select), or dragging from a color box (drag copy color value), etc.

Duarte: yes, that's very important. It may requite some extra work on the Blender side to get that working, but it's key to make things like the timeline working well with LMB select.

Duarte: yes, that's very important. It may requite some extra work on the Blender side to get that working, but it's key to make things like the timeline working well with LMB select.
Ludvik Koutny was unassigned by William Reynish 2018-05-07 16:47:26 +02:00
William Reynish self-assigned this 2018-05-07 16:47:26 +02:00

Added subscriber: @Rawalanche

Added subscriber: @Rawalanche

Removed subscriber: @AlbertoVelazquez

Removed subscriber: @AlbertoVelazquez

Added subscriber: @ChristianFriedrich

Added subscriber: @ChristianFriedrich

Hi William!

Im a bit curious about how the "Mesh element modes" [F9-F11] won over [1-3].
Sure, there are varying quantities of element modes listed, but the idea should be clear: numerics for "Mesh element modes".
Just a honest mistake?

On a side note: Do you think putting axis-locking [x,y,z] also on [1,2,3] would be an intuitive addition to this keymap? (and/or default keymap?)
Mesh element modes and axis-locking never interfere with each other. afaik.
Thanks, and great work so far William!

Hi William! Im a bit curious about how the "Mesh element modes" [F9-F11] won over [1-3]. Sure, there are varying quantities of element modes listed, but the idea should be clear: numerics for "Mesh element modes". Just a honest mistake? On a side note: Do you think putting [axis-locking ](https://docs.blender.org/manual/en/dev/editors/3dview/object/editing/transform/control/precision/axis_locking.html) [x,y,z] **also** on [1,2,3] would be an intuitive addition to this keymap? (and/or default keymap?) Mesh element modes and axis-locking never interfere with each other. afaik. Thanks, and great work so far William!

In Zbrush due to the many available brushes, the first letter of a Brush is the category ,
since Blender has way fewer brushes shipped with, you could assign the first letter of the Zbrush keystrokes to it and call it a day.

The brush menu is opened via the shortcut B
In 3DCoat the whole Brush menu is opened via the shortcut spacebar and there is a quickmenu available in which you can drag and drop most used brushes onto 1,2,3,4,5,6,7,8,9,0 on the keyboard.

The Blob tool from Blender seems imo to be similar in function with the Inflate tool in ZBrush but maybe someone else with more cross-knowledge needs to chime in here.

Blob tool I-N ??? L-9 ??? ???
Smooth tool shift shift shift ??? ???
Snake Hook tool S-H ??? L-6 ??? ???
Clay tool C-L ??? S-8 ?? ???
In Zbrush due to the many available brushes, the first letter of a Brush is the category , since Blender has way fewer brushes shipped with, you could assign the first letter of the Zbrush keystrokes to it and call it a day. The brush menu is opened via the shortcut B In 3DCoat the whole Brush menu is opened via the shortcut spacebar and there is a quickmenu available in which you can drag and drop most used brushes onto 1,2,3,4,5,6,7,8,9,0 on the keyboard. The Blob tool from Blender seems imo to be similar in function with the Inflate tool in ZBrush but maybe someone else with more cross-knowledge needs to chime in here. | Blob tool | **I**-N | ??? | L-9| ??? | ??? | | -- | -- | -- | -- | -- | -- | | Smooth tool | **shift** | **shift** | **shift** | ??? | ??? | | -- | -- | -- | -- | -- | -- | | Snake Hook tool | **S**-H | ??? | L-6| ??? | ??? | | -- | -- | -- | -- | -- | -- | | Clay tool | **C**-L | ??? | S-8| ?? | ??? | | -- | -- | -- | -- | -- | -- |

Christian: You are right, the number keys are clearly more of a standard, as this spreadsheet demonstrates. We could use:

  • 1 = Object Mode
  • 2 = Vertex Mode
  • 3 = Edge Mode
  • 4 = Face Mode
  • 5 = Sculpt Mode
  • 6 = Vertex Paint Mode
  • 7 = Weight Paint Mode
  • 8 = Texture Paint Mode
  • 9 = Hair Editing Mode

Timur: Thanks, yes, more input needed here for the sculpting & painting apps

Christian: You are right, the number keys are clearly more of a standard, as this spreadsheet demonstrates. We could use: - 1 = Object Mode - 2 = Vertex Mode - 3 = Edge Mode - 4 = Face Mode - 5 = Sculpt Mode - 6 = Vertex Paint Mode - 7 = Weight Paint Mode - 8 = Texture Paint Mode - 9 = Hair Editing Mode Timur: Thanks, yes, more input needed here for the sculpting & painting apps

Added subscriber: @jpthrash

Added subscriber: @jpthrash

I think it would feel more natural to have Object Mode after Face Mode, like so.

1-Vertex
2-Edge
3-Face
4-Object
5-Sculpt
etc.

1,2,3 rests more comfortably above the QWE and follows a similar progression to Modo Vertex to Item mode and 3ds Max Vertex to Element.

I think it would feel more natural to have Object Mode after Face Mode, like so. 1-Vertex 2-Edge 3-Face 4-Object 5-Sculpt etc. 1,2,3 rests more comfortably above the QWE and follows a similar progression to Modo Vertex to Item mode and 3ds Max Vertex to Element.

Added subscriber: @ACap99

Added subscriber: @ACap99

For modo
1-Vertex
2-Edge
3-Face
4-Material (selection by material is very useful for some tasks, It would be cool to have it in Blendet)
5-Objects

Center on selection in modo is not F. It is Shift+A
F - is flip normals.

I primarily use wacom tablet to work in Modo.
And I hope that Blender 2.8 will be a good tool to use with the tablet.
You have correct key mappings for modo in your table.
Alt + LMB - viewport rotation.
Alt + Shift + LMB - pan viewprot.
Alt + Ctrl + LMB(drag sideways horisontally) - zoom.

And I really hope that paint selection will be default to LMB selection, because it is really intuitive to paint your selection with the tablet just clicking and dragging on top of the model.
How it works:

  • while your cursor is over the polygons - left click and drag will activate paint selection tool. You can navigate around the model and shift + click - add to selection, and ctrl + click - subtract from selection.
  • when your cursor is outside the polygons - left click is doing nothing. But, if you activated move/scale/rotate tool - left click will change action center (it will place the gizmo where you clicked - super handy)

In blender 2.79 you have to press C and it is worse, also in 2.79 you can not navigate until you finished the paint selection mode - really annoying and destroying tablet workflow, because you have to click each polygon/edge/verticiex in order to select it.

dragging RMB activates lasso selection(you can change it to rectangle selection in the preferences if you are the mouse user. I prefer lasso, because it is super handy with wacom). This selection affects only visible polygons(facing you) in the shaded mode, and all polygons(even turned bacwards to you) in wireframe mode.
dragging MMB activates same functionality, but now it selects everything, that went under the lasso, regardless of normal direction.

Ctrl + LMB - deny selection
Shift + LMB - add to selection(if you completed first click. On wacom click can be very long, until you complete the stroke)
RMB - single click = context menu.

For modo 1-Vertex 2-Edge 3-Face 4-Material (selection by material is very useful for some tasks, It would be cool to have it in Blendet) 5-Objects Center on selection in modo is not F. It is Shift+A F - is flip normals. I primarily use wacom tablet to work in Modo. And I hope that Blender 2.8 will be a good tool to use with the tablet. You have correct key mappings for modo in your table. Alt + LMB - viewport rotation. Alt + Shift + LMB - pan viewprot. Alt + Ctrl + LMB(drag sideways horisontally) - zoom. And I really hope that paint selection will be default to LMB selection, because it is really intuitive to paint your selection with the tablet just clicking and dragging on top of the model. How it works: - while your cursor is over the polygons - left click and drag will activate paint selection tool. You can navigate around the model and shift + click - add to selection, and ctrl + click - subtract from selection. - when your cursor is outside the polygons - left click is doing nothing. But, if you activated move/scale/rotate tool - left click will change action center (it will place the gizmo where you clicked - super handy) In blender 2.79 you have to press C and it is worse, also in 2.79 you can not navigate until you finished the paint selection mode - really annoying and destroying tablet workflow, because you have to click each polygon/edge/verticiex in order to select it. dragging RMB activates lasso selection(you can change it to rectangle selection in the preferences if you are the mouse user. I prefer lasso, because it is super handy with wacom). This selection affects only visible polygons(facing you) in the shaded mode, and all polygons(even turned bacwards to you) in wireframe mode. dragging MMB activates same functionality, but now it selects everything, that went under the lasso, regardless of normal direction. Ctrl + LMB - deny selection Shift + LMB - add to selection(if you completed first click. On wacom click can be very long, until you complete the stroke) RMB - single click = context menu.

Added subscriber: @irfancelik

Added subscriber: @irfancelik

Hi William,

looking great so far. I wouldn´t mind seeing Blender in that spreadsheet as well ;)
I hope the Outliner and other views will get the same treatment as the 3dview.

Here are a few notes:

All views:

  • drag select in empty space should deselect

Outliner:

  • region select with shift (eg. select 1st item, shift select 10th item should select all items inbetween)
  • MMB to reorder or parent current selection
  • sync selection with 3dview (currently box select or "a" in outliner does not select anything in 3dview)
Hi William, looking great so far. I wouldn´t mind seeing Blender in that spreadsheet as well ;) I hope the Outliner and other views will get the same treatment as the 3dview. Here are a few notes: All views: - drag select in empty space should deselect Outliner: - region select with shift (eg. select 1st item, shift select 10th item should select all items inbetween) - MMB to reorder or parent current selection - sync selection with 3dview (currently box select or "a" in outliner does not select anything in 3dview)

For Texture painting due to its wide usage, the keystrokes of Substance Painter and maybe Mari should be taken too into consideration.
It might be of usage to compare the following things?;

Zbrush Mudbox 3D Coat Modo Mari Substance Painter Winner
Texture Painting
Resize Brush S ??? ctrl+RMB+drag left/right ??? R+any Mouse button ctrl+RMB
Intensity U ??? ??? ??? ??? ctrl+LMB+drag left/right
Paint tool ??? ??? ??? ??? P 1
Eraser Tool ??? ??? ??? ??? E 2
colour picker C ??? V ??? C P
Display next channel ??? ??? ??? ??? ??? C
Display previous channel ??? ??? ??? ??? ??? shift+C
Show Material ??? ??? ??? ??? ??? M
Symmetry X ??? S ??? ??? L
wireview ??? ??? W ??? shift+W ???
Swap foreground and background colors V ??? ??? ??? X L
rotate environment ??? ??? shift +LMB+drag left/right ??? ??? shift+RMB
Set Clone tool source ??? ??? ??? ??? ctrl ctrl+LMB
Stencil rotate ??? ??? ??? ??? ctrl+LMB S+LMB
Stencil snap rotate ??? ??? ??? ??? ??? shift+S+LMB
stencil pan ??? ??? ??? ??? shift+LMB S+MMB
stencil zoom ??? ??? ??? ??? ctrl+shift S+RMB
For Texture painting due to its wide usage, the keystrokes of Substance Painter and maybe Mari should be taken too into consideration. It might be of usage to compare the following things?; || Zbrush | Mudbox | 3D Coat | Modo |Mari | Substance Painter | **Winner**| | -- | -- | -- | -- | -- | -- | -- | -- | |***Texture Painting***| | Resize Brush | S | ??? | ctrl+RMB+drag left/right | ??? | R+any Mouse button | ctrl+RMB | | Intensity | U | ??? | ??? | ??? | ??? | ctrl+LMB+drag left/right | | Paint tool | ??? | ??? | ??? | ??? | P | 1 | | Eraser Tool | ??? | ??? | ??? | ??? | E | 2 | | colour picker | C | ??? | V | ??? | C | P | | Display next channel | ??? | ??? | ??? | ??? | ??? | C | | Display previous channel | ??? | ??? | ??? | ??? | ??? | shift+C | | Show Material | ??? | ??? | ???| ??? | ??? | M | | Symmetry | X | ??? | S | ??? | ??? | L | | wireview | ??? | ??? | W | ??? | shift+W | ??? | | Swap foreground and background colors | V | ??? | ??? | ??? | X | L | | rotate environment | ??? | ??? | shift +LMB+drag left/right | ??? | ??? | shift+RMB | | Set Clone tool source | ??? | ??? | ??? | ??? | ctrl | ctrl+LMB | | Stencil rotate | ??? | ??? | ??? | ??? | ctrl+LMB | S+LMB | | Stencil snap rotate | ??? | ??? | ??? | ??? | ??? | shift+S+LMB | | stencil pan | ??? | ??? | ??? | ??? | shift+LMB | S+MMB | | stencil zoom | ??? | ??? | ??? | ??? | ctrl+shift | S+RMB |

Thanks guys, I've updated the spreadsheet.

Thanks guys, I've updated the spreadsheet.

Added subscriber: @aunpyz

Added subscriber: @aunpyz

As for mudbox shortcut

Mudbox
Resize Brush B+click and drag
Intensity M+click and drag
Blob tool ??
Smooth tool Hold shift or 2(default)
Snake Hook tool *
Clay tool ??

*There's no Snake hook tool in mudbox, but the equivalent is grab tool with follow path enable

note that mudbox's brushes can be accessed via shortcut 1-9 and can the brush can be dragged to any position as you will

As for mudbox shortcut | | Mudbox | | -- | -- | | Resize Brush | B+click and drag| | Intensity| M+click and drag | | Blob tool| ??| | Smooth tool| Hold shift or 2(default)| | Snake Hook tool | *| | Clay tool | ??| *There's no Snake hook tool in mudbox, but the equivalent is grab tool with follow path enable note that mudbox's brushes can be accessed via shortcut 1-9 and can the brush can be dragged to any position as you will

Texture Painting
shift+F is used for wireview in Zbrush.

X is used for Swap foreground and background colors in 3DCoat.

**Texture Painting** shift+F is used for *wireview* in Zbrush. X is used for *Swap foreground and background colors* in 3DCoat.
Contributor

Since people prefer to have mesh element keys not offset by object mode, so that 1 is always vertex, 2 always edge and 3 always face, perhaps ~ (tilde) key could toggle object mode.

Since people prefer to have mesh element keys not offset by object mode, so that 1 is always vertex, 2 always edge and 3 always face, perhaps ~ (tilde) key could toggle object mode.

Perhaps, although not all common keyboard layouts have a tilde key. We could also just flip the order, so 1: Vertex, 2: Edge, 3: Face, 4: Object, 5: Sculpt etc

Perhaps, although not all common keyboard layouts have a tilde key. We could also just flip the order, so 1: Vertex, 2: Edge, 3: Face, 4: Object, 5: Sculpt etc

Added subscriber: @LucianoMunoz

Added subscriber: @LucianoMunoz

Maybe im off the line here,

But I'd try to keep these multiple hotkeys for similar actions under a pie menu (wasnt that the idea of implementing them after all), like one hotkey with the pie menu for cameras (like Q in 2.79), one hotkey with a pie menu for mode (like tab in 2.79), or like pivot point with "." or manipulators with "ctrl+space"

I thought the idea was to keep the standard default keymap to a minimum so you dont need to learn 10 keymaps only to change modes, just one that quickly gets you there.

thanks

Maybe im off the line here, But I'd try to keep these multiple hotkeys for similar actions under a pie menu (wasnt that the idea of implementing them after all), like one hotkey with the pie menu for cameras (like Q in 2.79), one hotkey with a pie menu for mode (like tab in 2.79), or like pivot point with "." or manipulators with "ctrl+space" I thought the idea was to keep the standard default keymap to a minimum so you dont need to learn 10 keymaps only to change modes, just one that quickly gets you there. thanks
Contributor

In #54963#501165, @LucianoMunoz wrote:
Maybe im off the line here,

But I'd try to keep these multiple hotkeys for similar actions under a pie menu (wasnt that the idea of implementing them after all), like one hotkey with the pie menu for cameras (like Q in 2.79), one hotkey with a pie menu for mode (like tab in 2.79), or like pivot point with "." or manipulators with "ctrl+space"

I thought the idea was to keep the standard default keymap to a minimum so you dont need to learn 10 keymaps only to change modes, just one that quickly gets you there.

thanks

Those things that are already in a Pie menu are also in a regular menu in 2.79. I mean it's not like if you disable pie menus in 2.79, then every single action that was in the Q pie will have separate hotkeys. It will just turn into a regular vertical context menu. I agree that pie menus should be utilized a bit more on 2.8, however I do not think that alone would solve the problem you are pointing out.

> In #54963#501165, @LucianoMunoz wrote: > Maybe im off the line here, > > But I'd try to keep these multiple hotkeys for similar actions under a pie menu (wasnt that the idea of implementing them after all), like one hotkey with the pie menu for cameras (like Q in 2.79), one hotkey with a pie menu for mode (like tab in 2.79), or like pivot point with "." or manipulators with "ctrl+space" > > I thought the idea was to keep the standard default keymap to a minimum so you dont need to learn 10 keymaps only to change modes, just one that quickly gets you there. > > thanks Those things that are already in a Pie menu are also in a regular menu in 2.79. I mean it's not like if you disable pie menus in 2.79, then every single action that was in the Q pie will have separate hotkeys. It will just turn into a regular vertical context menu. I agree that pie menus should be utilized a bit more on 2.8, however I do not think that alone would solve the problem you are pointing out.

We want to find a way to enable pie menus by default in Blender 2.8, both in the default keymap and in the industry standard keymap.

The main reason why it hasnt been on by default, is that is disrupts old habits, because you can no longer just hit, say, Tab to go to Edit Mode, because it now spawns a pie menu with all the modes. While that is mostly superior, because it allows you to quickly jump to any mode, we want to make it so that we can detect the difference between a tap and a hold+drag. This way the tab key can work as it did, but holding it will spawn a pie menu instead. This will require some testing and fine tuning to make sure both are equally fast, otherwise it defeats the purpose.

We want to find a way to enable pie menus by default in Blender 2.8, both in the default keymap and in the industry standard keymap. The main reason why it hasnt been on by default, is that is disrupts old habits, because you can no longer just hit, say, Tab to go to Edit Mode, because it now spawns a pie menu with all the modes. While that is mostly superior, because it allows you to quickly jump to any mode, we want to make it so that we can detect the difference between a tap and a hold+drag. This way the tab key can work as it did, but holding it will spawn a pie menu instead. This will require some testing and fine tuning to make sure both are equally fast, otherwise it defeats the purpose.

Yes, that sounds great, tapping could just bring you from the last mode used back to object mode (having edit mode be the default one to go to when you just started a session), and holding will get you the pie so you can quickly choose the one you want... this would work with very many tools if not all of them.

A lot of menus would benefit from being converted to pies, and the ones that are too long either should be split into 2 pie menus or nested ones, like W for specials is probably overcrowded in some cases.

Also a bit off topic-ish the Grease Pencil Pie menus should be definitely standarized and improved, they're a bit of all over the place.

Yes, that sounds great, tapping could just bring you from the last mode used back to object mode (having edit mode be the default one to go to when you just started a session), and holding will get you the pie so you can quickly choose the one you want... this would work with very many tools if not all of them. A lot of menus would benefit from being converted to pies, and the ones that are too long either should be split into 2 pie menus or nested ones, like W for specials is probably overcrowded in some cases. Also a bit off topic-ish the Grease Pencil Pie menus should be definitely standarized and improved, they're a bit of all over the place.

Added subscriber: @cedriclepiller

Added subscriber: @cedriclepiller

On my pie menus, I added the components to go directly on the component I want and not having to first go in edit mode and then choose the component.
It's would be better if blender does this as default.
There is no reason to make 2 actions when one is just fine.

I say that because you will make pie menus as default.
The last pie menus are from my own pie menus, but the dev removed this part sadly.
blender defaults_components.gif

On my pie menus, I added the components to go directly on the component I want and not having to first go in edit mode and then choose the component. It's would be better if blender does this as default. There is no reason to make 2 actions when one is just fine. I say that because you will make pie menus as default. The last pie menus are from my own pie menus, but the dev removed this part sadly. ![blender defaults_components.gif](https://archive.blender.org/developer/F3311108/blender_defaults_components.gif)
Contributor

In #54963#501261, @WilliamReynish wrote:
We want to find a way to enable pie menus by default in Blender 2.8, both in the default keymap and in the industry standard keymap.

The main reason why it hasnt been on by default, is that is disrupts old habits, because you can no longer just hit, say, Tab to go to Edit Mode, because it now spawns a pie menu with all the modes. While that is mostly superior, because it allows you to quickly jump to any mode, we want to make it so that we can detect the difference between a tap and a hold+drag. This way the tab key can work as it did, but holding it will spawn a pie menu instead. This will require some testing and fine tuning to make sure both are equally fast, otherwise it defeats the purpose.

I had the exact same idea! :) Just for the modeling tools.

For example there are currently different modes for Bevel, Extrude and Knife tool.

So let's say you have Bevel for example on a B key, then if you just tap B key, it will activate bevel tool, while if you hold down B key, it will open a pie menu where you can choose between bevel faces and bevel vertices.

Same would work great for extrude. Hit extrude hotkey, and you are in extrude mode. Hold down extrude hotkey, and a Pie menu will pop up, containing options to Extrude, Extrude individual and Extrude Region.

All it requires is for Blender to have a concept of "Central" pie menu operation, which triggers primary action when you just tap a key without holding it and moving the mouse.

> In #54963#501261, @WilliamReynish wrote: > We want to find a way to enable pie menus by default in Blender 2.8, both in the default keymap and in the industry standard keymap. > > The main reason why it hasnt been on by default, is that is disrupts old habits, because you can no longer just hit, say, Tab to go to Edit Mode, because it now spawns a pie menu with all the modes. While that is mostly superior, because it allows you to quickly jump to any mode, we want to make it so that we can detect the difference between a tap and a hold+drag. This way the tab key can work as it did, but holding it will spawn a pie menu instead. This will require some testing and fine tuning to make sure both are equally fast, otherwise it defeats the purpose. I had the exact same idea! :) Just for the modeling tools. For example there are currently different modes for Bevel, Extrude and Knife tool. So let's say you have Bevel for example on a B key, then if you just tap B key, it will activate bevel tool, while if you hold down B key, it will open a pie menu where you can choose between bevel faces and bevel vertices. Same would work great for extrude. Hit extrude hotkey, and you are in extrude mode. Hold down extrude hotkey, and a Pie menu will pop up, containing options to Extrude, Extrude individual and Extrude Region. All it requires is for Blender to have a concept of "Central" pie menu operation, which triggers primary action when you just tap a key without holding it and moving the mouse.
Added subscribers: @Jonathan-11, @william-70, @michaelknubben

Since the topic was ended elsewhere, I'll ask again here:
@william-70 Reynish (billreynish) It was my understanding that @Paweł Łyczkowski (plyczkowski) and @Jonathan-11 Williamson (carter2422) were in charge of the new Keymap? Has something changed?
Additionally, I now read here that it won't be the default, whereas I remember it previously being the intention of making a new default, and having 'old blender' as an optional keymap.

Since the topic was ended elsewhere, I'll ask again here: @william-70 Reynish (billreynish) It was my understanding that @Paweł Łyczkowski (plyczkowski) and @Jonathan-11 Williamson (carter2422) were in charge of the new Keymap? Has something changed? Additionally, I now read here that it won't be the default, whereas I remember it previously being the intention of making a new default, and having 'old blender' as an optional keymap.

In #54963#500023, @Rawalanche wrote:
I agree that consistency is good, but I am not sure there are that many users associating deselection key with modifier key for inverse of the action. My reasoning for this is that Shift key is very commonly used for addition to selection, not only in CG software, but in common mainstream software.

I agree Shift us commonly used to add to selection, even if default file managers like Windows Explorer.
But the main point I wish to convey with my comment is consistency; whichever you opt for (they can always be customized later anyway, right?), the important thing is consistency.
If you go with Shift to add to selection, and Ctrl to remove, just make it so it works similarly across all selection modes, be it Regular Click-Select, Border Select, Circle Select, Lasso, or any others, use the same modifier keys consistently across all selection modes for a predictable behavior.

> In #54963#500023, @Rawalanche wrote: > I agree that consistency is good, but I am not sure there are that many users associating deselection key with modifier key for inverse of the action. My reasoning for this is that Shift key is very commonly used for addition to selection, not only in CG software, but in common mainstream software. I agree Shift us commonly used to add to selection, even if default file managers like Windows Explorer. But the main point I wish to convey with my comment is **consistency**; whichever you opt for (they can always be customized later anyway, right?), the important thing is consistency. If you go with Shift to add to selection, and Ctrl to remove, just make it so it works similarly across all selection modes, be it Regular Click-Select, Border Select, Circle Select, Lasso, or any others, use the same modifier keys consistently across all selection modes for a predictable behavior.

just to correct set key in maya is S not i

just to correct set key in maya is S not i

Added subscriber: @Klutz

Added subscriber: @Klutz

For the Search/Quick Find function, I suggest the F1 key. As per today, it's being used in a non-standard way (Open File) by Blender (as so many other shortcuts), but this suggestion might actually keep the door open for implementing a "real" help system.

Initially, by pressing F1 you'd open the dialog that's now bound to the space bar. Later on, however, one might want to implement a new choice in that box so that you can choose between executing the command and opening a help function.

Implementation: Press F1, type Flip Normals into the text box, . Just as today the selected faces will ble flipped.

Possible future implementation: Press F1, type Flip Normals into the text box, . The selected faces will ble flipped.
But now, the dialog also gives you a second option: Instead of pressing you can press F1 (or another assigned key) again and open up the help context.

For the Search/Quick Find function, I suggest the F1 key. As per today, it's being used in a non-standard way *(Open File)* by Blender (as so many other shortcuts), but this suggestion might actually keep the door open for implementing a "real" help system. Initially, by pressing F1 you'd open the dialog that's now bound to the space bar. Later on, however, one might want to implement a new choice in that box so that you can choose between executing the command and opening a help function. **Implementation:** Press F1, type *Flip Normals* into the text box, <Enter>. Just as today the selected faces will ble flipped. **Possible future implementation:** Press F1, type *Flip Normals* into the text box, <Enter>. The selected faces will ble flipped. But now, the dialog also gives you a second option: Instead of pressing <Enter> you can press F1 (or another assigned key) again and open up the help context.
Contributor

In #54963#503609, @Klutz wrote:
For the Search/Quick Find function, I suggest the F1 key. As per today, it's being used in a non-standard way (Open File) by Blender (as so many other shortcuts), but this suggestion might actually keep the door open for implementing a "real" help system.

Initially, by pressing F1 you'd open the dialog that's now bound to the space bar. Later on, however, one might want to implement a new choice in that box so that you can choose between executing the command and opening a help function.

Implementation: Press F1, type Flip Normals into the text box, . Just as today the selected faces will ble flipped.

Possible future implementation: Press F1, type Flip Normals into the text box, . The selected faces will ble flipped.
But now, the dialog also gives you a second option: Instead of pressing you can press F1 (or another assigned key) again and open up the help context.

F1 key is occupied by opening help/manual in pretty much every single piece of software. Since this keymap should align with the industry standards, this probably won't go through.

> In #54963#503609, @Klutz wrote: > For the Search/Quick Find function, I suggest the F1 key. As per today, it's being used in a non-standard way *(Open File)* by Blender (as so many other shortcuts), but this suggestion might actually keep the door open for implementing a "real" help system. > > Initially, by pressing F1 you'd open the dialog that's now bound to the space bar. Later on, however, one might want to implement a new choice in that box so that you can choose between executing the command and opening a help function. > > **Implementation:** Press F1, type *Flip Normals* into the text box, <Enter>. Just as today the selected faces will ble flipped. > > **Possible future implementation:** Press F1, type *Flip Normals* into the text box, <Enter>. The selected faces will ble flipped. > But now, the dialog also gives you a second option: Instead of pressing <Enter> you can press F1 (or another assigned key) again and open up the help context. F1 key is occupied by opening help/manual in pretty much every single piece of software. Since this keymap should align with the industry standards, this probably won't go through.

If you read my proposal carefully, you'll see that I am suggesting that F1 be used for invoking help. There is nothing barring any software from extending its help functionality, as would be the case here.

Today Blender has no functional help system at all, but once one is implemented, there is nothing barring it from being combined with the actual commands that help system describes.

If you read my proposal carefully, you'll see that *I am* suggesting that F1 be used for invoking help. There is nothing barring any software from extending its help functionality, as would be the case here. Today Blender has no functional help system at all, but once one is implemented, there is nothing barring it from being combined with the actual commands that help system describes.

We currently have the Blender Reference Manual, which is essentially a 'Help' system. For the time being, we could make F1 open that. Further down the road, we could improve our Help functionality in multiple ways. For now, our focus is on 2.8 itself, and less on documentation & help systems. Once we have a strong foundation, and as we get closer to release, I expect we will begin to focus more on those things. We have several ideas and plans here, which we would like to share at some point.

We currently have the Blender Reference Manual, which is essentially a 'Help' system. For the time being, we could make F1 open that. Further down the road, we could improve our Help functionality in multiple ways. For now, our focus is on 2.8 itself, and less on documentation & help systems. Once we have a strong foundation, and as we get closer to release, I expect we will begin to focus more on those things. We have several ideas and plans here, which we would like to share at some point.

Added subscriber: @0o00o0oo

Added subscriber: @0o00o0oo

Just want to say this is a really smart move. Also, the decision to integrate pie menu to be default in Blender in general is very welcome, too.

Two questions:

  1. Any plans for loop select? I only used a fairly new version of Maya for a short time at a studio, but I remember their double-clicking to loop select feeling so intuitive.
  2. Will this effort to make industry keymap configurations work also resolve currently non-configurable hotkeys such as axis, trackball rotate, and edge slide? (As mentioned in the comments for #37520 but ignored)
Just want to say this is a really smart move. Also, the decision to integrate pie menu to be default in Blender in general is very welcome, too. Two questions: 1. Any plans for loop select? I only used a fairly new version of Maya for a short time at a studio, but I remember their double-clicking to loop select feeling so intuitive. 2. Will this effort to make industry keymap configurations work also resolve currently non-configurable hotkeys such as axis, trackball rotate, and edge slide? (As mentioned in the comments for #37520 but ignored)

Added subscriber: @ChristopherAnderssarian

Added subscriber: @ChristopherAnderssarian

Added subscriber: @VukGardasevic

Added subscriber: @VukGardasevic

In #54963#501261, @WilliamReynish wrote:
We want to find a way to enable pie menus by default in Blender 2.8, both in the default keymap and in the industry standard keymap.

The main reason why it hasnt been on by default, is that is disrupts old habits, because you can no longer just hit, say, Tab to go to Edit Mode, because it now spawns a pie menu with all the modes. While that is mostly superior, because it allows you to quickly jump to any mode, we want to make it so that we can detect the difference between a tap and a hold+drag. This way the tab key can work as it did, but holding it will spawn a pie menu instead. This will require some testing and fine tuning to make sure both are equally fast, otherwise it defeats the purpose.

As a way of thinking, an official python module API function could be made to enable / disable components /modules of add-ons. Currently the individual activation is used for a few add-ons like the pie menus and advanced objects, but that requires a lot of changes / refactors in each add-on. The code can be probably made more robust and available for all add-ons - usually the collection / complex types. That way the user can easily target which part of the add-on is taking up a shortcut and mix and match behaviors.

> In #54963#501261, @WilliamReynish wrote: > We want to find a way to enable pie menus by default in Blender 2.8, both in the default keymap and in the industry standard keymap. > > The main reason why it hasnt been on by default, is that is disrupts old habits, because you can no longer just hit, say, Tab to go to Edit Mode, because it now spawns a pie menu with all the modes. While that is mostly superior, because it allows you to quickly jump to any mode, we want to make it so that we can detect the difference between a tap and a hold+drag. This way the tab key can work as it did, but holding it will spawn a pie menu instead. This will require some testing and fine tuning to make sure both are equally fast, otherwise it defeats the purpose. As a way of thinking, an official python module API function could be made to enable / disable components /modules of add-ons. Currently the individual activation is used for a few add-ons like the pie menus and advanced objects, but that requires a lot of changes / refactors in each add-on. The code can be probably made more robust and available for all add-ons - usually the collection / complex types. That way the user can easily target which part of the add-on is taking up a shortcut and mix and match behaviors.

Added subscriber: @sus_unn2

Added subscriber: @sus_unn2

Blender can include online help pages in package to see it offline. By doing that users will read the manual no matter what condition.

Blender can include online help pages in package to see it offline. By doing that users will read the manual no matter what condition.

Added subscriber: @AnadinX

Added subscriber: @AnadinX

In #54963#503955, @0o00o0oo wrote:
Just want to say this is a really smart move. Also, the decision to integrate pie menu to be default in Blender in general is very welcome, too.

Two questions:

  1. Any plans for loop select? I only used a fairly new version of Maya for a short time at a studio, but I remember their double-clicking to loop select feeling so intuitive.
  2. Will this effort to make industry keymap configurations work also resolve currently non-configurable hotkeys such as axis, trackball rotate, and edge slide? (As mentioned in the comments for #37520 but ignored)

Double click for loop select definitely.

> In #54963#503955, @0o00o0oo wrote: > Just want to say this is a really smart move. Also, the decision to integrate pie menu to be default in Blender in general is very welcome, too. > > Two questions: > 1. Any plans for loop select? I only used a fairly new version of Maya for a short time at a studio, but I remember their double-clicking to loop select feeling so intuitive. > 2. Will this effort to make industry keymap configurations work also resolve currently non-configurable hotkeys such as axis, trackball rotate, and edge slide? (As mentioned in the comments for #37520 but ignored) Double click for loop select definitely.

Added subscriber: @TheRedWaxPolice

Added subscriber: @TheRedWaxPolice

In #54963#504054, @AnadinX wrote:

In #54963#503955, @0o00o0oo wrote:
Just want to say this is a really smart move. Also, the decision to integrate pie menu to be default in Blender in general is very welcome, too.

Two questions:

  1. Any plans for loop select? I only used a fairly new version of Maya for a short time at a studio, but I remember their double-clicking to loop select feeling so intuitive.
  2. Will this effort to make industry keymap configurations work also resolve currently non-configurable hotkeys such as axis, trackball rotate, and edge slide? (As mentioned in the comments for #37520 but ignored)

Double click for loop select definitely.

Definitely. Double click for loop select is very fast and intuitive, also other 3d apps use it too.

> In #54963#504054, @AnadinX wrote: >> In #54963#503955, @0o00o0oo wrote: >> Just want to say this is a really smart move. Also, the decision to integrate pie menu to be default in Blender in general is very welcome, too. >> >> Two questions: >> 1. Any plans for loop select? I only used a fairly new version of Maya for a short time at a studio, but I remember their double-clicking to loop select feeling so intuitive. >> 2. Will this effort to make industry keymap configurations work also resolve currently non-configurable hotkeys such as axis, trackball rotate, and edge slide? (As mentioned in the comments for #37520 but ignored) > > Double click for loop select definitely. Definitely. Double click for loop select is very fast and intuitive, also other 3d apps use it too.

If i can put some of my experience (and long time grief) to use here - LMB (or selection mouse button) to empty space - deselect all.

If i can put some of my experience (and long time grief) to use here - LMB (or selection mouse button) to empty space - deselect all.

Double-click to loop select, and click in empty space to deselect both seem reasonable and standard enough to include here.

Double-click to loop select, and click in empty space to deselect both seem reasonable and standard enough to include here.

Added subscriber: @JulianPerez

Added subscriber: @JulianPerez

I can't seem to find a proposal for RMB context menus.
It's pretty standard on most 3D apps to right click to open context-sensitive menus, depending on where you click, what mode you're in, what you have selected etc.
For example, if I'm in edit mode with a face selected, the RMB would bring me the mesh tools menu for faces, same for vertices/edges etc. Same behavior when in other modes like object/sculpt etc too.
I think it would be a great addition to this list. Besides, it's very intuitive imo.
Thanks.

I can't seem to find a **proposal for RMB context menus**. It's pretty standard on most 3D apps to right click to open context-sensitive menus, depending on where you click, what mode you're in, what you have selected etc. For example, if I'm in edit mode with a face selected, the RMB would bring me the mesh tools menu for faces, same for vertices/edges etc. Same behavior when in other modes like object/sculpt etc too. I think it would be a great addition to this list. Besides, it's very intuitive imo. Thanks.

For sculpting and texture painting (and even vertex painting), I'd go with a pie menu and the same hotkey for all, it could be B for Brush or S for Size and/or Strenght. Hitting said key should open a pie menu that contains the most common operations for the current mode, like brush selection, brush settings, color picker, switch dyntopo on/off (for sculpting), etc.

This would make it easier to change if a user wants to use another hotkey (instead of modifying an individual hotkey for every single tool) and it would keep all the modes that uses brushes consistent between each other. A piemenu for the most commonly used operations and tools for sculpting and/or painting makes it also much easier to work on full screen without the need to open toolbars, tabs, or menus

The current RMB pie menu by pitiwazou is the closest I've seen with such functionality.
Sculpt_PieMenu.jpg

Additionally, as some have mentioned already, the ability to easily map the number keys to the most used brushes is very handy.

For sculpting and texture painting (and even vertex painting), I'd go with a pie menu and the same hotkey for all, it could be B for Brush or S for Size and/or Strenght. Hitting said key should open a pie menu that contains the most common operations for the current mode, like brush selection, brush settings, color picker, switch dyntopo on/off (for sculpting), etc. This would make it easier to change if a user wants to use another hotkey (instead of modifying an individual hotkey for every single tool) and it would keep all the modes that uses brushes consistent between each other. A piemenu for the most commonly used operations and tools for sculpting and/or painting makes it also much easier to work on full screen without the need to open toolbars, tabs, or menus The current RMB pie menu by pitiwazou is the closest I've seen with such functionality. ![Sculpt_PieMenu.jpg](https://archive.blender.org/developer/F3419332/Sculpt_PieMenu.jpg) Additionally, as some have mentioned already, the ability to easily map the number keys to the most used brushes is very handy.

Yes, I think something like that is a good idea. I thought of this kind of thing already, but haven't added it yet to our design docs. It would be real useful to have a consistent way to access common tool settings this way, across all our modes and editors.

I didn't think of combining the active tool switcher with the tool settings like the pitiwazou pie menu. The issue with that is that it gets quite slow, because you have to first click the tool icon and then pick from a menu of available tools. At that point it is actually slower than simply using the toolbar, which negates most of the point. A shortcut pie menu like that wants to be as quick as possible.

We'll probably split it up in two: One quick menu for switching tools and another for quickly setting tool settings.

Yes, I think something like that is a good idea. I thought of this kind of thing already, but haven't added it yet to our design docs. It would be real useful to have a consistent way to access common tool settings this way, across all our modes and editors. I didn't think of combining the active tool switcher with the tool settings like the pitiwazou pie menu. The issue with that is that it gets quite slow, because you have to first click the tool icon and then pick from a menu of available tools. At that point it is actually slower than simply using the toolbar, which negates most of the point. A shortcut pie menu like that wants to be as quick as possible. We'll probably split it up in two: One quick menu for switching tools and another for quickly setting tool settings.

Sounds good! But even if there's one more click it still helps when on full screen mode, because you don't have to open (and move to) the toolbar, everything happens at the cursor location. Also, would it be possible to see the list of the brushes without clicking on the thumbnail first...?

Sounds good! But even if there's one more click it still helps when on full screen mode, because you don't have to open (and move to) the toolbar, everything happens at the cursor location. Also, would it be possible to see the list of the brushes without clicking on the thumbnail first...?

In general I found pie menus slower to work than the regular menus, due to the extra precision to click (cuz the circular nature of it), and the usual nested submenus. I'd prefer to switch tools using the regular context menus.

In general I found pie menus slower to work than the regular menus, due to the extra precision to click (cuz the circular nature of it), and the usual nested submenus. I'd prefer to switch tools using the regular context menus.

Julian: In Blender 2.8 you can already switch tools in a popup menu by pressing the space bar. If you prefer to work full screen with a hidden toolbar, you can use this method to switch tools. It works in any mode, with all the active tools.

Julian: In Blender 2.8 you can already switch tools in a popup menu by pressing the space bar. If you prefer to work full screen with a hidden toolbar, you can use this method to switch tools. It works in any mode, with all the active tools.

Haven't tried any recent 2.8 builds but that's great! Thank you William :)

Haven't tried any recent 2.8 builds but that's great! Thank you William :)

I don't know if you need info to fill those fields with the question marks (???), so in Cinema 4D the loop select and deselect are the same as Maya. Double-click edge to loop select, and click in empty space to deselect.

I don't know if you need info to fill those fields with the question marks (???), so in Cinema 4D the loop select and deselect are the same as Maya. Double-click edge to loop select, and click in empty space to deselect.
Contributor

In #54963#504116, @WilliamReynish wrote:
Julian: In Blender 2.8 you can already switch tools in a popup menu by pressing the space bar. If you prefer to work full screen with a hidden toolbar, you can use this method to switch tools. It works in any mode, with all the active tools.

Won't this interfere with Space being chosen for Viewport switching in this keymap? Or will tools pop up become the context menu (RMB?)

> In #54963#504116, @WilliamReynish wrote: > Julian: In Blender 2.8 you can already switch tools in a popup menu by pressing the space bar. If you prefer to work full screen with a hidden toolbar, you can use this method to switch tools. It works in any mode, with all the active tools. Won't this interfere with Space being chosen for Viewport switching in this keymap? Or will tools pop up become *the* context menu (RMB?)

Ludvik: Yes. This discussion got mixed in confusing ways with general features for switching tools. In the default Blender keymap, the space bar is uses for switching tools. In this Industry Standard keymap, I don't expect it to work like that, and for most tools it's not necessary, because users can simply use the shortcuts directly to switch active tools.

For this Industry Standard keymap, we should properly define how the right-click menus should work, and how the space-bar feature should work. We should analyze what all the apps do here to determine the most standard approach. Help in this area is much appreciated.

Ludvik: Yes. This discussion got mixed in confusing ways with general features for switching tools. In the default Blender keymap, the space bar is uses for switching tools. In this Industry Standard keymap, I don't expect it to work like that, and for most tools it's not necessary, because users can simply use the shortcuts directly to switch active tools. For this Industry Standard keymap, we should properly define how the right-click menus should work, and how the space-bar feature should work. We should analyze what all the apps do here to determine the most standard approach. Help in this area is much appreciated.

@WilliamReynish In Maya, the spacebar, aside from toggling the quad view, it also shows a layout of menu items while held down:

image.png
I never liked the way this looks. Also, the way it functions, I don't remember it being particularly useful, but if we could do a kind of general pie-menu like functionality, that could be really cool.

One example of a really useful layout is that of all the editors so the user can quickly change the current view to that editor. Add to that a way to make the editor popout as a separate floating window.

An example of how this could be made intuitive:

  1. The editors pie-menu appears when spacebar is held down.
  2. If the user:
  • Doesn't move the mouse and lets go, it toggles the quad view.
  • Moves the mouse over an editor name and lets go, it changes the current view to that editor.
  • Moves the mouse over an editor name and clicks on it, it brings up a floating window of that editor.

As a side note, I really hope creating an industry standard keymap also prompts some development effort to making sure every key is customizable (such as the axis, trackball rotation, and edge slide).

@WilliamReynish In Maya, the spacebar, aside from toggling the quad view, it also shows a layout of menu items while held down: ![image.png](https://archive.blender.org/developer/F3432322/image.png) I never liked the way this looks. Also, the way it functions, I don't remember it being particularly useful, but if we could do a kind of general pie-menu like functionality, that could be really cool. One example of a really useful layout is that of all the editors so the user can quickly change the current view to that editor. Add to that a way to make the editor popout as a separate floating window. An example of how this could be made intuitive: 1. The editors pie-menu appears when spacebar is held down. 2. If the user: - Doesn't move the mouse and lets go, it toggles the quad view. - Moves the mouse over an editor name and lets go, it changes the current view to that editor. - Moves the mouse over an editor name and clicks on it, it brings up a floating window of that editor. As a side note, I really hope creating an industry standard keymap also prompts some development effort to making sure every key is customizable (such as the axis, trackball rotation, and edge slide).
Contributor

In #54963#504272, @WilliamReynish wrote:
Ludvik: Yes. This discussion got mixed in confusing ways with general features for switching tools. In the default Blender keymap, the space bar is uses for switching tools. In this Industry Standard keymap, I don't expect it to work like that, and for most tools it's not necessary, because users can simply use the shortcuts directly to switch active tools.

For this Industry Standard keymap, we should properly define how the right-click menus should work, and how the space-bar feature should work. We should analyze what all the apps do here to determine the most standard approach. Help in this area is much appreciated.

Well, right click, in majority of 3D apps opens some context based menu. And a new 2.8 toolbar seems to be closest thing to context based menu Blender ever had. This could actually make a perfect sense, to have that floating version of the toolbar pop up at RMB click. It just would need to be a bit smaller, right now it's giant :)

> In #54963#504272, @WilliamReynish wrote: > Ludvik: Yes. This discussion got mixed in confusing ways with general features for switching tools. In the default Blender keymap, the space bar is uses for switching tools. In this Industry Standard keymap, I don't expect it to work like that, and for most tools it's not necessary, because users can simply use the shortcuts directly to switch active tools. > > For this Industry Standard keymap, we should properly define how the right-click menus should work, and how the space-bar feature should work. We should analyze what all the apps do here to determine the most standard approach. Help in this area is much appreciated. Well, right click, in majority of 3D apps opens some context based menu. And a new 2.8 toolbar seems to be closest thing to context based menu Blender ever had. This could actually make a perfect sense, to have that floating version of the toolbar pop up at RMB click. It just would need to be a bit smaller, right now it's giant :)

That could be something we could do for the right-click menu, but it’s also rather redundant. There’s already a toolbar and tool shortcuts, so there are multitudes of ways to switch active tools. Instead, I think we could do something more context sensitive. Just like right-clicking on properties brings up relevant context-sensitive options, we could do the same everywhere.

In the 3D View, right-clicking could bring up a context sensitive list of useful commands. For example, if you have an edge selected, right-clicking could bring up a menu with options to subdivide, mark or clear seams, etc. if a face is selected, you could get options to shade flat or smooth, and so on.

This kind of concept is something I’d like to work on fleshing out for this keymap.

That could be something we could do for the right-click menu, but it’s also rather redundant. There’s already a toolbar and tool shortcuts, so there are multitudes of ways to switch active tools. Instead, I think we could do something more context sensitive. Just like right-clicking on properties brings up relevant context-sensitive options, we could do the same everywhere. In the 3D View, right-clicking could bring up a context sensitive list of useful commands. For example, if you have an edge selected, right-clicking could bring up a menu with options to subdivide, mark or clear seams, etc. if a face is selected, you could get options to shade flat or smooth, and so on. This kind of concept is something I’d like to work on fleshing out for this keymap.

I agree. Context-sensitive right-click menus I think should be a given for industry standard keymap.

My example was a possible way to emulate what Maya does with the spacebar but in a more useful fashion specifically for Blender. I suggested different editors because I've yet to memorize the hotkeys for them, haha.

Another side question: Would an easy way to build pie menus be looked into for 2.8?
If pie menus become a default feature, the next logical thing in my mind is for a user to easily customize them.

I agree. Context-sensitive right-click menus I think should be a given for industry standard keymap. My example was a possible way to emulate what Maya does with the spacebar but in a more useful fashion specifically for Blender. I suggested different editors because I've yet to memorize the hotkeys for them, haha. Another side question: Would an easy way to build pie menus be looked into for 2.8? If pie menus become a default feature, the next logical thing in my mind is for a user to easily customize them.

I believe the space bar, being such a prominent and easy to reach key in most keyboards, should be reserved for something really important and frequently used.
Quite frankly I wouldn't mind at all if it was kept as the current search menu, it is an easy way to reach most operators not immediately available in the UI.

One other possibility would be some sort of tool switching, or tool properties shortcut, along the lines of the current Redo Last operator popup.
The reasoning being that it would be a quick way to access settings for the current tool while full screen, or directly over the 3D view near the content they pertain to, considerably reducing mouse travel distance.

A context menu for right click would definitely be welcome, though I understand it may well be out of scope here. In my current custom keymap I have it set for the Redo Last pop up, because it is a very convenient way to change tool settings without constantly having to go to the tool shelf and searching/scrolling/expanding the tiny operator pop up.

I believe the space bar, being such a prominent and easy to reach key in most keyboards, should be reserved for something really important and frequently used. Quite frankly I wouldn't mind at all if it was kept as the current search menu, it is an easy way to reach most operators not immediately available in the UI. One other possibility would be some sort of tool switching, or tool properties shortcut, along the lines of the current *Redo Last* operator popup. The reasoning being that it would be a quick way to access settings for the current tool while full screen, or directly over the 3D view near the content they pertain to, considerably reducing mouse travel distance. A context menu for right click would definitely be welcome, though I understand it may well be out of scope here. In my current custom keymap I have it set for the *Redo Last* pop up, because it is a very convenient way to change tool settings without constantly having to go to the tool shelf and searching/scrolling/expanding the tiny operator pop up.

Context-sensitive menus for right-click is not out of scope - it's exactly the kind of thing we want to enable with this keymap.

Context-sensitive menus for right-click is not out of scope - it's exactly the kind of thing we want to enable with this keymap.
Contributor

In #54963#504594, @WilliamReynish wrote:
Context-sensitive menus for right-click is not out of scope - it's exactly the kind of thing we want to enable with this keymap.

I am just not sure if it's a good idea to have a whole set of menus specific to just one version of they keymap. It would make more sense to utilize it globally, with all the keymaps.

> In #54963#504594, @WilliamReynish wrote: > Context-sensitive menus for right-click is not out of scope - it's exactly the kind of thing we want to enable with this keymap. I am just not sure if it's a good idea to have a whole set of menus specific to just one version of they keymap. It would make more sense to utilize it globally, with all the keymaps.

@Rawalanche It looks like context-sensitive menu is being developed as a whole anyways for 2.8 according to #55162.

@WilliamReynish Is the plan with pie menus to be accurate to Maya's implementation?

Maya combines context-sensitive menu with pie menus when right-clicked. #1 usage for me was changing edit mode because it's so fast. Quick example of how it works if needed: https://youtu.be/51t9b8ndttA?t=177

A typical order of operation when changing edit mode is to:

  1. Right-click hold on an object without needing to enter "Edit Mode" first
  2. Drag in a direction (e.g. up)
  3. Then let go (e.g. enable edge edit mode).

If nothing else, I think edit mode pie menus should be implemented like Maya's because 1) it's such a standard, 2) it's a very efficient/intuitive workflow. This will require at least 4 behavioral changes from current pie menus:

  1. Context-sensitivity based on what's under the mouse.
  2. Enabled by right-clicking instead of a hotkey.
  3. Ability to enter edit mode and engage specific edit mode in one go.
  4. Context-sensitive menu built to show as the bottom pie menu item.
@Rawalanche It looks like context-sensitive menu is being developed as a whole anyways for 2.8 according to #55162. @WilliamReynish Is the plan with pie menus to be accurate to Maya's implementation? Maya combines context-sensitive menu with pie menus when right-clicked. #1 usage for me was changing edit mode because it's so fast. Quick example of how it works if needed: https://youtu.be/51t9b8ndttA?t=177 A typical order of operation when changing edit mode is to: 1. Right-click hold on an object *without needing to enter "Edit Mode" first* 2. Drag in a direction (e.g. up) 3. Then let go (e.g. enable edge edit mode). If nothing else, I think edit mode pie menus should be implemented like Maya's because 1) it's such a standard, 2) it's a very efficient/intuitive workflow. This will require at least 4 behavioral changes from current pie menus: 1. Context-sensitivity based on what's under the mouse. 2. Enabled by right-clicking instead of a hotkey. 3. Ability to enter edit mode and engage specific edit mode in one go. 4. Context-sensitive menu built to show as the bottom pie menu item.
Contributor

In #54963#505360, @0o00o0oo wrote:
@Rawalanche It looks like context-sensitive menu is being developed as a whole anyways for 2.8 according to #55162.

Yes, that's is very nice :)

> In #54963#505360, @0o00o0oo wrote: > @Rawalanche It looks like context-sensitive menu is being developed as a whole anyways for 2.8 according to #55162. Yes, that's is very nice :)

Added subscriber: @zebus3dream

Added subscriber: @zebus3dream

How about the "o" overlay key to hide and unhide the overlays?, and the "p" key could be used for proportional editing. The "o" key is used in nuke just for that purpose too. To insert keyframes it is better to use the "k" key and thus be able to use the "s" key for separate objects in edit mode. It seems much more logical to me that way, bearing in mind that the scaling key is now the'r' key.

How about the "o" overlay key to hide and unhide the overlays?, and the "p" key could be used for proportional editing. The "o" key is used in nuke just for that purpose too. To insert keyframes it is better to use the "k" key and thus be able to use the "s" key for separate objects in edit mode. It seems much more logical to me that way, bearing in mind that the scaling key is now the'r' key.

in 3ds max Key M = Material Editor,
cann in blender set M = Shader Editor?
Is it possible to make keys in the blender to select Workspace ?
in blender 2.79 scene name ( uv editing, , Default)?111.jpg

Can I choose a particular mode through the button in 2.79 or 2.80?

in 3ds max Key M = Material Editor, cann in blender set M = Shader Editor? Is it possible to make keys in the blender to select Workspace ? in blender 2.79 scene name ( uv editing, , Default)?![111.jpg](https://archive.blender.org/developer/F3544241/111.jpg) Can I choose a particular mode through the button in 2.79 or 2.80?

Added subscriber: @JuriUnt

Added subscriber: @JuriUnt

I am a bit hesitant that 1,2,3,4 should be reserved for Mode switching. Half of these modes are not used daily. Subjectively, last time I painted weights was a week ago. Last time I used paint mode was a month ago. I am sure I am not the only one. This begs the question, how is it justified that some of the best keyboard realestate, reachable with your left hand, is assigned to modes that are so rarely used?

Personally I think that mode switching should be done with Pie or popup menu (1 button) while Selection Mode(vert,edge,face), that we do multiple times per minute, should be given the prime real-estate (1,2,3,4). It seems we have it in reverse?

The way I have it set up as such. Depending on selected object ( mesh, lattice, curve, armature etc):
1- OBJECT MODE (Universal. Exits whatever other mode).
2- Mesh: edit mode (vertex selection) | Curve: edit mode | Lattice: edit mode | Armature: pose mode
3- Mesh: edit mode (edge selection) | Curve: edit mode | Lattice: edit mode | Armature: edit mode
4- Mesh: edit mode (face selection) | Curve: edit mode | Lattice: edit mode | Armature: edit mode

ACCENT_GRAVE (` - above TAB) summons a mode switching popup (pie menu in my case):
pie.png

All of this is very efficient and allows you change modes, selections in a heartbeat.
Please consider that 3dsmax has 1,2,3,4 as Edit poly selection mode. So does Houdini. Modo also? We seem to be deviating a bit from standard.

Thank you for reading, consideration.

I am a bit hesitant that 1,2,3,4 should be reserved for Mode switching. Half of these modes are not used daily. Subjectively, last time I painted weights was a week ago. Last time I used paint mode was a month ago. I am sure I am not the only one. This begs the question, how is it justified that some of the best keyboard realestate, reachable with your left hand, is assigned to modes that are so rarely used? Personally I think that mode switching should be done with Pie or popup menu (1 button) while Selection Mode(vert,edge,face), that we do multiple times per minute, should be given the prime real-estate (1,2,3,4). It seems we have it in reverse? The way I have it set up as such. **Depending on selected object** ( mesh, lattice, curve, armature etc): 1- OBJECT MODE (Universal. Exits whatever other mode). 2- Mesh: edit mode (vertex selection) | Curve: edit mode | Lattice: edit mode | Armature: pose mode 3- Mesh: edit mode (edge selection) | Curve: edit mode | Lattice: edit mode | Armature: edit mode 4- Mesh: edit mode (face selection) | Curve: edit mode | Lattice: edit mode | Armature: edit mode ACCENT_GRAVE (` - above TAB) summons a mode switching popup (pie menu in my case): ![pie.png](https://archive.blender.org/developer/F3553813/pie.png) All of this is very efficient and allows you change modes, selections in a heartbeat. Please consider that **3dsmax has 1,2,3,4 as Edit poly selection mode. So does Houdini. Modo also?** We seem to be deviating a bit from standard. Thank you for reading, consideration.

Please consider that currently accessing Widget based transforms creates significant overhead (spacebar>manual select from popup). It's a slow workflow that cannot be used for modeling. Also I think many users liked their Spacebar way it was.

It's possible to preserve Blender default Operations for G,S,R (satisfying all experienced users), same time offer WIDGETS to anyone who prefers it or comes from other 3d software + free up spacebar as bonus. Best of both worlds with minimal overhead.

This is workflow I use in 2.79:
transforms.gif

Thank you for reading.

Please consider that currently accessing Widget based transforms creates significant overhead (spacebar>manual select from popup). It's a slow workflow that cannot be used for modeling. Also I think many users liked their Spacebar way it was. It's possible to preserve Blender default Operations for G,S,R (satisfying all experienced users), same time offer WIDGETS to anyone who prefers it or comes from other 3d software + free up spacebar as bonus. Best of both worlds with minimal overhead. This is workflow I use in 2.79: ![transforms.gif](https://archive.blender.org/developer/F3575866/transforms.gif) Thank you for reading.

For the industry standard keymap that won't be necessary. You'll just use W, E & R to enable Move, Rotate and Scale tools.

For the industry standard keymap that won't be necessary. You'll just use W, E & R to enable Move, Rotate and Scale tools.

In #54963#507548, @WilliamReynish wrote:
For the industry standard keymap that won't be necessary. You'll just use W, E & R to enable Move, Rotate and Scale tools.

Now the industry that never looked at us is above all else our new religion?

> In #54963#507548, @WilliamReynish wrote: > For the industry standard keymap that won't be necessary. You'll just use W, E & R to enable Move, Rotate and Scale tools. Now the industry that never looked at us is above all else our new religion?

As it says at the very top:

This will not replace blender's default keymap. This is an alternative keymap that will make Blender behave more like industry standard apps.

This keymap is for users who use mixed-software pipelines where it's impractical to switch hotkeys constantly, and also for users of other software packages who would like to try out Blender.

Again, this will not replace blender's default keymap.

As it says at the very top: This will not replace blender's default keymap. This is an alternative keymap that will make Blender behave more like industry standard apps. This keymap is for users who use mixed-software pipelines where it's impractical to switch hotkeys constantly, and also for users of other software packages who would like to try out Blender. Again, this will not replace blender's default keymap.

@WilliamReynish

Could the tiebreaker app for texturing please get changed to Substance Painter?
Reasoning would be; Zbrush is to this day not a dedicated texturing application (no ability to paint directly on textures, no texture layers, etc)

@WilliamReynish Could the tiebreaker app for texturing please get changed to Substance Painter? Reasoning would be; Zbrush is to this day not a dedicated texturing application (no ability to paint directly on textures, no texture layers, etc)

In #54963#507551, @WilliamReynish wrote:
As it says at the very top:

This will not replace blender's default keymap. This is an alternative keymap that will make Blender behave more like industry standard apps.

This keymap is for users who use mixed-software pipelines where it's impractical to switch hotkeys constantly, and also for users of other software packages who would like to try out Blender.

Again, this will not replace blender's default keymap.

Hi, will it be possible to assign a key to the material editor in 2.8? At 3d the max he was assigned to M.
It would be great if the blender would be something similar to compact material editor and safe material editor( in blender texture editor as node editor) like modal type.

> In #54963#507551, @WilliamReynish wrote: > As it says at the very top: > > This will not replace blender's default keymap. This is an alternative keymap that will make Blender behave more like industry standard apps. > > This keymap is for users who use mixed-software pipelines where it's impractical to switch hotkeys constantly, and also for users of other software packages who would like to try out Blender. > > Again, this will not replace blender's default keymap. Hi, will it be possible to assign a key to the material editor in 2.8? At 3d the max he was assigned to M. It would be great if the blender would be something similar to compact material editor and safe material editor( in blender texture editor as node editor) like modal type.

Added subscriber: @PierreSchiller

Added subscriber: @PierreSchiller

Yes, modo has 1:vertex selection (and please fix that Blender can do switch directly from object mode context to EDIT mode context upon pressing 1 to select vertices), 2:edges, 3:faces, 4:polygon element.

I am in favor of using 1-2-3 as main switching between vertex, edge and face. Those are used in a daily basis.

Please make them enter directly into EDIT context menu. All of the user being in OBJECT context waste an extra step by first switching context and then entering the edit mode selection.

I did a script to make those 2 functions in a single press, but please Developers, you can fix that now that we are on overview of shortcuts.

Pie menus are needed as well. Pies should continue to be consistant. Thanks

Yes, modo has 1:vertex selection (and please fix that Blender can do switch directly from object mode context to EDIT mode context upon pressing 1 to select vertices), 2:edges, 3:faces, 4:polygon element. I am in favor of using 1-2-3 as main switching between vertex, edge and face. Those are used in a daily basis. Please make them enter directly into EDIT context menu. All of the user being in OBJECT context waste an extra step by first switching context and then entering the edit mode selection. I did a script to make those 2 functions in a single press, but please Developers, you can fix that now that we are on overview of shortcuts. Pie menus are needed as well. Pies should continue to be consistant. Thanks

Proposing more efficient edit_mode selecting:
selection.gif

  • Currently double_click is not utilized. For example in maya when double_clicked on Edge it can do edge_loop. When on Face, it can do Element select (linked select )
  • Ring can be achieved with double_click + modifiers (ctrl/shift/doesnt_matter)
  • Ctrl+MWheel could be utilized to grow and shrink selection.
  • Border select is also often useful. Areas could be quickly marked (seam, sharp) and then recovered with double_click on face.

This is just an example, many ways to go about it.

Proposing more efficient edit_mode selecting: ![selection.gif](https://archive.blender.org/developer/F3665479/selection.gif) - Currently double_click is not utilized. For example in maya when double_clicked on Edge it can do edge_loop. When on Face, it can do Element select (linked select ) - Ring can be achieved with double_click + modifiers (ctrl/shift/doesnt_matter) - Ctrl+MWheel could be utilized to grow and shrink selection. - Border select is also often useful. Areas could be quickly marked (seam, sharp) and then recovered with double_click on face. This is just an example, many ways to go about it.

Added subscriber: @Djay

Added subscriber: @Djay

Added subscriber: @JonDoe286

Added subscriber: @JonDoe286

Added subscriber: @blender_noob

Added subscriber: @blender_noob

This comment was removed by @blender_noob

*This comment was removed by @blender_noob*

Added subscriber: @1D_Inc

Added subscriber: @1D_Inc

I use F key in object mode to center view (default alt+F), for creating polygons and F2 in edit mode.
Q is used to select linked (much better than L) in all editors.
Double scroll to zoom to selection in both cases.
Left mouse for select, Right mouse for pan, Scroll to zoom/rotate keeps whole navigation in mouse (Sketchfab mode).

Here is how it looks like

I use F key in object mode to center view (default alt+F), for creating polygons and F2 in edit mode. Q is used to select linked (much better than L) in all editors. Double scroll to zoom to selection in both cases. Left mouse for select, Right mouse for pan, Scroll to zoom/rotate keeps whole navigation in mouse (Sketchfab mode). Here is how it [looks like ](https://youtu.be/Tsaa_D6CcSo)

Ctrl+Mwheel, Shift+Mwheel and other mwheel modifications are used for custom tools, they should stay unassigned.
Doubleclick for selection is a really bad solution, as we remeber by sketchup.

Ctrl+Mwheel, Shift+Mwheel and other mwheel modifications are used for custom tools, they should stay unassigned. Doubleclick for selection is a really bad solution, as we remeber by sketchup.

Added subscriber: @jgz

Added subscriber: @jgz
Member

Added subscriber: @JulienKaspar

Added subscriber: @JulienKaspar

Added subscriber: @ArgentArts

Added subscriber: @ArgentArts

To correct the chart, MODO's does deselect by clicking in empty space and double-clicking selects an edge loop.

As far as pan, rotate, and zoom, I've never liked using all three mouse buttons ... particularly the MMB as it tends to be a scroll wheel and it just feels strangely uncomfortable to use for panning. I'm actually a fan of MODO's method of moving about the viewport - using ALT, ALT+SHIFT, and CTRL+SHIFT in conjunction with the LMB to tumble, pan, and zoom. But I do see that it is not the most commonly used method.

To correct the chart, MODO's does deselect by clicking in empty space and double-clicking selects an edge loop. As far as pan, rotate, and zoom, I've never liked using all three mouse buttons ... particularly the MMB as it tends to be a scroll wheel and it just feels strangely uncomfortable to use for panning. I'm actually a fan of MODO's method of moving about the viewport - using ALT, ALT+SHIFT, and CTRL+SHIFT in conjunction with the LMB to tumble, pan, and zoom. But I do see that it is not the most commonly used method.

Could we get a default for Paint Selection? In MODO, paint select is the default method of selecting vertices, edges, and faces. You click to select a single face, edge, or vertex, but click+drag to paint select. Box and lasso selections are done via another mouse button. I find that I am constantly using both double click (for edge loop selection) and click+drag for paint selection.

Could we get a default for Paint Selection? In MODO, paint select is the default method of selecting vertices, edges, and faces. You click to select a single face, edge, or vertex, but click+drag to paint select. Box and lasso selections are done via another mouse button. I find that I am constantly using both double click (for edge loop selection) and click+drag for paint selection.

Added subscriber: @Ko

Added subscriber: @Ko

If only Modo using it this way, then its not an industry standard.

If only Modo using it this way, then its not an industry standard.

Paint select is not even on the chart, which is why I asked about getting a default for it. Then I mentioned how it is done in MODO. I've no idea how it is done, if at all, in most other 3D apps.

Paint select is not even on the chart, which is why I asked about getting a default for it. Then I mentioned how it is done in MODO. I've no idea how it is done, if at all, in most other 3D apps.

Well, I hope they will use Modo style paint selection for 2.8, because I see no other way if we want to use tablet for modeling) I am using tablet for modeling in modo and paint select works perfectly, opposing to Maya, where I have to click on each individual poly/vertex/edge to select, and it is not that intuitive and slows me down. There is a manual paint selection tool in Maya - but you have to hit some hotkey to do that. In modo - it is on left click by default and it is suuuuper handy.

Well, I hope they will use Modo style paint selection for 2.8, because I see no other way if we want to use tablet for modeling) I am using tablet for modeling in modo and paint select works perfectly, opposing to Maya, where I have to click on each individual poly/vertex/edge to select, and it is not that intuitive and slows me down. There is a manual paint selection tool in Maya - but you have to hit some hotkey to do that. In modo - it is on left click by default and it is suuuuper handy.

That feature wasn`t added simply because it was forgotten during the creation of the Texturepainting spreadsheet.
Sorry, its actually my bad for not adding it initially.

Fill options for painting are common across all texturing applications, even the rudimentary texturing implementation inside of ZBrush has a Fill Button.
Blender has a fill feature which is the Fill Brush.
More additions especially when a feature already exists inside Blender should of course be taken into consideration.

In Substance Painter the Polygon Fill Tool can be activated via pressing 4, after that you
either click to select one specific part or you use click+drag for selecting multiple parts.

The Spreadsheet is imo not complete and if there are missing features or you know some shortcuts, please add them in the comments.

That feature wasn`t added simply because it was forgotten during the creation of the Texturepainting spreadsheet. Sorry, its actually my bad for not adding it initially. Fill options for painting are common across all texturing applications, even the rudimentary texturing implementation inside of ZBrush has a Fill Button. Blender has a fill feature which is the Fill Brush. More additions especially when a feature already exists inside Blender should of course be taken into consideration. In Substance Painter the Polygon Fill Tool can be activated via pressing *4*, after that you either *click to select* one specific part or you use *click+drag* for selecting multiple parts. The Spreadsheet is imo not complete and if there are missing features or you know some shortcuts, please add them in the comments.

I wasn't talking about texture painting or painting at all, but about "paint select". Paint Select is when you click+drag across multiple faces to select all polygonal faces you cross over (or edges or vertices, depending on which mode you are in). In Blender, this is accessed by pressing "C". However, MODO has "C" (if you will) on by default. You can either click to select a single component or click+drag to "paint" your selection. It makes it quite easy to use and fast because you don't have to hunt for or remember another shortcut key.

I wasn't talking about texture painting or painting at all, but about "paint select". Paint Select is when you click+drag across multiple faces to select all polygonal faces you cross over (or edges or vertices, depending on which mode you are in). In Blender, this is accessed by pressing "C". However, MODO has "C" (if you will) on by default. You can either click to select a single component or click+drag to "paint" your selection. It makes it quite easy to use and fast because you don't have to hunt for or remember another shortcut key.

Also, in 2.79 - If you hit C and try to paint selection over the model - you can not navigate around the object and it is just destroys my workflow, because, if I have a large object and want to select multiple elements on its surface - I will have to hit C every time I want to paint selection then hit C again to tun off painting mode - then navigate to the next element - hit C again - paint - hit C - navigate to the next etc.
In modo it would be like - I am freely flying around and paint select necessary vertex/edge/poly. Suuuuper handy. I really want to switch on Blender after 2.8 release and I hope this feature will be there)

Also, in 2.79 - If you hit C and try to paint selection over the model - you can not navigate around the object and it is just destroys my workflow, because, if I have a large object and want to select multiple elements on its surface - I will have to hit C every time I want to paint selection then hit C again to tun off painting mode - then navigate to the next element - hit C again - paint - hit C - navigate to the next etc. In modo it would be like - I am freely flying around and paint select necessary vertex/edge/poly. Suuuuper handy. I really want to switch on Blender after 2.8 release and I hope this feature will be there)

In #54963#518938, @ACap99 wrote:
Also, in 2.79 - If you hit C and try to paint selection over the model - you can not navigate around the object and it is just destroys my workflow, because, if I have a large object and want to select multiple elements on its surface - I will have to hit C every time I want to paint selection then hit C again to tun off painting mode - then navigate to the next element - hit C again - paint - hit C - navigate to the next etc.
In modo it would be like - I am freely flying around and paint select necessary vertex/edge/poly. Suuuuper handy. I really want to switch on Blender after 2.8 release and I hope this feature will be there)

In Blender 2.8 its easy to assign any tool to LMB (through Toolbar), including circle select.

> In #54963#518938, @ACap99 wrote: > Also, in 2.79 - If you hit C and try to paint selection over the model - you can not navigate around the object and it is just destroys my workflow, because, if I have a large object and want to select multiple elements on its surface - I will have to hit C every time I want to paint selection then hit C again to tun off painting mode - then navigate to the next element - hit C again - paint - hit C - navigate to the next etc. > In modo it would be like - I am freely flying around and paint select necessary vertex/edge/poly. Suuuuper handy. I really want to switch on Blender after 2.8 release and I hope this feature will be there) In Blender 2.8 its easy to assign any tool to LMB (through Toolbar), including circle select.

Yes. Can it be set up so that LMB click is select, but LMB drag is "C"?

Yes. Can it be set up so that LMB click is select, but LMB drag is "C"?

In #54963#518939, @Ko wrote:

In #54963#518938, @ACap99 wrote:
Also, in 2.79 - If you hit C and try to paint selection over the model - you can not navigate around the object and it is just destroys my workflow, because, if I have a large object and want to select multiple elements on its surface - I will have to hit C every time I want to paint selection then hit C again to tun off painting mode - then navigate to the next element - hit C again - paint - hit C - navigate to the next etc.
In modo it would be like - I am freely flying around and paint select necessary vertex/edge/poly. Suuuuper handy. I really want to switch on Blender after 2.8 release and I hope this feature will be there)

In Blender 2.8 its easy to assign any tool to LMB (through Toolbar), including circle select.

Even if so - I just downloaded blender 2.8 alpha and tried C command - I still can not navigate while this tool is active, so, it is almost useless.

> In #54963#518939, @Ko wrote: >> In #54963#518938, @ACap99 wrote: >> Also, in 2.79 - If you hit C and try to paint selection over the model - you can not navigate around the object and it is just destroys my workflow, because, if I have a large object and want to select multiple elements on its surface - I will have to hit C every time I want to paint selection then hit C again to tun off painting mode - then navigate to the next element - hit C again - paint - hit C - navigate to the next etc. >> In modo it would be like - I am freely flying around and paint select necessary vertex/edge/poly. Suuuuper handy. I really want to switch on Blender after 2.8 release and I hope this feature will be there) > > In Blender 2.8 its easy to assign any tool to LMB (through Toolbar), including circle select. Even if so - I just downloaded blender 2.8 alpha and tried C command - I still can not navigate while this tool is active, so, it is almost useless.

Currently in Blender 2.79, under the Circle Select Modal keymap, C key Release event can be set as Confirm, essentially making it only work when it is pressed.

This simulates well allowing navigation in between selection strokes, when in reality it just quits the modal operator.

Currently in Blender 2.79, under the *Circle Select Modal* keymap, `C` key *Release* event can be set as *Confirm*, essentially making it only work when it is pressed. This simulates well allowing navigation in between selection strokes, when in reality it just quits the modal operator.

There will be Ctrl+A for select all?

There will be Ctrl+A for select all?

Removed subscriber: @zebus3dream

Removed subscriber: @zebus3dream

Added subscriber: @JeffreyKlug

Added subscriber: @JeffreyKlug

Added subscriber: @zebus3dream

Added subscriber: @zebus3dream

Removed subscriber: @zebus3dream

Removed subscriber: @zebus3dream

Added subscriber: @Robw

Added subscriber: @Robw

A question: is anyone actually looking at the ergonomics of the various proposed keyboard maps?

This is wider than just the industry standard keymap so I'm not sure if this is the right thread, but I can't find a clear 'put your Blender 2.8 keyboard map related issues and questions here' thread.

The Blender keymap needs some serious love, as it is full to overflowing. I ask however, to please also or perhaps first, look at the ergonomics (which includes effectiveness and learnability) of a key map and of using a keyboard in combination with a mouse.

It seems to me that the discussion on keyboard maps / shortcut maps is severely missing the viewpoint of ergonomics. A nice example is the proposal for "A to select all / ALT-A to deselect all" (or, in general, Key_X / ALT_Key_X). The argument for having two shortcuts seems to be that "it is in accordance with standard X and therefore should be in Blender" (insert your standard of preference). It seems like adhering to a standard is more important than having something that is fast to use or in line with the Blender function or operation you are accessing at any given point.

Examples of proposals that impact ergonomics:

  • toggle actions are being removed. In many places, separate key combinations for 'toggle on' and 'toggle off' behavior are introduced, like select all/none (A - ALT-A), or opening/closing a menu (TAB, W, Shift_E, SHIFT-S, etc. to open, ESC to close). These actions are, in principle, toggle actions, teat them as such.
  • serial combinations of keyboard and mouse actions are introduced. Especially with the wider use of the pie menu, you need two actions to select/use a function or operation: TAB to open the menu, then slide/click to select a function/operation: 'sequential' combinations (TAB, followed by mouse action) are always slower to use than either a keyboard or a mouse action. To further complicate: given the placement of keys on most computer keyboards, TAB followed by Mouse action is probably not an easy or fast combination for left-handed people.
  • key combinations are introduced that do not match or relate to the functions they operate. An example of this is W/E/R for Move/Rotate/Scale, respectively. Please select shortcuts to match the functions.

I ask/propose the following:

  • please don't get hung up on 'it is in accordance with standard X and therefore should be in Blender'. Since there is arguably no proper 'standard' (except perhaps the IBM CUA from 1987), you will most likely end up with an amalgam or mashup of things other applications have invented for themselves. It will not necessarlily make Blender more consistent or more usable.
  • please don't introduce serial keyboard + mouse actions if they are avoidable. Provide for keyboard-only or mouse-only operation (preferrably both, to suit different user behaviors), it is generally faster to use one input mode than a combination of modes.
  • please acknowledge toggle actions and treat them as such: use the same keybord or mouse action for 'toggle on' and 'toggle off'. It makes for a smaller key map with fewer combinations to learn and for faster operation of the application.
  • please ensure that functions/operations and the accompanying shortcuts or mouse actions in line. G for Grab/move, S for Scale, R for Rotate, E for Extrude etc. correlate between key and function/operation and are therefore easier to learn.

Unless Blender is aiming to attract a completely new user base, most users will be transitioning from 2.7x to 2.8. Please don't make them relearn the application any more than necessary. For those users that are new to Blender: it is a complex application, let's acknowledge that and own it. Assist them by providing access to basic and/or important functions in a way that relates to what they are trying to accomplish. Also: it is not a bad thing to do your own thing; the Blender UI is itself based on rather rigorous application of a set of principles. Using key maps that help people use Blender effectively fits rather nicely.

I realise that the above is, like with everyone else's proposals and/or comments, rather subjective. I do believe, however, that the current direction of the discussion on keyboard maps is taking is not helping Blender forward as much as it should or could.

For background reading, perhaps some of the principles behind Human-computer interaction design or user-centered design might be useful (https:*en.wikipedia.org/wiki/Human%E2%80%93computer_interaction and https:*en.wikipedia.org/wiki/User-centered_design).

A question: is anyone actually looking at the ergonomics of the various proposed keyboard maps? This is wider than just the industry standard keymap so I'm not sure if this is the right thread, but I can't find a clear 'put your Blender 2.8 keyboard map related issues and questions here' thread. The Blender keymap needs some serious love, as it is full to overflowing. I ask however, to please also or perhaps first, look at the ergonomics (which includes effectiveness and learnability) of a key map and of using a keyboard in combination with a mouse. It seems to me that the discussion on keyboard maps / shortcut maps is severely missing the viewpoint of ergonomics. A nice example is the proposal for "A to select all / ALT-A to deselect all" (or, in general, Key_X / ALT_Key_X). The argument for having two shortcuts seems to be that "it is in accordance with standard X and therefore should be in Blender" (insert your standard of preference). It seems like adhering to a standard is more important than having something that is fast to use or in line with the Blender function or operation you are accessing at any given point. Examples of proposals that impact ergonomics: - toggle actions are being removed. In many places, separate key combinations for 'toggle on' and 'toggle off' behavior are introduced, like select all/none (A - ALT-A), or opening/closing a menu (TAB, W, Shift_E, SHIFT-S, etc. to open, ESC to close). These actions are, in principle, toggle actions, teat them as such. - serial combinations of keyboard and mouse actions are introduced. Especially with the wider use of the pie menu, you need two actions to select/use a function or operation: TAB to open the menu, then slide/click to select a function/operation: 'sequential' combinations (TAB, followed by mouse action) are always slower to use than either a keyboard or a mouse action. To further complicate: given the placement of keys on most computer keyboards, TAB followed by Mouse action is probably not an easy or fast combination for left-handed people. - key combinations are introduced that do not match or relate to the functions they operate. An example of this is W/E/R for Move/Rotate/Scale, respectively. Please select shortcuts to match the functions. I ask/propose the following: - please don't get hung up on 'it is in accordance with standard X and therefore should be in Blender'. Since there is arguably no proper 'standard' (except perhaps the IBM CUA from 1987), you will most likely end up with an amalgam or mashup of things other applications have invented for themselves. It will not necessarlily make Blender more consistent or more usable. - please don't introduce serial keyboard + mouse actions if they are avoidable. Provide for keyboard-only or mouse-only operation (preferrably both, to suit different user behaviors), it is generally faster to use one input mode than a combination of modes. - please acknowledge toggle actions and treat them as such: use the same keybord or mouse action for 'toggle on' and 'toggle off'. It makes for a smaller key map with fewer combinations to learn and for faster operation of the application. - please ensure that functions/operations and the accompanying shortcuts or mouse actions in line. G for Grab/move, S for Scale, R for Rotate, E for Extrude etc. correlate between key and function/operation and are therefore easier to learn. Unless Blender is aiming to attract a completely new user base, most users will be transitioning from 2.7x to 2.8. Please don't make them relearn the application any more than necessary. For those users that are new to Blender: it is a complex application, let's acknowledge that and own it. Assist them by providing access to basic and/or important functions in a way that relates to what they are trying to accomplish. Also: it is not a bad thing to do your own thing; the Blender UI is itself based on rather rigorous application of a set of principles. Using key maps that help people use Blender effectively fits rather nicely. I realise that the above is, like with everyone else's proposals and/or comments, rather subjective. I do believe, however, that the current direction of the discussion on keyboard maps is taking is not helping Blender forward as much as it should or could. For background reading, perhaps some of the principles behind Human-computer interaction design or user-centered design might be useful (https:*en.wikipedia.org/wiki/Human%E2%80%93computer_interaction and https:*en.wikipedia.org/wiki/User-centered_design).

As stated at the top of this page, the industry standard keymap is an ALTERNATIVE keymap and it will NOT REPLACE the standard Blender keymap. So, including an alternative keymap will not make Blender more difficult for current Blender user's to transition from 2.7x to 2.8 as the default will be Blender standard keymaps (with a few 2.8 changes). However, for people coming from using other 3D applications, like Maya, MODO, and Max, the alternative keymap will be there to help make their transition easier. And, as stated near the top of the page, "this is an alternative keymap for users who use Blender as part of their pipeline, in conjunction with industry standard apps." Creating an industry standard keymap allows people who already have an established pipeline to INCLUDE Blender with little trouble. For many people, it's a pain to switch from one app to another when their keyboard shortcuts are vastly different to do basically the same things.

So, you won't have to use the industry standard keymap if you don't want to. And, as has always been the case, you can change the keymap to whatever you like as you can completely customize it. But the industry standard keymap is an attempt to create a keymap that adheres the most common industry standards in order to be an aid to those who want to include Blender into their pre-existing pipelines.

As stated at the top of this page, the industry standard keymap is an ALTERNATIVE keymap and it will NOT REPLACE the standard Blender keymap. So, including an alternative keymap will not make Blender more difficult for current Blender user's to transition from 2.7x to 2.8 as the default will be Blender standard keymaps (with a few 2.8 changes). However, for people coming from using other 3D applications, like Maya, MODO, and Max, the alternative keymap will be there to help make their transition easier. And, as stated near the top of the page, "this is an alternative keymap for users who use Blender as part of their pipeline, in conjunction with industry standard apps." Creating an industry standard keymap allows people who already have an established pipeline to INCLUDE Blender with little trouble. For many people, it's a pain to switch from one app to another when their keyboard shortcuts are vastly different to do basically the same things. So, you won't have to use the industry standard keymap if you don't want to. And, as has always been the case, you can change the keymap to whatever you like as you can completely customize it. But the industry standard keymap is an attempt to create a keymap that adheres the most common industry standards in order to be an aid to those who want to include Blender into their pre-existing pipelines.

So in essence the "industry standard" keymap is just a mix of the most common hotkeys from every major software... in the end someone is gonna have to do the maya keymap, the max keymap, the houdini keymap, and the cinema 4d keymap, and this "industry standard really weirdly mixed mix of things " will become obsolete pretty fast.

Sorry for the negativity. it just hit me, and to tell you my experience, i've turned and help turn a couple of studios and artists to blender, and honestly the only things bothering people are the move, rotate, scale, but really more importantly the way you move around your scene and the rmb / lmb thing, thats it. the rest of the hotkeys they dont mind, and they love having SPACE BAR as search functions because it aids them learning the rest of the stuff they need quite fast, and its all compatible to learning the blender defaults.

just my 2 cents.

So in essence the "industry standard" keymap is just a mix of the most common hotkeys from every major software... in the end someone is gonna have to do the maya keymap, the max keymap, the houdini keymap, and the cinema 4d keymap, and this "industry standard really weirdly mixed mix of things " will become obsolete pretty fast. Sorry for the negativity. it just hit me, and to tell you my experience, i've turned and help turn a couple of studios and artists to blender, and honestly the only things bothering people are the move, rotate, scale, but really more importantly the way you move around your scene and the rmb / lmb thing, thats it. the rest of the hotkeys they dont mind, and they love having SPACE BAR as search functions because it aids them learning the rest of the stuff they need quite fast, and its all compatible to learning the blender defaults. just my 2 cents.

Added subscriber: @Invertex

Added subscriber: @Invertex

In #54963#521770, @Robw wrote:

  • key combinations are introduced that do not match or relate to the functions they operate. An example of this is W/E/R for Move/Rotate/Scale, respectively. Please select shortcuts to match the functions.

You're talking about ergonomics here, yet I fail to see how this suggestion is pro-ergonomics. You're saying that instead of grouping together 3 of the most used hotkeys (actually 4, "Q" reverts to default/selection tool), that they instead should be spread out to "more appropriate letters". That is anti-ergonomic. It comes off as "it bugs me it doesn't match the letter, so it's no good". Most people in the industry are very comfortable with their hand in the WASD and QWER positions as they are the most commonly used keys for software and games, and QWER allows you to rest your hand very comfortably on all 4 letters so you can rapidly move, scale and rotate your objects.

> In #54963#521770, @Robw wrote: > - key combinations are introduced that do not match or relate to the functions they operate. An example of this is W/E/R for Move/Rotate/Scale, respectively. Please select shortcuts to match the functions. You're talking about ergonomics here, yet I fail to see how this suggestion is pro-ergonomics. You're saying that instead of grouping together 3 of the most used hotkeys (actually 4, "Q" reverts to default/selection tool), that they instead should be spread out to "more appropriate letters". That is anti-ergonomic. It comes off as "it bugs me it doesn't match the letter, so it's no good". Most people in the industry are very comfortable with their hand in the WASD and QWER positions as they are the most commonly used keys for software and games, and QWER allows you to rest your hand very comfortably on all 4 letters so you can rapidly move, scale and rotate your objects.

Added subscriber: @nokipaike

Added subscriber: @nokipaike

I believe the combination of A select_all/deselect_all + alt-A deselect_all is Compatible and and satisfies everyone!
for those used to using the classic combination selection_all - deselection_all with A continue to use this combination as usual, for those who complain that A for deselected in scenes too heavy is inconvenient can easily use alt-A to deselect_all

I believe the combination of A select_all/deselect_all + alt-A deselect_all is Compatible and and satisfies everyone! for those used to using the classic combination selection_all - deselection_all with A continue to use this combination as usual, for those who complain that A for deselected in scenes too heavy is inconvenient can easily use alt-A to deselect_all

In #54963#524475, @Invertex wrote:
It comes off as "it bugs me it doesn't match the letter, so it's no good".

Your interpretation, not mine.

You seem to have missed the 2nd line in the post though: this is not about the industry-standard map alone. All over, discussion seems to concentrate mostly around people's personal preferences, not about having a consistent key map or effective use of Blender as an application. Factoring in ergonomics makes for better consistency, better learnability and more efficient use of the application. While this particular key map does not have 'learnability' as a goal, others do.

In #54963#524475, @Invertex wrote:
Most people in the industry are very comfortable with their hand in the WASD and QWER positions as they are the most commonly used keys for software and games, and QWER allows you to rest your hand very comfortably on all 4 letters so you can rapidly move, scale and rotate your objects.

Fair point. I'd like to see the stats on 'most people are very comfortable', though. If W/E/R works for people and it is 'standard': put it in. What I am saying is don't put it in because 'it is standard', but because it works better than the alternatives. That is the bit I don't see in each of the discussions.

> In #54963#524475, @Invertex wrote: >It comes off as "it bugs me it doesn't match the letter, so it's no good". Your interpretation, not mine. You seem to have missed the 2nd line in the post though: this is not about the industry-standard map alone. All over, discussion seems to concentrate mostly around people's personal preferences, not about having a consistent key map or effective use of Blender as an application. Factoring in ergonomics makes for better consistency, better learnability and more efficient use of the application. While this particular key map does not have 'learnability' as a goal, others do. > In #54963#524475, @Invertex wrote: >Most people in the industry are very comfortable with their hand in the WASD and QWER positions as they are the most commonly used keys for software and games, and QWER allows you to rest your hand very comfortably on all 4 letters so you can rapidly move, scale and rotate your objects. Fair point. I'd like to see the stats on 'most people are very comfortable', though. If W/E/R works for people and it is 'standard': put it in. What I am saying is don't put it in because 'it is standard', but because it works better than the alternatives. That is the bit I don't see in each of the discussions.

Added subscriber: @Skrapion

Added subscriber: @Skrapion

Wow, a keymap which actually uses the same mouse button for select and box-select? Revolutionary! ;)

@nokipaike Although it's not in the list yet, I believe Ctrl+A is far more standard than A/Alt+A for select all.

Most apps don't actually have a deselect all shortcut other than clicking on blank space, although often there will be a "Select None" option in the dropdown menus which you can assign a shortcut to if you're so inclined.

Wow, a keymap which actually uses the *same* mouse button for select and box-select? Revolutionary! ;) @nokipaike Although it's not in the list yet, I believe Ctrl+A is far more standard than A/Alt+A for select all. Most apps don't actually have a deselect all shortcut other than clicking on blank space, although often there will be a "Select None" option in the dropdown menus which you can assign a shortcut to if you're so inclined.

Photoshop offers a great way to resize your brush and to choose the softness/hardness of your brush. You press ALT+RMB +drag LEFT/RIGHT to resize and UP/DOWN to affect the hardness of the brush. This keeps people from having to learn a new keyboard shortcut and you do most of what you need to with your brush while painting via this one shortcut. Now, I am not married to ALT+RMB, but I do like the LEFT/RIGHT, UP/DOWN way of doing things. Clip Studio Paint uses CTRL+ALT+DRAG to resize the brush. MODO just uses RMB+Drag to resize (since you don't have it in the chart above).

I know that 3D programs may work a certain way when it comes to painting, but it seems to me emulating Photoshop (or other paint programs) would be the way to go for these shortcuts as most people who paint textures will be using these programs and having similar shortcuts would make it quite easy to shift between them when needed.

Photoshop offers a great way to resize your brush and to choose the softness/hardness of your brush. You press ALT+RMB +drag LEFT/RIGHT to resize and UP/DOWN to affect the hardness of the brush. This keeps people from having to learn a new keyboard shortcut and you do most of what you need to with your brush while painting via this one shortcut. Now, I am not married to ALT+RMB, but I do like the LEFT/RIGHT, UP/DOWN way of doing things. Clip Studio Paint uses CTRL+ALT+DRAG to resize the brush. MODO just uses RMB+Drag to resize (since you don't have it in the chart above). I know that 3D programs may work a certain way when it comes to painting, but it seems to me emulating Photoshop (or other paint programs) would be the way to go for these shortcuts as most people who paint textures will be using these programs and having similar shortcuts would make it quite easy to shift between them when needed.

Just tested that in Photoshop, that doesn't work here? All I get is the brush menu?

Just tested that in Photoshop, that doesn't work here? All I get is the brush menu?

If you just click the RMB, you get the brush menu. If you press+hold ALT and then press+hold+drag the RMB and drag left/right, you get a circle showing you the brush size and hardness. Keep holding the ALT and RMB and drag left/right to increase/decrease size and up/down to increase/decrease hardness. I've used this shortcut for years because it's interactive (and much better than using the bracket keys).

If you just click the RMB, you get the brush menu. If you press+hold ALT and then press+hold+drag the RMB and drag left/right, you get a circle showing you the brush size and hardness. Keep holding the ALT and RMB and drag left/right to increase/decrease size and up/down to increase/decrease hardness. I've used this shortcut for years because it's interactive (and much better than using the bracket keys).

Newest Photoshop here. That most certainly does not work by default. The Brush menu appears every time.

Newest Photoshop here. That most certainly does not work by default. The Brush menu appears every time.

If you're on a Mac, it's Control + Option plus drag left/right (according to a website ... I'm on a PC).

If you're on a Mac, it's Control + Option plus drag left/right (according to a website ... I'm on a PC).

I'm also running the latest Photoshop CC 2018 and it most definitely does work. If you do a Google search, you can see people talking about it (especially when it stopped working for them due to Windows 10 updates, Wacom driver issues, etc.).

For CC 2018, Adobe now says to use CTRL+ALT+RMB drag left/right, up/down. So, give that a try. Surprisingly, BOTH work for my on my system.

What follows is from an Adobe blog article on this (http://blogs.adobe.com/jkost/2017/05/brushes-and-painting-tool-shortcuts-in-photoshop-cc.html):

  1. Resizing Using the HUD (Heads-Up Display)

On Mac: Control + Option (Mac) –drag left/right in order to decrease/increase brush size and up/down to decrease/ increase brush hardness.
On Windows: Control + Alt + Right click -drag left/right to decrease/ increase brush size and up/down decrease/ increase brush hardness.
To use the change Brush Opacity (instead of the Brush Hardness), based on the vertical drag movement, select Preferences > Tools and uncheck “Vary Round Brush Hardness based on HUD vertical movement”.

I'm also running the latest Photoshop CC 2018 and it most definitely does work. If you do a Google search, you can see people talking about it (especially when it stopped working for them due to Windows 10 updates, Wacom driver issues, etc.). For CC 2018, Adobe now says to use CTRL+ALT+RMB drag left/right, up/down. So, give that a try. Surprisingly, BOTH work for my on my system. What follows is from an Adobe blog article on this (http://blogs.adobe.com/jkost/2017/05/brushes-and-painting-tool-shortcuts-in-photoshop-cc.html): 2) Resizing Using the HUD (Heads-Up Display) On Mac: Control + Option (Mac) –drag left/right in order to decrease/increase brush size and up/down to decrease/ increase brush hardness. On Windows: Control + Alt + Right click -drag left/right to decrease/ increase brush size and up/down decrease/ increase brush hardness. To use the change Brush Opacity (instead of the Brush Hardness), based on the vertical drag movement, select Preferences > Tools and uncheck “Vary Round Brush Hardness based on HUD vertical movement”.

Aha, yes, it works, but your explanation was wrong. To do that in Photoshop 2018, you have to hold Ctrl+Alt+LMB-drag. No RMB involved.

Aha, yes, it works, but your explanation was wrong. To do that in Photoshop 2018, you have to hold Ctrl+Alt+LMB-drag. No RMB involved.

No. It is RMB. Even the Adobe docs say so (see my post above):

"On Windows: Control + Alt + Right click -drag left/right to decrease/ increase brush size and up/down decrease/ increase brush hardness."

This has been in Photoshop for over a decade at least. I've been using this since at least PS4.

No. It is RMB. Even the Adobe docs say so (see my post above): "On Windows: Control + Alt + **Right click** -drag left/right to decrease/ increase brush size and up/down decrease/ increase brush hardness." This has been in Photoshop for over a decade at least. I've been using this since at least PS4.

When a brush is selected, ALT+LMBhas always given Photoshop users access to the Color Picker tool. ALT+RMB provides access to the ability to interactively adjust brush size/hardness.

When a brush is selected, ALT+**LMB**has always given Photoshop users access to the Color Picker tool. ALT+**RMB** provides access to the ability to interactively adjust brush size/hardness.

Yes, but Ctrl+Alt+LMB is the thing you were referring to. At least in the latest Photoshop on Mac.

Yes, but Ctrl+Alt+LMB is the thing you were referring to. At least in the latest Photoshop on Mac.

Sigh. No. I was not because, as stated, I am on a PC. I can't speak for a Mac as I don't own one. So, no, I was not explaining things incorrectly. It was and is still the RMB on the PC. However, because it wasn't working for you, I did post, from the Adobe blog, how it works on the Mac as well (see my posts above). Sorry for the confusion ...

Sigh. No. I was not because, as stated, I am on a PC. I can't speak for a Mac as I don't own one. So, no, I was not explaining things incorrectly. It was and is still the RMB on the PC. However, because it wasn't working for you, I did post, from the Adobe blog, how it works on the Mac as well (see my posts above). Sorry for the confusion ...

Added subscriber: @JuanCa

Added subscriber: @JuanCa

Added subscriber: @A.Lex_3D

Added subscriber: @A.Lex_3D

Removed subscriber: @A.Lex_3D

Removed subscriber: @A.Lex_3D

Added subscriber: @A.Lex_3D

Added subscriber: @A.Lex_3D

Added subscriber: @Luis.Burdallo

Added subscriber: @Luis.Burdallo

This comment was removed by @Luis.Burdallo

*This comment was removed by @Luis.Burdallo*

Added subscriber: @sebastianmroy

Added subscriber: @sebastianmroy
Hello I made this proposal in rcs: https://blender.community/c/rightclickselect/Wbcbbc/#5b9ac2e62155dc1e3e02dc06

Added subscriber: @mooncaine

Added subscriber: @mooncaine

All this talk about ergonomics is moot for left-handed users like me. The default layouts in the apps discussed here, like blender's, are all right-handed creations for right-handed people.

I prefer that you make key mapping easy to do, redo, undo, save and export.

I'm going to have to make my own keymap anyway.

All this talk about ergonomics is moot for left-handed users like me. The default layouts in the apps discussed here, like blender's, are all right-handed creations for right-handed people. I prefer that you make key mapping easy to *do*, *redo*, *undo*, *save* and *export*. I'm going to have to make my own keymap anyway.

In #54963#519016, @DuarteRamos wrote:
Currently in Blender 2.79, under the Circle Select Modal keymap, C key Release event can be set as Confirm, essentially making it only work when it is pressed.

This simulates well allowing navigation in between selection strokes, when in reality it just quits the modal operator.

That would be so much better for my tired hands. I'm not sure it's available on all platforms.

I cannot find this setting, nor reproduce the behavior, that duarteframos describes here. I'm using 2.79 on a Mac. None of the available KeyMapItem.value options are "Confirm" and none of the available options produce the behavior described.

For those interested in a quick way of finishing/canceling the C select mode, a right-click will do it.

> In #54963#519016, @DuarteRamos wrote: > Currently in Blender 2.79, under the *Circle Select Modal* keymap, `C` key *Release* event can be set as *Confirm*, essentially making it only work when it is pressed. > > This simulates well allowing navigation in between selection strokes, when in reality it just quits the modal operator. That would be so much better for my tired hands. I'm not sure it's available on all platforms. I cannot find this setting, nor reproduce the behavior, that duarteframos describes here. I'm using 2.79 on a Mac. None of the available KeyMapItem.value options are "Confirm" and none of the available options produce the behavior described. For those interested in a quick way of finishing/canceling the C select mode, a right-click will do it.

Added subscriber: @Skov

Added subscriber: @Skov

Added subscriber: @Dunathan

Added subscriber: @Dunathan

Consider using Max's viewport rotate/pan/zoom shortcuts to avoid conflicts with LMB shortcuts and actions, since all off them are based on MMB shortcuts. It wount affect LMB and RMB in any way. I´m already using them without any issue in blender for some time.

Consider using Max's viewport rotate/pan/zoom shortcuts to avoid conflicts with LMB shortcuts and actions, since all off them are based on MMB shortcuts. It wount affect LMB and RMB in any way. I´m already using them without any issue in blender for some time.

@nokipaike Although it's not in the list yet, I believe Ctrl+A is far more standard than A/Alt+A for select all.

Agreed,.... totally.

> @nokipaike Although it's not in the list yet, I believe Ctrl+A is far more standard than A/Alt+A for select all. Agreed,.... totally.

Added subscriber: @DanPool

Added subscriber: @DanPool

I see a bunch of these have been marked as "DONE". Where is the work on the current keymap being done? Is there a keyconfig or a git branch I can try somewhere?

I see a bunch of these have been marked as "DONE". Where is the work on the current keymap being done? Is there a keyconfig or a git branch I can try somewhere?

Added subscriber: @MarekHolly

Added subscriber: @MarekHolly

Selection:
Important logic behind adding and subtracting from selection:
Shift + LMB : add to selection is ok, but do not copy it like it works in Maya.
Explanation:

image.png
Selecting several obects wih LMB box selection

image.png
Adding another objects to selection (Shift++LMB), while selection overlaps to some of already selected objects

image.png
Result is – already selected objects touched by box selection become removed from selection. This is not good. You can prevent this behavior by performing box selection by Shift+Ctrl+LMB. In this case, all the boxes will be selected. I think this is against logic of ”add to selection”, because in fact it is not only adding, but subtracting as well.
So, the ideal, and most logical solution should be: Shift+LMB box selection always adds to selection everything, without subtracting from already selected. Subtracting from selection by Ctrl+LMB. Maya Shift+LMB button behavior could be then logically mimicked by Shift+Ctrl+LMB.
Exactly like it works in File Explorer:

image.png
LMB selection

image.png
Adding items to selection by Shift + LMB

image.png
Shift+Ctrl+LMB – adding unselected while removing already selected item.

Mesh Editing:
Extruding by Ctrl+E is ok. But inset shortcut “I” does not follow shortcut logic. Intuitivity, and logic speaks for using same shortcut scheme for same level type of commands. Basic mesh editing commands like inset, extrude, loop cut, and Bevel are the commands from same logical level, thus should be controlled by same shortcut logic So, if you decide to use Ctrl+ (key), you should use this logis for all the mesh editing commands For example:

Extrude: Ctrl+E,

Inset: Ctrl + I could be logical solution, but it is hard to press I together with Ctrl at once, so, this should be some other key within comfortable reach area. Ctrl+T? (yes, it is triangulate shortcut, but triangulate is much less used command than inset. Stronger beats weaker.)

Loop cut: Ctrl+C, But this is commonly used as copy command. Copy is stronger, so it wins. Ctrl+W seems to be within comfortable area, and no other command in blender seems to be using this shortcut.

Bevel: Ctrl+B. Seems like blender 2.8 will be using this shortcut for setting render border. Which, in terms of Ctrl logic should be assigned to some different shortcut. So, Ctrl+B is more important for bevel.

Animation:
Space for play/pause animation is good choice. It is commonly used in video players, and video editing apps for playback. But it needs to work very well with jump to previous/next keyframe shortcuts. Nicest solution for animation was IMHO in Softimage.

Arrow Up: start / pause playback
Arrow Down: pause playback
Arrow left: previous frame
Arrow right: next frame
Ctrl+arrow left: previous keyframe (on selected object(s))
Ctrl+arrow right: next keyframe (on selected object(s))
Ctrl+arrow up: first keyframe (on selected object(s))
Ctrl+arrow down: last keyframe (on selected object(s))
Home: jump to timeline start
End: jump to timeline end

This is flawless example of total animation playback control under one hand.

Pivot point / origin:
Easy origin manipulation is definitely one of the most crucial things that needs to be addressed in Blender.
I am not going to reinvent the wheel - combination of Maya and Softimage origin manipulation is surely the way to go.

Maya:
When translation tool is active, just press „D“ and hold. Move mouse over object, and pre-selection highlight will show you active element on which you are going to snap the origin. Click on desired element (also see „universal snap“ topis later), and origin will jump righ there.

image.png
D key pressed, mouse over active object will highlight future origin location.

image.png
LMB click, and origin snaps to previously pre-selection highlighted element.

Once the origin is at it’s new position, it is super easy to align it to any desired direction. Just press D+Ctrl, and move mouse over object , and pre-selection highlight will show you active element on which you are going to orient the origin.

image.png
Pressing D+Ctrl allows you to orient origin to any element

image.png
LMB click, and origin orientation is aligned to previously pre-selection highlighted element.

Moreover, you can aim origin’s x axis to any point of the object by pressing D+Ctrl+Shift

image.png
Aiming origin’s X-axis to the center of pre-selection highlighted polygon, using D+Ctrl+Shift shortcut..

image.png
LMB click and origin is oriented…

Of course, this works on multiple objects selected. If you want to lock pivot orientation, just check “Pin Component Pivot”.

image.png
Next time you will select object again, pivot will have your custom orientation.

Softimage:
Softimage approach is less powerful, but much more systematic. While moving origin in Maya means really moving origin, in Softimage you have basically two options (super foolproof):

1 direct origin manipulation
2 temporarily overriding actual origin position (transform pivot, or temporal pivot)

1 – direct origin manipulation is super easy – just press “Center” button on right panel..

image.png
…and you can freely move origin anywhere, or when you press Ctrl while translating origin, it will snap on any desired element (point, edge, midpoint, center of polygon) . But here comes the ultimate Softimage advantage over Maya. You can actually snap origin on any unselected object’s element:

image.png
Snapping origin of selected object to the vertex of unselected object (just holding Ctrl while translating).

This is killer feature (see “universal snap” and “knife tool” topic).

Once the origin is relocated, it stays there even after deselecting the object.

2 – Temporarily overriding actual origin position (transform pivot or, temporal pivot)

You can temporarily relocate origin without actually affecting origin position. In fact, it looks like you are relocating origin, but without “Center” button pressed. This origin relocation is temporal, and is active only while the object is selected.

image.png
However this looks complicated it is super easy. Just press Alt+LMB gizmo drag, and you can temporarily relocate origin anywhere. If pressed Alt+Ctrl+LMB drag, temporal origin will snap on whatever is predefined in snap settings (again, see “universal snap” chapter).

Moreover, if you need this temporal/transform origin to stay on this temporal position, even after you deselect the object, you can do it by clicking small white arrow, and choose “Lock”

image.png
Locking transform/temporal origin

This way you can work with origin super fast, without ever loosing it’s position accidentally.

Quick example:

image.png
I want these four points translate, so A1 vertex snaps to A2…

image.png
Alt+LMB click on A1 vertex will move&snap temporal origin to it’s position (even with no need to press Ctrl to snap. It knows what you are going to do… but still, if you drag instead of click, you can move it anywhere…)

image.png
Now, just Ctrl+LMB click drag to A2 position. Finito.

In Softimage, here are not such great tools to align, and orient origin like in Maya, unfortunately.

So, what is the output? Working with pivot relocation is very similar and straightforward in Maya and Softimage. With one big difference. While in Maya you can relocate only actual origin, in Softimage, you can use temporal (or in other words - fake) origin relocation which acts exactly like in Maya, but without affecting original origin position.

So, the ideal solution: Fake origin behavior from Softimage with total control over its alignment and orientation from Maya.

How this can work:
1 – we need direct switch (button like “Edit pivot” in Maya, or “Center” button in Softimage) to be able to manipulate only origin. After this button pressed, we will be able to translate origin only, with all the usual SRT shortcuts, and snaps. After button switched off, You are back in object manipulation mode. This would serve for true origin manipulation.
2 – To manipulate fake origin, there seems to be good solution to use Alt+LMB click&drag on center of the transform gizmo. In conjunction with Ctrl (meaning Ctrl+Alt+LMB click&drag) you will be able to snap fake origin to desired element.
3 – To Align/Orient origin to some of the object’s element it would be good to set shortcut to Shift+Alt+LMB click (on pre-selection highlighted?? element… this is supposed to work in object mode as well)
4 – In case of need, there could be also Maya’s Aiming origin’s X-axis to element mimicked by Shift+Ctrl+Alt+LMB click.

In terms of Blender logic, it maybe possibly OK, if we take Origin (in Blender meaning) as the “real” origin I mentioned above, and Pivot point (in Blender meaning) as “fake”, or temporal origin. So, “Origin“ would be the real center of object which could be manipulated easily like I described in point 1 above, and “Pivot point” would be this temporal / fake origin. This could bring some logic behind those terms.

Additional, very-nice-to-have feature:

1 - Softimage COG button functionality.
The functionality is visually similar to Bounding Box Center Pivot point in Blender.

image.png
But this works differently. If you press COG button, your manipulator is always in the center of geometry of selected object, no matter where your origin location is. This is very useful in case your object is far away from the center of the scene, but it’s origin must be in the 0,0,0 for some reason.

image.png
COG button off

image.png
COG button ON

2 - Softimage manipulator always in viewport functionality.
If your object’s origin is far away from object itself, you naturally cannot see transform manipulator, because it sits on object’s origin. Softimage has beautiful function (not switched on by default), which ensures you always see the manipulator. Check video:

XSI.gif

Universal snap:

Pressing CTRL should enable (sticky toggle) snapping with predefined properties. You should be able to easily define what you are going to snap on – at least those:

1 – points – vertices, curve points, curve knots,
2 – edges – possibility to define number of edge divisions to snap on. For instance division 2 = snap to midpoint, division 3 = snap to thirds, 4= snap to quarters etc.. Division1= snap anywhere along the edge
3 – polygons/nurbs surface - snap on the surface
4 – origins / centers– snap on the origin, and snap on the center of polygons

Those are the basics, but list can continue: grids, custom grids, particles, lattices, hair, hair tip/root…

The idea is, that user should be able to define everything he wants to snap on. All of it, none of it, or anything of it. Once the CTRL is pressed (again – sticky… pressed on, released off), user can snap on all he defined.

But most of all - snap must work on ALL objects. Universally. Means, If user wants to snap origin of selected object to some component of unselected object, he should be able to snap on it. If user wants to knife cut through selected object by snapping on some other “guide” objects that are unselected, he must be able to snap on it.

Knife Tool:
Doesn’t matter what shortcut will be used to run this tool. Functionality is more important. Please, allow knife tool to snap also on unselected object’s elements, to make precise cuts.

image.png
Knife tool cutting the selected geometry with snapping on unselected objects elements.

This is extremely important - at least in game development.

Repeat last command and MMB click functionality:
Pressing “G” for repeating last used command in Maya, is not exactly life saver, but definitely carpal tunnel avoider.

Middle mouse click on any button and menu item in Softimage, for repeating last command that was used through this button or menu item is also not life saver, but it definitely speeds up work significantly. For instance – if switch viewport to material editor, then you do not need to switch it back after. Just middle mouse click on menu item, and you will end up switching between viewport and material editor. The same applies to switching display modes. Once you switch from textured, to wireframe, then you will just click on menu item with MMB, and you will be cycling viewport modes. And it works throughout complete software - you need to assign some constrain to large amount of objects separately? Just do it once, and then just select another object, and perform MMB click on menu item, and constrain will be applied. No need to go through submenus..

That’s my 2 cents addition for Blender’s industry standard keymap discussion. Hope it will be considered. All of those suggestions are strong workflow accelerators.

Marek

EDIT: You can snap origin of selected object to unselected object element in MAYA as well, of course...

**Selection:** Important logic behind adding and subtracting from selection: Shift + LMB : add to selection is ok, but do not copy it like it works in Maya. Explanation: ![image.png](https://archive.blender.org/developer/F5080664/image.png) Selecting several obects wih LMB box selection ![image.png](https://archive.blender.org/developer/F5080674/image.png) Adding another objects to selection (Shift++LMB), while selection overlaps to some of already selected objects ![image.png](https://archive.blender.org/developer/F5080677/image.png) Result is – already selected objects touched by box selection become removed from selection. This is not good. You can prevent this behavior by performing box selection by Shift+Ctrl+LMB. In this case, all the boxes will be selected. I think this is against logic of ”add to selection”, because in fact it is not only adding, but subtracting as well. So, the ideal, and most logical solution should be: Shift+LMB box selection always adds to selection everything, without subtracting from already selected. Subtracting from selection by Ctrl+LMB. Maya Shift+LMB button behavior could be then logically mimicked by Shift+Ctrl+LMB. Exactly like it works in File Explorer: ![image.png](https://archive.blender.org/developer/F5080684/image.png) LMB selection ![image.png](https://archive.blender.org/developer/F5080692/image.png) Adding items to selection by Shift + LMB ![image.png](https://archive.blender.org/developer/F5080696/image.png) Shift+Ctrl+LMB – adding unselected while removing already selected item. **Mesh Editing:** Extruding by Ctrl+E is ok. But inset shortcut “I” does not follow shortcut logic. Intuitivity, and logic speaks for using same shortcut scheme for same level type of commands. Basic mesh editing commands like inset, extrude, loop cut, and Bevel are the commands from same logical level, thus should be controlled by same shortcut logic So, if you decide to use Ctrl+ (key), you should use this logis for all the mesh editing commands For example: Extrude: Ctrl+E, Inset: Ctrl + I could be logical solution, but it is hard to press I together with Ctrl at once, so, this should be some other key within comfortable reach area. Ctrl+T? (yes, it is triangulate shortcut, but triangulate is much less used command than inset. Stronger beats weaker.) Loop cut: Ctrl+C, But this is commonly used as copy command. Copy is stronger, so it wins. Ctrl+W seems to be within comfortable area, and no other command in blender seems to be using this shortcut. Bevel: Ctrl+B. Seems like blender 2.8 will be using this shortcut for setting render border. Which, in terms of Ctrl logic should be assigned to some different shortcut. So, Ctrl+B is more important for bevel. **Animation:** Space for play/pause animation is good choice. It is commonly used in video players, and video editing apps for playback. But it needs to work very well with jump to previous/next keyframe shortcuts. Nicest solution for animation was IMHO in Softimage. Arrow Up: start / pause playback Arrow Down: pause playback Arrow left: previous frame Arrow right: next frame Ctrl+arrow left: previous keyframe (on selected object(s)) Ctrl+arrow right: next keyframe (on selected object(s)) Ctrl+arrow up: first keyframe (on selected object(s)) Ctrl+arrow down: last keyframe (on selected object(s)) Home: jump to timeline start End: jump to timeline end This is flawless example of total animation playback control under one hand. **Pivot point / origin:** Easy origin manipulation is definitely one of the most crucial things that needs to be addressed in Blender. I am not going to reinvent the wheel - combination of Maya and Softimage origin manipulation is surely the way to go. `Maya:` When translation tool is active, just press „D“ and hold. Move mouse over object, and pre-selection highlight will show you active element on which you are going to snap the origin. Click on desired element (also see „universal snap“ topis later), and origin will jump righ there. ![image.png](https://archive.blender.org/developer/F5080702/image.png) D key pressed, mouse over active object will highlight future origin location. ![image.png](https://archive.blender.org/developer/F5080706/image.png) LMB click, and origin snaps to previously pre-selection highlighted element. Once the origin is at it’s new position, it is super easy to align it to any desired direction. Just press D+Ctrl, and move mouse over object , and pre-selection highlight will show you active element on which you are going to orient the origin. ![image.png](https://archive.blender.org/developer/F5080712/image.png) Pressing D+Ctrl allows you to orient origin to any element ![image.png](https://archive.blender.org/developer/F5080720/image.png) LMB click, and origin orientation is aligned to previously pre-selection highlighted element. Moreover, you can aim origin’s x axis to any point of the object by pressing D+Ctrl+Shift ![image.png](https://archive.blender.org/developer/F5080724/image.png) Aiming origin’s X-axis to the center of pre-selection highlighted polygon, using D+Ctrl+Shift shortcut.. ![image.png](https://archive.blender.org/developer/F5080730/image.png) LMB click and origin is oriented… Of course, this works on multiple objects selected. If you want to lock pivot orientation, just check “Pin Component Pivot”. ![image.png](https://archive.blender.org/developer/F5080735/image.png) Next time you will select object again, pivot will have your custom orientation. `Softimage:` Softimage approach is less powerful, but much more systematic. While moving origin in Maya means really moving origin, in Softimage you have basically two options (super foolproof): 1 direct origin manipulation 2 temporarily overriding actual origin position (transform pivot, or temporal pivot) *1 – direct origin manipulation is super easy – just press “Center” button on right panel..* ![image.png](https://archive.blender.org/developer/F5080750/image.png) …and you can freely move origin anywhere, or when you press Ctrl while translating origin, it will snap on any desired element (point, edge, midpoint, center of polygon) . But here comes the ultimate Softimage advantage over Maya. You can actually snap origin on any unselected object’s element: ![image.png](https://archive.blender.org/developer/F5080754/image.png) Snapping origin of selected object to the vertex of unselected object (just holding Ctrl while translating). This is killer feature (see “universal snap” and “knife tool” topic). Once the origin is relocated, it stays there even after deselecting the object. *2 – Temporarily overriding actual origin position (transform pivot or, temporal pivot)* You can temporarily relocate origin without actually affecting origin position. In fact, it looks like you are relocating origin, but without “Center” button pressed. This origin relocation is temporal, and is active only while the object is selected. ![image.png](https://archive.blender.org/developer/F5080763/image.png) However this looks complicated it is super easy. Just press Alt+LMB gizmo drag, and you can temporarily relocate origin anywhere. If pressed Alt+Ctrl+LMB drag, temporal origin will snap on whatever is predefined in snap settings (again, see “universal snap” chapter). Moreover, if you need this temporal/transform origin to stay on this temporal position, even after you deselect the object, you can do it by clicking small white arrow, and choose “Lock” ![image.png](https://archive.blender.org/developer/F5080768/image.png) Locking transform/temporal origin This way you can work with origin super fast, without ever loosing it’s position accidentally. Quick example: ![image.png](https://archive.blender.org/developer/F5080776/image.png) I want these four points translate, so A1 vertex snaps to A2… ![image.png](https://archive.blender.org/developer/F5080780/image.png) Alt+LMB click on A1 vertex will move&snap temporal origin to it’s position (even with no need to press Ctrl to snap. It knows what you are going to do… but still, if you drag instead of click, you can move it anywhere…) ![image.png](https://archive.blender.org/developer/F5080786/image.png) Now, just Ctrl+LMB click drag to A2 position. Finito. In Softimage, here are not such great tools to align, and orient origin like in Maya, unfortunately. So, what is the output? Working with pivot relocation is very similar and straightforward in Maya and Softimage. With one big difference. While in Maya you can relocate only actual origin, in Softimage, you can use temporal (or in other words - fake) origin relocation which acts exactly like in Maya, but without affecting original origin position. So, the ideal solution: Fake origin behavior from Softimage with total control over its alignment and orientation from Maya. How this can work: 1 – we need direct switch (button like “Edit pivot” in Maya, or “Center” button in Softimage) to be able to manipulate only origin. After this button pressed, we will be able to translate origin only, with all the usual SRT shortcuts, and snaps. After button switched off, You are back in object manipulation mode. This would serve for true origin manipulation. 2 – To manipulate fake origin, there seems to be good solution to use Alt+LMB click&drag on center of the transform gizmo. In conjunction with Ctrl (meaning Ctrl+Alt+LMB click&drag) you will be able to snap fake origin to desired element. 3 – To Align/Orient origin to some of the object’s element it would be good to set shortcut to Shift+Alt+LMB click (on pre-selection highlighted?? element… this is supposed to work in object mode as well) 4 – In case of need, there could be also Maya’s Aiming origin’s X-axis to element mimicked by Shift+Ctrl+Alt+LMB click. In terms of Blender logic, it maybe possibly OK, if we take Origin (in Blender meaning) as the “real” origin I mentioned above, and Pivot point (in Blender meaning) as “fake”, or temporal origin. So, “Origin“ would be the real center of object which could be manipulated easily like I described in point 1 above, and “Pivot point” would be this temporal / fake origin. This could bring some logic behind those terms. **Additional, very-nice-to-have feature:** *1 - Softimage COG button functionality.* The functionality is visually similar to Bounding Box Center Pivot point in Blender. ![image.png](https://archive.blender.org/developer/F5080802/image.png) But this works differently. If you press COG button, your manipulator is always in the center of geometry of selected object, no matter where your origin location is. This is very useful in case your object is far away from the center of the scene, but it’s origin must be in the 0,0,0 for some reason. ![image.png](https://archive.blender.org/developer/F5080807/image.png) COG button off ![image.png](https://archive.blender.org/developer/F5080810/image.png) COG button ON *2 - Softimage manipulator always in viewport functionality.* If your object’s origin is far away from object itself, you naturally cannot see transform manipulator, because it sits on object’s origin. Softimage has beautiful function (not switched on by default), which ensures you always see the manipulator. Check video: ![XSI.gif](https://archive.blender.org/developer/F5080820/XSI.gif) **Universal snap:** Pressing CTRL should enable (sticky toggle) snapping with predefined properties. You should be able to easily define what you are going to snap on – at least those: 1 – points – vertices, curve points, curve knots, 2 – edges – possibility to define number of edge divisions to snap on. For instance division 2 = snap to midpoint, division 3 = snap to thirds, 4= snap to quarters etc.. Division1= snap anywhere along the edge 3 – polygons/nurbs surface - snap on the surface 4 – origins / centers– snap on the origin, and snap on the center of polygons Those are the basics, but list can continue: grids, custom grids, particles, lattices, hair, hair tip/root… The idea is, that user should be able to define everything he wants to snap on. All of it, none of it, or anything of it. Once the CTRL is pressed (again – sticky… pressed on, released off), user can snap on all he defined. But most of all - snap must work on ALL objects. Universally. Means, If user wants to snap origin of selected object to some component of unselected object, he should be able to snap on it. If user wants to knife cut through selected object by snapping on some other “guide” objects that are unselected, he must be able to snap on it. **Knife Tool:** Doesn’t matter what shortcut will be used to run this tool. Functionality is more important. Please, allow knife tool to snap also on unselected object’s elements, to make precise cuts. ![image.png](https://archive.blender.org/developer/F5080826/image.png) Knife tool cutting the selected geometry with snapping on unselected objects elements. This is extremely important - at least in game development. **Repeat last command and MMB click functionality:** Pressing “G” for repeating last used command in Maya, is not exactly life saver, but definitely carpal tunnel avoider. Middle mouse click on any button and menu item in Softimage, for repeating last command that was used through this button or menu item is also not life saver, but it definitely speeds up work significantly. For instance – if switch viewport to material editor, then you do not need to switch it back after. Just middle mouse click on menu item, and you will end up switching between viewport and material editor. The same applies to switching display modes. Once you switch from textured, to wireframe, then you will just click on menu item with MMB, and you will be cycling viewport modes. And it works throughout complete software - you need to assign some constrain to large amount of objects separately? Just do it once, and then just select another object, and perform MMB click on menu item, and constrain will be applied. No need to go through submenus.. That’s my 2 cents addition for Blender’s industry standard keymap discussion. Hope it will be considered. All of those suggestions are strong workflow accelerators. Marek EDIT: You can snap origin of selected object to unselected object element in MAYA as well, of course...

Marek: Many good points here. I largely agree, esp with the more consistent keymap comments.

Softimage's approach to animation & playback is interesting for sure.

Many of your suggestions are outside of the scope of this keymap though. Some of these things are more like feature requests, which this keymap can't fix.

My primary focus first, is making sure LMB to select and RMB for contextual menus work well. The next thing is making all the hotkeys activate the active tools, rather than the immediate-mode ones. Then there will be a process of refining the keymap.

Cheers

Marek: Many good points here. I largely agree, esp with the more consistent keymap comments. Softimage's approach to animation & playback is interesting for sure. Many of your suggestions are outside of the scope of this keymap though. Some of these things are more like feature requests, which this keymap can't fix. My primary focus first, is making sure LMB to select and RMB for contextual menus work well. The next thing is making all the hotkeys activate the active tools, rather than the immediate-mode ones. Then there will be a process of refining the keymap. Cheers

This is shaping up to be an excellent upgrade to general usability.
My only concern so far is that I think Select All operator should be mapped to Ctrl + A, in the name of keeping up with "industry standards".
It is the common select all in many applications, and the default behavior in operating systems, like the file manager, lists of items, or text input boxes, among others.

It still solves the previously raised valid issue of unintentionally selecting all in heavy scenes or potentially slow situations, or having to toggle All/None when in doubt.
A key could then be either direct Deselect All, or be kept as the current toggle behavior. Alt + A would be for deselecting, which would be consistent with many other operators "Alt behavior".

This is shaping up to be an excellent upgrade to general usability. My only concern so far is that I think *Select All* operator should be mapped to `Ctrl` + `A`, in the name of keeping up with "industry standards". It is the common select all in many applications, and the default behavior in operating systems, like the file manager, lists of items, or text input boxes, among others. It still solves the previously raised valid issue of unintentionally selecting all in heavy scenes or potentially slow situations, or having to toggle All/None when in doubt. `A` key could then be either direct *Deselect All*, or be kept as the current toggle behavior. `Alt` + `A` would be for deselecting, which would be consistent with many other operators "Alt behavior".

This is shaping up to be an excellent revamp of the default key map.

@DuarteRamos You mean "This is shaping up to be an excellent industry standard key map", right? The default Blender standard key map is another task altogether.

> This is shaping up to be an excellent revamp of the default key map. @DuarteRamos You mean "This is shaping up to be an excellent *industry standard* key map", right? The default Blender standard key map is [another task ](https://developer.blender.org/T55162) altogether.

Bill: Thanks for positive feedback. If possible I would gladly put more of my time and knowledge into this... (testing, feedbacking...)
Which of the things I mentioned above, you think would be possible to consider for industry standard keymap?

Do you have any powers to propose pivot/origin things to core team, to be considered?

You say LMB to select, RMB for contextual menu (!!!happy!!!), does it mean, industry standard key map will not rely so much on 3D cursor? As I wrote several times, I am not a friend of 3D cursor - most of it's functionality could be easily replaced by smart origin/pivot relocation implementation. But until then (and I strongly hope, Blender core team will come to knowing how important this thing is), 3D cursor presence is, in my opinion, inevitable. Do you plan to discard 3D cursor completely in industry standard keymap, or you are just planning to push it little more to the background? I would be glad if you can describe it little bit more clearly.

Bill: Thanks for positive feedback. If possible I would gladly put more of my time and knowledge into this... (testing, feedbacking...) Which of the things I mentioned above, you think would be possible to consider for industry standard keymap? Do you have any powers to propose pivot/origin things to core team, to be considered? You say LMB to select, RMB for contextual menu (!!!happy!!!), does it mean, industry standard key map will not rely so much on 3D cursor? As I wrote several times, I am not a friend of 3D cursor - most of it's functionality could be easily replaced by smart origin/pivot relocation implementation. But until then (and I strongly hope, Blender core team will come to knowing how important this thing is), 3D cursor presence is, in my opinion, inevitable. Do you plan to discard 3D cursor completely in industry standard keymap, or you are just planning to push it little more to the background? I would be glad if you can describe it little bit more clearly.

Removed subscriber: @1D_Inc

Removed subscriber: @1D_Inc

In #54963#541129, @Skrapion wrote:
I see a bunch of these have been marked as "DONE". Where is the work on the current keymap being done? Is there a keyconfig or a git branch I can try somewhere?

Can we please get this because i agree

> In #54963#541129, @Skrapion wrote: > I see a bunch of these have been marked as "DONE". Where is the work on the current keymap being done? Is there a keyconfig or a git branch I can try somewhere? Can we please get this because i agree

Added subscriber: @NNois

Added subscriber: @NNois

@WilliamReynish this is totally unfair you don't count Softimage in the Industry Standard Software WTF ???

Otherwise this is a very good job, but I have a very specific request, keyframe in Softimage is "K", this makes it the winner could you change this one please ^^ ?

For further work I believe outside of the scope here please have a look too about the Softimage workflow and essentially how the pivot point handling and snapping is done, I'm in the industry for about 25y and never saw a better workflow.

@WilliamReynish this is totally unfair you don't count Softimage in the Industry Standard Software WTF ??? Otherwise this is a very good job, but I have a very specific request, keyframe in Softimage is "K", this makes it the winner could you change this one please ^^ ? For further work I believe outside of the scope here please have a look too about the Softimage workflow and essentially how the pivot point handling and snapping is done, I'm in the industry for about 25y and never saw a better workflow.

About the default keymap or alternative keymap thing.

I assume the Blender keymap is for Blender users and the Industry one is for newcomers?
So why not making the inverse? This is a really serious issue, you don't even know how many artists I saw ditching blender some hours later for his alien keymap thing...
You should at least present that on a first run splash screen, leaving the option to old blender users to keep the old way.

About the default keymap or alternative keymap thing. I assume the Blender keymap is for Blender users and the Industry one is for newcomers? So why not making the inverse? This is a really serious issue, you don't even know how many artists I saw ditching blender some hours later for his alien keymap thing... You should at least present that on a first run splash screen, leaving the option to old blender users to keep the old way.

In #54963#544159, @NNois wrote:
@WilliamReynish this is totally unfair you don't count Softimage in the Industry Standard Software WTF ???

Softimage is EOL/dead since 2014.
This Task about the Industry Standard Keymap is more about currently relevant and more important alive Industry tools.

> In #54963#544159, @NNois wrote: > @WilliamReynish this is totally unfair you don't count Softimage in the Industry Standard Software WTF ??? Softimage is EOL/dead since 2014. This Task about the Industry Standard Keymap is more about currently relevant and more important alive Industry tools.

@NNois: Softimage was a great DCC app, but was unfortunately killed years ago, so I didn't include it here. Even so, K for keyframe has a certain logic to it. May change it.

@NNois: Softimage was a great DCC app, but was unfortunately killed years ago, so I didn't include it here. Even so, K for keyframe has a certain logic to it. May change it.

In #54963#544170, @TimurAriman wrote:

In #54963#544159, @NNois wrote:
@WilliamReynish this is totally unfair you don't count Softimage in the Industry Standard Software WTF ???

Softimage is EOL/dead since 2014.
This Task about the Industry Standard Keymap is more about currently relevant and more important alive Industry tools.

The fact is, that Softimage was the youngest app from Maya/Max/Softimage trio. I mean Softimage XSI, not Softimage 3D. XSI was completely rewritten, and released in 2000. Maya 1.0 was released in 1998, and Max 1.0 was released back in 1996.

Until XSI was eaten by Autodesk, each of main XSI releases brought groundbreaking features (2.0 - compositor, hair, fur. 3.0 - crowd system, 4.0 - RBD, syflex,,schematic view, 5.0 - GATOR, physX, FaceRobot, Shape manager, 6.0 - animation layers, MOTOR, material manager, delta referencing. 7.0 (last Avid release) - ICE. 7.5 (first Autodesk release) - viewcube... )

Softimage had youngest core of all programs, best documentation, and best performance ( multithreaded when Maya and Max were just dreaming about it).

This program deserves very serious respect. Any former Softimage user will tell you, that none of current apps have comparable workflow and logic. Those guys who created Softimage were really smart. Now, when XSI is dead, there is big chance for Blender to get inspired by this beautiful, artist friendly, and extremely well done app.

I understand, why Bill did not included Softimage. But for me it is very sad to see, how XSI heritage fades out, without being noticed.... And the fact, that it is dead, means wasting your time speaking about it for most of you. Softimage is history. Wise man said "A people without the knowledge of their past history, origin and culture is like a tree without roots". See? History! Construction history in XSI. Even now, nobody can beat it.... See? Origin! Even he is speaking how good was work with origin in XSI... See? Culture! This is culture of use - keyboard layout, and overall program logic...

But seriously. We must learn from the past. XSI can not be added to industry standard comparison, because XSI is standard. Even when it is dead. Like Da Vinci is standard for renaissance man.

Blender devs - get inspired by this history. And put the seed of XSI inside Blender. You will never regret it. Me, and (i am sure) lots of other Softimagists will gladly offer their time for you, to see this seed grow.

> In #54963#544170, @TimurAriman wrote: >> In #54963#544159, @NNois wrote: >> @WilliamReynish this is totally unfair you don't count Softimage in the Industry Standard Software WTF ??? > > Softimage is EOL/dead since 2014. > This Task about the Industry Standard Keymap is more about currently relevant and more important alive Industry tools. The fact is, that Softimage was the youngest app from Maya/Max/Softimage trio. I mean Softimage XSI, not Softimage 3D. XSI was completely rewritten, and released in 2000. Maya 1.0 was released in 1998, and Max 1.0 was released back in 1996. Until XSI was eaten by Autodesk, each of main XSI releases brought groundbreaking features (2.0 - compositor, hair, fur. 3.0 - crowd system, 4.0 - RBD, syflex,,schematic view, 5.0 - GATOR, physX, FaceRobot, Shape manager, 6.0 - animation layers, MOTOR, material manager, delta referencing. 7.0 (last Avid release) - ICE. 7.5 (first Autodesk release) - viewcube... ) Softimage had youngest core of all programs, best documentation, and best performance ( multithreaded when Maya and Max were just dreaming about it). This program deserves very serious respect. Any former Softimage user will tell you, that none of current apps have comparable workflow and logic. Those guys who created Softimage were really smart. Now, when XSI is dead, there is big chance for Blender to get inspired by this beautiful, artist friendly, and extremely well done app. I understand, why Bill did not included Softimage. But for me it is very sad to see, how XSI heritage fades out, without being noticed.... And the fact, that it is dead, means wasting your time speaking about it for most of you. Softimage is history. Wise man said "A people without the knowledge of their past history, origin and culture is like a tree without roots". See? History! Construction history in XSI. Even now, nobody can beat it.... See? Origin! Even he is speaking how good was work with origin in XSI... See? Culture! This is culture of use - keyboard layout, and overall program logic... But seriously. We must learn from the past. XSI can not be added to industry standard comparison, because XSI is standard. Even when it is dead. Like Da Vinci is standard for renaissance man. Blender devs - get inspired by this history. And put the seed of XSI inside Blender. You will never regret it. Me, and (i am sure) lots of other Softimagists will gladly offer their time for you, to see this seed grow.

I agree with you. I know Softimage XSI fairly well, and have used it in the past. It was an excellent app, with some very well thought out paradigms, workflows and features, that all seemed to fit together well, rather than being a random hodgepodge of checklist additions.

Cheers.

I agree with you. I know Softimage XSI fairly well, and have used it in the past. It was an excellent app, with some very well thought out paradigms, workflows and features, that all seemed to fit together well, rather than being a random hodgepodge of checklist additions. Cheers.

the melting pot between the Softimage XSI users and the blender users, is something that I have somehow imagined it could happen ... for the simple fact that there is a whole community of ex users of Softimage XSI that wants dead a certain company.
and Softimage XSI users were people with attributes ... maybe a minority but smart

the melting pot between the Softimage XSI users and the blender users, is something that I have somehow imagined it could happen ... for the simple fact that there is a whole community of ex users of Softimage XSI that wants dead a certain company. and Softimage XSI users were people with attributes ... maybe a minority but smart

In #54963#544379, @WilliamReynish wrote:
I agree with you. I know Softimage XSI fairly well, and have used it in the past. It was an excellent app, with some very well thought out paradigms, workflows and features, that all seemed to fit together well, rather than being a random hodgepodge of checklist additions.

Cheers.

...and, isn't that what you named, exactly what Blender lacks? :-)
There is still large Softimage users community. Alive, and kicking. Still using Softimage, because they haven't found any good alternative. What are their choices?
Maya?:

  • NOPE. Until not forced to use it, they will not.. Trust issue. It is Audtodesk. It is like buying a car from the guy, who stole your old one.
    Max?
  • Max is joke for XSI users. Substantial workflow and user experience downgrade..
    Cinema 4D?
  • Well, decent feature set, stable, easy to use. But, there is not so much Cinema users. Cinema seems to reach some amount of users, and this amount is not going to grow so much in future. And this means, limited job opportunities.
    Modo?
  • Not really.
    Houdini?
  • Yes. More technical users already migrated. Houdini's procedural approach is top notch for simulations, pyro, fluids, liquid, and all variety of simulation based effects. But day-to-day use for modeling/texturing, is still not the best.
    Blender?
  • This is for lots of XSI users light at the end of the tunnel. No - the fact it is open source is not the main Blender feature for us. Rich feature set, braveness to implement new features, rapid development, and user base growth are the main features. Showstopper is UX, logic, overall consistency, and mulish inclination to some old paradigms. But 2.8 is again raising some good amount of hopes. Industry standard Keymap even more...

Lots of former XSI users, who are seeking for "swiss army knife" DCC app, which will replace XSI, are looking at Blender. That's it. It's up on Ton, or whoever is responsible for general Blender heading, if he decides to welcome this community, with arms wide open (you all know what I mean...), or just will ignore them... I suggest - take that chance, it will pay off more than you think.

Anyway, my bi*ching around would change nothing. So let's get back to work: Bill - is there any real work, that can be done on our side, to help you make ISK great?

Marek

> In #54963#544379, @WilliamReynish wrote: > I agree with you. I know Softimage XSI fairly well, and have used it in the past. It was an excellent app, with some very well thought out paradigms, workflows and features, that all seemed to fit together well, rather than being a random hodgepodge of checklist additions. > > Cheers. ...and, isn't that what you named, exactly what Blender lacks? :-) There is still large Softimage users community. Alive, and kicking. Still using Softimage, because they haven't found any good alternative. What are their choices? Maya?: - NOPE. Until not forced to use it, they will not.. Trust issue. It is Audtodesk. It is like buying a car from the guy, who stole your old one. Max? - Max is joke for XSI users. Substantial workflow and user experience downgrade.. Cinema 4D? - Well, decent feature set, stable, easy to use. But, there is not so much Cinema users. Cinema seems to reach some amount of users, and this amount is not going to grow so much in future. And this means, limited job opportunities. Modo? - Not really. Houdini? - Yes. More technical users already migrated. Houdini's procedural approach is top notch for simulations, pyro, fluids, liquid, and all variety of simulation based effects. But day-to-day use for modeling/texturing, is still not the best. Blender? - This is for lots of XSI users light at the end of the tunnel. No - the fact it is open source is not the main Blender feature for us. Rich feature set, braveness to implement new features, rapid development, and user base growth are the main features. Showstopper is UX, logic, overall consistency, and mulish inclination to some old paradigms. But 2.8 is again raising some good amount of hopes. Industry standard Keymap even more... Lots of former XSI users, who are seeking for "swiss army knife" DCC app, which will replace XSI, are looking at Blender. That's it. It's up on Ton, or whoever is responsible for general Blender heading, if he decides to welcome this community, with arms wide open (you all know what I mean...), or just will ignore them... I suggest - take that chance, it will pay off more than you think. Anyway, my bi*ching around would change nothing. So let's get back to work: Bill - is there any real work, that can be done on our side, to help you make ISK great? Marek

@MarekHolly: Once we have it implemented, which should be in a few weeks or so, you can help out by testing and giving feedback.

@MarekHolly: Once we have it implemented, which should be in a few weeks or so, you can help out by testing and giving feedback.

Added subscriber: @Loner-2

Added subscriber: @Loner-2

I am sorry, but question at me. When include this at standard keymap in Blender user preferences? Because you have to start getting used to the new keymap, and her is not in user preferences. A she will in beta?

I am sorry, but question at me. When include this at standard keymap in Blender user preferences? Because you have to start getting used to the new keymap, and her is not in user preferences. A she will in beta?

Added subscriber: @RafaelHattge

Added subscriber: @RafaelHattge

As someone commented above, industry standard should be the default keymap, and a "classic" option could be added perhaps, for the current one. People getting into 3d usually are already familiar with a lot of software, and Blender is the last one they are gonna consider when they try to navigate inside the application. Blender as it currently is, contradicts the navigation and selection system of every software out there, including operating systems. Learning 3d is hard enough without having to relearn everything you know about navigating on a computer. I went to Maya 10 years ago after trying blender because of this, I'm not the only one. But why should it be the default, and not just an option? Because future realeased training and tutorials will be more inclined to teach the default keymap, and this is specially important in training aimed towards beginners. Advanced users are not that much concerned about the shortcuts when watching tutorials, they already know most of the basic ones. And throughout the software's lifecycle, it is most likely going to have a lot more new users than the ones currently using the software. ESPECIALLY if you guys adopt a new keymap system that is intuitive to people that already uses software like Photoshop, Illustrator, Unreal Engine, Unity, Maya, Cinema 4D... I've been following the development of Blender for a long time, and I want to migrate from Maya, but I just can't when it makes my muscle memory works against me, giving me zero benefit on my workflow.

As someone commented above, industry standard should be the default keymap, and a "classic" option could be added perhaps, for the current one. People getting into 3d usually are already familiar with a lot of software, and Blender is the last one they are gonna consider when they try to navigate inside the application. Blender as it currently is, contradicts the navigation and selection system of every software out there, including operating systems. Learning 3d is hard enough without having to relearn everything you know about navigating on a computer. I went to Maya 10 years ago after trying blender because of this, I'm not the only one. But why should it be the default, and not just an option? Because future realeased training and tutorials will be more inclined to teach the default keymap, and this is specially important in training aimed towards beginners. Advanced users are not that much concerned about the shortcuts when watching tutorials, they already know most of the basic ones. And throughout the software's lifecycle, it is most likely going to have a lot more new users than the ones currently using the software. ESPECIALLY if you guys adopt a new keymap system that is intuitive to people that already uses software like Photoshop, Illustrator, Unreal Engine, Unity, Maya, Cinema 4D... I've been following the development of Blender for a long time, and I want to migrate from Maya, but I just can't when it makes my muscle memory works against me, giving me zero benefit on my workflow.

In #54963#544950, @WilliamReynish wrote:
@MarekHolly: Once we have it implemented, which should be in a few weeks or so, you can help out by testing and giving feedback.

Bill, if I may, here is sum of my previous posts + couple of my thoughts about shortcuts hierarchy rules and prioritizing.

1. Operating system inherited commands: are the highest, first grade priority (like Ctrl+A,Crl+C,Ctrl+V, mouse selection logic, left click (with Shift, Ctrl+Shift..), right click for context menu, etc...). If you really care about new users - if you want current children to become future Blender users, keep this in mind - those are the shortcuts of their first contact with computer. It will be stored deepest in their memory. That's why every program respect it. This is holy grail. Commands from this club, are supposed to win against anything else.

2. Common shortcuts from other DCC: the wider use of specific command, the higher priority. Although, you can find areas of improvement - like Maya box selection I mentioned above - but first rule should solve this. Some of those commands can be beaten by 3rd rule.

3. Ergonomics: Left hand would naturally sit on left part of keyboard, because of navigation shortcuts - which is most frequently used. All the other command should be prioritized according frequency of use. Most frequent shortcuts should sit just under left hand. The less frequent command, the farther to the right. That's why W,E,R, is better than G,R,S. Also ergonomics rule should beat Common shortcuts rule in some cases. Like component object/selection in Maya (F8-F12), is against ergonomics, thus 1-5 is far better.

4. Key combination logic: as mentioned in my previous post, same command class = same key combination logic. For instance - using CTRL+"key" for mesh editing commands like extrude (Ctrl+E), means, inset command (from the same command class) should use same logic - CTRL+"key". Although, there is really lot of commands inherited from operating system which use Ctrl+"key" combination.. So in this case, I would suggest to look at different key combination. For instance Alt+"Key", which could serve much better according ergonomics rule.

5. Command name rule: While Ctrl+E for extrude is OK, Ctrl+I for inset is not (ergonomics rule). So, it is OK for shortcuts to follow first letter of commands name, but Ergonomics rule is stronger. As soon as shortcut will have good position under left hand, muscle memory will do the rest. No need to look at the keyboard to correctly press Ctrl+I.

6. Left handed users: Sorry to say that, but ignore them for now. I know, it is politically incorrect. And a lot of people could be angry on me. But I have good reasons to say that.

a. There is approximately 10% of world population left handed. 90% vs 10%. Stronger wins.
b. None of major apps and systems is specifically designed for left handed users. Windows can be only customized (switch to left button priority), Maya - nothing, Houdini - (just the possibility to roll out menu to the right side, so it is easier for left handed to select.....)
c. There can not be any keyboard shortcut logic which will fit left and right handed people at the same time, and equally well. One group will always suffer, one less. But nobody will be satisfied.
d. Most of left handed people are using their own keymap anyway.

I do not say, to abandon left handed people at all. But now, good implementation of ISK is priority.

Marek

> In #54963#544950, @WilliamReynish wrote: > @MarekHolly: Once we have it implemented, which should be in a few weeks or so, you can help out by testing and giving feedback. Bill, if I may, here is sum of my previous posts + couple of my thoughts about shortcuts hierarchy rules and prioritizing. ***1. Operating system inherited commands:*** are the highest, first grade priority (like Ctrl+A,Crl+C,Ctrl+V, mouse selection logic, left click (with Shift, Ctrl+Shift..), right click for context menu, etc...). If you really care about new users - if you want current children to become future Blender users, keep this in mind - those are the shortcuts of their first contact with computer. It will be stored deepest in their memory. That's why every program respect it. This is holy grail. Commands from this club, are supposed to win against anything else. ***2. Common shortcuts from other DCC:*** the wider use of specific command, the higher priority. Although, you can find areas of improvement - like Maya box selection I mentioned above - but first rule should solve this. Some of those commands can be beaten by 3rd rule. ***3. Ergonomics***: Left hand would naturally sit on left part of keyboard, because of navigation shortcuts - which is most frequently used. All the other command should be prioritized according frequency of use. Most frequent shortcuts should sit just under left hand. The less frequent command, the farther to the right. That's why W,E,R, is better than G,R,S. Also ergonomics rule should beat Common shortcuts rule in some cases. Like component object/selection in Maya (F8-F12), is against ergonomics, thus 1-5 is far better. ***4. Key combination logic:*** as mentioned in my previous post, same command class = same key combination logic. For instance - using CTRL+"key" for mesh editing commands like extrude (Ctrl+E), means, inset command (from the same command class) should use same logic - CTRL+"key". Although, there is really lot of commands inherited from operating system which use Ctrl+"key" combination.. So in this case, I would suggest to look at different key combination. For instance Alt+"Key", which could serve much better according ergonomics rule. ***5. Command name rule:*** While Ctrl+E for extrude is OK, Ctrl+I for inset is not (ergonomics rule). So, it is OK for shortcuts to follow first letter of commands name, but Ergonomics rule is stronger. As soon as shortcut will have good position under left hand, muscle memory will do the rest. No need to look at the keyboard to correctly press Ctrl+I. ***6. Left handed users:*** Sorry to say that, but ignore them for now. I know, it is politically incorrect. And a lot of people could be angry on me. But I have good reasons to say that. a. There is approximately 10% of world population left handed. 90% vs 10%. Stronger wins. b. None of major apps and systems is specifically designed for left handed users. Windows can be only customized (switch to left button priority), Maya - nothing, Houdini - (just the possibility to roll out menu to the right side, so it is easier for left handed to select.....) c. There can not be any keyboard shortcut logic which will fit left and right handed people at the same time, and equally well. One group will always suffer, one less. But nobody will be satisfied. d. Most of left handed people are using their own keymap anyway. I do not say, to abandon left handed people at all. But now, good implementation of ISK is priority. Marek

Added subscriber: @Znio.G

Added subscriber: @Znio.G

@RafaelHattge i agree with you in most parts making blender more intuitive in left select mode is essential however blender has things that are completely different from other apps like 3d cursor, entering/exiting modes..etc they need to be taken into consideration...i came from maya and i had to heavily modify the 2.8 right click keymap to work with left click/select box ..etc..some parts need more work like pivot pointing from origin and snapping.....pie menus help a bit but you always have to enter and exit edit mode and use menus.

@MarekHolly i am a left handed and i don't think this is an issue..it works very well for us since in blender u can swap everything top/bottom or left and right, actually when i used maya i wasn't able to change certain things because they are hard-coded with not the possibility to change them.

@RafaelHattge i agree with you in most parts making blender more intuitive in left select mode is essential however blender has things that are completely different from other apps like 3d cursor, entering/exiting modes..etc they need to be taken into consideration...i came from maya and i had to heavily modify the 2.8 right click keymap to work with left click/select box ..etc..some parts need more work like pivot pointing from origin and snapping.....pie menus help a bit but you always have to enter and exit edit mode and use menus. @MarekHolly i am a left handed and i don't think this is an issue..it works very well for us since in blender u can swap everything top/bottom or left and right, actually when i used maya i wasn't able to change certain things because they are hard-coded with not the possibility to change them.

6. Left handed users: Sorry to say that, but ignore them for now. I know, it is politically incorrect. And a lot of people could be angry on me. But I have good reasons to say that.

a. There is approximately 10% of world population left handed. 90% vs 10%. Stronger wins.
b. None of major apps and systems is specifically designed for left handed users. Windows can be only customized (switch to left button priority), Maya - nothing, Houdini - (just the possibility to roll out menu to the right side, so it is easier for left handed to select.....)
c. There can not be any keyboard shortcut logic which will fit left and right handed people at the same time, and equally well. One group will always suffer, one less. But nobody will be satisfied.
d. Most of left handed people are using their own keymap anyway.

I do not say, to abandon left handed people at all. But now, good implementation of ISK is priority.

I am left handed and I've never had any issue with any program, I don't even use the mouse with my left hand, is just weird. Maybe I'm in the minority of a minority hehe, but I don't think a left handed specific keymap would be of much help, it would only confuse people more. Being left or right handed is only important when you're setting up a wacom tablet, otherwise is just a waste of time.

About the Industry Standard Keymap being the default I completely agree. Any experienced user of Blender already knows how to change the preferences according to their own taste so there's no loss with having the current keymap as an option, call it Classic Keymap, or Blender Keymap and add a dropdown to choose the desired keymap on the splash screen.

> ***6. Left handed users:*** Sorry to say that, but ignore them for now. I know, it is politically incorrect. And a lot of people could be angry on me. But I have good reasons to say that. > > a. There is approximately 10% of world population left handed. 90% vs 10%. Stronger wins. > b. None of major apps and systems is specifically designed for left handed users. Windows can be only customized (switch to left button priority), Maya - nothing, Houdini - (just the possibility to roll out menu to the right side, so it is easier for left handed to select.....) > c. There can not be any keyboard shortcut logic which will fit left and right handed people at the same time, and equally well. One group will always suffer, one less. But nobody will be satisfied. > d. Most of left handed people are using their own keymap anyway. > > I do not say, to abandon left handed people at all. But now, good implementation of ISK is priority. > I am left handed and I've never had any issue with any program, I don't even use the mouse with my left hand, is just weird. Maybe I'm in the minority of a minority hehe, but I don't think a left handed specific keymap would be of much help, it would only confuse people more. Being left or right handed is only important when you're setting up a wacom tablet, otherwise is just a waste of time. About the Industry Standard Keymap being the default I completely agree. Any experienced user of Blender already knows how to change the preferences according to their own taste so there's no loss with having the current keymap as an option, call it Classic Keymap, or Blender Keymap and add a dropdown to choose the desired keymap on the splash screen.

Added subscriber: @orvb

Added subscriber: @orvb

Added subscriber: @GatisKurzemnieks

Added subscriber: @GatisKurzemnieks

Added subscriber: @0rAngE

Added subscriber: @0rAngE

For Sculpting and any brush/painting related modes, can we have something like in the addon by Vrav, Sculpt Paint Workflow Suite.
The feature allows both brush size and strength to be adjusted by gestures on the same hotkey. RMB Click-Drag Up/Down=Strenth; RMB Click-Drag Left/Right=Size.
You could borrow some of the code he has?

Vrav
https://blenderartists.org/t/addon-sculpt-paint-workflow-suite/553819

This is (generally) the way it is in Silo, 3DCoat, Sculptris. I find it the most ergonomic way to adjust Strength/Size for brush related modes.

For Sculpting and any brush/painting related modes, can we have something like in the addon by Vrav, Sculpt Paint Workflow Suite. The feature allows both brush size and strength to be adjusted by gestures on the same hotkey. RMB Click-Drag Up/Down=Strenth; RMB Click-Drag Left/Right=Size. You could borrow some of the code he has? Vrav https://blenderartists.org/t/addon-sculpt-paint-workflow-suite/553819 This is (generally) the way it is in Silo, 3DCoat, Sculptris. I find it the most ergonomic way to adjust Strength/Size for brush related modes.

@0rAngE: That's certainly a quite interesting way to handle basic brush settings. I will keep this in mind.

@0rAngE: That's certainly a quite interesting way to handle basic brush settings. I will keep this in mind.
William Reynish changed title from Blender 2.8 Industry Standard Keymap to Compatible Keymap (previously: Industry Standard Keymap) 2018-11-18 21:03:34 +01:00

In #54963#521774, @LucianoMunoz wrote:
So in essence the "industry standard" keymap is just a mix of the most common hotkeys from every major software... in the end someone is gonna have to do the maya keymap, the max keymap, the houdini keymap, and the cinema 4d keymap, and this "industry standard really weirdly mixed mix of things " will become obsolete pretty fast.

Sorry for the negativity. it just hit me, and to tell you my experience, i've turned and help turn a couple of studios and artists to blender, and honestly the only things bothering people are the move, rotate, scale, but really more importantly the way you move around your scene and the rmb / lmb thing, thats it. the rest of the hotkeys they dont mind, and they love having SPACE BAR as search functions because it aids them learning the rest of the stuff they need quite fast, and its all compatible to learning the blender defaults.

just my 2 cents.

Also, please restore to the RIGHT CLICK CONTEXT menu the SEARCH function at top of the context menu list. Free "F3" to be available for other custom entry with custom keyboard shortcuts.

Also, please, for heaven´s sake: Don´t make 5-7 possible ways to combine the same procedure in the shortcut keys. Just place 1 command alone. The keyboard shortcut list needs to be cleaned of redundancy. It almost looks like if every workspace has a different "G" command to move. Since there are 21 workspaces available, it´s unimaginable why "move" has to has so many G combinations, let alone all other "alternative" methods inside the same editor: to manipulate and move things.

Let´s clean the redundancy on the keyboard shortcuts per workspace. If "Q" is to be selection, let it be selection for everything in every interaction mode/editor.

Thanks.

> In #54963#521774, @LucianoMunoz wrote: > So in essence the "industry standard" keymap is just a mix of the most common hotkeys from every major software... in the end someone is gonna have to do the maya keymap, the max keymap, the houdini keymap, and the cinema 4d keymap, and this "industry standard really weirdly mixed mix of things " will become obsolete pretty fast. > > Sorry for the negativity. it just hit me, and to tell you my experience, i've turned and help turn a couple of studios and artists to blender, and honestly the only things bothering people are the move, rotate, scale, but really more importantly the way you move around your scene and the rmb / lmb thing, thats it. the rest of the hotkeys they dont mind, and they love having SPACE BAR as search functions because it aids them learning the rest of the stuff they need quite fast, and its all compatible to learning the blender defaults. > > just my 2 cents. Also, please restore to the RIGHT CLICK CONTEXT menu the SEARCH function at top of the context menu list. Free "F3" to be available for other custom entry with custom keyboard shortcuts. Also, please, for heaven´s sake: Don´t make 5-7 possible ways to combine the same procedure in the shortcut keys. Just place 1 command alone. The keyboard shortcut list needs to be cleaned of redundancy. It almost looks like if every workspace has a different "G" command to move. Since there are 21 workspaces available, it´s unimaginable why "move" has to has so many G combinations, let alone all other "alternative" methods inside the same editor: to manipulate and move things. Let´s clean the redundancy on the keyboard shortcuts per workspace. If "Q" is to be selection, let it be selection for everything in every interaction mode/editor. Thanks.

@PierreSchiller: Adding the operator search into the contextual menu is a neat idea. Technically it's not trivial though - it's not currently possible to do that. We could keep it in mind for something to do, perhaps in a later release.

Edit: It can be done in a simple way to having the Search menu as a normal menu item, just like we do in the Node Editor Add menu. But it would be much nicer if the search field itself could be properly integrated here.

As for the rest of your post, I didn't understand it I'm afraid.

@PierreSchiller: Adding the operator search into the contextual menu is a neat idea. Technically it's not trivial though - it's not currently possible to do that. We could keep it in mind for something to do, perhaps in a later release. Edit: It can be done in a simple way to having the Search menu as a normal menu item, just like we do in the Node Editor Add menu. But it would be much nicer if the search field itself could be properly integrated here. As for the rest of your post, I didn't understand it I'm afraid.

In #54963#555347, @PierreSchiller wrote:
Also, please restore to the RIGHT CLICK CONTEXT menu the SEARCH function at top of the context menu list. Free "F3" to be available for other custom entry with custom keyboard shortcuts.

We don't have a "search" row in the tables yet, but there's some precedence here. This is how Unreal works, at least in the nodes view: you right-click, and it gives you a list of all the objects you can add, with copy/paste/etc at the bottom, and a search bar at the top. You can start typing immediately to narrow down the context options, and it has a "context sensitive" checkbox which determines whether or not it filters out options based on what's currently selected.

> In #54963#555347, @PierreSchiller wrote: > Also, please restore to the RIGHT CLICK CONTEXT menu the SEARCH function at top of the context menu list. Free "F3" to be available for other custom entry with custom keyboard shortcuts. We don't have a "search" row in the tables yet, but there's some precedence here. This is how Unreal works, at least in the nodes view: you right-click, and it gives you a list of all the objects you can add, with copy/paste/etc at the bottom, and a search bar at the top. You can start typing immediately to narrow down the context options, and it has a "context sensitive" checkbox which determines whether or not it filters out options based on what's currently selected.

Removed subscriber: @Dunathan

Removed subscriber: @Dunathan

Hi Bill
Do you already have some ETA, when we can test it out?

Hi Bill Do you already have some ETA, when we can test it out?
Brecht Van Lommel changed title from Compatible Keymap (previously: Industry Standard Keymap) to Industry Compatible Keymap 2018-11-19 14:14:28 +01:00

Added subscriber: @hydrogen-2

Added subscriber: @hydrogen-2

@MarekHolly: This keymap is tied to fixing some issues related to left click selection that we have to do with the default Blender left click setting. When more of those issues are solved, we should be able to include this keymap too.

@MarekHolly: This keymap is tied to fixing some issues related to left click selection that we have to do with the default Blender left click setting. When more of those issues are solved, we should be able to include this keymap too.

Added subscriber: @Dheim

Added subscriber: @Dheim

In #54963#545676, @MarekHolly wrote

Bill, if I may, here is sum of my previous posts + couple of my thoughts about shortcuts hierarchy rules and prioritizing.

I could not agree more with all of the ergonomic issues pointed out here.

> In #54963#545676, @MarekHolly wrote > > Bill, if I may, here is sum of my previous posts + couple of my thoughts about shortcuts hierarchy rules and prioritizing. > I could not agree more with all of the ergonomic issues pointed out here.

In #54963#556853, @WilliamReynish wrote:
@MarekHolly: This keymap is tied to fixing some issues related to left click selection that we have to do with the default Blender left click setting. When more of those issues are solved, we should be able to include this keymap too.

Wait. I would like to test and start using new keymap.

> In #54963#556853, @WilliamReynish wrote: > @MarekHolly: This keymap is tied to fixing some issues related to left click selection that we have to do with the default Blender left click setting. When more of those issues are solved, we should be able to include this keymap too. Wait. I would like to test and start using new keymap.

Hi. Since blender 2.8 beta is out, it would be cool if you wold give us a chance to try and test this key configuration. Even as a temporary separate file. I am planning to put a lot of time in learning blender and I will be happy to test new keymap and give you valuable feedback.

Hi. Since blender 2.8 beta is out, it would be cool if you wold give us a chance to try and test this key configuration. Even as a temporary separate file. I am planning to put a lot of time in learning blender and I will be happy to test new keymap and give you valuable feedback.

Added subscriber: @KloWorks

Added subscriber: @KloWorks

@ACap99: It's coming. The keymap itself is done and is trivial to do, but for it to work well, left click support has to be improved still.

Follow the progress here: https://developer.blender.org/T57918

@ACap99: It's coming. The keymap itself is done and is trivial to do, but for it to work well, left click support has to be improved still. Follow the progress here: https://developer.blender.org/T57918

Added subscriber: @pitom

Added subscriber: @pitom

Added subscriber: @stephenwongdesign

Added subscriber: @stephenwongdesign

Added subscriber: @Midda

Added subscriber: @Midda

In #54963#543169, @MarekHolly wrote:
Selection:

Maya:
When translation tool is active, just press „D“ and hold. Move mouse over object, and pre-selection highlight will show you active element on which you are going to snap the origin. Click on desired element (also see „universal snap“ topis later), and origin will jump righ there.

image.png

speaking about pressing "D" there isn't function in blender to make "D" active by holding it then deactivate when release the "D" key.

sssdsss.png

cccr.PNG

the "release" in blender act different from "release" in Maya.

in Maya :
"Release" value = holding key will active until you release the key it will deactivate.
in Blender :
"Release" value = holding key nothing will happen until you release the key it become active ! which I see no different from "Click".

adding new function or fix "release" function in blender will be great.

its not new operator actually but its use in some specific exclusive key ( ctrl,alt,shift and "S" color picker in texture paint layout.).

I also talk about it I give some example :
https://devtalk.blender.org/t/keyboard-release-not-working-the-correct-way/3876/9

so hope it will add in blender its useful operator for many cases.

> In #54963#543169, @MarekHolly wrote: > **Selection:** > > `Maya:` > When translation tool is active, just press „D“ and hold. Move mouse over object, and pre-selection highlight will show you active element on which you are going to snap the origin. Click on desired element (also see „universal snap“ topis later), and origin will jump righ there. > > ![image.png](https://archive.blender.org/developer/F5080702/image.png) speaking about pressing "D" there isn't function in blender to make "D" active by holding it then deactivate when release the "D" key. ![sssdsss.png](https://archive.blender.org/developer/F5808797/sssdsss.png) ![cccr.PNG](https://archive.blender.org/developer/F5808796/cccr.PNG) the "release" in blender act different from "release" in Maya. in Maya : "Release" value = holding key will active until you release the key it will deactivate. in Blender : "Release" value = holding key nothing will happen until you release the key it become active ! which I see no different from "Click". adding new function or fix "release" function in blender will be great. its not new operator actually but its use in some specific exclusive key ( ctrl,alt,shift and "S" color picker in texture paint layout.). I also talk about it I give some example : https://devtalk.blender.org/t/keyboard-release-not-working-the-correct-way/3876/9 so hope it will add in blender its useful operator for many cases.

Added subscriber: @Rasmus-Rantamaki

Added subscriber: @Rasmus-Rantamaki

Added subscriber: @TheFaceless

Added subscriber: @TheFaceless

Added subscriber: @zaha

Added subscriber: @zaha

Added subscriber: @De3n

Added subscriber: @De3n

Added subscriber: @cez

Added subscriber: @cez

This is great, is this ticket still alive? This is exactly the config I need, could we try it as is?

This is great, is this ticket still alive? This is exactly the config I need, could we try it as is?

Added subscriber: @clawjelly

Added subscriber: @clawjelly

Added subscriber: @KartoonHead

Added subscriber: @KartoonHead

Added subscriber: @DanieleViagi

Added subscriber: @DanieleViagi

@cez: It's still alive but still waiting for issues to be solved with left click described here: #57918. Now that left click is enabled by default, it's paramount that we tackle these remaining issues anyway, and that will also pave the way for keymaps such as this one.

@cez: It's still alive but still waiting for issues to be solved with left click described here: #57918. Now that left click is enabled by default, it's paramount that we tackle these remaining issues anyway, and that will also pave the way for keymaps such as this one.

Added subscriber: @Frozen_Death_Knight

Added subscriber: @Frozen_Death_Knight

Added subscriber: @Pendali

Added subscriber: @Pendali

Added subscriber: @yrrnn

Added subscriber: @yrrnn

This keyboard is mandatory for the new blender.
Your work on this is fantastic but this can't be without work on snapping too (so removing the 3d pointer). Please don't forget that

This keyboard is mandatory for the new blender. Your work on this is fantastic but this can't be without work on snapping too (so removing the 3d pointer). Please don't forget that

In #54963#593809, @WilliamReynish wrote:
@cez: It's still alive but still waiting for issues to be solved with left click described here: #57918. Now that left click is enabled by default, it's paramount that we tackle these remaining issues anyway, and that will also pave the way for keymaps such as this one.

Hey, William!

Good job on taking the time to work on this. I am also in the middle of making my own keybinds for Blender 2.8, and I think I have found a solution to deselect everything by using double L click (as described in your other thread , which works while clicking inside and outside o the mesh. Just take the code from the keybind "select or deselect all", then deactivate everything except "deselect" and assign it to L click with the double modifier. That way you can avoid deselecting everything by accidentally clicking once outside of the mesh.

As for the rest of the keybinds, I took a different approach to a bunch of stuff. For instance, I managed to add two pie menus on the same command by having ctrl, shift, and alt modifiers as well as adding double R click into the mix, which makes you able to assign two separate menus to the same keybinds while only needing to click once or twice to access each of them. Really simplifies a lot of the workflow by reducing the amount of keys on your keyboard you need to memorize to access each of these menus, since you can access them all with just your mouse and ctrl, shift, and alt.

> In #54963#593809, @WilliamReynish wrote: > @cez: It's still alive but still waiting for issues to be solved with left click described here: #57918. Now that left click is enabled by default, it's paramount that we tackle these remaining issues anyway, and that will also pave the way for keymaps such as this one. Hey, William! Good job on taking the time to work on this. I am also in the middle of making my own keybinds for Blender 2.8, and I think I have found a solution to deselect everything by using double L click (as described in [your other thread ](https://developer.blender.org/T57918), which works while clicking inside and outside o the mesh. Just take the code from the keybind "select or deselect all", then deactivate everything except "deselect" and assign it to L click with the double modifier. That way you can avoid deselecting everything by accidentally clicking once outside of the mesh. As for the rest of the keybinds, I took a different approach to a bunch of stuff. For instance, I managed to add two pie menus on the same command by having ctrl, shift, and alt modifiers as well as adding double R click into the mix, which makes you able to assign two separate menus to the same keybinds while only needing to click once or twice to access each of them. Really simplifies a lot of the workflow by reducing the amount of keys on your keyboard you need to memorize to access each of these menus, since you can access them all with just your mouse and ctrl, shift, and alt.

Removed subscriber: @hydrogen-2

Removed subscriber: @hydrogen-2

Added subscriber: @Ferodun

Added subscriber: @Ferodun

In #54963#599506, @NNois wrote:
This keyboard is mandatory for the new blender.
Your work on this is fantastic but this can't be without work on snapping too (so removing the 3d pointer). Please don't forget that

Snapping, and working with pivot is crucial... any news Bill?

> In #54963#599506, @NNois wrote: > This keyboard is mandatory for the new blender. > Your work on this is fantastic but this can't be without work on snapping too (so removing the 3d pointer). Please don't forget that Snapping, and working with pivot is crucial... any news Bill?

Added subscriber: @brecht

Added subscriber: @brecht

I’m still waiting on @brecht who is doing left click select fixes.

I’m still waiting on @brecht who is doing left click select fixes.

Added subscriber: @Somnolent

Added subscriber: @Somnolent
Contributor

@MarekHolly
Hey, if you are looking for a keymap that is complete, but ergonomic (unlike plans for this one), then check this out: https://blenderartists.org/t/a-proper-keymap-for-blender-2-8/1145406

(Sorry for spamming this task, but I couldn't find a way to contact Marek otherwise. Not possible to DM people here, apparently.)

@MarekHolly Hey, if you are looking for a keymap that is complete, but ergonomic (unlike plans for this one), then check this out: https://blenderartists.org/t/a-proper-keymap-for-blender-2-8/1145406 (Sorry for spamming this task, but I couldn't find a way to contact Marek otherwise. Not possible to DM people here, apparently.)

In #54963#612762, @Rawalanche wrote:
@MarekHolly
Hey, if you are looking for a keymap that is complete, but ergonomic (unlike plans for this one), then check this out: https://blenderartists.org/t/a-proper-keymap-for-blender-2-8/1145406

(Sorry for spamming this task, but I couldn't find a way to contact Marek otherwise. Not possible to DM people here, apparently.)

Thanks Ludvik.
I will take a look on this during upcoming week. (Sorry, missed you on linkedIN)

> In #54963#612762, @Rawalanche wrote: > @MarekHolly > Hey, if you are looking for a keymap that is complete, but ergonomic (unlike plans for this one), then check this out: https://blenderartists.org/t/a-proper-keymap-for-blender-2-8/1145406 > > (Sorry for spamming this task, but I couldn't find a way to contact Marek otherwise. Not possible to DM people here, apparently.) Thanks Ludvik. I will take a look on this during upcoming week. (Sorry, missed you on linkedIN)

Added subscriber: @centuruk

Added subscriber: @centuruk

Added subscriber: @renatoiwa

Added subscriber: @renatoiwa

Added subscriber: @hawc445

Added subscriber: @hawc445

Added subscriber: @Kartridge

Added subscriber: @Kartridge

Added subscriber: @PiettroJewelry

Added subscriber: @PiettroJewelry

For Gizmo or Gimbol , we using for move or rotation or scaling like first we click in G for moving and than for Shift X,Y,Z, for can make same cordinate make play to move instead of this we can use Gimbol logo there is on it in Blender 2.8 Shift X,Y,Z, button for can move or rotate or scaling , i mean not the arrow i mean between arrow the square in Gimbol which you let to move any direction in same axis , as before we click on Spacebar and than G or R or S for using Gimbol now when i click on Spacebar and G or R or S i see Toggle bar Left Hide and Shown , i mean we cant using Gimbol . Its important for can using Gimbol as shortcut hotkeys as before .
Thank you.

For Gizmo or Gimbol , we using for move or rotation or scaling like first we click in G for moving and than for Shift X,Y,Z, for can make same cordinate make play to move instead of this we can use Gimbol logo there is on it in Blender 2.8 Shift X,Y,Z, button for can move or rotate or scaling , i mean not the arrow i mean between arrow the square in Gimbol which you let to move any direction in same axis , as before we click on Spacebar and than G or R or S for using Gimbol now when i click on Spacebar and G or R or S i see Toggle bar Left Hide and Shown , i mean we cant using Gimbol . Its important for can using Gimbol as shortcut hotkeys as before . Thank you.

Added subscriber: @NjordyJovanovich

Added subscriber: @NjordyJovanovich

Hey Bill
Can we get some status update? I mean, some real estimates when we can test it. Good keymap in conjunction with soon-to-be released redshift addon is gonna be the biggest Blender's gate opener to wide pro audience. Really, really important thing.

Hey Bill Can we get some status update? I mean, some real estimates when we can test it. Good keymap in conjunction with soon-to-be released redshift addon is gonna be the biggest Blender's gate opener to wide pro audience. Really, really important thing.

@MarekHolly just like you I am also eagerly awaiting this. The answer is the same as before: to be able to do this well, Blender is missing some capabilities, described in the Left Click Select Fixes document referenced earlier.

Over the past many months, the focus has been more or less exclusively on the bug tracker, which has taken longer than anticipated to get under control and to make Blender 2.8 more stable.

The core developers in the Blender Institute have been assisting the Spring team to make sure they were able to finish their work. This keymap stuff was not a priority for them.

The good news is that, now that the Spring project is over, hopefully there will now be more focus on wrapping up these last tasks.

@MarekHolly just like you I am also eagerly awaiting this. The answer is the same as before: to be able to do this well, Blender is missing some capabilities, described in the Left Click Select Fixes document referenced earlier. Over the past many months, the focus has been more or less exclusively on the bug tracker, which has taken longer than anticipated to get under control and to make Blender 2.8 more stable. The core developers in the Blender Institute have been assisting the Spring team to make sure they were able to finish their work. This keymap stuff was not a priority for them. The good news is that, now that the Spring project is over, hopefully there will now be more focus on wrapping up these last tasks.

In #54963#647455, @WilliamReynish wrote:
The good news is that, now that the Spring project is over, hopefully there will now be more focus on wrapping up these last tasks.

That is a great news. Because I cannot use Blender fully until it's done. :)

P.S. And, yes, I do think what "Industry Standard" should be default one (because insane navigation/shortcuts was the biggest turn off for me, as a newbie),

> In #54963#647455, @WilliamReynish wrote: > The good news is that, now that the Spring project is over, hopefully there will now be more focus on wrapping up these last tasks. That is a great news. Because I cannot use Blender fully until it's done. :) P.S. And, yes, I do think what "Industry Standard" should be default one (because insane navigation/shortcuts was the biggest turn off for me, as a newbie),

Added subscriber: @Werwack

Added subscriber: @Werwack

Hello,
We are a big studio moving to Blender. Having an easy way to change the key mapping to mach the industry standard would be for us a major addition to Blender. It would considerably facilitate the entry of all our artists (especially the more reluctant ones, because of habits) to this new DCC tool and would help all of us to avoid frustration when switching from app to app during the day because of our mixed environment.
Thank you, Blender team, for your understanding of the importance of this point.

Hello, We are a big studio moving to Blender. Having an easy way to change the key mapping to mach the industry standard would be for us a major addition to Blender. It would considerably facilitate the entry of all our artists (especially the more reluctant ones, because of habits) to this new DCC tool and would help all of us to avoid frustration when switching from app to app during the day because of our mixed environment. Thank you, Blender team, for your understanding of the importance of this point.

At this point I think I might try to add this, even if there are no improvements to the underlying abilities in Blender.

At this point I think I might try to add this, even if there are no improvements to the underlying abilities in Blender.

@Werwack, and anyone else waiting for this.
I had a very functional keymap for 2.7x, that I have rebuilt for 2.80. It's got a fully integrated LMB selection, and Maya ALT-Navigation.

Check it out, it's easy to install and revert back.
Comes packed with some free community addons, and is also pretty well documented.

https://blenderartists.org/t/input-custom-blender-setup-alt-maya-navigation-lmb-selections-for-blender-2-80/1136954/20

@Werwack, and anyone else waiting for this. I had a very functional keymap for 2.7x, that I have rebuilt for 2.80. It's got a fully integrated LMB selection, and Maya ALT-Navigation. Check it out, it's easy to install and revert back. Comes packed with some free community addons, and is also pretty well documented. https://blenderartists.org/t/input-custom-blender-setup-alt-maya-navigation-lmb-selections-for-blender-2-80/1136954/20

@0rAngE Thanks a lot, I'll give it a try with pleasure :)

@0rAngE Thanks a lot, I'll give it a try with pleasure :)

Please insert automated snap for 3d modeling thank you

Please insert automated snap for 3d modeling thank you

im Rhino 3d user working for production 3d printing for jewelry designs , i mean like rhino 3d automate snap please for more clear measurements , thank you .

im Rhino 3d user working for production 3d printing for jewelry designs , i mean like rhino 3d automate snap please for more clear measurements , thank you .

And for Eevee there is no Diamond reflection please fixed it for can we use Diamond reflection on Eevee Render Engine , thank you

And for Eevee there is no Diamond reflection please fixed it for can we use Diamond reflection on Eevee Render Engine , thank you

@PiettroJewelry All of those things are outside the scope of what a keymap can do. This is only about making the input more familiar, not about bringing feature parity with all DCC apps.

@PiettroJewelry All of those things are outside the scope of what a keymap can do. This is only about making the input more familiar, not about bringing feature parity with all DCC apps.

Ok William Thank you , i appreciate your hard work always .

Ok William Thank you , i appreciate your hard work always .

Added subscriber: @dev369

Added subscriber: @dev369

i am trying to switch between modes by pressing f1,f2,f3,f4 instead of toggling it with TAB key, so when i press f1 it goes to object mode. when i press f2 it goes edit mode etc. ive tried adding the command to the keymap under 3d view global but it says its reserved for internal use. is there any way to do this kind of thing ?

i am trying to switch between modes by pressing f1,f2,f3,f4 instead of toggling it with TAB key, so when i press f1 it goes to object mode. when i press f2 it goes edit mode etc. ive tried adding the command to the keymap under 3d view global but it says its reserved for internal use. is there any way to do this kind of thing ?

Removed subscriber: @Kartridge

Removed subscriber: @Kartridge

In #54963#651072, @WilliamReynish wrote:
At this point I think I might try to add this, even if there are no improvements to the underlying abilities in Blender.

I think it would be a good idea to get feedback on it to have enough time to evaluate and polish it before 2.8 is released.
For me it's also the only thing holding me back right now to fully switch to 2.8 since I don't want to relearn keymap changes twice, from 2.79 to 2.8 and then to the industry standard keymap.

> In #54963#651072, @WilliamReynish wrote: > At this point I think I might try to add this, even if there are no improvements to the underlying abilities in Blender. I think it would be a good idea to get feedback on it to have enough time to evaluate and polish it before 2.8 is released. For me it's also the only thing holding me back right now to fully switch to 2.8 since I don't want to relearn keymap changes twice, from 2.79 to 2.8 and then to the industry standard keymap.

@zaha Yes, I agree, and look forward to the feedback. However, the trouble is that there are some aspects that will be limited, because the items described in #57918 are not yet done, which limits somewhat what this keymap can do.

@zaha Yes, I agree, and look forward to the feedback. However, the trouble is that there are some aspects that will be limited, because the items described in #57918 are not yet done, which limits somewhat what this keymap can do.

In #54963#651655, @WilliamReynish wrote:
@zaha Yes, I agree, and look forward to the feedback. However, the trouble is that there are some aspects that will be limited, because the items described in #57918 are not yet done, which limits somewhat what this keymap can do.

I think most users who install blender are aware there will be limitations:) I for one love software that is still evolving and even more if I can take part in the process.
Is this on a branch, somewhere I could test maybe?

> In #54963#651655, @WilliamReynish wrote: > @zaha Yes, I agree, and look forward to the feedback. However, the trouble is that there are some aspects that will be limited, because the items described in #57918 are not yet done, which limits somewhat what this keymap can do. I think most users who install blender are aware there will be limitations:) I for one love software that is still evolving and even more if I can take part in the process. Is this on a branch, somewhere I could test maybe?

In #54963#651675, @cez wrote:

In #54963#651655, @WilliamReynish wrote:
@zaha Yes, I agree, and look forward to the feedback. However, the trouble is that there are some aspects that will be limited, because the items described in #57918 are not yet done, which limits somewhat what this keymap can do.

I think most users who install blender are aware there will be limitations:) I for one love software that is still evolving and even more if I can take part in the process.
Is this on a branch, somewhere I could test maybe?

@WilliamReynish I definitely see the dilemma here: Release too early and you get lots of feedback on stuff that you guys are already aware of, release too late and you run out of time to polish. But wouldn't that keymap be opt-in and not replace the default one? As @cez pointed out this would mean mostly people that are willing to go down the bumpy road will use it at first. I would argue it's worth the risk to gain some valuable feedback at this point in time.

> In #54963#651675, @cez wrote: >> In #54963#651655, @WilliamReynish wrote: >> @zaha Yes, I agree, and look forward to the feedback. However, the trouble is that there are some aspects that will be limited, because the items described in #57918 are not yet done, which limits somewhat what this keymap can do. > > I think most users who install blender are aware there will be limitations:) I for one love software that is still evolving and even more if I can take part in the process. > Is this on a branch, somewhere I could test maybe? @WilliamReynish I definitely see the dilemma here: Release too early and you get lots of feedback on stuff that you guys are already aware of, release too late and you run out of time to polish. But wouldn't that keymap be opt-in and not replace the default one? As @cez pointed out this would mean mostly people that are willing to go down the bumpy road will use it at first. I would argue it's worth the risk to gain some valuable feedback at this point in time.

I do think, what it's better to tie it with 2.8 stable release, and keep polishing til 2.8b or 2.81 or whatever.
2.8 is one of the very significant iterations in Blender history. Even UI is overhauled. And it's the best time to introduce new build-in keymap.

P.S. Plus, for newbies learning from video tutorials, if they see the "new UI design", they would know, what it has different keymap instantly, and the instructor will probably use it. Yes, it's not 100% ready, but nothing is :D

I do think, what it's better to tie it with 2.8 stable release, and keep polishing til 2.8b or 2.81 or whatever. 2.8 is one of the very significant iterations in Blender history. Even UI is overhauled. And it's the best time to introduce new build-in keymap. P.S. Plus, for newbies learning from video tutorials, if they see the "new UI design", they would know, what it has different keymap instantly, and the instructor will probably use it. Yes, it's not 100% ready, but nothing is :D
Contributor

If you really need a good keymap right now, then you can use this one: https://blenderartists.org/t/a-proper-keymap-for-blender-2-8/1145406

It's not official, but it's really good :)

If you really need a good keymap right now, then you can use this one: https://blenderartists.org/t/a-proper-keymap-for-blender-2-8/1145406 It's not official, but it's really good :)

In #54963#651655, @WilliamReynish wrote:
@zaha Yes, I agree, and look forward to the feedback. However, the trouble is that there are some aspects that will be limited, because the items described in #57918 are not yet done, which limits somewhat what this keymap can do.

Agree that it is better to add before and know the opinion of users, rather than later.

> In #54963#651655, @WilliamReynish wrote: > @zaha Yes, I agree, and look forward to the feedback. However, the trouble is that there are some aspects that will be limited, because the items described in #57918 are not yet done, which limits somewhat what this keymap can do. Agree that it is better to add before and know the opinion of users, rather than later.

D4626 includes an initial implementation of this keymap, intended for testing and feedback. It's not added to master yet, but is awaiting review.

[D4626](https://archive.blender.org/developer/D4626) includes an initial implementation of this keymap, intended for testing and feedback. It's not added to master yet, but is awaiting review.

Removed subscriber: @Luis.Burdallo

Removed subscriber: @Luis.Burdallo

After implementing the Industry Compatible Keymap, I have some questions for feedback:

  • Ctrl-D: Should this Deselect or Duplicate?
    Different apps do different things here. We could use Shift-D for the other one.

These items are not yet assigned to any keys:

  • Mirror
  • Transform Pivot (currently still uses comma)
  • Transform Orientation (currently still uses period)
  • Snapping on/off
  • Proportional Editing/Soft Selection

Which keys should the above be assigned to?

After implementing the Industry Compatible Keymap, I have some questions for feedback: - Ctrl-D: Should this Deselect or Duplicate? Different apps do different things here. We could use Shift-D for the other one. These items are not yet assigned to any keys: - Mirror - Transform Pivot (currently still uses comma) - Transform Orientation (currently still uses period) - Snapping on/off - Proportional Editing/Soft Selection Which keys should the above be assigned to?

In #54963#651998, @WilliamReynish wrote:

  • Ctrl-D: Should this Deselect or Duplicate?

Duplicate.

We could use Shift-D for the other one.

Sounds good. Or, if there is a way to make "Duplicate as an instance" in Blender, then maybe this keys make more sense

  • Transform Pivot (currently still uses comma)
  • Snapping on/off

I never used "mode" in Maya, always just holding D, plus holding XCV for snapping. I cannot imagine anything more comfortable :).

Another thing I just love about Maya is TAB for Brush Select. But it's probably better to leave Tab as it is, for edit mode.

The macOS ⌘-key (Command) is fully supported. Anything where you would use Ctrl on Windows or Linux, you do by using ⌘ on the Mac. This is handled automatically by the keymap.

Thank you so much for this!! It was making me mad actually :D I'm so happy.

> In #54963#651998, @WilliamReynish wrote: > - Ctrl-D: Should this Deselect or Duplicate? Duplicate. > We could use Shift-D for the other one. Sounds good. Or, if there is a way to make "Duplicate as an instance" in Blender, then maybe this keys make more sense > - Transform Pivot (currently still uses comma) > - Snapping on/off I never used "mode" in Maya, always just holding D, plus holding XCV for snapping. I cannot imagine anything more comfortable :). Another thing I just love about Maya is TAB for Brush Select. But it's probably better to leave Tab as it is, for edit mode. > The macOS ⌘-key (Command) is fully supported. Anything where you would use Ctrl on Windows or Linux, you do by using ⌘ on the Mac. This is handled automatically by the keymap. Thank you so much for this!! It was making me mad actually :D I'm so happy.

@NjordyJovanovich

If Ctrl/Cmd-D is used for Duplicate, which key should be used for Deselect All then?
I set Tab to the Quick Favourites menu.
1-9 keys are used for the modes/elements (Object, Vertex, Edge, Face, Sculpt etc)

@NjordyJovanovich If Ctrl/Cmd-D is used for Duplicate, which key should be used for Deselect All then? I set Tab to the Quick Favourites menu. 1-9 keys are used for the modes/elements (Object, Vertex, Edge, Face, Sculpt etc)

In #54963#652005, @WilliamReynish wrote:
If Ctrl/Cmd-D is used for Duplicate, which key should be used for Deselect All then?

I think A/Double-A quite satisfactory and intuitive. Unless it's being changed to something else. Maya has a zoom in option, but I think everything in this regard should be build around F key. IMHO

1-9 keys are used for the modes/elements (Object, Vertex, Edge, Face, Sculpt etc)

Ah, good :)

P.S. One thing I really love in Houdini — Spacebar+1/2/3/4/5 for Switch Views. I believe it can co-exist with Maya's traditional Spacebar for four-view > Click to chose one.

> In #54963#652005, @WilliamReynish wrote: > If Ctrl/Cmd-D is used for Duplicate, which key should be used for Deselect All then? I think A/Double-A quite satisfactory and intuitive. Unless it's being changed to something else. Maya has a zoom in option, but I think everything in this regard should be build around F key. IMHO > 1-9 keys are used for the modes/elements (Object, Vertex, Edge, Face, Sculpt etc) Ah, good :) P.S. One thing I really love in Houdini — Spacebar+1/2/3/4/5 for Switch Views. I believe it can co-exist with Maya's traditional Spacebar for four-view > Click to chose one.

In #54963#652005, @WilliamReynish wrote:
@NjordyJovanovich

If Ctrl/Cmd-D is used for Duplicate, which key should be used for Deselect All then?

Personally I'm torn on Ctrl+D or Shift+D for Duplicate. My instinct is to use Ctrl+D but I feel like since it's adding something to the scene that Shift as the operator would keep more in line with other uses of Shift as an "add" operator. Ctrl+D could then be used for Deselect (though I'd imagine most people would just click in an empty area instead)

I set Tab to the Quick Favourites menu.

I'm torn on this one as well. I do love access to the QF menu being something easily reached with the left hand but so many other 3D apps use 1/2/3 as vertex/edge/face that I would hate to deviate from that. I feel like that would get confusing for many people to be "one number off" of what they're used to when coming from other apps.

1-9 keys are used for the modes/elements (Object, Vertex, Edge, Face, Sculpt etc)

My personal preference would be Vertex, Edge, Face, Object.

As a recovering 3ds Max user I'm so thankful this is being looked into as a proper implementation! Keep up the great work!

> In #54963#652005, @WilliamReynish wrote: > @NjordyJovanovich > > If Ctrl/Cmd-D is used for Duplicate, which key should be used for Deselect All then? Personally I'm torn on Ctrl+D or Shift+D for Duplicate. My instinct is to use Ctrl+D but I feel like since it's adding something to the scene that Shift as the operator would keep more in line with other uses of Shift as an "add" operator. Ctrl+D could then be used for Deselect (though I'd imagine most people would just click in an empty area instead) > I set Tab to the Quick Favourites menu. I'm torn on this one as well. I do love access to the QF menu being something easily reached with the left hand but so many other 3D apps use 1/2/3 as vertex/edge/face that I would hate to deviate from that. I feel like that would get confusing for many people to be "one number off" of what they're used to when coming from other apps. > 1-9 keys are used for the modes/elements (Object, Vertex, Edge, Face, Sculpt etc) My personal preference would be Vertex, Edge, Face, Object. As a recovering 3ds Max user I'm so thankful this is being looked into as a proper implementation! Keep up the great work!

Ok,

I'll set Ctrl/Cmd-D to Duplicate. To Deselect you can click in empty space, or you can hit Ctrl-Shift-D
I'll set the 1-9 keys to Vert, Edge, Face, Object, in that order instead.

Ok, I'll set Ctrl/Cmd-D to Duplicate. To Deselect you can click in empty space, or you can hit Ctrl-Shift-D I'll set the 1-9 keys to Vert, Edge, Face, Object, in that order instead.

In #54963#652011, @Dheim wrote:

1-9 keys are used for the modes/elements (Object, Vertex, Edge, Face, Sculpt etc)

My personal preference would be Vertex, Edge, Face, Object.

As a Houdini user (with no intentions on leaving this software) that wouldn't be desirable for me. We got Object on "1" :) But if it's in 3Dmax, and a lot of people migrate from it to Blender, maybe it would be better...

> In #54963#652011, @Dheim wrote: >> 1-9 keys are used for the modes/elements (Object, Vertex, Edge, Face, Sculpt etc) > My personal preference would be Vertex, Edge, Face, Object. As a Houdini user (with no intentions on leaving this software) that wouldn't be desirable for me. We got Object on "1" :) But if it's in 3Dmax, and a lot of people migrate from it to Blender, maybe it would be better...

In #54963#652012, @WilliamReynish wrote:
I'll set Ctrl/Cmd-D to Duplicate. To Deselect you can click in empty space, or you can hit Ctrl-Shift-D

Works for me!

In #54963#652017, @NjordyJovanovich wrote:
As a Houdini user (with no intentions on leaving this software) that wouldn't be desirable for me. We got Object on "1" :) But if it's in 3Dmax, and a lot of people migrate from it to Blender, maybe it would be better...

Well, I can see the argument both ways. I'm not familiar with Houdini but I can see your argument for that keymapping. Honestly so long as it's easy to rebind those inputs then it should be fine. I am not familiar enough with programs other than Max to say what the industry standard should be in this case.

> In #54963#652012, @WilliamReynish wrote: > I'll set Ctrl/Cmd-D to Duplicate. To Deselect you can click in empty space, or you can hit Ctrl-Shift-D Works for me! > In #54963#652017, @NjordyJovanovich wrote: > As a Houdini user (with no intentions on leaving this software) that wouldn't be desirable for me. We got Object on "1" :) But if it's in 3Dmax, and a lot of people migrate from it to Blender, maybe it would be better... Well, I can see the argument both ways. I'm not familiar with Houdini but I can see your argument for that keymapping. Honestly so long as it's easy to rebind those inputs then it should be fine. I am not familiar enough with programs other than Max to say what the industry standard should be in this case.

On second thought, 1-4 keys being Vert/Edge/Face/Object doesn't work all that well because for other object types (curves etc there is no vert/edge/face selection mode. So what to do then becomes unclear.

We could change the order to be Object/Face/Edge/Vertex, or keep Object/Vertex/Edge/Face, or accept that if we use Vert/Edge/Face/Object, it will be inconsistent with other object types.

On second thought, 1-4 keys being Vert/Edge/Face/Object doesn't work all that well because for other object types (curves etc there is no vert/edge/face selection mode. So what to do then becomes unclear. We could change the order to be Object/Face/Edge/Vertex, or keep Object/Vertex/Edge/Face, or accept that if we use Vert/Edge/Face/Object, it will be inconsistent with other object types.

In #54963#652019, @WilliamReynish wrote:
Object/Face/Edge/Vertex

It's the most logical thing. But aside of that... it exist in no other software (sadly) and (complete reverse) will confuse everyone!

> In #54963#652019, @WilliamReynish wrote: > Object/Face/Edge/Vertex It's the most logical thing. But aside of that... it exist in no other software (sadly) and (complete reverse) will confuse everyone!

Added subscriber: @DotBow

Added subscriber: @DotBow

My team also making move from 3DS Max to Blender .
Actually, I use Blender for 2 years as main software (after 3DS Max and Maya), but it is interesting to see how people get confused by things that I never thought of might be a problem.

So, in terms of keymap right now the biggest problem is super alpha state of tool panel witch is confusing for people who used to manipulators.
Blender still very aggressively dictates using shortcuts G, R, S (and Z, X, Y) instead of switching between tools.

I don't know if Blender will have finished tools on 2.8 release, but they need to be tight with main keymaps for standard compatibility.

Actually, I don't know where better to write such stuff, because there is a lot of areas Blender has bad practice even for 2-year user like me who love this software.

My team also making move from 3DS Max to Blender . Actually, I use Blender for 2 years as main software (after 3DS Max and Maya), but it is interesting to see how people get confused by things that I never thought of might be a problem. So, in terms of keymap right now the biggest problem is super alpha state of tool panel witch is confusing for people who used to manipulators. Blender still very aggressively dictates using shortcuts G, R, S (and Z, X, Y) instead of switching between tools. I don't know if Blender will have finished tools on 2.8 release, but they need to be tight with main keymaps for standard compatibility. Actually, I don't know where better to write such stuff, because there is a lot of areas Blender has bad practice even for 2-year user like me who love this software.

In #54963#652021, @NjordyJovanovich wrote:

In #54963#652019, @WilliamReynish wrote:
Object/Face/Edge/Vertex

It's the most logical thing. But aside of that... it exist in no other software (sadly) and (complete reverse) will confuse everyone!

In Maya the order goes Object, Vertex, Edge, Face (https://damassets.autodesk.net/content/dam/autodesk/www/shortcuts/maya/autodesk-maya-one-key-shortcuts-hotkeys-1600x1206.jpg)
In Max the Object is at the end but otherwise the same. I believe modo also has vertex, edge, face in that order. If we're doing an industry compatible mapping I think it should then be Object, V, E, F.

> In #54963#652021, @NjordyJovanovich wrote: >> In #54963#652019, @WilliamReynish wrote: >> Object/Face/Edge/Vertex > > It's the most logical thing. But aside of that... it exist in no other software (sadly) and (complete reverse) will confuse everyone! In Maya the order goes Object, Vertex, Edge, Face (https://damassets.autodesk.net/content/dam/autodesk/www/shortcuts/maya/autodesk-maya-one-key-shortcuts-hotkeys-1600x1206.jpg) In Max the Object is at the end but otherwise the same. I believe modo also has vertex, edge, face in that order. If we're doing an industry compatible mapping I think it should then be Object, V, E, F.

In #54963#652012, @WilliamReynish wrote:
Ok,

I'll set Ctrl/Cmd-D to Duplicate. To Deselect you can click in empty space, or you can hit Ctrl-Shift-D
I'll set the 1-9 keys to Vert, Edge, Face, Object, in that order instead.

Will A/Alt-A stay for select/deselect all? Because I found this to be on the same key with just a modifier to switch mode to be really handy and fast.

Or is it Ctrl-A/Ctrl-D then in the industry keymap?

> In #54963#652012, @WilliamReynish wrote: > Ok, > > I'll set Ctrl/Cmd-D to Duplicate. To Deselect you can click in empty space, or you can hit Ctrl-Shift-D > I'll set the 1-9 keys to Vert, Edge, Face, Object, in that order instead. Will A/Alt-A stay for select/deselect all? Because I found this to be on the same key with just a modifier to switch mode to be really handy and fast. Or is it Ctrl-A/Ctrl-D then in the industry keymap?

It's Ctrl/Cmd-A to Select/Deselect all.

Ctrl/Cmd-D is now Duplicate.

An alternative way to duplicate, is to use the Move tool and hold Shift while dragging in the viewport. This will create a duplicate object/item.

It's Ctrl/Cmd-A to Select/Deselect all. Ctrl/Cmd-D is now Duplicate. An alternative way to duplicate, is to use the Move tool and hold Shift while dragging in the viewport. This will create a duplicate object/item.

Added subscriber: @Regnas

Added subscriber: @Regnas

In #54963#652045, @WilliamReynish wrote:
It's Ctrl/Cmd-A to Select/Deselect all.

How is it on Windows?

> In #54963#652045, @WilliamReynish wrote: > It's Ctrl/Cmd-A to Select/Deselect all. How is it on Windows?

Ctrl/Cmd means it uses Ctrl on Windows & Linux, but ⌘(Cmd) on Mac

Everything that uses Ctrl on Windows/Linux is set to Cmd on the Mac automatically by the keymap.

`Ctrl/Cmd` means it uses `Ctr`l on Windows & Linux, but `⌘(Cmd)` on Mac Everything that uses Ctrl on Windows/Linux is set to Cmd on the Mac automatically by the keymap.

In #54963#652154, @WilliamReynish wrote:
Ctrl/Cmd means it uses Ctrl on Windows, but ⌘(Cmd) on Mac

That's what I thought, but there's a problem, Select/Deselect all can't use the same hotkey as a toggle, they need to have different hotkeys, as seen on most 3d apps.

> In #54963#652154, @WilliamReynish wrote: > `Ctrl/Cmd` means it uses `Ctr`l on Windows, but `⌘(Cmd)` on Mac That's what I thought, but there's a problem, Select/Deselect all can't use the same hotkey as a toggle, they need to have different hotkeys, as seen on most 3d apps.

@Regnas What should the hotkey to deselect be then?

I had it set to Ctrl/⌘-D as some apps do, but others use it for Duplicate.

@Regnas What should the hotkey to deselect be then? I had it set to Ctrl/⌘-D as some apps do, but others use it for Duplicate.

In #54963#652156, @WilliamReynish wrote:
@Regnas What should the hotkey to deselect be then?

I had it set to Ctrl/⌘-D as some apps do, but others use it for Duplicate.

Is there anything that speaks against using Alt-A just like with the default keymap?

> In #54963#652156, @WilliamReynish wrote: > @Regnas What should the hotkey to deselect be then? > > I had it set to Ctrl/⌘-D as some apps do, but others use it for Duplicate. Is there anything that speaks against using Alt-A just like with the default keymap?

Any chance we can get Tab for direct search in all of the node editors? I know it will conflict with node groups but maybe we can find something else for that. Maya, Nuke and I believe Houdini use it as well.

Any chance we can get Tab for direct search in all of the node editors? I know it will conflict with node groups but maybe we can find something else for that. Maya, Nuke and I believe Houdini use it as well.

In #54963#652156, @WilliamReynish wrote:
@Regnas What should the hotkey to deselect be then?

I had it set to Ctrl/⌘-D as some apps do, but others use it for Duplicate.

The most used hotkey is ctrl+shift+a to deselect all.

In #54963#652157, @zaha wrote:
Is there anything that speaks against using Alt-A just like with the default keymap?

No, but the issue is that it's not the common hotkey for that.

> In #54963#652156, @WilliamReynish wrote: > @Regnas What should the hotkey to deselect be then? > > I had it set to Ctrl/⌘-D as some apps do, but others use it for Duplicate. The most used hotkey is ctrl+shift+a to deselect all. > In #54963#652157, @zaha wrote: > Is there anything that speaks against using Alt-A just like with the default keymap? No, but the issue is that it's not the common hotkey for that.

@irfancelik
Currently, tab is used for the Quick Favourites.

I could map Tab to Operator Search everywhere, and then find a different key for Quick Favourites.

Any suggestions on what to set Quick Favourites to then?

@Regnas Yes I will do that.

@irfancelik Currently, tab is used for the Quick Favourites. I could map Tab to Operator Search everywhere, and then find a different key for Quick Favourites. Any suggestions on what to set Quick Favourites to then? @Regnas Yes I will do that.

Of the top of my head I would say Ctrl or Shift+Tab could work or maybe even Ctrl+RMB?
It does get quite complicated since I wouldn´t want it to collide too much with addons like the Node Wrangler either.

Of the top of my head I would say Ctrl or Shift+Tab could work or maybe even Ctrl+RMB? It does get quite complicated since I wouldn´t want it to collide too much with addons like the Node Wrangler either.

Ok, I can map Operator Search to Tab and then Quick Favourites to perhaps Ctrl-RMB, although that could be an issue to do on some laptops.

Currently though, I use Ctrl/Cmd-F for Find/Search and Tab for Quick Favourites, which does work well, even on one-button trackpads. If I can think of a better solution to Quick Favourites, I will go ahead.

Shift-Tab may be ok, although I wonder if it’s better to make Quick Favourites quicker than Search? Once you have your Quick Favorites set up, wouldn’t you prefer to make that the easier one to execute?

So:

Quick Favourites: Tab
Search: Shift-Tab

or would you prefer:

Quick Favourites: Shift-Tab
Search: Tab

Still looking for suggestions on shortcuts for:

  • Mirror
  • Transform Pivot (currently still uses comma)
  • Transform Orientation (currently still uses period)
  • Snapping on/off
  • Proportional Editing/Soft Selection
Ok, I can map Operator Search to Tab and then Quick Favourites to perhaps Ctrl-RMB, although that could be an issue to do on some laptops. Currently though, I use Ctrl/Cmd-F for Find/Search and Tab for Quick Favourites, which does work well, even on one-button trackpads. If I can think of a better solution to Quick Favourites, I will go ahead. Shift-Tab may be ok, although I wonder if it’s better to make Quick Favourites quicker than Search? Once you have your Quick Favorites set up, wouldn’t you prefer to make that the easier one to execute? So: Quick Favourites: Tab Search: Shift-Tab or would you prefer: Quick Favourites: Shift-Tab Search: Tab Still looking for suggestions on shortcuts for: - Mirror - Transform Pivot (currently still uses comma) - Transform Orientation (currently still uses period) - Snapping on/off - Proportional Editing/Soft Selection

Tab had been suggested as getting in and out of Edit mode. What's the currently decided way to do that? I know 1,2,3,4 were talked about to get into those modes but how do you quickly get out of Edit mode?

Tab had been suggested as getting in and out of Edit mode. What's the currently decided way to do that? I know 1,2,3,4 were talked about to get into those modes but how do you quickly get out of Edit mode?

You would just use the 1 and 2 keys, respectively to go to whichever of those modes you wish - or any of the other modes using the number keys.

Tab for Edit Mode is an old Blender convention - not something that makes sense in this context. In fact, it doesn’t even really make sense in the main Blender keymap either, because it always prioritizes Edit Mode.

Animators who use Pose Mode are then second-class citizens when one mode is prioritized above others. So, in this keymap, like many other apps, the number keys are used to jump directly to modes.

You would just use the 1 and 2 keys, respectively to go to whichever of those modes you wish - or any of the other modes using the number keys. Tab for Edit Mode is an old Blender convention - not something that makes sense in this context. In fact, it doesn’t even really make sense in the main Blender keymap either, because it always prioritizes Edit Mode. Animators who use Pose Mode are then second-class citizens when one mode is prioritized above others. So, in this keymap, like many other apps, the number keys are used to jump directly to modes.

Tab is great for search once you get used to not having to use that for edit mode. What's space used for?

Tab is great for search once you get used to not having to use that for edit mode. What's space used for?

Space, currently, is Play/Pause. Different DCC apps do various different things with the Spacebar. There exists no complete standard inside 3d DCC apps for Play/Pause, but in that case I fall back to the greater field of creative apps in general, where Space is very often Play/Pause.

Space, currently, is Play/Pause. Different DCC apps do various different things with the Spacebar. There exists no complete standard inside 3d DCC apps for Play/Pause, but in that case I fall back to the greater field of creative apps in general, where Space is very often Play/Pause.

Space should be used for viewport. Ether going full screen, or switching views (I vote for latter, especially with 1-2-3-4 modifiers). Animation for me would be perfect as [every] NLE and video app: J-K-L.

Space should be used for viewport. Ether going full screen, or switching views (I vote for latter, especially with 1-2-3-4 modifiers). Animation for me would be perfect as [every] NLE and video app: J-K-L.

In #54963#652166, @WilliamReynish wrote:
You would just use the 1 and 2 keys, respectively to go to whichever of those modes you wish - or any of the other modes using the number keys.

Tab for Edit Mode is an old Blender convention - not something that makes sense in this context. In fact, it doesn’t even really make sense in the main Blender keymap either, because it always prioritizes Edit Mode.

Oh, duh. I completely spaced on "1" being for Object mode - in my head I was still thinking that that would be Object mode as it exists in Max, which is essentially "select linked" in Blender. Oops!

In #54963#652172, @NjordyJovanovich wrote:
Space should be used for viewport. Ether going full screen, or switching views (I vote for latter, especially with 1-2-3-4 modifiers)

Agreed.

> In #54963#652166, @WilliamReynish wrote: > You would just use the 1 and 2 keys, respectively to go to whichever of those modes you wish - or any of the other modes using the number keys. > > Tab for Edit Mode is an old Blender convention - not something that makes sense in this context. In fact, it doesn’t even really make sense in the main Blender keymap either, because it always prioritizes Edit Mode. Oh, duh. I completely spaced on "1" being for Object mode - in my head I was still thinking that that would be Object mode as it exists in Max, which is essentially "select linked" in Blender. Oops! > In #54963#652172, @NjordyJovanovich wrote: > Space should be used for viewport. Ether going full screen, or switching views (I vote for latter, especially with 1-2-3-4 modifiers) Agreed.

@NjordyJovanovich J-K-L is an interesting suggestion for Rewind/Pause/Play - many NLE's indeed use this.

@NjordyJovanovich J-K-L is an interesting suggestion for Rewind/Pause/Play - many NLE's indeed use this.

I'm fine for space as play/pause, I actually use shift+space for that because space is search (but that's tab here) and ctrl+space for maximize view. Unity uses space as play/pause. 3ds max has "/" for play/pause which I never thought was intuitive..

Here's a thought, can we have 1/2/3/4 as vert/edge/face/object in uv editor?

I see Q is box select, isn't box select the default behavior for drag in 2.8 already?

I'm fine for space as play/pause, I actually use shift+space for that because space is search (but that's tab here) and ctrl+space for maximize view. Unity uses space as play/pause. 3ds max has "/" for play/pause which I never thought was intuitive.. Here's a thought, can we have 1/2/3/4 as vert/edge/face/object in uv editor? I see Q is box select, isn't box select the default behavior for drag in 2.8 already?

@NjordyJovanovich
Tried JKL for backwards/pause/forwards. Currently it doesn't work so well because you cannot go directly from playing backwards to forwards without pausing first. I might be ble to do a workaround to fix that issue though.

@cez

can we have 1/2/3/4 as vert/edge/face/object in uv editor?

Yes

I see Q is box select, isn't box select the default behavior for drag in 2.8 already?

Yes, and Q is the hotkey to return to the Select tool.

@NjordyJovanovich Tried JKL for backwards/pause/forwards. Currently it doesn't work so well because you cannot go directly from playing backwards to forwards without pausing first. I might be ble to do a workaround to fix that issue though. @cez > can we have 1/2/3/4 as vert/edge/face/object in uv editor? Yes > I see Q is box select, isn't box select the default behavior for drag in 2.8 already? Yes, and Q is the hotkey to return to the Select tool.

J K L — play backwards / pause / play forwards.
Pressing J/L multiple times is a speed multiplier.
Holding K (pause) and pressing J/L is a prev/next frame.
If this keys will be chosen, I'd also assign a key for "jump to first frame" around them, Ctrl+J for example.

playing backwards to forwards without pausing first.

The thing is, pressing J (backwards) should slow forward speed, not stop it. So they basically go against each other. One key is a "force against" the other.

J K L — play backwards / pause / play forwards. Pressing J/L multiple times is a speed multiplier. Holding K (pause) and pressing J/L is a prev/next frame. If this keys will be chosen, I'd also assign a key for "jump to first frame" around them, Ctrl+J for example. > playing backwards to forwards without pausing first. The thing is, pressing J (backwards) should slow forward speed, not stop it. So they basically go against each other. One key is a "force against" the other.

@NjordyJovanovich Yes, I know it from NLE's - the trouble is that Blender doesn't support this really. I would need to write custom operators to work that way.

While I would love to have JKL support working like in Final Cut, Premiere or Avid, but Blender doesn't support it.

I could do a poor-mans version of it, where J always plays backwards, K always pauses and L always plays forward.

@NjordyJovanovich Yes, I know it from NLE's - the trouble is that Blender doesn't support this really. I would need to write custom operators to work that way. While I would love to have JKL support working like in Final Cut, Premiere or Avid, but Blender doesn't support it. I could do a poor-mans version of it, where J always plays backwards, K always pauses and L always plays forward.

In #54963#652045, @WilliamReynish wrote:
An alternative way to duplicate, is to use the Move tool and hold Shift while dragging in the viewport. This will create a duplicate object/item.

Is this currently possible in Blender?
I'm looking for this functionality since forever. Btw, in most 3d apps this is usually done with the ctrl + dragging the gizmo, not shift.

> In #54963#652045, @WilliamReynish wrote: > An alternative way to duplicate, is to use the Move tool and hold Shift while dragging in the viewport. This will create a duplicate object/item. Is this currently possible in Blender? I'm looking for this functionality since forever. Btw, in most 3d apps this is usually done with the ctrl + dragging the gizmo, not shift.

@Regnas You can add it as part of the keymap, which I did. I added it to the Move tool only, for now.

I would actually have preferred to use Alt, but Alt-LMB is already used for navigation.

Ctrl-LMB is used for spawning the context menus for laptops with trackpads.

So, that's why it's Shift-LMB.

@Regnas You can add it as part of the keymap, which I did. I added it to the Move tool only, for now. I would actually have preferred to use Alt, but Alt-LMB is already used for navigation. Ctrl-LMB is used for spawning the context menus for laptops with trackpads. So, that's why it's Shift-LMB.

In #54963#652200, @WilliamReynish wrote:
Ctrl-LMB is used for spawning the context menus for laptops with trackpads.

So, that's why it's Shift-LMB.

Is spawning a context menu on a laptop with trackpad more important than duplicating objects? Sounds like a pretty particular use case to me.
Otherwise I would suggest maybe switching the two, Ctrl-LMB for duplicating and Shift-LMB for the context menu. (btw, why LMB? Wouldn't it make more sense to have context menus on RMB as is standard everywhere?) EDIT: Nevermind, it just occured to me that there might be no RMB on a trackpad (although I have to say, my laptop does have both).

Really like the idea of duplicating via the move gizmo btw. Love that feature in the Unreal Engine and I use it all the time.

> In #54963#652200, @WilliamReynish wrote: > Ctrl-LMB is used for spawning the context menus for laptops with trackpads. > > So, that's why it's Shift-LMB. Is spawning a context menu on a laptop with trackpad more important than duplicating objects? Sounds like a pretty particular use case to me. Otherwise I would suggest maybe switching the two, Ctrl-LMB for duplicating and Shift-LMB for the context menu. (btw, why LMB? Wouldn't it make more sense to have context menus on RMB as is standard everywhere?) EDIT: Nevermind, it just occured to me that there might be no RMB on a trackpad (although I have to say, my laptop does have both). Really like the idea of duplicating via the move gizmo btw. Love that feature in the Unreal Engine and I use it all the time.

@zaha
Ctrl-LMB is used as an alternative, when there is no RMB available. This is important to support Mac laptops.

@zaha Ctrl-LMB is used as an alternative, when there is no RMB available. This is important to support Mac laptops.

In #54963#652205, @WilliamReynish wrote:
@zaha
Ctrl-LMB is used as an alternative, when there is no RMB available. This is important to support Mac laptops.

I see. Could this shortcut be tied to the "Emulate 3 button mouse" option?
AFAIK this option is designed for such users anyway and does not represent the regular use case.

> In #54963#652205, @WilliamReynish wrote: > @zaha > Ctrl-LMB is used as an alternative, when there is no RMB available. This is important to support Mac laptops. I see. Could this shortcut be tied to the "Emulate 3 button mouse" option? AFAIK this option is designed for such users anyway and does not represent the regular use case.

@zaha Not with this keymap. The reason is that Emutale 3 Button Mouse uses Alt-LMB to emulate MMB. It cannot be controlled by keymaps.

@zaha Not with this keymap. The reason is that Emutale 3 Button Mouse uses Alt-LMB to emulate MMB. It cannot be controlled by keymaps.

It would be nice if a shift (or Ctrl) drag duplicates in all transform modes and if spacebar toggled between box select and drag behavior for all of the tools. This would replicate 3ds Max’s Lock Selection behavior which I’ve always been a fan of.

Also, I’m a big fan of the jkl keymap. I wrote a pause then play fwd and pause then play backward scripts for this purpose.

It would be nice if a shift (or Ctrl) drag duplicates in all transform modes and if spacebar toggled between box select and drag behavior for all of the tools. This would replicate 3ds Max’s Lock Selection behavior which I’ve always been a fan of. Also, I’m a big fan of the jkl keymap. I wrote a pause then play fwd and pause then play backward scripts for this purpose.

@DanPool if you don’t mind posting your JKL script here, it might be useful for this.

@DanPool if you don’t mind posting your JKL script here, it might be useful for this.

In #54963#652358, @DanPool wrote:
It would be nice if a shift (or Ctrl) drag duplicates in all transform modes and if spacebar toggled between box select and drag behavior for all of the tools. This would replicate 3ds Max’s Lock Selection behavior which I’ve always been a fan of.

If I'm understanding you correctly then what you're describing is something I've wanted for Blender, too. In Max I can be in Edge mode, activate the move tool, hold Shift and just drag out a new edge (basically extruding it to a new polygon). It's wonderful. :)

> In #54963#652358, @DanPool wrote: > It would be nice if a shift (or Ctrl) drag duplicates in all transform modes and if spacebar toggled between box select and drag behavior for all of the tools. This would replicate 3ds Max’s Lock Selection behavior which I’ve always been a fan of. If I'm understanding you correctly then what you're describing is something I've wanted for Blender, too. In Max I can be in Edge mode, activate the move tool, hold Shift and just drag out a new edge (basically extruding it to a new polygon). It's wonderful. :)

@WilliamReynish Sure. I actually had the controls rolled into the builtin space_time.py. Below I've put it in its own panel in the 3d view. I wanted to set this up to work like video editing apps like Avid. The standard is this:

  • J always plays forward
  • L always plays backward
  • K always pauses
  • While playing, if you press J or K again, the speed increases (1.5x, 2x, 4x, 8x, back to 1x)*
  • If you hold K and tap J, the cursor jumps back one frame**
  • If you hold K and tap L, the cursor jumps forward one frame**

*I took this code out of what I'm posting, because I used "Time Remapping" to make this work. I was afraid this would confuse people who stumble across this code and tried it out only to find that their animations were rendering out at a slow speed. I had to store the last play direction since it's only possible to know if the animation is playing and not what direction the animation is playing in using python unless you wanted to wait a few frames before the action worked, which I found annoying. It looks like there is screen.animation_step that could fix this issue, but I'm not completely sure how to use this other than in the the Keymap tab of the Preference Editor, Animation Step uses a Timer assigned to "Timer 0". I feel like if I knew how to make new timers, I could overcome this limitation.
**While you can use an arbitrary key as a modifer, making J+K a possible shortcut combo, this works unpredictably in blender when J and K are also assigned a keyboard shortcut. That's why I'm currently using Alt+J and Alt+K. Not sure if this should be reported as a bug or if there is a work around. Please advise.


class JKL_OT_Operator(bpy.types.Operator):

bl_idname = "view3d.jkl_controls"
bl_label = "jkl Controls"
bl_description = "jkl Controls"

mode = bpy.props.StringProperty()

def execute(self, context):
scr = bpy.context.screen
scops = bpy.ops.screen

  print(self.mode)
  print(bpy.context.scene.frame_current)
  
  if self.mode == "j":
      if scr.is_animation_playing == True:
          scops.animation_play()
          scops.animation_play(reverse=True)
      else:
          scops.animation_play(reverse=True)
  elif self.mode == "l":
      if scr.is_animation_playing == True:
          scops.animation_play()
          scops.animation_play()
      else:
          scops.animation_play()
  elif self.mode == "kj":
      if scr.is_animation_playing == True:
          scops.animation_play()
      bpy.context.scene.frame_set(bpy.context.scene.frame_current - 1)
  elif self.mode == "kl":
      if scr.is_animation_playing == True:
          scops.animation_play()
      bpy.context.scene.frame_set(bpy.context.scene.frame_current + 1)
  else:
      if scr.is_animation_playing == True:
          scops.animation_play()
          
  return {'FINISHED'}

class JKL_PT_Panel(bpy.types.Panel):

bl_idname = "JKL_PT_Panel"
bl_label = "JKL Panel"
bl_category = "JKL Addon"
bl_space_type = "VIEW_3D"
bl_region_type = "UI"

def draw(self, context):
layout = self.layout

  row = layout.row(align=True)
  row.operator('view3d.jkl_controls', text="(--)").mode = "kj"
  row.operator('view3d.jkl_controls', text="", icon='PLAY_REVERSE').mode = "j"
  row.operator('view3d.jkl_controls', text="", icon='PAUSE').mode = "k"
  row.operator('view3d.jkl_controls', text="", icon='PLAY').mode = "l"
  row.operator('view3d.jkl_controls', text="(+)").mode = "kl"
@WilliamReynish Sure. I actually had the controls rolled into the builtin space_time.py. Below I've put it in its own panel in the 3d view. I wanted to set this up to work like video editing apps like Avid. The standard is this: - J always plays forward - L always plays backward - K always pauses - While playing, if you press J or K again, the speed increases (1.5x, 2x, 4x, 8x, back to 1x)* - If you hold K and tap J, the cursor jumps back one frame** - If you hold K and tap L, the cursor jumps forward one frame** *I took this code out of what I'm posting, because I used "Time Remapping" to make this work. I was afraid this would confuse people who stumble across this code and tried it out only to find that their animations were rendering out at a slow speed. I had to store the last play direction since it's only possible to know if the animation is playing and not what direction the animation is playing in using python unless you wanted to wait a few frames before the action worked, which I found annoying. It looks like there is screen.animation_step that could fix this issue, but I'm not completely sure how to use this other than in the the Keymap tab of the Preference Editor, Animation Step uses a Timer assigned to "Timer 0". I feel like if I knew how to make new timers, I could overcome this limitation. **While you can use an arbitrary key as a modifer, making J+K a possible shortcut combo, this works unpredictably in blender when J and K are also assigned a keyboard shortcut. That's why I'm currently using Alt+J and Alt+K. Not sure if this should be reported as a bug or if there is a work around. Please advise. ```import bpy class JKL_OT_Operator(bpy.types.Operator): ``` bl_idname = "view3d.jkl_controls" bl_label = "jkl Controls" bl_description = "jkl Controls" mode = bpy.props.StringProperty() def execute(self, context): scr = bpy.context.screen scops = bpy.ops.screen print(self.mode) print(bpy.context.scene.frame_current) if self.mode == "j": if scr.is_animation_playing == True: scops.animation_play() scops.animation_play(reverse=True) else: scops.animation_play(reverse=True) elif self.mode == "l": if scr.is_animation_playing == True: scops.animation_play() scops.animation_play() else: scops.animation_play() elif self.mode == "kj": if scr.is_animation_playing == True: scops.animation_play() bpy.context.scene.frame_set(bpy.context.scene.frame_current - 1) elif self.mode == "kl": if scr.is_animation_playing == True: scops.animation_play() bpy.context.scene.frame_set(bpy.context.scene.frame_current + 1) else: if scr.is_animation_playing == True: scops.animation_play() return {'FINISHED'} ``` class JKL_PT_Panel(bpy.types.Panel): ``` bl_idname = "JKL_PT_Panel" bl_label = "JKL Panel" bl_category = "JKL Addon" bl_space_type = "VIEW_3D" bl_region_type = "UI" def draw(self, context): layout = self.layout row = layout.row(align=True) row.operator('view3d.jkl_controls', text="(--)").mode = "kj" row.operator('view3d.jkl_controls', text="", icon='PLAY_REVERSE').mode = "j" row.operator('view3d.jkl_controls', text="", icon='PAUSE').mode = "k" row.operator('view3d.jkl_controls', text="", icon='PLAY').mode = "l" row.operator('view3d.jkl_controls', text="(+)").mode = "kl" ```

Added subscriber: @Luiz-Kruel

Added subscriber: @Luiz-Kruel

Will the shortcuts of the sculpting mode be changed to be more "compatible", or at least more "zbrush like"?

Will the shortcuts of the sculpting mode be changed to be more "compatible", or at least more "zbrush like"?
Contributor

Honestly, I don't find the JKL playback controls very intuitive. Overwhelming majority of Blender users are on Windows, where they don't have access to Final Cut Pro, so it would make more sense to get the keymap closer to Windows editing tools, such as Adobe Premiere, which is truly an industry standard, or Blackmagic Resolve. Premiere and Resolve are available on both Windows and Mac, while Final Cut is only Mac. That should cover a lot more users.

Honestly, I don't find the JKL playback controls very intuitive. Overwhelming majority of Blender users are on Windows, where they don't have access to Final Cut Pro, so it would make more sense to get the keymap closer to Windows editing tools, such as Adobe Premiere, which is truly an industry standard, or Blackmagic Resolve. Premiere and Resolve are available on both Windows and Mac, while Final Cut is only Mac. That should cover a lot more users.

@TheRedWaxPolice
Yes, I will get to it after the basics are working

@Rawalanche
JKL is neither a Mac convention nor a Final Cut one. It is used by all the major editing suites.

It could be removed, but it’s not a Mac-only phenomenon.

@TheRedWaxPolice Yes, I will get to it after the basics are working @Rawalanche JKL is neither a Mac convention nor a Final Cut one. It is used by all the major editing suites. It could be removed, but it’s not a Mac-only phenomenon.
Contributor

In #54963#655157, @WilliamReynish wrote:
@Rawalanche
JKL is neither a Mac convention nor a Final Cut one. It is used by all the major editing suites.

It could be removed, but it’s not a Mac-only phenomenon.

Oh, yes, you are right. I've just right now checked, and both Premiere and Resolve actually share the exact same key combo. In that case, I am actually all for it. It would make great sense, at the very least in the VSE editor.

https://helpx.adobe.com/premiere-pro/using/default-keyboard-shortcuts-cc.html
http://www.logickeyboard.com/shortcut/RES142017.html

> In #54963#655157, @WilliamReynish wrote: > @Rawalanche > JKL is neither a Mac convention nor a Final Cut one. It is used by all the major editing suites. > > It could be removed, but it’s not a Mac-only phenomenon. Oh, yes, you are right. I've just right now checked, and both Premiere and Resolve actually share the exact same key combo. In that case, I am actually all for it. It would make great sense, at the very least in the VSE editor. https://helpx.adobe.com/premiere-pro/using/default-keyboard-shortcuts-cc.html http://www.logickeyboard.com/shortcut/RES142017.html

Yup it is a standard, but it's not only good for the VSE. It's great to have all of your animation playback and scrubbing keys right there under the i key (the default add keyframe key in blender). Try scrubbing back and forth and stepping through frames using the keys as I described above in resolve or premiere. It's also really nice to go from playing forward to playing backward directly without having to pause first. This is great for troubleshooting animations.

Or you can download the add-on from my github . I don't assign the key shortcuts in the addon, so you'll have to set them yourself. In the JKL Addon (in the N panel) the shortcuts from left to right should be Alt+J, J, K, L, and Alt+L. The Alt shortcuts should be changed to K+J and K+L when arbitrary modifier keys are fixed in Blender.

Again, this is easy to setup the j and l key to change playback speed as well, but it changes the Time Remapping as well, which means it adjust playback speed not only for the viewport, but also for the final render, which could be troublesome. We really need a way to decouple these for a proper JKL keymap, but even without this decoupling of viewport and render time mapping, I really like the way it performs as is.

Yup it is a standard, but it's not only good for the VSE. It's great to have all of your animation playback and scrubbing keys right there under the i key (the default add keyframe key in blender). Try scrubbing back and forth and stepping through frames using the keys as I described above in resolve or premiere. It's also really nice to go from playing forward to playing backward directly without having to pause first. This is great for troubleshooting animations. Or you can download the add-on from my [github ](https://github.com/dpdpforlife/jkl). I don't assign the key shortcuts in the addon, so you'll have to set them yourself. In the JKL Addon (in the N panel) the shortcuts from left to right should be Alt+J, J, K, L, and Alt+L. The Alt shortcuts should be changed to K+J and K+L when arbitrary modifier keys are fixed in Blender. Again, this is easy to setup the j and l key to change playback speed as well, but it changes the Time Remapping as well, which means it adjust playback speed not only for the viewport, but also for the final render, which could be troublesome. We really need a way to decouple these for a proper JKL keymap, but even without this decoupling of viewport and render time mapping, I really like the way it performs as is.

In #54963#655157, @WilliamReynish wrote:
@TheRedWaxPolice
Yes, I will get to it after the basics are working

@Rawalanche
JKL is neither a Mac convention nor a Final Cut one. It is used by all the major editing suites.

It could be removed, but it’s not a Mac-only phenomenon.

My humble opinion - playback shortcuts from editing programs is completely different world. I would definitely not take an inspiration from it. All the keys there are there around cutting, scrubbing, trimming etc.. 3D DCC apps needs to deal with uncomparable much more shortcuts, which are operation specific (UV, sculpting, modeling, object manipulation... you name it). That's why shortcuts needs to be really well designed. I am generalist/animator. Personally, I take playback controls as completely separate group of shortcuts which could/should be not mixed with modeling/sculpting/UV keys. When I do animations, I do not need to have extrude, or any other operator under my thumb. It will just produce huge mess, if you mistakenly create keyframe or move one frame forward while modeling. That's why I think JKL is really bad choice.

Lastly I am again going to present most logical animation control:

Up arrow - playback forward, another press pauses playback, another press continues playback forward
Down arrow - playback backward, another press pauses playback, and another press continues playback backward
Right arrow - one frame forward
Left arrow - one frame backward
Shift + Up arrow - playback forward speed change (1.5x, 2x, 4x, 8x, back to 1x)
Shift + Down arrow - playback backward speed change (1.5x, 2x, 4x, 8x, back to 1x)
Ctrl+ Right arrow - jump to next keyframe
Ctrl + Left arrow - jump to previous keyframe
Ctrl + Shift + Right arrow - jump to last keyframe
Ctrl + Shift + Left arrow - jump to first keyframe
Home - jump to timeline start
End - jump to timeline end

That's it. Absolutely self explanatory, and intuitive.

Marek

> In #54963#655157, @WilliamReynish wrote: > @TheRedWaxPolice > Yes, I will get to it after the basics are working > > @Rawalanche > JKL is neither a Mac convention nor a Final Cut one. It is used by all the major editing suites. > > It could be removed, but it’s not a Mac-only phenomenon. My humble opinion - playback shortcuts from editing programs is completely different world. I would definitely not take an inspiration from it. All the keys there are there around cutting, scrubbing, trimming etc.. 3D DCC apps needs to deal with uncomparable much more shortcuts, which are operation specific (UV, sculpting, modeling, object manipulation... you name it). That's why shortcuts needs to be really well designed. I am generalist/animator. Personally, I take playback controls as completely separate group of shortcuts which could/should be not mixed with modeling/sculpting/UV keys. When I do animations, I do not need to have extrude, or any other operator under my thumb. It will just produce huge mess, if you mistakenly create keyframe or move one frame forward while modeling. That's why I think JKL is really bad choice. Lastly I am again going to present most logical animation control: ------------------------------------------------------------------ Up arrow - playback forward, another press pauses playback, another press continues playback forward Down arrow - playback backward, another press pauses playback, and another press continues playback backward Right arrow - one frame forward Left arrow - one frame backward Shift + Up arrow - playback forward speed change (1.5x, 2x, 4x, 8x, back to 1x) Shift + Down arrow - playback backward speed change (1.5x, 2x, 4x, 8x, back to 1x) Ctrl+ Right arrow - jump to next keyframe Ctrl + Left arrow - jump to previous keyframe Ctrl + Shift + Right arrow - jump to last keyframe Ctrl + Shift + Left arrow - jump to first keyframe Home - jump to timeline start End - jump to timeline end That's it. Absolutely self explanatory, and intuitive. ------------------------------------------------------------------ Marek

The initial implementation of this keymap is now included with Blender 2.8, and will appear in the official builds for testing.

The initial implementation of this keymap is now included with Blender 2.8, and will appear in the official builds for testing.

In #54963#658003, @WilliamReynish wrote:
The initial implementation of this keymap is now included with Blender 2.8, and will appear in the official builds for testing.

Great news! Thank you!

> In #54963#658003, @WilliamReynish wrote: > The initial implementation of this keymap is now included with Blender 2.8, and will appear in the official builds for testing. Great news! Thank you!
Contributor

In #54963#658003, @WilliamReynish wrote:
The initial implementation of this keymap is now included with Blender 2.8, and will appear in the official builds for testing.

You may want to add this to the list of changes needed in Blender: https://developer.blender.org/T62154

Otherwise it's impossible to navigate viewport in knife tool if Orbit is set to Alt+LMB click-drag. If orbit is set to Alt+LMB Press, then Alt+LMB Click becomes unusable for anything in the 3D viewport which then causes other potential conflicts.

> In #54963#658003, @WilliamReynish wrote: > The initial implementation of this keymap is now included with Blender 2.8, and will appear in the official builds for testing. You may want to add this to the list of changes needed in Blender: https://developer.blender.org/T62154 Otherwise it's impossible to navigate viewport in knife tool if Orbit is set to Alt+LMB click-drag. If orbit is set to Alt+LMB Press, then Alt+LMB Click becomes unusable for anything in the 3D viewport which then causes other potential conflicts.

In #54963#658003, @WilliamReynish wrote:
The initial implementation of this keymap is now included with Blender 2.8, and will appear in the official builds for testing.

Thank you for your hard work on this and for asking for our feedback!

> In #54963#658003, @WilliamReynish wrote: > The initial implementation of this keymap is now included with Blender 2.8, and will appear in the official builds for testing. Thank you for your hard work on this and for asking for our feedback!

@Rawalanche I don't fully understand the issue. I just tested the Knife tool, and it seems to work fine with Maya-style navigation, unless there is something I am missing.

@Rawalanche I don't fully understand the issue. I just tested the Knife tool, and it seems to work fine with Maya-style navigation, unless there is something I am missing.
Contributor

In #54963#658126, @WilliamReynish wrote:
@Rawalanche I don't fully understand the issue. I just tested the Knife tool, and it seems to work fine with Maya-style navigation, unless there is something I am missing.

It works because most likely, in your Industry Compatible keymap, you have the view3d.rotate operator mapped to Alt+LMB Press, not Click-Drag:
image.png
In this case, navigation in knife mode will indeed work, BUT it also means Alt+LMB, Alt+RMB and Alt+MMB are now completely occupied anywhere in the 3D view. So for example if you wanted to have Alt+RMB click to perform any action, it would be overtaken by viewport orbit. Remapping view3d.rotate operator to Alt+LMB Click-Drag will make it possible to rotate view using Alt+LMB but still also utilize Alt+LMB click for other things. But unfortunately, then it doesn't work in knife mode :(

Sure it would be possible to build the entire Industry Compatible keymap without utilizing Alt+LMB/MMB/RMB clicks, but I still feel like it's quite limiting.

EDIT: Forgot to mention that mapping view3d.rotate to Alt+LMB Press will also disable any other Alt+Mouse button related combinations, such as Alt+Shit+LMB or Ctrl+Alt+RMB, etc...

> In #54963#658126, @WilliamReynish wrote: > @Rawalanche I don't fully understand the issue. I just tested the Knife tool, and it seems to work fine with Maya-style navigation, unless there is something I am missing. It works because most likely, in your Industry Compatible keymap, you have the view3d.rotate operator mapped to Alt+LMB Press, not Click-Drag: ![image.png](https://archive.blender.org/developer/F6928379/image.png) In this case, navigation in knife mode will indeed work, **BUT** it also means Alt+LMB, Alt+RMB and Alt+MMB are now completely occupied anywhere in the 3D view. So for example if you wanted to have Alt+RMB click to perform any action, it would be overtaken by viewport orbit. Remapping view3d.rotate operator to Alt+LMB Click-Drag will make it possible to rotate view using Alt+LMB but still also utilize Alt+LMB click for other things. But unfortunately, then it doesn't work in knife mode :( Sure it would be possible to build the entire Industry Compatible keymap without utilizing Alt+LMB/MMB/RMB clicks, but I still feel like it's quite limiting. EDIT: Forgot to mention that mapping view3d.rotate to Alt+LMB Press will also disable any other Alt+Mouse button related combinations, such as Alt+Shit+LMB or Ctrl+Alt+RMB, etc...

In #54963#658003, @WilliamReynish wrote:
The initial implementation of this keymap is now included with Blender 2.8, and will appear in the official builds for testing.

Great news! But sadly there have been no more nightly builds for Windows since 10th April, right before the keymap was added, so I wasn't able to test it yet. :(

> In #54963#658003, @WilliamReynish wrote: > The initial implementation of this keymap is now included with Blender 2.8, and will appear in the official builds for testing. Great news! But sadly there have been no more nightly builds for Windows since 10th April, right before the keymap was added, so I wasn't able to test it yet. :(

It's live! Last night's build has it included. Everyone go test it!!

It's live! Last night's build has it included. Everyone go test it!!

In #54963#652162, @WilliamReynish wrote:
Ok, I can map Operator Search to Tab and then Quick Favourites to perhaps Ctrl-RMB, although that could be an issue to do on some laptops.

Currently though, I use Ctrl/Cmd-F for Find/Search and Tab for Quick Favourites, which does work well, even on one-button trackpads. If I can think of a better solution to Quick Favourites, I will go ahead.

Shift-Tab may be ok, although I wonder if it’s better to make Quick Favourites quicker than Search? Once you have your Quick Favorites set up, wouldn’t you prefer to make that the easier one to execute?

Ctrl/Cmd-F is nice, didnt know that existed :)

Tab is currently operator search in every editor. It makes sense in the 3dview but not so much in the node views.
I was thinking of the "shift+A, search" feature to go to tab for just the node views (shader, compositing, everything nodes...)

Now with the new viewport transform gizmos, I think it would be better to map W E R to those instead of the active tools.

Also, is there an easy way to find out what shortcut has been taken away from the regular blender keymap?

> In #54963#652162, @WilliamReynish wrote: > Ok, I can map Operator Search to Tab and then Quick Favourites to perhaps Ctrl-RMB, although that could be an issue to do on some laptops. > > Currently though, I use Ctrl/Cmd-F for Find/Search and Tab for Quick Favourites, which does work well, even on one-button trackpads. If I can think of a better solution to Quick Favourites, I will go ahead. > > Shift-Tab may be ok, although I wonder if it’s better to make Quick Favourites quicker than Search? Once you have your Quick Favorites set up, wouldn’t you prefer to make that the easier one to execute? Ctrl/Cmd-F is nice, didnt know that existed :) Tab is currently operator search in every editor. It makes sense in the 3dview but not so much in the node views. I was thinking of the "shift+A, search" feature to go to tab for just the node views (shader, compositing, everything nodes...) Now with the new viewport transform gizmos, I think it would be better to map W E R to those instead of the active tools. Also, is there an easy way to find out what shortcut has been taken away from the regular blender keymap?

All right, here comes a round of first impressions and observations:

  • Ctrl + LMB is currently bound to "Call menu". The table in the this task says "Subtract from selection" which makes more sense. Is this a bug or was this deliberately changed?
  • Loop select does not work with Double Click nor Ctrl + LMB (this also calls the menu)
  • I'm missing MASK_MT_add (SHIFT+ A in the default Keymap). As far as I can tell SHIFT + A is free so can we keep it there?
  • How do you set the 3D cursor? It says LMB (which I would discourage. Does something speak against SHIFT + RMB? This is Blender-specific anyway)
  • How do you invoke the direct transform tools? (Like before when single/double pressing G, R or S. Similar for Extrude, Inset and so on.) Could this be added on top of the shortcuts, like when you add SHIFT it's the direct operation and without SHIFT it's selected as active tool? (which I like btw)
  • Will there be shortcuts for Select Circle or Lasso in the 3D View?

I think I read something about this somethere, but mentioning it for completeness: Rotating the viewport while in Knife tool mode does not work.

And some suggestions:

  • Would it be possible or make sense to have "Invert selection" also bound to A? For example Ctrl + Alt + A. Would be nice to have everything on the same key for quick selection changes
  • Please keep using the Mouse Wheel to increase the loop cuts for Alt + C
  • Rename is on Enter? Please keep this on F2 as well, AFAIK that's by far the most common shortcut for this.
  • I find it a bit inconsistent to have Mesh Editing tools like Extrude (CTRL + E), Inset (i), Bevel (B) and Loop cut (ALT + C) on various modifier keys. How about putting them all on the same, e.g. like Extrude (CTRL + E), Inset (CTRL +
    i), Bevel (CTRL + B) and Loop cut (CTRL + C). Since there are not many shared shortcuts here between programs anyway I think sacrificing following the industry here a bit for adding extra consistency would be a good tradeoff. IMHO the main goal with this keymap should not be 100% compliance with the industry standard tools but to have a good keymap in the end that is as close to the industry as possible without sacrifing usability.

If some issues are duplicates or already on the to-do feel free to ignore it here, don't want to waste anyones time by repeating stuff over and over again.

All right, here comes a round of first impressions and observations: - Ctrl + LMB is currently bound to "Call menu". The table in the this task says "Subtract from selection" which makes more sense. Is this a bug or was this deliberately changed? - Loop select does not work with Double Click nor Ctrl + LMB (this also calls the menu) - I'm missing MASK_MT_add (SHIFT+ A in the default Keymap). As far as I can tell SHIFT + A is free so can we keep it there? - How do you set the 3D cursor? It says LMB (which I would discourage. Does something speak against SHIFT + RMB? This is Blender-specific anyway) - How do you invoke the direct transform tools? (Like before when single/double pressing G, R or S. Similar for Extrude, Inset and so on.) Could this be added on top of the shortcuts, like when you add SHIFT it's the direct operation and without SHIFT it's selected as active tool? (which I like btw) - Will there be shortcuts for Select Circle or Lasso in the 3D View? # I think I read something about this somethere, but mentioning it for completeness: Rotating the viewport while in Knife tool mode does not work. And some suggestions: - Would it be possible or make sense to have "Invert selection" also bound to A? For example Ctrl + Alt + A. Would be nice to have everything on the same key for quick selection changes - Please keep using the Mouse Wheel to increase the loop cuts for Alt + C - Rename is on Enter? Please keep this on F2 as well, AFAIK that's by far the most common shortcut for this. - I find it a bit inconsistent to have Mesh Editing tools like Extrude (CTRL + E), Inset (i), Bevel (B) and Loop cut (ALT + C) on various modifier keys. How about putting them all on the same, e.g. like Extrude (CTRL + E), Inset (CTRL + i), Bevel (CTRL + B) and Loop cut (CTRL + C). Since there are not many shared shortcuts here between programs anyway I think sacrificing following the industry here a bit for adding extra consistency would be a good tradeoff. IMHO the main goal with this keymap should not be 100% compliance with the industry standard tools but to have a good keymap in the end that is as close to the industry as possible without sacrifing usability. If some issues are duplicates or already on the to-do feel free to ignore it here, don't want to waste anyones time by repeating stuff over and over again.

In #54963#660224, @zaha wrote:
All right, here comes a round of first impressions and observations:

Ctrl + LMB is currently bound to "Call menu". The table in the this task says "Subtract from selection" which makes more sense. Is this a bug or was this deliberately changed?

Will fix

Loop select does not work with Double Click nor Ctrl + LMB (this also calls the menu)

Double-click should work

I'm missing MASK_MT_add (SHIFT+ A in the default Keymap). As far as I can tell SHIFT + A is free so can we keep it there?

How do you set the 3D cursor? It says LMB (which I would discourage. Does something speak against SHIFT + RMB? This is Blender-specific anyway)

3D Cursor you set by enabling the 3D Cursor tool and clicking. A hotkey should be bound to the 3D Cursor tool. Could use C or Y.

How do you invoke the direct transform tools? (Like before when single/double pressing G, R or S. Similar for Extrude, Inset and so on.) Could this be added on top of the shortcuts, like when you add SHIFT it's the direct operation and without SHIFT it's selected as active tool? (which I like btw)

You use the active tools like other software.

Will there be shortcuts for Select Circle or Lasso in the 3D View?

I think I read something about this somethere, but mentioning it for completeness: Rotating the viewport while in Knife tool mode does not work.

Will fix

And some suggestions:

  • Would it be possible or make sense to have "Invert selection" also bound to A? For example Ctrl + Alt + A. Would be nice to have everything on the same key for quick selection changes

Ctrl/Cmd-I does Invert Selection

  • Please keep using the Mouse Wheel to increase the loop cuts for Alt + C

Mouse wheel does zoom.

  • Rename is on Enter? Please keep this on F2 as well, AFAIK that's by far the most common shortcut for this.

Rename is set to Return, not Enter. Can use F2 too.

  • I find it a bit inconsistent to have Mesh Editing tools like Extrude (CTRL + E), Inset (i), Bevel (B) and Loop cut (ALT + C) on various modifier keys. How about putting them all on the same, e.g. like Extrude (CTRL + E), Inset (CTRL +
    i), Bevel (CTRL + B) and Loop cut (CTRL + C). Since there are not many shared shortcuts here between programs anyway I think sacrificing following the industry here a bit for adding extra consistency would be a good tradeoff. IMHO the main goal with this keymap should not be 100% compliance with the industry standard tools but to have a good keymap in the end that is as close to the industry as possible without sacrifing usability.

The goal here is to make switching tools as effortless as possible. I strive to use direct hotkeys with no modifiers. So QWER, B, I etc,

> In #54963#660224, @zaha wrote: > All right, here comes a round of first impressions and observations: > > # Ctrl + LMB is currently bound to "Call menu". The table in the this task says "Subtract from selection" which makes more sense. Is this a bug or was this deliberately changed? Will fix > # Loop select does not work with Double Click nor Ctrl + LMB (this also calls the menu) Double-click should work > # I'm missing MASK_MT_add (SHIFT+ A in the default Keymap). As far as I can tell SHIFT + A is free so can we keep it there? > # How do you set the 3D cursor? It says LMB (which I would discourage. Does something speak against SHIFT + RMB? This is Blender-specific anyway) 3D Cursor you set by enabling the 3D Cursor tool and clicking. A hotkey should be bound to the 3D Cursor tool. Could use C or Y. > # How do you invoke the direct transform tools? (Like before when single/double pressing G, R or S. Similar for Extrude, Inset and so on.) Could this be added on top of the shortcuts, like when you add SHIFT it's the direct operation and without SHIFT it's selected as active tool? (which I like btw) You use the active tools like other software. > # Will there be shortcuts for Select Circle or Lasso in the 3D View? > # I think I read something about this somethere, but mentioning it for completeness: Rotating the viewport while in Knife tool mode does not work. Will fix > And some suggestions: > > - Would it be possible or make sense to have "Invert selection" also bound to A? For example Ctrl + Alt + A. Would be nice to have everything on the same key for quick selection changes Ctrl/Cmd-I does Invert Selection > - Please keep using the Mouse Wheel to increase the loop cuts for Alt + C Mouse wheel does zoom. > - Rename is on Enter? Please keep this on F2 as well, AFAIK that's by far the most common shortcut for this. Rename is set to Return, not Enter. Can use F2 too. > - I find it a bit inconsistent to have Mesh Editing tools like Extrude (CTRL + E), Inset (i), Bevel (B) and Loop cut (ALT + C) on various modifier keys. How about putting them all on the same, e.g. like Extrude (CTRL + E), Inset (CTRL + > i), Bevel (CTRL + B) and Loop cut (CTRL + C). Since there are not many shared shortcuts here between programs anyway I think sacrificing following the industry here a bit for adding extra consistency would be a good tradeoff. IMHO the main goal with this keymap should not be 100% compliance with the industry standard tools but to have a good keymap in the end that is as close to the industry as possible without sacrifing usability. The goal here is to make switching tools as effortless as possible. I strive to use direct hotkeys with no modifiers. So QWER, B, I etc,

Loop select does not work with Double Click nor Ctrl + LMB (this also calls the menu)

Double-click should work

Either I'm doing something wrong or it does not work in the current build. Tried several times now to double click with LMB and nothing happens. Using the Menu Select Loops » Edge Loops works.

I'm missing MASK_MT_add (SHIFT+ A in the default Keymap). As far as I can tell SHIFT + A is free so can we keep it there?

I think you missed that point. Will there be a shortcut for it, too?

How do you invoke the direct transform tools? (Like before when single/double pressing G, R or S. Similar for Extrude, Inset and so on.) Could this be added on top of the shortcuts, like when you add SHIFT it's the direct operation and without SHIFT it's selected as active tool? (which I like btw)

You use the active tools like other software.

Ok, that's a bummer. Always loved that you could switch between global and local orientation by double tapping it. But I guess then it will be W » , » 4/6 in the future.

  • Please keep using the Mouse Wheel to increase the loop cuts for Alt + C

Mouse wheel does zoom.

I see. How about using CTRL + Mouse Wheel or CTRL + +/- then to increase/decrease the number of loop cuts?

  • Rename is on Enter? Please keep this on F2 as well, AFAIK that's by far the most common shortcut for this.

Rename is set to Return, not Enter. Can use F2 too.

Ah my bad, mixed up Enter and Return. Please do add it on F2. In my experience it's very common.

Thanks for the other explanations.

>> # Loop select does not work with Double Click nor Ctrl + LMB (this also calls the menu) > Double-click should work Either I'm doing something wrong or it does not work in the current build. Tried several times now to double click with LMB and nothing happens. Using the Menu Select Loops » Edge Loops works. > # I'm missing MASK_MT_add (SHIFT+ A in the default Keymap). As far as I can tell SHIFT + A is free so can we keep it there? I think you missed that point. Will there be a shortcut for it, too? >> # How do you invoke the direct transform tools? (Like before when single/double pressing G, R or S. Similar for Extrude, Inset and so on.) Could this be added on top of the shortcuts, like when you add SHIFT it's the direct operation and without SHIFT it's selected as active tool? (which I like btw) > > You use the active tools like other software. Ok, that's a bummer. Always loved that you could switch between global and local orientation by double tapping it. But I guess then it will be W » , » 4/6 in the future. >> - Please keep using the Mouse Wheel to increase the loop cuts for Alt + C > Mouse wheel does zoom. I see. How about using CTRL + Mouse Wheel or CTRL + +/- then to increase/decrease the number of loop cuts? >> - Rename is on Enter? Please keep this on F2 as well, AFAIK that's by far the most common shortcut for this. > Rename is set to Return, not Enter. Can use F2 too. Ah my bad, mixed up Enter and Return. Please do add it on F2. In my experience it's very common. Thanks for the other explanations.

Added subscriber: @nabaxo

Added subscriber: @nabaxo

In #54963#660241, @zaha wrote:

Loop select does not work with Double Click nor Ctrl + LMB (this also calls the menu)

Double-click should work

Either I'm doing something wrong or it does not work in the current build. Tried several times now to double click with LMB and nothing happens. Using the Menu Select Loops » Edge Loops works.

Any chance you have a "Restore" button on that section of the keymapping that's over riding it?

> In #54963#660241, @zaha wrote: >>> # Loop select does not work with Double Click nor Ctrl + LMB (this also calls the menu) >> Double-click should work > > Either I'm doing something wrong or it does not work in the current build. Tried several times now to double click with LMB and nothing happens. Using the Menu Select Loops » Edge Loops works. > Any chance you have a "Restore" button on that section of the keymapping that's over riding it?

In #54963#660326, @Dheim wrote:

In #54963#660241, @zaha wrote:

Loop select does not work with Double Click nor Ctrl + LMB (this also calls the menu)

Double-click should work

Either I'm doing something wrong or it does not work in the current build. Tried several times now to double click with LMB and nothing happens. Using the Menu Select Loops » Edge Loops works.

Any chance you have a "Restore" button on that section of the keymapping that's over riding it?

No, but doing a factory reset fixed it for me. There must have been something wrong in my settings, maybe from an older build. Thanks, your question made me realize I could try that!

> In #54963#660326, @Dheim wrote: >> In #54963#660241, @zaha wrote: >>>> # Loop select does not work with Double Click nor Ctrl + LMB (this also calls the menu) >>> Double-click should work >> >> Either I'm doing something wrong or it does not work in the current build. Tried several times now to double click with LMB and nothing happens. Using the Menu Select Loops » Edge Loops works. >> > Any chance you have a "Restore" button on that section of the keymapping that's over riding it? No, but doing a factory reset fixed it for me. There must have been something wrong in my settings, maybe from an older build. Thanks, your question made me realize I could try that!

Double-Click to select an edge loop is working for me. However, if I hold down SHIFT and double-click to attempt to add/select a second edge loop to the already selected one, this only seems to work some of the time, and then very infrequently. This is making it difficult to quickly select multiple edge loops.

EDIT: Figured it out. If I already have an edge loop selected and want to add another one, I need to first select an edge (shift+click) and the, after it is selected, shift+double-click to add the new edge loop selection. I wasn't first selecting an edge THEN double-clicking on it.

Double-Click to select an edge loop is working for me. However, if I hold down SHIFT and double-click to attempt to add/select a second edge loop to the already selected one, this only seems to work some of the time, and then very infrequently. This is making it difficult to quickly select multiple edge loops. EDIT: Figured it out. If I already have an edge loop selected and want to add another one, I need to first select an edge (shift+click) and the, after it is selected, shift+double-click to add the new edge loop selection. I wasn't first selecting an edge THEN double-clicking on it.

Currently, pressing 1 puts Blender in object mode, 2-4 are edit mode, vertex, edge, and face respectively. However, I am used to 3D software assigning 1-3 as vertex, edge, and face mode, with either 4 or 5 being object mode (sometimes 4 is material selection mode and 5 object mode). I think it makes more sense to have 1-3 assigned as editing modes (vertex, edge, and face) because, when modeling, you spend most of your time in these modes, and not in object mode.

Currently, pressing 1 puts Blender in object mode, 2-4 are edit mode, vertex, edge, and face respectively. However, I am used to 3D software assigning 1-3 as vertex, edge, and face mode, with either 4 or 5 being object mode (sometimes 4 is material selection mode and 5 object mode). I think it makes more sense to have 1-3 assigned as editing modes (vertex, edge, and face) because, when modeling, you spend most of your time in these modes, and not in object mode.

This one may be small, but it currently irks me. In the standard Blender keymap, when you bevel and edge, you can roll the mouse wheel to add smoothness (more edges). With the industry keymap, you have to keep the LMB pressed while, at the same time, scrolling the mouse wheel to add more edges. This takes a little more dexterity and, as a result, is not as simple as the Blender keymap way of doing it. Is there any way to make a sort of hybrid between the two where the LMB can be released and the bevel action is not dropped so the mouse wheel can be scrolled to add smoothness to the bevel?

This one may be small, but it currently irks me. In the standard Blender keymap, when you bevel and edge, you can roll the mouse wheel to add smoothness (more edges). With the industry keymap, you have to keep the LMB pressed while, at the same time, scrolling the mouse wheel to add more edges. This takes a little more dexterity and, as a result, is not as simple as the Blender keymap way of doing it. Is there any way to make a sort of hybrid between the two where the LMB can be released and the bevel action is not dropped so the mouse wheel can be scrolled to add smoothness to the bevel?

Added subscriber: @r4p7or_3D

Added subscriber: @r4p7or_3D

(Sorry if this is a known issue.)

Blender 2.8 win 64
14884cda1f (d13.m4.y2019 18:58)

Industry Compatible Keymap is ON

I have just noticed a bug. If I am rotating the view using Alt + LMB and my cursor happens to be inside or near the manipulator circle (Move tool) Blender engages the move command instead of rotating the view.

Alt + LMB should be reserved for navigation only no matter what is under the cursor.

This also happens with other tools like Rotate and Scale.

blender_industry_c_keymap_nav_bug.webm

*(Sorry if this is a known issue.)* Blender 2.8 win 64 **14884cda1ff5** (d13.m4.y2019 18:58) Industry Compatible Keymap is ON I have just noticed a bug. If I am rotating the view using Alt + LMB and my cursor happens to be inside or near the manipulator circle (Move tool) Blender engages the move command instead of rotating the view. Alt + LMB should be reserved for navigation only no matter what is under the cursor. This also happens with other tools like Rotate and Scale. [blender_industry_c_keymap_nav_bug.webm](https://archive.blender.org/developer/F6944505/blender_industry_c_keymap_nav_bug.webm)

I'm not sure if I've just missed an option somewhere, but I've noticed that marquee selection doesn't work if you're currently using any tool other than the standard selection. Most packages I've used will still allow you to marquee select no matter what manipulation tool you're currently using. The current behaviour will move/rotate/whatever in screen space if you click and drag in the empty areas. I personally find it a bit cumbersome to have to hit Q to go back to the selection tool, drag a selection box, then hit W or E to go back to the last tool I was using.

I can understand why the current behaviour might be preferrable for some, but an option to choose one or the other would be great, if it doesn't already exist.

I'm not sure if I've just missed an option somewhere, but I've noticed that marquee selection doesn't work if you're currently using any tool other than the standard selection. Most packages I've used will still allow you to marquee select no matter what manipulation tool you're currently using. The current behaviour will move/rotate/whatever in screen space if you click and drag in the empty areas. I personally find it a bit cumbersome to have to hit Q to go back to the selection tool, drag a selection box, then hit W or E to go back to the last tool I was using. I can understand why the current behaviour might be preferrable for some, but an option to choose one or the other would be great, if it doesn't already exist.

In #54963#660735, @Midda wrote:
I'm not sure if I've just missed an option somewhere, but I've noticed that marquee selection doesn't work if you're currently using any tool other than the standard selection. Most packages I've used will still allow you to marquee select no matter what manipulation tool you're currently using. The current behaviour will move/rotate/whatever in screen space if you click and drag in the empty areas. I personally find it a bit cumbersome to have to hit Q to go back to the selection tool, drag a selection box, then hit W or E to go back to the last tool I was using.

I can understand why the current behaviour might be preferrable for some, but an option to choose one or the other would be great, if it doesn't already exist.

I think this is the current intended functionality, but I agree that LMB marquee selection should be possible with any transform tool active. Rather than using LMB drag anywhere in the viewport to move/rotate/scale when a transform tool is active (and an object is selected), I would recommend that this keymap use middle-mouse drag for this functionality, similar to how it works in Maya. This way left-click drag is always available for marquee selection.

> In #54963#660735, @Midda wrote: > I'm not sure if I've just missed an option somewhere, but I've noticed that marquee selection doesn't work if you're currently using any tool other than the standard selection. Most packages I've used will still allow you to marquee select no matter what manipulation tool you're currently using. The current behaviour will move/rotate/whatever in screen space if you click and drag in the empty areas. I personally find it a bit cumbersome to have to hit Q to go back to the selection tool, drag a selection box, then hit W or E to go back to the last tool I was using. > > I can understand why the current behaviour might be preferrable for some, but an option to choose one or the other would be great, if it doesn't already exist. I think this is the current intended functionality, but I agree that LMB marquee selection should be possible with any transform tool active. Rather than using LMB drag anywhere in the viewport to move/rotate/scale when a transform tool is active (and an object is selected), I would recommend that this keymap use middle-mouse drag for this functionality, similar to how it works in Maya. This way left-click drag is always available for marquee selection.

Yeah, I expect it's the intended behaviour, as this is how the default Blender keymap behaves. But yeah, it could just be because I'm used to Maya, but using middle-click in place of the current left-click behaviour would allow both types of functionality, as middle-mouse doesn't currently do anything when you click and drag in empty areas.

Yeah, I expect it's the intended behaviour, as this is how the default Blender keymap behaves. But yeah, it could just be because I'm used to Maya, but using middle-click in place of the current left-click behaviour would allow both types of functionality, as middle-mouse doesn't currently do anything when you click and drag in empty areas.

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'

Setting as Resolved for now, although feedback is still welcome.

Setting as Resolved for now, although feedback is still welcome.

in uv editor no job select mode vertex, edge, face.
in 3ds max sub object job in all mode 1-5.

in uv editor no job select mode vertex, edge, face. in 3ds max sub object job in all mode 1-5.

A binding for "Toggle sidebar" is missing in many editors, e.g. the 3D viewport.

A binding for "Toggle sidebar" is missing in many editors, e.g. the 3D viewport.
Contributor

Some issues I have encountered:

  1. If the map has to be compatible with industry standards, then the zoom method setting in the preferences should be changed from vertical to horizontal. Most of the Maya style navigation users are used to zoom horizontally, as it's much easier to do while holding a mouse:
    image.png
  2. 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.
  3. 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.
  4. Ctrl+Left clicking to deselect triggers a menu entry instead for some reason:
    2019-04-15 22-11-58.mov
  5. Ring select shortcut missing...?
Some issues I have encountered: 1. If the map has to be compatible with industry standards, then the zoom method setting in the preferences should be changed from vertical to horizontal. Most of the Maya style navigation users are used to zoom horizontally, as it's much easier to do while holding a mouse: ![image.png](https://archive.blender.org/developer/F6949128/image.png) 2. 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. 3. 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. 4. Ctrl+Left clicking to deselect triggers a menu entry instead for some reason: [2019-04-15 22-11-58.mov](https://archive.blender.org/developer/F6949148/2019-04-15_22-11-58.mov) 5. Ring select shortcut missing...?

Added subscriber: @lemenicier_julien

Added subscriber: @lemenicier_julien

Removed subscriber: @hawc445

Removed subscriber: @hawc445

Added subscriber: @hawc445

Added subscriber: @hawc445

Added subscriber: @ArmoredWolf

Added subscriber: @ArmoredWolf

In #54963#661145, @Rawalanche wrote:

  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?

> In #54963#661145, @Rawalanche wrote: > 2. 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. > 3. 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. > 4. Ctrl+Left clicking to deselect triggers a menu entry instead for some reason: This was changed already. > 5. 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.

  2. 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. Can I suggest adding 'Duplicate Linked' as *Alt-D* ? I think it is even more frequently used than regular Duplicate. 2. 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.
Contributor

In #54963#661400, @WilliamReynish wrote:

In #54963#661145, @Rawalanche wrote:

  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
image.png
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

> In #54963#661400, @WilliamReynish wrote: >> In #54963#661145, @Rawalanche wrote: > >> 2. 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. > >> 3. 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. > >> 4. Ctrl+Left clicking to deselect triggers a menu entry instead for some reason: > > This was changed already. > >> 5. 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 ![image.png](https://archive.blender.org/developer/F6950722/image.png) 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
Member

Removed subscriber: @JulienKaspar

Removed subscriber: @JulienKaspar

@GatisKurzemnieks
Set viewpoints to F-keys as you suggest.

@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.

@GatisKurzemnieks Set viewpoints to F-keys as you suggest. @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 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

In #54963#661688, @ACap99 wrote:
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.

> In #54963#661688, @ACap99 wrote: > 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.
Contributor

In #54963#661621, @WilliamReynish wrote:
@GatisKurzemnieks
Set viewpoints to F-keys as you suggest.

@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.

> In #54963#661621, @WilliamReynish wrote: > @GatisKurzemnieks > Set viewpoints to F-keys as you suggest. > > @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.

In #54963#661416, @GatisKurzemnieks wrote:

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

This is important

In #54963#661417, @Rawalanche wrote:
@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.

In #54963#661416, @GatisKurzemnieks wrote:
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.

> In #54963#661416, @GatisKurzemnieks wrote: > 1. Can I suggest adding 'Duplicate Linked' as *Alt-D* ? I think it is even more frequently used than regular Duplicate. This is important > In #54963#661417, @Rawalanche wrote: > @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. > In #54963#661416, @GatisKurzemnieks wrote: >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.

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.

Removed subscriber: @nabaxo

Removed subscriber: @nabaxo

Added subscriber: @Oskar3d

Added subscriber: @Oskar3d

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 Panningset 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:
knife_tool_workaround.png

Maybe we can add this to the IC Keymap?

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: ![knife_tool_workaround.png](https://archive.blender.org/developer/F6951550/knife_tool_workaround.png) Maybe we can add this to the IC Keymap?

Added subscriber: @nabaxo

Added subscriber: @nabaxo

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?

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?

@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.

@Oskar3d This should be how it works already.

@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.

@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. @Oskar3d This should be how it works already. @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-70, 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-70, 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

In #54963#661895, @ArmoredWolf wrote:
@william-70, 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.

> In #54963#661895, @ArmoredWolf wrote: > @william-70, 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 ](http://xahlee.info/kbd/i/layout/Germany_kbd.png)). Will there be a localized equivalent here? Otherwise that key is unusable for many people.
Contributor

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? :|

In #54963#661909, @Rawalanche wrote:
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!

> In #54963#661909, @Rawalanche wrote: > 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!

In #54963#661895, @ArmoredWolf wrote:
@william-70, 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.

> In #54963#661895, @ArmoredWolf wrote: > @william-70, 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.

- 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](https://archive.blender.org/developer/F6952358/Desktop_2019.04.16_-_21.08.28.04.mp4)}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.

In #54963#661928, @DanieleViagi wrote:

  • 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.

> In #54963#661928, @DanieleViagi wrote: > > - 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.

@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.

@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.

@DanieleViagi 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.

@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. @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. @DanieleViagi 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.

In #54963#661930, @WilliamReynish wrote:
@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).

> In #54963#661930, @WilliamReynish wrote: > @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).

@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.

@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.

Added subscriber: @dan-34

Added subscriber: @dan-34

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

@william-70 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

@dan-34 Silverman (ArgentArts) This is why I wrote almost impossible, I thought this was a bug :) I don't think it's ideal too @william-70 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 ](https://developer.blender.org/F6952358)

In #54963#661929, @ArgentArts wrote:

In #54963#661928, @DanieleViagi wrote:

  • 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).

> In #54963#661929, @ArgentArts wrote: >> In #54963#661928, @DanieleViagi wrote: >> >> - 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).

In #54963#661935, @WilliamReynish wrote:
@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

> In #54963#661935, @WilliamReynish wrote: > @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

In #54963#661935, @WilliamReynish wrote:
@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.

> In #54963#661935, @WilliamReynish wrote: > @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.

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

@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.

@ArmoredWolf The loop select extend issue was simply a bug in the keymap. It is now fixed. @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?
preferences.png

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? ![preferences.png](https://archive.blender.org/developer/F6952473/preferences.png)

In #54963#661940, @zaha wrote:

In #54963#661935, @WilliamReynish wrote:
@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.

> In #54963#661940, @zaha wrote: >> In #54963#661935, @WilliamReynish wrote: >> @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.

@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.

@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.

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.

In #54963#661946, @WilliamReynish wrote:
@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.

@WilliamReynish 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.

> In #54963#661946, @WilliamReynish wrote: > @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. @WilliamReynish 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.

@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.

@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.

In #54963#661952, @zaha wrote:
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.

In #54963#661953, @WilliamReynish wrote:
@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.

> In #54963#661952, @zaha wrote: > 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. > In #54963#661953, @WilliamReynish wrote: > @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.

@WilliamReynish
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: edc1b01675)
It creates a point every time you hover over an edge (without clicking).
knife_tool_bug.gif
But it works fine with my settings, don't know why. If you like I can try to reproduce how I set it up.

@WilliamReynish 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). ![knife_tool_bug.gif](https://archive.blender.org/developer/F6952582/knife_tool_bug.gif) 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.

+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.

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.

Industry Compatible Keymap.PNG

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. 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. ![Industry Compatible Keymap.PNG](https://archive.blender.org/developer/F6953467/Industry_Compatible_Keymap.PNG) 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'} ```

In #54963#662053, @DanPool wrote:
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!

> In #54963#662053, @DanPool wrote: > 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!
Contributor

In #54963#661930, @WilliamReynish wrote:
@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).

> In #54963#661930, @WilliamReynish wrote: > @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).
Contributor

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.

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.
Contributor

In #54963#662061, @WilliamReynish wrote:
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?

> In #54963#662061, @WilliamReynish wrote: > 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?

Removed subscriber: @NNois

Removed subscriber: @NNois
  • 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 - 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
Contributor

In #54963#662064, @WilliamReynish wrote:
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.

> In #54963#662064, @WilliamReynish wrote: > 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.

In #54963#662061, @WilliamReynish wrote:
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).

> In #54963#662061, @WilliamReynish wrote: > 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
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
Contributor

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.

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

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

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 :)

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.

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.

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?

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?
Contributor

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.

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.

In #54963#662087, @brecht wrote:
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.

> In #54963#662087, @brecht wrote: > 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.

In #54963#662061, @WilliamReynish wrote:

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.

> In #54963#662061, @WilliamReynish wrote: > > 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 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 @WilliamReynish 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.

As @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 @WilliamReynish 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.

In #54963#662149, @zaha wrote:
Do you consider such users a target audience for this keymap @WilliamReynish 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. ;)

> In #54963#662149, @zaha wrote: > Do you consider such users a target audience for this keymap @WilliamReynish 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. ;)

In #54963#662151, @ArgentArts wrote:

In #54963#662149, @zaha wrote:
Do you consider such users a target audience for this keymap @WilliamReynish 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.

> In #54963#662151, @ArgentArts wrote: >> In #54963#662149, @zaha wrote: >> Do you consider such users a target audience for this keymap @WilliamReynish 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.

@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.

@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.

In #54963#662168, @brecht wrote:
@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).

> In #54963#662168, @brecht wrote: > @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?

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?

Removed subscriber: @LucianoMunoz

Removed subscriber: @LucianoMunoz

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.

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-70 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 Desktop 2019.04.18 - 08.48.07.01.mp4

My proposal Desktop 2019.04.16 - 21.08.28.04.mp4

@william-70 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 [Desktop 2019.04.18 - 08.48.07.01.mp4](https://archive.blender.org/developer/F6956121/Desktop_2019.04.18_-_08.48.07.01.mp4) My proposal [Desktop 2019.04.16 - 21.08.28.04.mp4](https://archive.blender.org/developer/F6952358/Desktop_2019.04.16_-_21.08.28.04.mp4)

In #54963#662087, @brecht wrote:
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.

> In #54963#662087, @brecht wrote: > 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.

Added subscriber: @giakaama

Added subscriber: @giakaama

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 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.

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.
Contributor

@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

@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

@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.)

@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.)

@WilliamReynish 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 Shortcut Notes
Edit & Object Mode Tools
Add VIEW3D_MT_add, VIEW3D_MT_mesh_add Shift + A
Toggle Snap ToolSettings.use_snap X Taken from Maya according to Google research
Transformation Tool Toggling
Toggle Move gizmo show_gizmo_object_translate Shift + W It would be nice to toggle the visibility of the transform gizmos by adding Shift to the keys
Toggle Rotate gizmo show_gizmo_object_rotate Shift + E
Toggle Scale gizmo show_gizmo_object_scale Shift + R
Selection Tools
Circle select builtin.select_circle Ctrl + Q The standard key for quitting the application should be Alt + F4 (which already works, too). If not possible Shift + Q could be used instead.
Lasso select builtin.select_lasso Alt + Q
Cursor Tool
Reset/center cursor ? Shift + C
Set 3D Cursor ? Shift + RMB Since 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
Bevel Mesh -> Bevel Shift + B
Inset Mesh -> Inset Faces Shift + I
Loop cut Mesh -> Loop Cut and Slide Shift + Alt + C
Extrude Mesh -> Extrude and Move on Normals Shift + Ctrl + E
Knife Mesh -> Knife Topology Tool Shift + K

Issues:

  • "Deselect All" is really strenuous to press with all keys being very close to each other.
Name Proposed Shortcut Notes
Deselect All Ctrl + Alt + A
Alternative
Select All Shift + A Even better, going with the convention of Shift is adding to a selection.
Deselect All Shift + 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.
@WilliamReynish 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 Shortcut** | **Notes**| | -- | -- | -- | -- | | *Edit & Object Mode Tools*| | Add | VIEW3D_MT_add, VIEW3D_MT_mesh_add | Shift + A | | Toggle Snap | ToolSettings.use_snap| X | Taken from Maya according to Google research | | *Transformation Tool Toggling* | | Toggle Move gizmo | show_gizmo_object_translate | Shift + W | It would be nice to toggle the visibility of the transform gizmos by adding Shift to the keys | | Toggle Rotate gizmo | show_gizmo_object_rotate| Shift + E | | Toggle Scale gizmo | show_gizmo_object_scale| Shift + R | | *Selection Tools* | | Circle select | builtin.select_circle | Ctrl + Q | The standard key for quitting the application should be Alt + F4 (which already works, too). If not possible Shift + Q could be used instead. | | Lasso select | builtin.select_lasso | Alt + Q | | *Cursor Tool* | | Reset/center cursor | ? | Shift + C | | Set 3D Cursor | ? | Shift + RMB | Since 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** | | -- | -- | -- | | Bevel | Mesh -> Bevel | Shift + B | | Inset | Mesh -> Inset Faces| Shift + I | | Loop cut| Mesh -> Loop Cut and Slide| Shift + Alt + C | | Extrude | Mesh -> Extrude and Move on Normals|Shift + Ctrl + E | | Knife | Mesh -> Knife Topology Tool| Shift + K | **Issues:** - "Deselect All" is really strenuous to press with all keys being very close to each other. | **Name**| **Proposed Shortcut** | **Notes** | | -- | -- | -- | | Deselect All | Ctrl + Alt + A | | *Alternative* | | Select All | Shift + A | Even better, going with the convention of Shift is adding to a selection. | | Deselect All | Shift + 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.

Added subscriber: @michael-123

Added subscriber: @michael-123

@michael-123 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

@michael-123 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

@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.
ClickDrag.png

@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.

@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. ![ClickDrag.png](https://archive.blender.org/developer/F6970363/ClickDrag.png) @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.
ff.png

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. ![ff.png](https://archive.blender.org/developer/F6970367/ff.png)

In #54963#664917, @DanPool wrote:
@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.
ClickDrag.png

@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. @WilliamReynish 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.

@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.

> In #54963#664917, @DanPool wrote: > @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. > ![ClickDrag.png](https://archive.blender.org/developer/F6970363/ClickDrag.png) > > @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. @WilliamReynish 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. @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.

In #54963#664924, @Znio.G wrote:
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.
ff.png

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

> In #54963#664924, @Znio.G wrote: > 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. > ![ff.png](https://archive.blender.org/developer/F6970367/ff.png) Yes, that would be the main Ideea, now we only need @WilliamReynish to change those :) . I think Pablo said that the " move, rotate, scale - TOOLS " will be obsolete and be removed .

In #54963#664924, @Znio.G wrote:
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.

> In #54963#664924, @Znio.G wrote: > 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.

In #54963#665280, @TheRedWaxPolice wrote:

In #54963#664924, @Znio.G wrote:
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.

> In #54963#665280, @TheRedWaxPolice wrote: >> In #54963#664924, @Znio.G wrote: >> 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.

In #54963#665280, @TheRedWaxPolice wrote:

In #54963#664924, @Znio.G wrote:
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.
Select Tool.PNG

> In #54963#665280, @TheRedWaxPolice wrote: >> In #54963#664924, @Znio.G wrote: >> 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. ![Select Tool.PNG](https://archive.blender.org/developer/F6972558/Select_Tool.PNG)

In #54963#665307, @Znio.G wrote:
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.

In #54963#665361, @DanPool wrote:
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.
Select Tool.PNG

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.

> In #54963#665307, @Znio.G wrote: > 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. > In #54963#665361, @DanPool wrote: > 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. > ![Select Tool.PNG](https://archive.blender.org/developer/F6972558/Select_Tool.PNG) 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.

@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.

@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 .
image.png

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 . ![image.png](https://archive.blender.org/developer/F6974802/image.png)

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.

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.

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.

In #54963#665795, @WilliamReynish wrote:
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.

@WilliamReynish Thank you, that was bothering me.

> In #54963#665795, @WilliamReynish wrote: > 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. @WilliamReynish Thank you, that was bothering me.

Hey William, this is a lot better now especially with the middle mouse button.
One small issue though. If you want to move the object by 5 units in X, you have to click MMB once, move the mouse slightly then hit X, then 5 and enter.
Would it be possible to not move the mouse slightly or would it interfere with something else?

Also, TAB seems to be operator search in every editor. It would make more sense to have it as "node search" rather then operator search in the shader and comp editor.

Will some original blender shortcuts make a return in this one like the add menu or TAB for edit in 3dview?

Hey William, this is a lot better now especially with the middle mouse button. One small issue though. If you want to move the object by 5 units in X, you have to click MMB once, move the mouse slightly then hit X, then 5 and enter. Would it be possible to not move the mouse slightly or would it interfere with something else? Also, TAB seems to be operator search in every editor. It would make more sense to have it as "node search" rather then operator search in the shader and comp editor. Will some original blender shortcuts make a return in this one like the add menu or TAB for edit in 3dview?

It seems the buildbot didn't updated. I've downloaded a new build and it's still the same :( .

It seems the buildbot didn't updated. I've downloaded a new build and it's still the same :( .

In #54963#665927, @irfancelik wrote:
Hey William, this is a lot better now especially with the middle mouse button.
One small issue though. If you want to move the object by 5 units in X, you have to click MMB once, move the mouse slightly then hit X, then 5 and enter.

That is because the modal keymap is only active while moving. There's no real way around this.

Would it be possible to not move the mouse slightly or would it interfere with something else?

It would. It's both technically tricky but also would make it impossible to use the keyboard to change tools, if the keyboard is being used to make adjustments to the current tool.

Also, TAB seems to be operator search in every editor. It would make more sense to have it as "node search" rather then operator search in the shader and comp editor.

Maybe it could invoke the Add menu here, but really that would be rather inconsistent.

Will some original blender shortcuts make a return in this one like the add menu or TAB for edit in 3dview?

The modes are set to the number keys.

> In #54963#665927, @irfancelik wrote: > Hey William, this is a lot better now especially with the middle mouse button. > One small issue though. If you want to move the object by 5 units in X, you have to click MMB once, move the mouse slightly then hit X, then 5 and enter. That is because the modal keymap is only active while moving. There's no real way around this. > Would it be possible to not move the mouse slightly or would it interfere with something else? It would. It's both technically tricky but also would make it impossible to use the keyboard to change tools, if the keyboard is being used to make adjustments to the current tool. > Also, TAB seems to be operator search in every editor. It would make more sense to have it as "node search" rather then operator search in the shader and comp editor. Maybe it could invoke the Add menu here, but really that would be rather inconsistent. > Will some original blender shortcuts make a return in this one like the add menu or TAB for edit in 3dview? The modes are set to the number keys.

I didn´t mean the Add menu itself, I meant the search item in the add menu in the node editor. This is the way it is in Nuke, Maya etc. You hit TAB and directly type in what you are looking for.
Anyway, if that is not possible, and since shift+A is still used for the add menu in the node editor, wouldn´t it be more consistent to have shift+A for the add menu in the 3d view as well?

I didn´t mean the Add menu itself, I meant the search item in the add menu in the node editor. This is the way it is in Nuke, Maya etc. You hit TAB and directly type in what you are looking for. Anyway, if that is not possible, and since shift+A is still used for the add menu in the node editor, wouldn´t it be more consistent to have shift+A for the add menu in the 3d view as well?

In #54963#666157, @giakaama wrote:
It seems the buildbot didn't updated. I've downloaded a new build and it's still the same :( .

Oh I am building blender myself. Sorry :)

William, there seems to something wrong with the T and N panel. I can´t seem to activate them via their hotkeys nor drag them out with the mouse. Just with the menu entry and when that is done once, it works using the mouse again yet still no luck with the hotkeys.

> In #54963#666157, @giakaama wrote: > It seems the buildbot didn't updated. I've downloaded a new build and it's still the same :( . Oh I am building blender myself. Sorry :) William, there seems to something wrong with the T and N panel. I can´t seem to activate them via their hotkeys nor drag them out with the mouse. Just with the menu entry and when that is done once, it works using the mouse again yet still no luck with the hotkeys.

Hi , for toggle quad view and return in any view shortcut please . Thank you .

Hi , for toggle quad view and return in any view shortcut please . Thank you .

In #54963#666178, @irfancelik wrote:

In #54963#666157, @giakaama wrote:
It seems the buildbot didn't updated. I've downloaded a new build and it's still the same :( .

Oh I am building blender myself. Sorry :)

William, there seems to something wrong with the T and N panel. I can´t seem to activate them via their hotkeys nor drag them out with the mouse. Just with the menu entry and when that is done once, it works using the mouse again yet still no luck with the hotkeys.

Those are two separate things. I assume you are referring to the Toolbar and Sidebar, which happen to be assigned to the T and N keys in the default keymap. In this keymap they aren't bound to those keys.

As for the arrow, it's a bug bug not related to keymaps.

> In #54963#666178, @irfancelik wrote: >> In #54963#666157, @giakaama wrote: >> It seems the buildbot didn't updated. I've downloaded a new build and it's still the same :( . > > Oh I am building blender myself. Sorry :) > > William, there seems to something wrong with the T and N panel. I can´t seem to activate them via their hotkeys nor drag them out with the mouse. Just with the menu entry and when that is done once, it works using the mouse again yet still no luck with the hotkeys. Those are two separate things. I assume you are referring to the Toolbar and Sidebar, which happen to be assigned to the T and N keys in the default keymap. In this keymap they aren't bound to those keys. As for the arrow, it's a bug bug not related to keymaps.

Sorry for being unclear. I meant the Toolbar and Sidebar and according to the menu entry, they are assigned to CTRL [ and CTRL ] which don´t work on my German keyboard layout.

Sorry for being unclear. I meant the Toolbar and Sidebar and according to the menu entry, they are assigned to CTRL [ and CTRL ] which don´t work on my German keyboard layout.

In #54963#666316, @irfancelik wrote:
Sorry for being unclear. I meant the Toolbar and Sidebar and according to the menu entry, they are assigned to CTRL [ and CTRL ] which don´t work on my German keyboard layout.

I experienced the same at first, but then found out that you have to press the keys at the same location as [ and ] on the US layout instead of the same character, which would be ? and ` (to two keys to the right of backspace).

And I have to support adding Shift + A to the 3dView (as mentioned several times already by me, but it hasn't been answered so far :( ).

> In #54963#666316, @irfancelik wrote: > Sorry for being unclear. I meant the Toolbar and Sidebar and according to the menu entry, they are assigned to CTRL [ and CTRL ] which don´t work on my German keyboard layout. I experienced the same at first, but then found out that you have to press the keys at the same location as [ and ] on the US layout instead of the same character, which would be ? and ` (to two keys to the right of backspace). And I have to support adding Shift + A to the 3dView (as mentioned several times already by me, but it hasn't been answered so far :( ).

Removed subscriber: @ideasman42

Removed subscriber: @ideasman42

@zaha: do any other apps use Shift-A to add new items or primitives?

@zaha: do any other apps use Shift-A to add new items or primitives?

In #54963#666319, @WilliamReynish wrote:
@zaha: do any other apps use Shift-A to add new items or primitives?

Nope, In modo usualy you bind a shortcut to each primitive if you want to speed it up. The rest are the same bind shortcuts or press the menu button .

(EDIT)

Usualy there is only 1 click to produce the primitive. In blender there are 2
Shift+A then click on the primitive

In other apps the primitives are usualy in the main menu so it's just 1 click and 1m x 1m cube or sphere etc ... appears in the viewport .

After you made the primitive you can edit it :) .

It's ok even with Shift+A then click ... my oppinion if you want to go faster ... move the Shift+A menu on RightClick when in Object Mode .
Like in Silo 3D

And If it's not a bother can you please put

1 For Vertex Mode
2 For Edge Mode
3 For Face Mode
4 For Object Mode
?

EX in Modo 4 it's for Select By Material and 5 Is for object mode :) ( I know I can change them myself )

> In #54963#666319, @WilliamReynish wrote: > @zaha: do any other apps use Shift-A to add new items or primitives? Nope, In modo usualy you bind a shortcut to each primitive if you want to speed it up. The rest are the same bind shortcuts or press the menu button . (EDIT) Usualy there is only 1 click to produce the primitive. In blender there are 2 Shift+A then click on the primitive In other apps the primitives are usualy in the main menu so it's just 1 click and 1m x 1m cube or sphere etc ... appears in the viewport . After you made the primitive you can edit it :) . It's ok even with Shift+A then click ... my oppinion if you want to go faster ... move the Shift+A menu on RightClick when in Object Mode . Like in Silo 3D And If it's not a bother can you please put 1 For Vertex Mode 2 For Edge Mode 3 For Face Mode 4 For Object Mode ? EX in Modo 4 it's for Select By Material and 5 Is for object mode :) ( I know I can change them myself )

In #54963#666319, @WilliamReynish wrote:
@zaha: do any other apps use Shift-A to add new items or primitives?

@WilliamReynish I'm not that familiar with the other apps but as Catalin said they usually have a button in the UI to add primitives with 1 click. Since it's a very useful shortcut and does not conflict with anything, why not copy this from blenders default keymap?
Right now you have to click, dig down into a cascading menu and click again, making this rather slow for such a common operation. The same principle as with the mesh editing tools should apply here to keep this on an easy to reach key.

> In #54963#666319, @WilliamReynish wrote: > @zaha: do any other apps use Shift-A to add new items or primitives? @WilliamReynish I'm not that familiar with the other apps but as Catalin said they usually have a button in the UI to add primitives with 1 click. Since it's a very useful shortcut and does not conflict with anything, why not copy this from blenders default keymap? Right now you have to click, dig down into a cascading menu and click again, making this rather slow for such a common operation. The same principle as with the mesh editing tools should apply here to keep this on an easy to reach key.

This bug is still present here with the ICKeymap.
Seems like the Knife Tool works as if the LMB is always pressed.
It creates a point every time you hover over an edge (without clicking).
knife_tool_bug.gif

Do you guys experience the same thing?

PS:
OK, I found a fix.
For Add Cut we need to set the Left Mouse click to "Any".
knife_tool_keymap_fix.png

This bug is still present here with the ICKeymap. Seems like the Knife Tool works as if the LMB is always pressed. It creates a point every time you hover over an edge (without clicking). ![knife_tool_bug.gif](https://archive.blender.org/developer/F6952582/knife_tool_bug.gif) Do you guys experience the same thing? PS: OK, I found a fix. For Add Cut we need to set the Left Mouse click to "Any". ![knife_tool_keymap_fix.png](https://archive.blender.org/developer/F6978749/knife_tool_keymap_fix.png)

Removed subscriber: @Dheim

Removed subscriber: @Dheim

@Oskar3d I’ll look into it.

@Oskar3d I’ll look into it.

I found a fix.
For Add Cut we need to set the Left Mouse click to "Any".
knife_tool_keymap_fix.png

I found a fix. For Add Cut we need to set the Left Mouse click to "Any". ![knife_tool_keymap_fix.png](https://archive.blender.org/developer/F6978749/knife_tool_keymap_fix.png)

@william-70 Reynish (billreynish)
Thank you William this keymap is getting better and better.
Just one thing
I don't know if it's possible, but I think can be a good improvement.

Current behaviour:
1.jpg
My proposal
2.jpg
3.jpg

And I still missing an easy way for edge ring selection.

@william-70 Reynish (billreynish) Thank you William this keymap is getting better and better. Just one thing I don't know if it's possible, but I think can be a good improvement. Current behaviour: ![1.jpg](https://archive.blender.org/developer/F6978992/1.jpg) My proposal ![2.jpg](https://archive.blender.org/developer/F6978998/2.jpg) ![3.jpg](https://archive.blender.org/developer/F6979032/3.jpg) And I still missing an easy way for edge ring selection.

How do various apps let you select edge rings? If there’s a good way that fits and causes no apparent conflicts I am happy to add it.

How do various apps let you select edge rings? If there’s a good way that fits and causes no apparent conflicts I am happy to add it.

I'd say the usual workflow is for you to select one edge and then double click another edge in the direction of the ring. Generally speaking if you double click on the very next edge on the ring it will give you a full ring and if you click on a few edges down in the ring it will give you a partial ring bound by your 2 edges. This last workflow is also the same for loops

I'd say the usual workflow is for you to select one edge and then double click another edge in the direction of the ring. Generally speaking if you double click on the very next edge on the ring it will give you a full ring and if you click on a few edges down in the ring it will give you a partial ring bound by your 2 edges. This last workflow is also the same for loops
Contributor

In case of 3ds Max it's selecting another mesh element next to the one already selected in the direction of the ring while holding Shift. Or Ctrl+R.

Also, as I said already - Alt+LMB is the most obvious solution, but you've closed the door for using it without conflict by ignoring #62154

In case of 3ds Max it's selecting another mesh element next to the one already selected in the direction of the ring while holding Shift. Or Ctrl+R. Also, as I said already - Alt+LMB is the most obvious solution, but you've closed the door for using it without conflict by ignoring #62154

Right now It's good but, it can be better :) .

I know I insist with Modo but that software got very good interaction :) . Anyway just a little bit of changes if it's possible .

The mouse interaction is :
Left Click - selects element by element ( painting selection, something like circle selection )
Middle Click - Lasoo, Box selection through the object ( with this you can select all the faces visible and occluded )
Right Click - It's Lasoo, Box selection normal style ... you can select only the visible faces

I realy think right now blender it's ok, maybe if it's possible ...
Left Click - box select/circle/lasoo
MiddleClick - maybe we can add the select through
Right Click - you can have the context menu that appears with CLICK - Release , and with CLICK -Pressed and drag you can have the moving functionality it's right now :)

Right now It's good but, it can be better :) . I know I insist with Modo but that software got very good interaction :) . Anyway just a little bit of changes if it's possible . The mouse interaction is : Left Click - selects element by element ( painting selection, something like circle selection ) Middle Click - Lasoo, Box selection through the object ( with this you can select all the faces visible and occluded ) Right Click - It's Lasoo, Box selection normal style ... you can select only the visible faces I realy think right now blender it's ok, maybe if it's possible ... Left Click - box select/circle/lasoo MiddleClick - maybe we can add the select through Right Click - you can have the context menu that appears with CLICK - Release , and with CLICK -Pressed and drag you can have the moving functionality it's right now :)

About the edge loops and rings I find Maya way very intuitive.
Everything here is just Shift + Double Left Click:
loop_ring_maya.gif

About the edge loops and rings I find Maya way very intuitive. Everything here is just **Shift + Double Left Click**: ![loop_ring_maya.gif](https://archive.blender.org/developer/F6980412/loop_ring_maya.gif)

Neither the loop or ring select operators in Blender currently work this way, so it’s outaide of the scope of the keymap to do it that way.

Neither the loop or ring select operators in Blender currently work this way, so it’s outaide of the scope of the keymap to do it that way.

Removed subscriber: @Skrapion

Removed subscriber: @Skrapion

Can you add select behind (vertex-edge-face) without using xray ?
I found this really slow my work each time I need to enable xray to select behind. is there away to add an option to select behind ?
any software let you have this option I hope to add this option for blender too.
Untitled 1.jpg

Can you add select behind (vertex-edge-face) without using xray ? I found this really slow my work each time I need to enable xray to select behind. is there away to add an option to select behind ? any software let you have this option I hope to add this option for blender too. ![Untitled 1.jpg](https://archive.blender.org/developer/F6982721/Untitled_1.jpg)

Added subscriber: @AlexPetrov

Added subscriber: @AlexPetrov

This comment was removed by @AlexPetrov

*This comment was removed by @AlexPetrov*

@AlexPetrov wrote:
Can we have separate industry standard navigation (Alt+click movement and basics) and Blender default keymap at the same time? Industry compatible option is currently frustrating for existing Blender users who also use Maya etc - when you were given a familiar alt+click navigation but you're completely lost in new hotkeys... Although I use many apps, I only set Alt-navigation and F for the center in Blender because my muscle memory has already remembered default Blender keymap for years. The only thing which irritates me a lot is that still when you try to orbit with Alt-LMB when the cursor is hovering on any object, you move the object instead of orbiting. So in a dense scene, you can't even orbit. I'm not sure if it happens when Industry compatible is ON, but when you set your own keys it does, and it's frustrating.

That's kinda what I have in my setup. I left as many defaults as I "could". Mostly focusing around Maya Alt-Navigation; and various selections.
If you feel adventurous to try it out, here's the link:
https://blenderartists.org/t/input-custom-blender-setup-alt-maya-navigation-lmb-selections-for-blender-2-80/1136954

>@AlexPetrov wrote: > Can we have separate industry standard navigation (Alt+click movement and basics) and Blender default keymap at the same time? Industry compatible option is currently frustrating for existing Blender users who also use Maya etc - when you were given a familiar alt+click navigation but you're completely lost in new hotkeys... Although I use many apps, I only set Alt-navigation and F for the center in Blender because my muscle memory has already remembered default Blender keymap for years. The only thing which irritates me a lot is that still when you try to orbit with Alt-LMB when the cursor is hovering on any object, you move the object instead of orbiting. So in a dense scene, you can't even orbit. I'm not sure if it happens when Industry compatible is ON, but when you set your own keys it does, and it's frustrating. That's kinda what I have in my setup. I left as many defaults as I "could". Mostly focusing around Maya Alt-Navigation; and various selections. If you feel adventurous to try it out, here's the link: https://blenderartists.org/t/input-custom-blender-setup-alt-maya-navigation-lmb-selections-for-blender-2-80/1136954

I recently wrote about having separate options: Industry compatible keymap and navigation because some people prefer Alt-click navigation but got used to default Blender keymap. But then deleted it because actually the current Industry compatible keymap is not that bad and lots of key bindings make sense. I only added a few for now:

  • F11 - toggle Renderview
  • Home - Jump to the first frame
  • End - jump to the last frame
  • Spacebar - Toggle Maximize Area (like Nuke and Katana)
  • L - play animation forward (Davinci, YouTube)
  • J - play animation backward (Davinci, YouTube)
  • Ctrl+J - join objects
I recently wrote about having separate options: Industry compatible keymap and navigation because some people prefer Alt-click navigation but got used to default Blender keymap. But then deleted it because actually the current Industry compatible keymap is not that bad and lots of key bindings make sense. I only added a few for now: - **F11** - toggle Renderview - **Home** - Jump to the first frame - **End** - jump to the last frame - **Spacebar** - Toggle Maximize Area (like Nuke and Katana) - **L** - play animation forward (Davinci, YouTube) - **J** - play animation backward (Davinci, YouTube) - **Ctrl+J** - join objects

In #54963#666853, @AlexPetrov wrote:
Can we have separate industry standard navigation (Alt+click movement and basics) and Blender default keymap at the same time? Industry compatible option is currently frustrating for existing Blender users who also use Maya etc - when you were given a familiar alt+click navigation but you're completely lost in new hotkeys... Although I use many apps, I only set Alt-navigation and F for the center in Blender because my muscle memory has already remembered default Blender keymap for years. The only thing which irritates me a lot is that still when you try to orbit with Alt-LMB when the cursor is hovering on any object, you move the object instead of orbiting. So in a dense scene, you can't even orbit. I'm not sure if it happens when Industry compatible is ON, but when you set your own keys it does, and it's frustrating.

Same here, all I really care about is Maya-style Navigation and WER for the transform tools. Those are the major pain points. For the rest, I don't care that much as long as it's functional and lends itself to a good user experience.

Right now, the industry standard keymap sacrifices too much on the altar of strictly adhering to the industry apps in my opinion. It's missing functionality and effectiveness that is there in the Blender default keymap. Overall it's too reliant on the mouse which makes it slow. I tried to address this with my feedback, but most of it has been either ignored or rejected with the argument that it's not following other industry standard apps. :(

I will still follow it's development to see how it turns out in th end, but sadly I get more and more inclined to go with a modified Blender default keymap. Might try out @0rAngE's keymap as well but I would've preferrred to stick with an official keymap.

> In #54963#666853, @AlexPetrov wrote: > Can we have separate industry standard navigation (Alt+click movement and basics) and Blender default keymap at the same time? Industry compatible option is currently frustrating for existing Blender users who also use Maya etc - when you were given a familiar alt+click navigation but you're completely lost in new hotkeys... Although I use many apps, I only set Alt-navigation and F for the center in Blender because my muscle memory has already remembered default Blender keymap for years. The only thing which irritates me a lot is that still when you try to orbit with Alt-LMB when the cursor is hovering on any object, you move the object instead of orbiting. So in a dense scene, you can't even orbit. I'm not sure if it happens when Industry compatible is ON, but when you set your own keys it does, and it's frustrating. Same here, all I really care about is Maya-style Navigation and WER for the transform tools. Those are the major pain points. For the rest, I don't care that much as long as it's functional and lends itself to a good user experience. Right now, the industry standard keymap sacrifices too much on the altar of strictly adhering to the industry apps in my opinion. It's missing functionality and effectiveness that is there in the Blender default keymap. Overall it's too reliant on the mouse which makes it slow. I tried to address this with my feedback, but most of it has been either ignored or rejected with the argument that it's not following other industry standard apps. :( I will still follow it's development to see how it turns out in th end, but sadly I get more and more inclined to go with a modified Blender default keymap. Might try out @0rAngE's keymap as well but I would've preferrred to stick with an official keymap.

Added subscriber: @AlanNoble

Added subscriber: @AlanNoble

Honestly, while I applaud the effort, I see this as taking a half measure when you needed to take a whole. Imagine being a Maya user, and opening Blender for the first time. You've heard 2.8 is great, so you fire up the program.

You have two options:

  1. Use the default Blender settings, and have to re-learn everything you've gotten used to from scratch, because Blender insists on being weird and idiosyncratic and doesn't conform to the standards 95% of other programs use

  2. Use the "Industry Standard Keymap", which works great... until you have to google something for help, and you find that all the forum discussions and stackexchange posts and tutorials are based around the default settings. Now you have to go through the additional step of trying to translate what they're saying and work out how to do it with your non-standard keymap.

Eventually, after several days of this, it looks real tempting to just quit and go back to Maya.

I think the best approach is just to bite the bullet and change the default settings, while allowing old users to revert to the Legacy settings if they feel like it.

I think the Blender developers need to start seeing the industry as a whole as its target audience, instead of serving the whims of its current users at the expense of everyone else. I'm glad to see you've already started doing this with the Left-Click Select, Drag box select and the Spacebar key. But I think you need to go one step further and move to the WER/manipulator tool approach and Alt-Click standard.

Honestly, while I applaud the effort, I see this as taking a half measure when you needed to take a whole. Imagine being a Maya user, and opening Blender for the first time. You've heard 2.8 is great, so you fire up the program. You have two options: 1. Use the default Blender settings, and have to re-learn everything you've gotten used to from scratch, because Blender insists on being weird and idiosyncratic and doesn't conform to the standards 95% of other programs use 2. Use the "Industry Standard Keymap", which works great... until you have to google something for help, and you find that all the forum discussions and stackexchange posts and tutorials are based around the default settings. Now you have to go through the additional step of trying to translate what they're saying and work out how to do it with your non-standard keymap. Eventually, after several days of this, it looks real tempting to just quit and go back to Maya. I think the best approach is just to bite the bullet and **change the default settings**, while allowing old users to revert to the Legacy settings if they feel like it. I think the Blender developers need to start seeing the industry as a whole *as its target audience*, instead of serving the whims of its current users at the expense of everyone else. I'm glad to see you've already started doing this with the Left-Click Select, Drag box select and the Spacebar key. But I think you need to go one step further and move to the WER/manipulator tool approach and Alt-Click standard.

In #54963#666832, @KloWorks wrote:
Can you add select behind (vertex-edge-face) without using xray ?
I found this really slow my work each time I need to enable xray to select behind. is there away to add an option to select behind ?
any software let you have this option I hope to add this option for blender too.
Untitled 1.jpg

It would be great to have this, but I guess it isn't part of the keymap.

Currently as a workaround it can be achieved with a custom Macro operator.
When you click and drag instead of starting the box select it first triggers xray mode, then box select and after you release the button it disables the xray mode.
select_through.gif
os_select_through.py
You can load this as an addon and add it in the keymap.
In 3D View -> 3D View (Global) and 3D View -> Object Mode -> 3D View Tool: Move/Rotate/Scale
add this:

os.select_through

as Tweek | Left Mouse | Any multiple times for the different selection functions with Ctrl/Shift/Ctrl+Shift etc and change the settings for the selection Mode.

> In #54963#666832, @KloWorks wrote: > Can you add select behind (vertex-edge-face) without using xray ? > I found this really slow my work each time I need to enable xray to select behind. is there away to add an option to select behind ? > any software let you have this option I hope to add this option for blender too. > ![Untitled 1.jpg](https://archive.blender.org/developer/F6982721/Untitled_1.jpg) It would be great to have this, but I guess it isn't part of the keymap. Currently as a workaround it can be achieved with a custom Macro operator. When you click and drag instead of starting the box select it first triggers xray mode, then box select and after you release the button it disables the xray mode. ![select_through.gif](https://archive.blender.org/developer/F6984421/select_through.gif) [os_select_through.py](https://archive.blender.org/developer/F6984435/os_select_through.py) You can load this as an addon and add it in the keymap. In **3D View -> 3D View (Global)** and **3D View -> Object Mode -> 3D View Tool: Move/Rotate/Scale** add this: ``` os.select_through ``` as **Tweek | Left Mouse | Any** multiple times for the different selection functions with Ctrl/Shift/Ctrl+Shift etc and change the settings for the selection Mode.

Lots of these posts are general Blender feature requests and are outside the scope of the keymap. A keymap can only change the keyboard mappings, and cannot add entirely new features in Blender.

Lots of these posts are general Blender feature requests and are outside the scope of the keymap. A keymap can only change the keyboard mappings, and cannot add entirely new features in Blender.

In #54963#666917, @AlanNoble wrote:
Honestly, while I applaud the effort, I see this as taking a half measure when you needed to take a whole. Imagine being a Maya user, and opening Blender for the first time. You've heard 2.8 is great, so you fire up the program.

You have two options:

  1. Use the default Blender settings, and have to re-learn everything you've gotten used to from scratch, because Blender insists on being weird and idiosyncratic and doesn't conform to the standards 95% of other programs use

  2. Use the "Industry Standard Keymap", which works great... until you have to google something for help, and you find that all the forum discussions and stackexchange posts and tutorials are based around the default settings. Now you have to go through the additional step of trying to translate what they're saying and work out how to do it with your non-standard keymap.

Eventually, after several days of this, it looks real tempting to just quit and go back to Maya.

I think the best approach is just to bite the bullet and change the default settings, while allowing old users to revert to the Legacy settings if they feel like it.

I think the Blender developers need to start seeing the industry as a whole as its target audience, instead of serving the whims of its current users at the expense of everyone else. I'm glad to see you've already started doing this with the Left-Click Select, Drag box select and the Spacebar key. But I think you need to go one step further and move to the WER/manipulator tool approach and Alt-Click standard.

Don't think that such a dramatic change would fare well with a lot of original blender users. This keymap is doing well, if you want maya behavior then just switch to it.
Regarding the translation problem between this and legacy shortcuts I think there should at least be some solid documentation somewhere in blender help about what changes are in this keymap OR a translator addon, anyone?;)

> In #54963#666917, @AlanNoble wrote: > Honestly, while I applaud the effort, I see this as taking a half measure when you needed to take a whole. Imagine being a Maya user, and opening Blender for the first time. You've heard 2.8 is great, so you fire up the program. > > You have two options: > > 1. Use the default Blender settings, and have to re-learn everything you've gotten used to from scratch, because Blender insists on being weird and idiosyncratic and doesn't conform to the standards 95% of other programs use > > 2. Use the "Industry Standard Keymap", which works great... until you have to google something for help, and you find that all the forum discussions and stackexchange posts and tutorials are based around the default settings. Now you have to go through the additional step of trying to translate what they're saying and work out how to do it with your non-standard keymap. > > Eventually, after several days of this, it looks real tempting to just quit and go back to Maya. > > I think the best approach is just to bite the bullet and **change the default settings**, while allowing old users to revert to the Legacy settings if they feel like it. > > I think the Blender developers need to start seeing the industry as a whole *as its target audience*, instead of serving the whims of its current users at the expense of everyone else. I'm glad to see you've already started doing this with the Left-Click Select, Drag box select and the Spacebar key. But I think you need to go one step further and move to the WER/manipulator tool approach and Alt-Click standard. Don't think that such a dramatic change would fare well with a lot of original blender users. This keymap is doing well, if you want maya behavior then just switch to it. Regarding the translation problem between this and legacy shortcuts I think there should at least be some solid documentation somewhere in blender help about what changes are in this keymap OR a **translator addon**, anyone?;)

Scrubbing the timeline doesn't work on top half of area after resizing the timeline (also graph editor, dope sheet and other animation tools). Throws "Error: animation channel (index = 1) not found in mouse_action_keys()" exception.
output.gif
Here you can see me furiously trying to drag in the upper half portion of the timeline to no effect while it works as intended in the bottom. This works fine in blender keymap (right click).

Scrubbing the timeline doesn't work on top half of area after resizing the timeline (also graph editor, dope sheet and other animation tools). Throws "Error: animation channel (index = 1) not found in mouse_action_keys()" exception. ![output.gif](https://archive.blender.org/developer/F6984672/output.gif) Here you can see me furiously trying to drag in the upper half portion of the timeline to no effect while it works as intended in the bottom. This works fine in blender keymap (right click).

@ces That issue is a Blender issue. Will be solved shortly by D4654

@ces That issue is a Blender issue. Will be solved shortly by [D4654](https://archive.blender.org/developer/D4654)

Unwrap doesn't have a shortcut yet.

Unwrap doesn't have a shortcut yet.

This task was getting a bit noisy, so in order to keep developer.blender.org more focused on developers, I have started a thread on devtalk instead:

https://devtalk.blender.org/t/industry-compatible-keymap-questions-suggestions-and-answers/

So, if anyone has any questions, suggestions or comments, please direct them there instead.

Thanks.

This task was getting a bit noisy, so in order to keep developer.blender.org more focused on developers, I have started a thread on devtalk instead: https://devtalk.blender.org/t/industry-compatible-keymap-questions-suggestions-and-answers/ So, if anyone has any questions, suggestions or comments, please direct them there instead. Thanks.

Removed subscriber: @Oskar3d

Removed subscriber: @Oskar3d

Same behaviour "bug?" on three different computer at work.
Desktop 2019.05.18 - 20.58.21.02.mp4

Same behaviour "bug?" on three different computer at work. [Desktop 2019.05.18 - 20.58.21.02.mp4](https://archive.blender.org/developer/F7045890/Desktop_2019.05.18_-_20.58.21.02.mp4)

Added subscriber: @StephenMF

Added subscriber: @StephenMF

In the above chart, it would be nice to be able to see the default Blender keys... Should be easy to add.
Thanks.
Stephen

In the above chart, it would be nice to be able to see the default Blender keys... Should be easy to add. Thanks. Stephen

Removed subscriber: @zaha

Removed subscriber: @zaha

Added subscriber: @opafaf-4

Added subscriber: @opafaf-4

So is the idea that Blender 2.8 will have the "Winner" column for the navigation controls? Because the most recent one I downloaded does not... and it is practically un-useable from someone coming from Maya.. It just slows stuff down so much.

So is the idea that Blender 2.8 will have the "Winner" column for the navigation controls? Because the most recent one I downloaded does not... and it is practically un-useable from someone coming from Maya.. It just slows stuff down so much.

@opafaf-4 this is a separate keymap. Select it in Edit > Preferences > Keymap

@opafaf-4 this is a separate keymap. Select it in Edit > Preferences > Keymap

Added subscriber: @anonym

Added subscriber: @anonym

Added subscriber: @ZhangRichey

Added subscriber: @ZhangRichey

"Loop cut" in Cinema 4D is "Alt+X" (In a newer version, it's change to "M-M").

"Loop cut" in Cinema 4D is "Alt+X" (In a newer version, it's change to "M-M").

Removed subscriber: @nabaxo

Removed subscriber: @nabaxo

Added subscriber: @AndreaMonzini

Added subscriber: @AndreaMonzini

Removed subscriber: @anonym

Removed subscriber: @anonym

Added subscriber: @eiphen

Added subscriber: @eiphen

What about assigning the top left key (grave accent) to subd/poly mode ?
shift + to set as subd (adds a subd modifer) ctrl + to set as poly (disable the last sub modifier)

What about assigning the top left key (grave accent) to subd/poly mode ? shift + ` to set as subd (adds a subd modifer) ctrl + ` to set as poly (disable the last sub modifier)
Contributor

Added subscriber: @KevinCBurke

Added subscriber: @KevinCBurke
Contributor

I would also love to see a keyboard shortcut for Toggle Quad View. If the aim is Industry Compatibility, Maya uses Spacebar, 3DS Max is Alt-W, modo is "0" (zero) on the numeric keypad, Cinema 4D has a button at the top right of every viewport (and the command is assignable to a keyboard shortcut)...these are all one click/button solutions.

Blender in the Industry Compatible Keymap is either going down two levels of drop down menus or searching for it with multiple keystrokes. This is a highly-used function and I believe deserves a key in this keymap.

I would also love to see a keyboard shortcut for Toggle Quad View. If the aim is Industry Compatibility, Maya uses Spacebar, 3DS Max is Alt-W, modo is "0" (zero) on the numeric keypad, Cinema 4D has a button at the top right of every viewport (and the command is assignable to a keyboard shortcut)...these are all one click/button solutions. Blender in the Industry Compatible Keymap is either going down two levels of drop down menus or searching for it with multiple keystrokes. This is a highly-used function and I believe deserves a key in this keymap.

Added subscriber: @Ghostroots

Added subscriber: @Ghostroots

Added subscriber: @meathead

Added subscriber: @meathead

I am struggeling with how to get started with Blender and my biggest hangup right now is the hot keys.. I tried this, industry compatable keymap.. as I would LOVE for blender to work with all of the Maya hotkeys.. but I found a few probelms with it:

  • blender has so many modes, that you end up changing and deleting keyboard shortcuts you might need in another mode
  • the alt_LMB,RMB,MMB nav worked great in objct mode.. but started behaving unpredictably in other modes..

Because blender has so many modes.. and gives you NO clue as to what hot keys you are destroying when you change one on your own.. I am convinced that there is only one solution that is sane.. and that is to have zero global hot keys.. and instead have a hot key list for each mode, or panel.. Totally independent of one another.. So that you would always know, that you were not over writing some essential hot key in another place.. and could control your experience explicitly depending on what mode or tool you were in..

I am struggeling with how to get started with Blender and my biggest hangup right now is the hot keys.. I tried this, industry compatable keymap.. as I would LOVE for blender to work with all of the Maya hotkeys.. but I found a few probelms with it: - blender has so many modes, that you end up changing and deleting keyboard shortcuts you might need in another mode - the alt_LMB,RMB,MMB nav worked great in objct mode.. but started behaving unpredictably in other modes.. Because blender has so many modes.. and gives you NO clue as to what hot keys you are destroying when you change one on your own.. I am convinced that there is only one solution that is sane.. and that is to have zero global hot keys.. and instead have a hot key list for each mode, or panel.. Totally independent of one another.. So that you would always know, that you were not over writing some essential hot key in another place.. and could control your experience explicitly depending on what mode or tool you were in..

Added subscriber: @KepSight

Added subscriber: @KepSight

Added subscriber: @Thaina-Yu

Added subscriber: @Thaina-Yu

In 2D ui such as texture/uv and node graph editor. There is some program use MMB to pan when there is nothing selected. Is it possible to do that in blender too?

I am using graph node and moving selected node with MMB is fine. But when there is nothing selected I wish it would fallback to just view2D.pan

In 2D ui such as texture/uv and node graph editor. There is some program use MMB to pan when there is nothing selected. Is it possible to do that in blender too? I am using graph node and moving selected node with MMB is fine. But when there is nothing selected I wish it would fallback to just view2D.pan
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
110 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#54963
No description provided.