In T62971#776278, @William Reynish (billreynish) wrote:

In T62971#776266, @Ludvik Koutny (rawalanche) wrote:

In T62971#775904, @William Reynish (billreynish) wrote:

@Ludvik Koutny (rawalanche) you can simply press P to go to the parent folder. This works for the default Blender keymap, just as it always has.

I always switch to ICK when testing 2.81, so I assume that industry standard in that case would be backspace :)

No, on Windows it is Alt-Up and on Mac it is Cmd-Up, for going to the parent folder.
I've enabled Cmd-up now for Mac users, so both will feel at home now.

In T62971#775904, @William Reynish (billreynish) wrote:

@Ludvik Koutny (rawalanche) you can simply press P to go to the parent folder. This works for the default Blender keymap, just as it always has.

I don't wonder that people are requesting double dot to come back when folder up action was mapped on Alt+Up Arrow. That shortcut literally takes two hands to execute, so one has to let go of mouse and use both hands just to go one folder up. If the double dot has to go away, then you need to provide a sane alternative to up one folder, which Alt+Up Arrow is certainly not.

Let's add fixing this: https://devtalk.blender.org/t/workspaces-change-content-of-floating-window/8673 to the list.
Right now, floating windows very limited in usability when used with workspaces, or conversely, workspaces are very limited in usability when used with multiple windows.
The use case of switching workspaces but having something else on the second window on the second monitor needs to be improved.

In D5769#132941, @Juan Gea (juang3d) wrote:

In D5769#132935, @Ludvik Koutny (rawalanche) wrote:

Well, I would not clutter UI with fakes that someone may, or may not use. If you don't want to see the light, then you can simply turn off the Camera ray visibility flag. If you want to see the light but don't want it to occlude other lights, then simply turn of Shadow ray visibility flag. All that's really needed here to cover most of the production scenarios is that every single of these flags works correctly with area lights :)

Or maybe we can just manage the alpha with the alpha defined in the color, by default it would be 1.0 and leave the user decide, this would be useful for "modifying" the actual shape of the emission.
For example we could use a circle gradient in the color to define the actual distribution of a studio light softener

And use the same alpha to define which zones could be more transparent, hence being able to use a rectangle area light with different shapes that could be adapted to any other shape, or this can also help to give variance and defects to the emitting light, for example it could allow to have a "whole" with 0 emission in the center of the area light.
Of course alpha should multiply with the light intensity in those zones, so we get 0 emission where alpha is 0.
Being able to add "masks" to area lights it's a great feature.

In D5769#132929, @Juan Gea (juang3d) wrote:

Well, I agree in that having the light as a opaque object should be the expected behaviour, I imagine that if the problem is that is stacks two lights then one of them should be disabled or at least disable it's emission capabilities, that we we would not have double light, but the alpha should be 1.0 as soon as we make the light visible, at least I cannot imagine any other situation where I could want to have a 0 alpha light.
But if you can imagine some case it's as easy as making it an option, something like "solid light" to enable/disable the alpha of the light, that way any situation would be covered I think.

In D5769#132920, @Lukas Stockner (lukasstockner97) wrote:

The invisible light in front of the background isn't a problem in Cycles - if you check the pixel values of the rendered image, you'll see that the lamp is actually there, but they also have an alpha of zero.
This is consistent with the lamps being transparent - after all, the point of transparent background is that you can composite it over your own background, and since the lamp is transparent, you're supposed to get both the background and the lamp.
The real issue here appears to be in the Image Editor, which does not show the pure-emission pixels correctly. With unpremultiplied alpha (aka correct alpha ;) ), a pixel with zero alpha but nonzero color is perfectly valid.
As for lamps being transparent in the first place - yeah, that's expected as well. After all, if you stack two area lights, the floor will be twice as bright. Therefore, the second light can't be occluding the first one.
Finally: Sorry for not seeing the questions earlier. There's some review comments in the original patch that still apply here, is it fine with you if I fix those?

In T66304#769703, @Campbell Barton (campbellbarton) wrote:

Adding 1D tool gizmo seems fine.
Having all tools accessible by a 1D gizmo by default is quite a big change, if you have to click on a small area of the screen it makes activating tools much less efficient.
Then this means:

• Single mouse click to change a tool.
• Single mouse click on a gizmo to run it.

If some users like this, maybe it's OK but if you need to change the default per tool - I think it's defaulting to a slow workflow without having a convenient way to avoid using it, it could be off by default, or a tool-setting stored per scene.
There are missing details for this task.

