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

Ability to manually control affinity is crucial if one needs to use the PC for other tasks while also waiting for some long render to finish. In some cases, setting CPU priority to low is not enough to free up enough resources, fast enough so that other software does not lag.

In D4022#92939, @Brecht Van Lommel (brecht) wrote:

My main issue is not the pie menu, but this:

Because this means that when you're changing snapping modes for move, you have to be careful to always keep increment active for rotate. It means you have to do 3 clicks each time you want to change snapping mode for move while leaving rotate unchanged, instead of just one click and drag.

In that mockup, it seems you are proposing quite different behavior, not just UI. Rather than disabling vertex snap for rotate / scale, you are making it so you can disable increment snap for move while presumably still keeping vertex snap active for rotate / scale.

Personally I don't think that is easier to understand. And as a mental model to me it seems harder for a user to keep track of having multiple snapping modes active to get the typical desired behavior for the various transform modes. As far as I know, in practice you almost always want increment mode to be available for rotation and scale. And the user having to keep that in mind while changing snapping settings for move seems annoying and slows down the workflow.

Further, it requires users to understand combined snapping modes to understand how to get increment for rotate and something else for move. I don't think that is something many users will discover by themselves, without reading documentation.

Here's a more graphical explanation of what I propose:

In D4022#92932, @Benjamin Sauder (kioku) wrote:

I think youre making it a bigger issue than it is. Yes the tooltip could be improved to mention the increment fallback - but how about making a concrete suggestion what it should say?
In my original tooltip there was somethign about it, maybe it was too lengthy or because of the changes it made no sense anymore - anyways its just a tooltip/wording issue, the usage of this is straight forward.

I am sorry but this really should not be left the way it is now. It's really beyond confusing. Imagine yourself being a new user and seeing this:

In D4022#92881, @Brecht Van Lommel (brecht) wrote:

By default, the snapping settings don't affect rotate/scale at all. Just press Ctrl during rotation to snap to increments there.

Why isn't it possible to have those move/rotate/scale buttons be sub options of "Increment" mode specifically, and define which of the transform tools does increment mode specifically affect?

Because this means that when you're changing snapping modes for move, you have to be careful to always keep increment active for rotate. It means you have to do 3 clicks each time you want to change snapping mode for move while leaving rotate unchanged, instead of just one click and drag. If someone controls snapping modes with a pie menu, that would break as well.

In D4022#92830, @Benjamin Sauder (kioku) wrote:

@Ludvik Koutny (rawalanche)
builder.blender.org already has brechts iteration of this - just give a try?

I do think this works pretty well and is simple and easy to use. happy its solved now.

In D4022#92799, @Brecht Van Lommel (brecht) wrote:

The implementation does not follow this specification:

• When an option is off, then for that transform type it works as if snapping is off and the snapping type is set to increment. That is you press ctrl and it will snap to increments, otherwise it does not snap.

The idea is that if you disable Rotate and Scale, the snapping settings do not affect them at all. Instead you get the basic type of snapping like you do when using e.g. Ctrl when dragging number buttons, which happens to be the same as incrementing mode. But communicating this as "forcing increment mode" is wrong.

In D4022#92776, @Benjamin Sauder (kioku) wrote:

you dont need to activate incremental snap - just use vertex snap and disable affect for rotate&scale. if affect is turn off these modes will always fall back to incremental snapping.

In D4022#92739, @Campbell Barton (campbellbarton) wrote:

Thanks for the update.
Added version patch (so existing files have the flag initialized) and commited rB879c9665985b36c93f21a49663df033a010d2829

In rB6491d50d02b7c93b4955fe05dae62930f3a76ce1#210125, @William Reynish (billreynish) wrote:

Ok, so we have discussed this topic in the UI meeting.

The issue is that there are certain corner cases where it may be useful for the gizmos to be in a different orientation from the modal operators.

Here's how we think we can solve it:

1. We make the change so that using modal operators follow the scene orientation primarily, as this patch did
2. Each tool then gets a dropdown to either use this orientation, or set a different one
   
   That's it.
   
   That makes it so that users can set the scene to use one orientation, but override it for certain tools. By default everything simply uses the scene orientation, and there would be nothing else to worry about in the vast majority of cases.
   
   Here's an image to visualize this:
   
   
   

In D4022#92075, @Brecht Van Lommel (brecht) wrote:

We went over this in the UI meeting today. We found the issue with using Alt is that it interferes with some other shortcuts in transform, and doesn't work with MMB emulation.

Apologies for the changing ideas all the time, but we now agreed on the following:

• At the bottom of the snapping panel, add 3 toggles like this: ` Affects Move | Rotate | Scale `
• This is hidden when only the Increment snapping type is selected, to make clear that it does not affect that case.
• This setting is shared for all snapping types.
• By default, Move is on and Rotate and Scale are off.
• When an option is off, then for that transform type it works as if snapping is off and the snapping type is set to increment. That is you press ctrl and it will snap to increments, otherwise it does not snap.

@Brecht Van Lommel (brecht) @Campbell Barton (campbellbarton)
Any news on this? Is the latest revision feasible?

In D4022#91082, @Brecht Van Lommel (brecht) wrote:

Perhaps it is increment snapping that should be decoupled from the rest of the snapping enum, rather than making a distinction between move/rotate/scale? If we bind increment snapping to its own key it could be available for any transform operator.

I've always found it a bit weird that increment was part of the snapping system. It is mutually exclusive, but still feels like quite a different feature.

If we don't want to break anything it can be done in a conservative way, just adding a new shortcut for increment snapping.

In D4013#90837, @William Reynish (billreynish) wrote:

