The same key that is used to enter to a mode will be used to choose sub modes (in those modes that have sub modes). William had proposed doing it through the pie menu, but Campbell implemented a floating menu for now. I am not sure what the future plans are, but I do not think that is anything that prevents an optional way to do it through the pie menu.
This is not yet in buildbot builds, these are changes that are being made right now.
Pie menus could be great, you could hold 2 for example, even in another mode, and have the pie menu showing up and get directly in the wanted submode.
Note that changes to the keymap are experimental, we may change them, I have some of my own concerns with this new keymap - best the artists in the studio try them out - we can see how it goes.
Share concerns. Not a fan of 1,2,3,4,5- different modes. These are prime real estate (reachable with left hand) and to use them for operations that you might use 1-2x a day (e.g sculpt or weight/some other paint) is not really optimal.
As with other software (@ Houdini, Max) 1,2,3,4 serves optimally as selection mode (1-object, 2-vertex, 3…). I have it mapped as such and it’s very comfortable, especially as it works universally with everything (curves, lattice, armature(object mode>pose>edit) etc.
Modes should be switchable with pie menu.
Just subjective point of view.
https://twitter.com/BlenderDev/status/1001450063703527426
Ongoing discussions about the future of blender animation
nice picture.
Oh,I see. I do not fully understand what would be the risk of accidentally entering an unwanted mode. Using keyboard shortcuts there are always risks of pressing the wrong key, for example in Edit mode by accidentally pressing “Y” key, and you may not even realize for a long time that you made the mistake. Anyway I am also fine if the decision is to use a single key to change sub modes.
About muscle memory… I do not understand why order of numeric keys do not follow order of how modes appear in drop-down menu. I do not even mean an exact numerical correlation between one and the other, i mean just the order. For example, order in modes menu is Vertext, Weight and Texture Paint. But in numbers keys order is Texture, Vertex, Weight paint. I am not sure if it is intentional for some reason, but for those of us who do not have a very good memory, these little questions help to better remember when relating one thing to another.
The risk is you may intend to press the number button for a mode to open it’s submode menu (press the edit-mode number to select between vert/edge/face) but accidentally enter a different mode by pressing a different number.
Where as fitts law makes keys at the edge of the keyboard - more accessible with muscle memory.
Oh, okay. So this is not a potential risk of accidentally destroy something, but something that can become annoying to slow down the work.
Ok, no problem. I am fine with anything that you and those people who are testing it in the studio decide.
Thanks.
How could any other solution possibly avoid this? If there was a menu of modes, you may misclick, which happens about equally as often. I’ve been using number keys for modes in several different software packages for over 8 years and never had any issues.
Entering and exiting modes, especially jumping between mesh edit mode and object mode is very frequent action. It definitely deserves a key that’s close to hand’s resting position without any modifier key combination.
@rawalanche, If I am understanding all this well, what is being discussed is the method of selecting sub modes, not modes.
Personally I have 1-4 mapped as such(depending on object type selected):
1 - object mode (always! @ risk). Handy as it exits whatever unintended mode.
2 - for mesh(vertex), for curve or lattice(edit mode), armature (pose mode)
3 - for mesh(edge), for curve or lattice(edit mode), armature (edit mode)
4 - for mesh (face)
It’s identical to max, houdini (in select mode) so a lot of users might find it comfortable.
Tab or `(Accent grave?) above it can be used to summon Pie menu for mode selection:
This makes absolutely no sense to me when we already have a place where this stuff should be. The Properties panel. That needs to be fixed not have more stuff tacked on to the 3D view imo. The properties panel should be persistent. It should be context sensitive so that only information for selected objects are present. Render properties, dynamic properties, shouldn’t;t be there period. The dynamics and particle pane should only show up when a modifier gets added to an object explicitly saying you need dynamics on the object. Render properties should move to the Render menu.
The consistency of Maya, Houdini’s and XSI’s properties panel is imo a good way to handle these things rather than adding more panels because the current properties panel in blender is a hot mess.
Maybe it’s now possible to fix the problem that animated properties of custom nodes (PyNodes) do not show up in the graph editor and dope sheet?
https://github.com/LuxCoreRender/BlendLuxCore/issues/167
https://github.com/JacquesLucke/animation_nodes/issues/359
https://github.com/JacquesLucke/animation_nodes/issues/820
Hey ouraf, this has been solved (as far as I know) a little while ago - Campbell made the undo stack unique, so that you cannot lose changes by switching to a mode and back anymore.
@apoclypse : while I agree that properties could be made more clean (they’re working on this I believe) and more adaptive/intelligent, it’s quite a different story than Maya or Houdini - in both those packages the “properties panel” is really the selected node’s properties, since over there everything is a node, so it’s going to be naturally more consistent.
Regarding my own usage, I like having render settings displayed somewhere persistently, for tweaking sampling and other stuff for test/final renders. On the other hand I agree the dynamics tab could stay hidden unless there’s a simulation modifier on the selected object.
Whe need these in Eevee!
Yeah, not really very happy about vert/edge/face menu being still a menu. These 3 are switched so often during modeling that anything longer than a single button press is just too slow. I think defaults should be done well, as we want to encourage also beginners to be efficient with the software.
But from selfish point of view, as long as we can customize keymap the same way we can in 2.7, we can always fix it ourselves 
Yes, I’ll redo my pie menus to have something better with the new tools.