• Which tools will this apply to exactly?
  • If you go over each tool there are some where this wont work so well, Rip tool for example will be annoying to use IMHO if it's only accessible via a gizmo.
  • Currently we rely on viewport dragging for spin and shear for example, adding a 1D gizmo wouldn't work on this case, we would need to extend the existing gizmo. It can work, it's just that it involves work not mentioned in this task.
• How would users control options for border select, would these be exposed in the UI?
• Would the keymap for border select also be enabled? (modifier keys for different operations). Or only support single action without modifiers?
• Should the gizmo be locked to the view center if it happens to be outside the view? May be more of an issue if we rely on the gizmo for using the tool. ----

This task states:

It's too much of a hassle to switch between selection and operation

Currently you can box select by pressing the B-Key, it's not a lot of hassle compared to the overhead introduced by tool switching and having to press on a gizmo to access tools.
Although this should be more discoverable.
Further, switching between tools should not be a hassle, we should really provide a quick way to switch tools by default. Not doing this was a mistake in my opinion, now we try to solve this work workaround that only works for a single selection tool.
I would prefer to focus on faster tool switching then overlaying multiple tools on top of each other in a way that makes adding useful shortcuts to one tool, disable the ability to select in another.
Even if this is supported, it is a limited solution since it doesn't help when users want to do different kinds of selection.

When we are already talking about what is a preference vs what is a scene setting, Import/Export settings for various importers and exporters should be preference too. Despite being aware of it not being the case, it gets me every day and causes constant errors. Import and Export format settings are software-wide preferences in any other 3D software, for a very good reason.

In T62971#767561, @Zsolt Stefan (zsoltst) wrote:

In T62971#767554, @William Reynish (billreynish) wrote:

@Ludvik Koutny (rawalanche) absolutely. There's no reason for this. It's a holdover from when Blender used to have confirmation popups for everything.

I'm not sure this is a good idea. Every time you misspell a folder (where you want to navigate to) it would create an empty folder without asking. Or if you mess up something when copying/pasting a path.

In T62971#767559, @Julian Eisel (Severin) wrote:

I removed it last week, rBea94cade2991.

not really sure if it's in the scope of this task but I'd say so since it's complete File Browser UI overhaul. Could we also add finally ditching the New Folder confirmation popup?

In T62971#763574, @Piotr Adamowicz (madminstrel) wrote:

I don't see how that's an argument against the dots. There's nothing wrong with opening the parent directory on doubleclick.
One thing I forgot to mention is that the dots also facilitate good old keyboard navigation.

In T69132#763290, @Paul Kotelevets (1D_Inc) wrote:

In T69132#763179, @Campbell Barton (campbellbarton) wrote:

This is similar to pressing Ctrl-P to parent, from talking to artists in the studio

Do you mean Blender animation studio?
I recently trying to figure out a workflow source in Blender development scheme.
It is needed for workflow protection - a lot of recent solutions do not stand up even to simple repetitive work, because they do not respect the principle of relevance, so huge amount of workflows has been corrupted in 2.8 because of no care.
Like milliseconds in the Olympic Games or Formula 1 races, such details become important only in the process of the hardest of possible workflow conditions.
Blender animation studio is marked as one of the main workflow source with limited workflows range.

In D5577#127996, @William Reynish (billreynish) wrote:

Doesn't look quite as nice, but is more practical probably.
I am not really happy with the double 'Dimensions' text. I like the prev solution,
but maybe this is acceptable even if it doesn't look as nice.

In T69132#762142, @Campbell Barton (campbellbarton) wrote:

In T69132#762132, @Benjamin Sauder (kioku) wrote:

After playing around with it for a bit - I do find it strange that it's not possible to snap the origin onto the object itself. For example if you have a wall module and want to snap the origin to the left bottom corner - you still have to use the 3d cursor, as you just can't snap to it.

Good point, added to the TODO list.

In D5577#127598, @William Reynish (billreynish) wrote:

In these kinds of discussions, you will always find some users advocating to see everything, all the time. If you were to follow that principle, you’d get a hot mess - UI taking more space, more confusion, more information overload.
What is gained by adding Dimensions to the Transform panel, is that you don’t need to open the Sidebar to access this, meaning users have less UI chrome and more space for content.

I guess the confusion here stems from the fact that Blender doesn't allow you to have linked mesh data between object while having object data unique.