Ah, I see. Yes, I'm afraid I think this solution is simply too difficult to understand I think. The one in the proposal on rightclickselect gives a clearer, direct visualization of what is enabled for what.

In D4022#90974, @Campbell Barton (campbellbarton) wrote:

Straightforward improvements/fixes are one thing, but adding options needs careful considerations.

I'd rather postpone changes like this until after 2.80 release.

@William Reynish (billreynish) @Brecht Van Lommel (brecht) Hi, is the proper solution for this being worked on? This should not be forgotten.

@Philipp Oeser (lichtwerk) Why was this closed and merged with an old duplicate report which has also been closed. No one will EVER find this yet this is crucial design flaw that should be fixed before 2.8 final release. Right now it's in some ultra-obscure TODO list no one ever looks at :(

In rB6491d50d02b7c93b4955fe05dae62930f3a76ce1#206860, @Brecht Van Lommel (brecht) wrote:

My argument is not against any specific solution to the problem. If we end up agreeing to add extra options, so be it.

I only insist that we first agree on a solution that does not seriously break things, and then we make the change in the Blender code. If it turns out there was a serious problem that we can't agree a solution for in a few hours, we revert the change until we have a solution. Again, this revert is about development process, not design decisions.

In rB6491d50d02b7c93b4955fe05dae62930f3a76ce1#206857, @Brecht Van Lommel (brecht) wrote:

In rB6491d50d02b7c93b4955fe05dae62930f3a76ce1#206849, @Ludvik Koutny (rawalanche) wrote:

It's a shame a step back was taken just because one or two people had extremely exotic workflows.

It's not 1 or 2 people, I've seen about 10 people having problems with the new behavior in the last day. Again, dismissing things this way is not helpful to get to a better solution.

There was solution in place. "Set tool by name" input mapping could have been replaced with Transform.[tool] with "Global" sub option. Saying that's it's a never ending whack-a-mole feels like a double standard, given that you are not reluctant to maintain LMB and RMB keymap at the same time, with very specific toggles for things like spacebar behavior, tab behavior. This one falls into the very same category, yet suddenly it becomes impossible.

It may solve the issue for one animator, and it requires changing the keymap in a way that then only works well for animation. That's not a good solution.

No one is saying it's impossible or that we will not change things further. But for the development process we make sure there are no serious regressions first, and then make the change. Not the other way around, this is basic software development practice.

In rB6491d50d02b7c93b4955fe05dae62930f3a76ce1#206838, @Brecht Van Lommel (brecht) wrote:

As a general principle, we should not break important workflows without no solution in place.

Well... them I am back to having literally hours of my work wasted every month :(

Thanks for the fix.

One more thing. In 2.79 it was possible to actually customize tool defaults in the input editor, and transform orientation was one of them:

In rB6491d50d02b7c93b4955fe05dae62930f3a76ce1#206739, @Campbell Barton (campbellbarton) wrote:

@Julien Kaspar (JulienKaspar), @Hjalti Hjálmarsson (hjalti) .. we had meeting and tried to account for previous feedback.

IIRC an issue previously was global became unpredictable (you needed to remember the current orientation) OTOH,
if you're always using global transform, this is always an extra key press.

Possible solutions:

• Have a way for the transform tool to use it's own orientation (eg, lock icon, you turn off and you can select an alternate orientation which is only used when transforming via the gizmo).
• We could remember the last used orientation state (user/global), so if you transform with global axis once, next time it uses this again. (has the down side that keys behavior depends on previous uses, the advantage that users who always use one or the other don't have so many key presses).
• Have a preference for global to be the first orientation (this feels weak, noting for completeness).
• Revert this change.

I guess I would be fine if the legacy transform tools (G, R, S) did not use this, and only new ones did. I will be using the new transform tools anyway, since with "click anywhere" functionality, they combine best of freeform tools and gizmo tools in one. But I understand that this may cause some code schizophrenia. If hitting X, Y or Z keys or holding down MMB while dragging a gizmo using "click anywhere" would use the new behavior, while using G, R, S keys would always use global, I, personally would be fine with it.

Yep, I am fine with just the one in outliner, and other one being somewhere else :)

I am just adding my vote that I also find Screen and Eye icons in the outliner confusing. I did not yet bring myself to look up and figure how it works. I did not understand it but with a few test clicks, I noticed that the screen icon appears to be a superset of the eye icon, so I just adapted the habit of always using the screen icon, as it does what I need it to do.

In rB6491d50d02b7c93b4955fe05dae62930f3a76ce1#206602, @Campbell Barton (campbellbarton) wrote:

@Ludvik Koutny (rawalanche), MMB now respects the constraint. rB78a6c2e12c8d144d10f759d05cbb3503f555883b

re:

However, is there any reason why GXX in Global mode could not do global first, and local second?

The reason this change was rejected previously is because this is what we were doing. It meant there was no predictable way to use global transform, w/o being aware of the space you were in.

Yes, I guess that makes sense. In that case, I think that "Load UI" should be a persistent user preference, rather than something that resets every time you create a new scene or open blender.

@Campbell Barton (campbellbarton) Also, unfortunately, it doesn't appear to work with Middle Mouse Button drag gesture yet :/ That one still defaults to global space.

Yassss, thank you very much for this!

I'm happy to finally see release confirms added. One more I am sure many would appreciate is if "Load UI" when opening .blend file was off by default. I am sure most people dislike their UI being shuffled around randomly when opening someone else's .blend file.

I've just tested 3ds Max, and it happens exactly as Campbell had described. If cursor is both over a gizmo handle and selectable item, then on click (mouse press and release) without cursor being moved, item is selected. When the mouse cursor is just on a selectable item, without gizmo on top, then the selection already happens on button down, not after the release.