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.
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
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)}
**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.
@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... ?
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... ?
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 ?
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.
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.
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 ... 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 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 ... 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  and moving mouse left and right.
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.
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#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.
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*
@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.
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.
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.
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 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.
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?
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.
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.
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 :)
@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...
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. :)
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.
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.
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:
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:
> 
> 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 Reynish2018-05-07 16:47:26 +02:00
William Reynish
self-assigned this 2018-05-07 16:47:26 +02:00
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
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.
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.
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 |
*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
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
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
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.
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.
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.
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.
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.
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.
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.
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:
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.
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)
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.
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:
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.
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.
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:
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.
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.
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.
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.
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.
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.
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:
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:
The editors pie-menu appears when spacebar is held down.
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:
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).
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.
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:
Right-click hold on an object without needing to enter "Edit Mode" first
Drag in a direction (e.g. up)
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:
Context-sensitivity based on what's under the mouse.
Enabled by right-clicking instead of a hotkey.
Ability to enter edit mode and engage specific edit mode in one go.
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.
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 :)
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)?
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)?
Can I choose a particular mode through the button in 2.79 or 2.80?
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):
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):
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:
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:
Thank you for reading.
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?
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.
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.
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
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:
- 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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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”.
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.
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 ...
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.
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.
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?
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:
Selecting several obects wih LMB box selection
Adding another objects to selection (Shift++LMB), while selection overlaps to some of already selected objects
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:
LMB selection
Adding items to selection by Shift + LMB
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.
D key pressed, mouse over active object will highlight future origin location.
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.
Pressing D+Ctrl allows you to orient origin to any element
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
Aiming origin’s X-axis to the center of pre-selection highlighted polygon, using D+Ctrl+Shift shortcut..
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”.
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..
…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:
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.
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”
Locking transform/temporal origin
This way you can work with origin super fast, without ever loosing it’s position accidentally.
Quick example:
I want these four points translate, so A1 vertex snaps to A2…
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…)
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.
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.
COG button off
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:
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.
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:
Selecting several obects wih LMB box selection
Adding another objects to selection (Shift++LMB), while selection overlaps to some of already selected objects
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:
LMB selection
Adding items to selection by Shift + LMB
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.
D key pressed, mouse over active object will highlight future origin location.
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.
Pressing D+Ctrl allows you to orient origin to any element
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
Aiming origin’s X-axis to the center of pre-selection highlighted polygon, using D+Ctrl+Shift shortcut..
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”.
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..*
…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:
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.
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”
Locking transform/temporal origin
This way you can work with origin super fast, without ever loosing it’s position accidentally.
Quick example:
I want these four points translate, so A1 vertex snaps to A2…
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…)
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.
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.
COG button off
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:
**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.
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.
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
@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#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
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?
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
@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.
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?
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.
@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.
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.
@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
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.
speaking about pressing "D" there isn't function in blender to make "D" active by holding it then deactivate when release the "D" key.
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.).
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.
>
> 
speaking about pressing "D" there isn't function in blender to make "D" active by holding it then deactivate when release the "D" key.
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.
@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.
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.
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:
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
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:
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.
Testing
This keymap is now included with the Blender 2.8 beta.
Added subscribers: @WilliamReynish, @ideasman42
Added subscriber: @Mantasku
{F3275947}
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.
@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... ?
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 ?
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.
Added subscriber: @Ghostil
This will be the standard layout now in 2.8 as in many applications?
Vyacheslav: What do you mean by 'standard layout' ?
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 ...
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 
and moving mouse left and right.
The layout that will default to the blender.
Added subscriber: @DuarteRamos
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.
Alberto: the purpose of this keymap is to comply with ‘industry standards’
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.
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?
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
HhidesAlt+Hunhides,PParents,Alt+Punparents,RRotates,Alt+Rclears 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+LMBshould remove from selection, if border selection as a certain key, thenAltplus 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
@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.
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
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.
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
Sorry, I misinterpreted (may bad English helped for this). Thanks for the clarification.
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.
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?
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 :)
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.
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
@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.
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;
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 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
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
^^ 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.
Added subscriber: @Rawalanche
Removed subscriber: @AlbertoVelazquez
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!
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.
Christian: You are right, the number keys are clearly more of a standard, as this spreadsheet demonstrates. We could use:
Timur: Thanks, yes, more input needed here for the sculpting & painting apps
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.
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:
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
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:
Outliner:
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?;
Thanks guys, I've updated the spreadsheet.
Added subscriber: @aunpyz
As for mudbox shortcut
*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.
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
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
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.
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
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.
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.
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
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.
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.
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
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:
Added subscriber: @ChristopherAnderssarian
Added subscriber: @VukGardasevic
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
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
Double click for loop select definitely.
Added subscriber: @TheRedWaxPolice
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.
Double-click to loop select, and click in empty space to deselect both seem reasonable and standard enough to include here.
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.
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.
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.
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.
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 :)
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.
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.
@WilliamReynish In Maya, the spacebar, aside from toggling the quad view, it also shows a layout of menu items while held down:
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:
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).
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.
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.
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:
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:
Yes, that's is very nice :)
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.
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)?
Can I choose a particular mode through the button in 2.79 or 2.80?
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):
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:
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.
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.
@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)
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
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:
This is just an example, many ways to go about it.
Added subscriber: @Djay
Added subscriber: @JonDoe286
Added subscriber: @blender_noob
This comment was removed by @blender_noob
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
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: @JulienKaspar
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.
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
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.
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.
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)
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"?
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,
Ckey 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?
Removed subscriber: @zebus3dream
Added subscriber: @JeffreyKlug
Added subscriber: @zebus3dream
Removed subscriber: @zebus3dream
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:
I ask/propose the following:
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.
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
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
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
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.
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
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.
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).
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).
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):
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.
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.
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 ...
Added subscriber: @JuanCa
Added subscriber: @A.Lex_3D
Removed subscriber: @A.Lex_3D
Added subscriber: @A.Lex_3D
Added subscriber: @Luis.Burdallo
This comment was removed by @Luis.Burdallo
Added subscriber: @sebastianmroy
Hello I made this proposal in rcs:
https://blender.community/c/rightclickselect/Wbcbbc/#5b9ac2e62155dc1e3e02dc06
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.
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: @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.
Agreed,.... totally.
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?
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:
Selecting several obects wih LMB box selection
Adding another objects to selection (Shift++LMB), while selection overlaps to some of already selected objects
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:
LMB selection
Adding items to selection by Shift + LMB
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.
D key pressed, mouse over active object will highlight future origin location.
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.
Pressing D+Ctrl allows you to orient origin to any element
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
Aiming origin’s X-axis to the center of pre-selection highlighted polygon, using D+Ctrl+Shift shortcut..
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”.
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..
…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:
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.
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”
Locking transform/temporal origin
This way you can work with origin super fast, without ever loosing it’s position accidentally.
Quick example:
I want these four points translate, so A1 vertex snaps to A2…
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…)
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.
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.
COG button off
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:
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.
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
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.
Akey could then be either direct Deselect All, or be kept as the current toggle behavior.Alt+Awould be for deselecting, which would be consistent with many other operators "Alt behavior".@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.
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
Can we please get this because i agree
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.
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.
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.
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.
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
...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?:
Max?
Cinema 4D?
Modo?
Houdini?
Blender?
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.
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?
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.
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
@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.
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: @GatisKurzemnieks
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.
@0rAngE: That's certainly a quite interesting way to handle basic brush settings. I will keep this in mind.
Blender 2.8 Industry Standard Keymapto Compatible Keymap (previously: Industry Standard Keymap)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.
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
Hi Bill
Do you already have some ETA, when we can test it out?
Compatible Keymap (previously: Industry Standard Keymap)to Industry Compatible KeymapAdded 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.
Added subscriber: @Dheim
I could not agree more with all of the ergonomic issues pointed out here.
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.
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
Added subscriber: @pitom
Added subscriber: @stephenwongdesign
Added subscriber: @Midda
speaking about pressing "D" there isn't function in blender to make "D" active by holding it then deactivate when release the "D" key.
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: @TheFaceless
Added subscriber: @zaha
Added subscriber: @De3n
Added subscriber: @cez
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: @KartoonHead
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.
Added subscriber: @Frozen_Death_Knight
Added subscriber: @Pendali
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
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.
Removed subscriber: @hydrogen-2
Added subscriber: @Ferodun