I do think that it should have its shortcut

In D5577#127545, @William Reynish (billreynish) wrote:

This is not for the sidebar - this is for object properties, which currently have no way to display the dimensions. You can continue to use the Sidebar, which is unchanged.

I don't think it's a good idea to have an enum toggle between scale and dimensions. It should just mirror the layout in the sidebar. I do agree that the naive way of just adding more controls is never a good thing, but there's an exception in this case, which makes it not naive:

In T69003#761614, @William Reynish (billreynish) wrote:

We could add a toggle for this also in the Tool Settings header, like we do for X Mirror and Auto Merge. It’s not entirely unreasonable. We’d need an icon for it though.
As for the name of Pivot vs Origin: IMO this is off-topic. Obviously this must be consistent throughout Blender, and renaming all uses of Origin to Pivot causes a naming clash with the existing Pivot Point controls, which then also needs a new name. It can be done, but this should be discussed separately elsewhere, ie in the Naming Conventions task.

In T69003#761605, @William Reynish (billreynish) wrote:

We could add a visual indication to show it’s enabled. For example, we could make the origins more prominent.
@Ludvik Koutny (rawalanche) I have no idea what you mean by ‘unique’. The old method involving the 3D cursor was unique. This direct method is what virtually all other DCCs do. So the previous approach was the unique one.
As for other missing features like better snapping or ability to work in more modes, those are just that - missing features in the initial implementation.

In T69003#761606, @Campbell Barton (campbellbarton) wrote:

In T69003#761596, @Ludvik Koutny (rawalanche) wrote:

Very disappointing implementation:

I followed the proposal from @William Reynish (billreynish) which seems reasonable.
We can always extend initial basic functionality.

1. It's very clunky to access (2 clicks)

Only a single click-drag is needed on the pivot, release over the "Origin" checkbox, this is the case for all toggles in popovers.

2. There's absolutely no visual indication that you are in the pivot editing mode, so if you use hotkey to switch it, you have to cycle the state to make sure you are in or out of the pivot editing mode. This is big issue in many areas of Blender. Often you have no idea which state you are in, so you first need to do an error and then correct it by undoing, rather than having an indicator of the current state to prevent erroneous action.

We can see how this goes, by this reasoning we would have to move many options in front of the user which takes screen space.

3. The most important feature, being able to snap the pivot does not work. It can't be snapped to the vertices in object mode for example.

This has been fixed.

4. Affect origins and affect locations options can be used together. What sense does that make?

Although it would be rare, there are times it could be useful.

5. Not working in edit mode.

This was not planned, as with many features it could be supported.

Very disappointing implementation:

1. It's very clunky to access (2 clicks)
2. There's absolutely not visual indication that you are in the pivot editing mode, so if you use hotkey to switch it, you have to cycle the state to make sure you are in or out of the pivot editing mode
3. The most important feature, being able to snap the pivot does not work. It can't be snapped to the vertices in object mode for example.

Yes, +1. Having volumes closed by default is very frustrating. All the more frustrating is the fact that things like these save per scene. Which rollouts are open and closed in the file browser is something that should be stored within user preferences, not within file. It's not something one wants to constantly configure per file.

In T69003#759822, @William Reynish (billreynish) wrote:

@Ludvik Koutny (rawalanche) since this is a general pivot option, you could enable it and switch between the transform tools freely to move the origin aound as you wish.

In T69003#759465, @William Reynish (billreynish) wrote:

@Ludvik Koutny (rawalanche) It doesn't make a lot of sense to introduce an entire mode just to be able to transform the pivot. That mode would not have any tools or features, other than the single ability to transform origins.
As for the name, Blender's lingo for this concept is origin. Some apps call it the pivot point, but in Blender, Pivot Point means something else. It's really not within the scope of this feature or task to discuss the overall naming convention of what we call the origin in general.
For that, see T56648: Blender 2.8: Naming Conventions or you can discuss it separately on Devtalk or Rightclickselect.

Transforming origin (which should finally be named pivot BTW!!!) is quite frequent operation, so the workflow definitely should not be as clumsy as a checkbox inside a popover. I honestly think it should be a mode. There is edit (geometry) mode, which when enabled, moves contents of the object without affecting pivot. There should be "Edit pivot mode" which would do the opposite, and could be jumped in and out of the same way edit mode can.

I also don't like that behavior, and make sure to turn zoom to mouse position off in any app I use, BUT:

