- User Since
- Mar 8 2017, 9:24 PM (122 w, 6 d)
Mon, Jul 15
Thu, Jul 11
This is very problematic. Most new users don't even grasp the concept of preferences autosaving being something optional, since in almost all other softwares, preferences are always auto-saved. So many people will think that "Skip auto-save" refers to skipping auto-saving of the .blend files for backup and recovery purposes, and they will most likely proceed to uncheck that checkbox. There's absolutely nothing that implies this UI element is related to preferences, not auto-save feature of autosaving .blend files periodically.
Wed, Jul 10
Tue, Jul 9
Same here. I can confirm that debug code 474 solves the problem. Windows 10 1809 + GTX1080Ti
Mon, Jul 8
Thu, Jul 4
Tue, Jul 2
Low priority? Really? This behavior can have severe, sometimes even devastating effects when unnoticed.
Tue, Jun 25
Thu, Jun 20
Jun 17 2019
Jun 14 2019
Jun 13 2019
Jun 2 2019
This change needs to be combined with the change of default drag distance value. Current default of 10px will be indeed uncomfortable for most people. 3px feels reasonable.
Jun 1 2019
I am unable to reproduce it again. I may have accidentally launched Blender once without having created portable config directory first, so it may have been a mistake on my side. I guess this can be closed, at least until I manage to reproduce it again. Sorry.
May 29 2019
May 28 2019
I am confused as to how detecting modifier key solves this? Modifier key is not always held when selecting an item which can be covered by a gizmo. Sometimes you just want to select a single vertex, which is being occluded by a gizmo. Not *add* it to the selection, just select it. That case would not be covered then since simple selection does not involve any modifier key. What happened to differentiation between click and click-drag? That's how for example 3ds Max solves it, and it works very well.
All that is really needed is to have additional keymap operator that activates a toolbar tool instead of directly activating a tool mode. It is already doable by a mouse click. There is no reason it should not be doable using a hotkey press too.
May 27 2019
May 20 2019
May 10 2019
Laggy (only blender running):
Smooth (OBS just running in the background - not recording):
May 9 2019
Apr 26 2019
In case of 3ds Max it's selecting another mesh element next to the one already selected in the direction of the ring while holding Shift. Or Ctrl+R.
Apr 25 2019
I've just tested latest build and I can confirm it also fixes the T62176
Apr 19 2019
@Jaroslav Brudna (r4p7or_3D) (sorry for offtopic) Hey, if you want the functionality you propose straight away, without waiting, then this may help you: https://blenderartists.org/t/a-proper-keymap-for-blender-2-8/1145406
Apr 17 2019
Yep, another vote for the Tab key for object mode toggle. If quick search is an issue, then that one is equally as much found on Ctrl+Space or F1 keys in other apps. It'd made general sense, as 1-9 keys would be to enter different modes, and Tab key would be to exit any mode, so it's kind of a different type of key.
Ouch... I'd assume that the number keys will always toggle edit submodes of any mode you are in in the same order. At least that's how it works in all the other apps that use number keys to switch edit submodes :)
Also, it doesn't appear to be working in other modes with multiple sub-modes. Such as hair edit mode. Hair edit mode has 3 submodes yet 234 buttons do not switch them but instead switch back to mesh edit mode.
By the way Ctrl+LMB in the industry keymap is still broken. Blender uses some heuristic to select closest element to mouse cursor when selecting. In this keymap, it works for Shift+LMB to Add to selection, but does not work with Ctrl+LMB to remove from selection. Deselecting edges using Ctrl+LMB for example is nearly impossible now, as one needs to click pixel-precisely on the edge. It works in my custom keymap though...
Apr 16 2019
I still don't get it. What's wrong with the idea of using non number key for switching back to object mode? :|
Apr 15 2019
Some issues I have encountered:
- If the map has to be compatible with industry standards, then the zoom method setting in the preferences should be changed from vertical to horizontal. Most of the Maya style navigation users are used to zoom horizontally, as it's much easier to do while holding a mouse:
- 1234 keys currently do not make sense. In almost all other packages, mesh element modes start from 1-vertex, 2-edge, etc... Yet in a typical weird Blender manner, 1 is object mode here, and vertex starts at 2.
- Inset tool doesn't appear to be working at the first sight, because there is no viewport gizmo. It appears as if nothing happened upon pressing I. Same goes for Bevel.
- Ctrl+Left clicking to deselect triggers a menu entry instead for some reason:
- Ring select shortcut missing...?
Apr 11 2019
Apr 10 2019
Apr 9 2019
I think it could be a good idea if there was just one "Select" entry which would respect whatever mode the select tool is set to inside the toolbar. Otherwise switching between select tool modes would then also require user to switch to that different select tool mode in each of the 4 transform tools. That could result in overwhelming micromanagement of selection behavior across every other tool in the toolbar. Or the drag action should be a global setting for all the tools, not remembered per tool.
Apr 8 2019
Apr 7 2019
Apr 6 2019
Apr 5 2019
Honestly, I don't find the JKL playback controls very intuitive. Overwhelming majority of Blender users are on Windows, where they don't have access to Final Cut Pro, so it would make more sense to get the keymap closer to Windows editing tools, such as Adobe Premiere, which is truly an industry standard, or Blackmagic Resolve. Premiere and Resolve are available on both Windows and Mac, while Final Cut is only Mac. That should cover a lot more users.
Apr 3 2019
I agree that numbers for collections is a really weak concept. I think easy solution in this case is to make sure industry keymap is good enough so that most people will use it, and the people using legacy keymap, which will come with collection number hotkeys, will sooner or later switch to the industry one, once everyone else will be using anyway, and the legacy keymap will finally be deprecated.
Apr 2 2019
Mar 30 2019
If you really need a good keymap right now, then you can use this one: https://blenderartists.org/t/a-proper-keymap-for-blender-2-8/1145406
Mar 17 2019
Anyway, this is a bit more complicated problem indeed. Blender has this unique weird concept of datablock being something user can explicitly name. It works in case of Blender:
But it doesn't work in case of Unreal Engine 4:
Mar 16 2019
Mar 10 2019
Mar 6 2019
Mar 5 2019
How's this moving along? :) Given the huge value of this in everyday workflows of pretty much everyone, I think it deserves priority.
Mar 4 2019
@Sebastian Parborg (zeddb) Hi, I'd just like to make sure this bug has not been forgotten. It's been reported back in 2016, last activity on it was almost 3 months ago and it is assigned to a person who's probably not active anymore, yet the status of this bug is still "Needs triage by developer".
Any news on this? It makes procedural texturing very difficult.
Mar 3 2019
Mar 1 2019
I would definitely consider it a bug. I mean, if the geometry is not thin, then it works even without user having to go through the hoops of orienting the topology to cater to the modifier (or destructively applying rotation transform). Here's an example with a box:
X, Y and Z axes respectively, all of them work. Do you see any logical reason why the topology being thin should have any effect on this?