In T67048#723774, @Philipp Oeser (lichtwerk) wrote:

This is not reproducable with a sharable file?
otherwise: are you on https://blender.chat/channel/blender-coders? (think we can send files one-to-one there...)

In T67048#723751, @Philipp Oeser (lichtwerk) wrote:

Cannot reproduce here.
[Stairs themselves have flipped normals on the side :), but thats another story... existing objects remain untouched afaict...]
[also dont see any recent commits that might have changed this...]

Do you have a .blend for us where this happens?

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.

In T66602#716533, @Brecht Van Lommel (brecht) wrote:

We want to improve the performance here in the future, but it's not considered a bug.

Same here. I can confirm that debug code 474 solves the problem. Windows 10 1809 + GTX1080Ti

In T65387#712411, @Brecht Van Lommel (brecht) wrote:

Lack of customizability in the keymap is not considered a bug, but a feature request.

Low priority? Really? This behavior can have severe, sometimes even devastating effects when unnoticed.

In T61474#706230, @LazyDodo (LazyDodo) wrote:

I currently don't have an nvidia card so can't check, but can you see if switching this option to maximum performance (for just blender, second tab in that screenshot, not global) solves the issue when blender is running alone?

In T65800#703312, @Sebastian Parborg (zeddb) wrote:

This is not a bug but a feature request and should go to: https://blender.community/c/rightclickselect/

In T65417#693608, @William Reynish (billreynish) wrote:

@Ludvik Koutny (rawalanche) The default drag distance *is* already 3px for mouse input, but there's a bug that means it sometimes uses the wrong threshold value, which is why it's currently inconsistent.

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.

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.

In T65266#692852, @Brecht Van Lommel (brecht) wrote:

I can't reproduce this problem. For me it's saving to the portable install folder.
It's not clear to me what could be causing the bug, as the code for auto-saving and pressing the Save Preferences button manually appears to be the same. I guess some state could change right before Blender quits, but I can't see how it would affect portable install detection.

In T63996#690518, @Christophe (StroBlend) wrote:

In T63996#689879, @Ludvik Koutny (rawalanche) wrote:

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.

You mean in case there is already a selection and you want to override it by selecting a vertex behind the gizmo ? Does this happens really often ?
In this case we need to click an empty space or press "a" key to deselect everything then do the new selection. That's not a big deal because most of time you prefer to be sure to have nothing selected before doing a new selection.
Lowering the drag threshold can do the trick but it requires some test because having a sluggish gizmo is very annoying

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.

In T63392#689299, @Campbell Barton (campbellbarton) wrote:

@Ludvik Koutny (rawalanche) if you use cycle it preserves the select state, it just cycles after you press it again.

In T63392#688789, @Campbell Barton (campbellbarton) wrote:

Currently using keymaps you can activate a spesific tool directly, or you can cycle the group of tools (which first activates the group, then cycles).
If we want some additional ways to activate tools they can be added - but it's a feature request.

In T63392#688548, @Campbell Barton (campbellbarton) wrote:

Talked online, this is already supported, enable cycle option in the keymap.

Laggy (only blender running):

In T61474#675150, @Adrian Rutkowski (rrtk) wrote:

the problem is still there even with today's build
I think that saying its related to gizmo is super misleading.
It is way more noticeable when gizmos are present but it's still there without it
I mentioned that before on topic that was merged here, the problem is there only if other software ( even in the background) is not using the video card
Opening anything next to blender instance will give an instant speedup that includes Nvidia Experience Overlay which is enabled on GTX cards by default, so 99% of users will not even notice unless they disable everything.

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.

I've just tested latest build and I can confirm it also fixes the T62176

In rBf41ab375f38b0f828701f846fe33ec1d8ebd320e#226617, @noki paike (amonpaike) wrote:

this generation of videocards now work very well especially on windows, why deprecate them after solving most of the known problems?

@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

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.

In T54963#662064, @William Reynish (billreynish) wrote:

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

In T54963#662061, @William Reynish (billreynish) wrote:

I would rather not use Esc, which is both odd and hard to reach. Will keep as-is because none of the other alternative proposals will work well.
Tab is more useful for other things like operator search.
Using 1 for object mode is used by some other apps, and it’s also the default mode in Blender. Plus, it mirrors the same order you see in the Mode drop down menu. So I’ll keep it this way.

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...