Yep. The general idea here is that it would be very sad if there was a "retopo mode" which would have some great tools useful also for regular poly modeling/creation, but users would have to constantly juggle between two different modes to access the good tools from both retopo and edit mode. Retopo modeling tools, if done right, are equally as useful in regular modeling of organic stuff, such as humans, animals, creatures or plants.

The original idea to have separate retopology mode is ultimately a consequence of how messy and overcomplicated current display and snapping settings are. What should be done is mainly a cleanup and redesign of snapping tools so that it's easier and more convenient to switch between them as well as using multiple modes at once. Rather than avoiding excessive complexity by separating whole retopo workflow into new, separate mode, the excessive complexity should be avoided by cleaning up existing tools to make them more universal

Yet another big issue with current file browser is how random and wrong the persistence of save settings is. For example, export settings do not survive file reload, they only stick during the file open session. Render output save settings on the other hand do not even persist during file open session, and are immediately forgotten every single time file browser is closed. This creates a huge space for error.

In T68312#747414, @Jeroen Bakker (jbakker) wrote:

Just for completeness, here is the image that shows the difference when rendering the spheres in cycles and eevee using an HDRI with highlights.

@Vladimir (evilvoland) thanks for your suggestions. When valid we can add options later on, but this needs to be carefully designed.
About the only render option. We are aware of this, but it is not related to shading. There should be a separate design for that.

Can we please, please pretty please finally fix the background blur in lookdev mode with Eevee? That one makes it really frustrating to use and is the reason I avoid using it unless I really need to: https://devtalk.blender.org/t/lookdev-mode-blurry-background-problem/2706

In T62971#744161, @William Reynish (billreynish) wrote:

@Ludvik Koutny (rawalanche) in this branch, we use click to select an double-click to open. This will become the default behavior, so if there are any issues with this, it will have to be solved.

One important issue that should be resolved along with this overhaul us that currently, File Explorer fills the name text field with the folder name if you click on a folder. This issue is not visible in default Blender's keymap configuration, as it opens folders on "Press" action, but when the keymap is changed to more OS standard Double-Click to open folders, the first click fills the name field with the name of the folder. The name field fill should be ignored when clicking folders, and only used when clicking files. Currently, I am unable to make the autofilled name stay in the name field if I want to browse to a different folder.

In T66667#743306, @Sybren A. Stüvel (sybren) wrote:

Please see the discussion at D5228. Currently we see this as a specific corner case that's unlikely to happen (not many people will have an enabled but empty Mesh Cache modifier) and has a workaround (disable the modifier).

In D5241#121708, @Brecht Van Lommel (brecht) wrote:

Switching between using scene lights and neutral lights would be a single click in the Viewport Shading settings, regardless if that's in LookDev or Rendered shading mode. The question here is if switching between those should be the same as switching shading modes (whatever they are called, they can be renamed). And I don't think that's needed here.

In D5241#121696, @Brecht Van Lommel (brecht) wrote:

The issues you mention are unrelated to this, they are to be solved separately. Being able to use Eevee when Cycles is the active render engine is important for texture painting, we are not going to change LookDev to always be Cycles, that's not on the table.

In D5241#121671, @Brecht Van Lommel (brecht) wrote:

I'm not sure this is the best way to arrange these options. I think it's much more clear for users if "LookDev" is always Eevee and "Rendered" is always Cycles. And then "Rendered" can get options to disable the scene lights or use a custom background.
The name "LookDev" is then not really accurate, but still I think it's better to keep that separation between engines more clear, rather than "LookDev" shading mode using a different renderer depending on the settings.
@Julien Kaspar (JulienKaspar) and @Andy Goralczyk (eyecandy), do you have a preference on how this would work?

In T67242#734617, @Brecht Van Lommel (brecht) wrote:

You keep trying to use the bug tracker to report usability issues or potential improvements, if every user did this we wouldn't be able to handle the amount of reports and I will not make special exceptions, please stop doing this.
Developers working on modules can create their own list of todo's and priorities, if a specific report is something they consider a to do is up to them to decide. Nearly all the time these are known limitations, a bug report about them is not new information and closing the report does not throw away anything.

In T67242#734280, @Brecht Van Lommel (brecht) wrote:

This is not a bug, the nodes plugged into the Image Texture node are not taken into account even if this would be good to support.

It's been reported so many times yet it still sits here at low priority :(

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.