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

Ok, I did some testing of the experimental build:

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

@Ludvik Koutny (rawalanche):
Roughness should be supported in master already, the others aren't though.
This patch does not add any new types, but with it we can easily add them in the future without touching Blender's code or worrying about bitflags (adding roughness took up the last available bit, so now's the time for an overhaul, similar the the RenderPasses a while back).
I also just pushed the updated version to the experimental buildbot, builds should be up soon at https://builder.blender.org/download/experimental/ (check the date, should be Feb 25th).

@Wo!262 (wo262):
The option to bake any number of custom outputs definitely is something I want to look into in the future, that's what the AOV ToDo in the latest update is about. As far as I'm aware, it shouldn't be too hard.
Also, thanks for the Selected to Active reminder, I've implemented the collection approach now.

this is absolutely amazing! Blender's pretty much ideal choice for any degree of content creation for game development, except one pitfall - baking, which you have now decided to tackle. I am eternally grateful.

In T54728#625368, @Braeden (B-Rae) wrote:

(ctrl+) Home and End seem pretty intuitive and logical - just googled the shortcuts for this because I realized the old ones no longer functioned and was getting pretty frustrated editing my timeline animation, appreciate that you guys are already on this. Thanks.

*although one thing: ctrl + home/end requires two hands, seeing as the in/out are marked using cursor location, it is a little clunky having to let go of the mouse to do this - just some food for thought.

I vote for ability to retain all the functionality, just changing what delete does from hard delete to moving to recycle bin. I am not familiar how hard it is to implement on Windows, but if it's not too hard, that would be the way to go. All the other Windows software has either its own file browser or uses the Windows one, but in both cases, deleting is expected to mean moving to recycle bin.

In T61509#619751, @Brecht Van Lommel (brecht) wrote:

We are aware of this issue, it can use an optimization similar to rendering to better work with small tile sizes. But this is outside the scope of the bug tracker.

In D4304#98312, @derek barker (lordodin) wrote:

Ive been testing with denoising the light passes instead of the images and it does a significantly better job keeping the texture data.

Alright, I will wait and see how it works out in practice :)

In T61209#617807, @William Reynish (billreynish) wrote:

@Bastien Montagne (mont29) Ok, in that case I don't mind keeping the Fake User then. We could even probably rename it to 'Resist Purge' , 'Don't Purge' or 'Exclude from Purge'. Something like that.

The term 'Fake User' is also just a confusing name - both the term 'fake' and 'user' don't make any intuitive sense in this context at all.

In T61375#617858, @Sebastian Parborg (zeddb) wrote:

This seems like a feature request... Just kidding ;)

I can reproduce this issue on my end too. It seems like (the final) face normals are indeed not preserved.

In T61412#617664, @William Reynish (billreynish) wrote:

It's not a bug though - but a critical issue. Not sure how to triage.

@Mets 3D (Mets)
That option is very important. You probably don't posses enough experience with offline 3D rendering to be aware of all the use cases. When random seed is on, you will get noise variance between frames.

Keep in mind that this needs to be managed on per-case basis, and some common sense needs to be used. Generally, the way this is handled should be aligned with general expectations of users. Let me show you two examples:

Reset to factory settings did not help, but Brecht is right, it has something to do with aspect ratio of the texture. I have replaced the texture on the first material slot of the mesh with square aspect ratio texture and pack is no longer distorted. That's very odd behavior for three reasons:

In T61239#614684, @Sebastian Parborg (zeddb) wrote:

I'm using the latest commit on the 2.8 git branch. But I don't see any obvious fixes for this problem in the commit log.

Just for the sanity of both of us, here you have a video when I try to reproduce this in 2.8:

output.mkv3 MBDownload

I'm guessing that something might have broken it and then fixed it today? I'll try the commit from the build bot too.

In T61239#614667, @Sebastian Parborg (zeddb) wrote:

This is the result I got when following the instructions in both 2.79 (git) and 2.8 (2.8 to the left and 2.79 to the right):

As you can see the difference is not that much so I thought you were requesting something that had not been in blender before.
You should have made it clear from the bug report that this was the case.

But instead you just said to expect garbage output. And because I got nearly the same in 2.79, you can see how I made my conclusion.

In T61239#614646, @Brecht Van Lommel (brecht) wrote:

This was indeed an unintentional change

@Ludvik Koutny (rawalanche), please be professional and avoid the personal attacks, mistakes happen if you triage dozens of bugs a day.

In T61239#614563, @Sebastian Parborg (zeddb) wrote:

This is not a bug but a feature request.
All features requests go to: https://rightclickselect.com/

In D4304#97605, @Stefan Werner (swerner) wrote:

Here some comparisons at higher sample counts, with hair, SSS, depth of field and motion blur.
11_01_A.lighting.flamenco, 50% resolution, 1024 AA samples.

Could you please also post 256 sample results, or something like that? It will be much better at showing how inferior Cycles denoiser is to OIDN :)

In some cases, it's truly extremely bad. Here's comparison between 2.79 (top) and 2.8 (bottom):

In T61202#613776, @Marco (nacioss) wrote:

Mine get antialiased...

Please try to go in File and select Load Factory Settings, then try again to see if this solved the problem

In D4304#97394, @Sergey Sharybin (sergey) wrote:

I'm not sure whether it's just an experiment or what, but i am not convinced in this.

Even keeping specific implementation aside, the OpenImagheDenoise fails in a simple scenes, and does almost nothing on our production shots.

I also don't think we should be having more denoising algorithm is a great idea. Better to make Cycles' denoiser available in compositor. So then we can always replicate final F12 result when only having multilayer EXR.

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