In T54963#661930, @William Reynish (billreynish) wrote:

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

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

In T62154#661793, @Oskar (Oskar) wrote:

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

In T54963#661621, @William Reynish (billreynish) wrote:

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

In T54963#661400, @William Reynish (billreynish) wrote:

In T54963#661145, @Ludvik Koutny (rawalanche) wrote:

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

Doing it that way is harder to support in practice, because of the fact that different object types have a different number of edit mode element submodes.
Also, because object mode is the default mode in Blender, setting it to 1 has the nice advantage is making it easy to go back to it.

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

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

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

This was changed already.

5. Ring select shortcut missing...?

Do you have a suggestion for it?

Some issues I have encountered:

1. If the map has to be compatible with industry standards, then the zoom method setting in the preferences should be changed from vertical to horizontal. Most of the Maya style navigation users are used to zoom horizontally, as it's much easier to do while holding a mouse:

2. 1234 keys currently do not make sense. In almost all other packages, mesh element modes start from 1-vertex, 2-edge, etc... Yet in a typical weird Blender manner, 1 is object mode here, and vertex starts at 2.
3. Inset tool doesn't appear to be working at the first sight, because there is no viewport gizmo. It appears as if nothing happened upon pressing I. Same goes for Bevel.
4. Ctrl+Left clicking to deselect triggers a menu entry instead for some reason:

5. Ring select shortcut missing...?

In T63475#658369, @Julien DUROURE (julien) wrote:

This will be manage on upstream issue tracker:
https://github.com/KhronosGroup/glTF-Blender-IO/issues/419

In T54963#658126, @William Reynish (billreynish) wrote:

@Ludvik Koutny (rawalanche) I don't fully understand the issue. I just tested the Knife tool, and it seems to work fine with Maya-style navigation, unless there is something I am missing.

In T54963#658003, @William Reynish (billreynish) wrote:

The initial implementation of this keymap is now included with Blender 2.8, and will appear in the official builds for testing.

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.

In D2862#67556, @Brecht Van Lommel (brecht) wrote:

I'll revisit this patch when I've done some other changes. Initially I was testing with a GTX 1080 on Linux, but I found out this combination supports compute preemption and doesn't suffer from display freezing anyway. Windows does not support compute preemption and it seems for a responsive display you need to set the timeout quite low there, which makes performance worse than before. That may be useful anyway for viewport rendering, but then probably should also have some UI control or only apply to viewport render.

In T54963#655157, @William Reynish (billreynish) wrote:

@Ludvik Koutny (rawalanche)
JKL is neither a Mac convention nor a Final Cut one. It is used by all the major editing suites.
It could be removed, but it’s not a Mac-only phenomenon.

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.

In T61492#654168, @Brent Lio (remotecrab131) wrote:

In T61492#654016, @Ludvik Koutny (rawalanche) wrote:

I think the easy solution, in this case, is to make sure industry keymap is good enough.

The problem is, the "INDUSTRY STANDARD" keymap never had things for quickly toggle layers. It's a unique Blender feature.
What's the point of making Blender follow the "INDUSTRY STANDARD", while the so-called "INDUSTRY STANDARD" is so far behind blender's innovation on the user interface. You know, the actual "USE" part.
Not to mention, also, as only a small part of the big industry, Blender is not here to change the industry standard. The industry standard is a thing everyone agrees on. Not something you can just change.
Some of these ideas, debates, and changes made to Blender's UI are so counter-intuitive/counter-productive it boggles my mind.
But for the actual topic, yea I think the Move to Collection key should work similarly like 2.7. OR,
what about moving the collection/layer control into a pie menu or something way more efficient than a bunch of keys in terms of efficiency? Such as an infinite scroll menu that corresponds to the number keys when open?
The reason I suggest an infinite scroll menu that responds to number key input only after the menu is open, is that I also don't like filling the 1-9 keys with almost identical functions only with parameter changes.
I was able to create menus in Blender where the operation works differently based on which modifier you held down when clicking the menu items.
So, we could go to this infinite scroll menu, find the collection you want to look at, click it, and show it; Shift-Click it to toggle its visibility; Alt-Click to move selection into this collection; Alt-Ctrl click to take the selection out of its original collection and put into the new collection.
Hell, we could even make this menu persistent after clicking, essentially making it a Collection/layer Manager.
The number 1 keys responds to the first displayed item in the list of collections, and scroll wheel scrolls the list.

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.

In T63212#653411, @Brecht Van Lommel (brecht) wrote:

I don't see how what you explain relates to armature modifiers in edit mode at all. The difficulty is to position and rotate the gizmo along with the armature deform, and to do the inverse when applying the gizmo transform to vertices.

In T63212#653306, @William Reynish (billreynish) wrote:

@Ludvik Koutny (rawalanche) All of that is actually unrelated to this issue, which is that modifiers aren’t taken into account. Changing any of those things won’t solve the problem of modifiers and gizmos.

In T63212#653280, @William Reynish (billreynish) wrote:

@takeshi funahashi (waitinfuture) It isn't really a bug, just more of a current limitation. It would be nice if gizmos would take modifiers into account, but it's probably not completely trivial to support all kinds of modifiers.

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

In T62663#642133, @Bastien Montagne (mont29) wrote:

Well, report was missing two crucial pieces actually:

1. A .blend file to reproduce the issue (given incomplete info I had, I though that it might have been a specific set-up triggering the issue).
2. More important than anything, complete info with detailed steps to reproduce it (since it's not reimporting FBX file into Blender that is the issue, it’s importing it into UE4).

Now am sorry, but if UE4 decides to use the geometry part of FBX data's name as its object name, we cannot do anything about it. Blender's FBX exporter export Model FBX nodes with object name, and Geometry FBX nodes with obdata (mesh) names, as it's expected.

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:

In T62663#641901, @Bastien Montagne (mont29) wrote:

Please follow our submission template and guidelines, also read these tips about bug reports, and make a complete, valid bug report, with required info, precise description of the issue (only ONE issue per report!), precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.
Cannot confirm here, and FBX code certainly uses Object name for the Model node, not its geometry…

In T62039#633680, @Howard Trickey (howardt) wrote:

I fixed this with rB208fafb

In T61209#632775, @Brecht Van Lommel (brecht) wrote:

Priority is fixing bugs and getting 2.80 released with the planned targets.
@Ludvik Koutny (rawalanche): in general, please don't do "thread bumping" on developer.blender.org. If all users start doing this it will be a mess.

How's this moving along? :) Given the huge value of this in everyday workflows of pretty much everyone, I think it deserves priority.

In T47655#632030, @Sebastian Parborg (zeddb) wrote:

@Ludvik Koutny (rawalanche) these bugs are not forgotten. If you want to fix this issue, feel free to do so. Patches are welcome

@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.

In T62080#630448, @Philipp Oeser (lichtwerk) wrote:

Still havent looked at the code, but if geometry is not thin, its verts most likely are non-zero in local Z. (this seems to be the important part, as mentioned above...)
This might be for historical reasons [iirc in 2.79 you couldnt even pick an axis...], but like I said, would need to check code first...

In T57209#630380, @Campbell Barton (campbellbarton) wrote:

Only for 3D view, work is needed for UV editor too.

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:

In T62039#629304, @Brecht Van Lommel (brecht) wrote:

We already have a report of this for bevel, which shares the same code.
Beyond that this bug report is too broad, and more user feedback than a bug report.

In D3203#100122, @Lukas Stockner (lukasstockner97) wrote:

@Ludvik Koutny (rawalanche) Good point about baking multiple objects - to be honest, I'm not really sure why I just removed it in the first place, it was broken in the previous version of the patch but fixing it wasn't hard.
Regarding the arbitrary output - I don"t really like the idea of having baking settings inside a shader node. My idea was to have a separate output node in which you can set a name and connect stuff to it. Then, the workflow would be to add such nodes for everything you want to output and to add a BakePass for each one. The neat part about that is that it works with normal rendering as well - you could add render passes which contain that information from each object whose shader contains the matching node.
Regarding tile size and AO samples - are you sure that these are affected by this patch? This only changes stuff on the Blender side, I don't see how it could impact either of those things...