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.

Hi, any news on approving this? Beta is around the corner and it would be a shame if it was released without this.

Thank you so much for taking care of this! :) If this was indeed based on my feedback on devtalk, could you please next time perhaps at least post the link to the task, so that I actually get to know it's being addressed? Otherwise I remain in the dark not knowing it's being acknowledged and worked on :)

In T57857#556012, @William Reynish (billreynish) wrote:

@Ludvik Koutny (rawalanche): If you read the proposal, this is about exactly that - changing that to make it more sensible so they are not the same. The thing in the viewport would then set the visibility in that viewport, and remove the eye icon in the Outliner which is redundant anyway.

I am a bit confused as to why do we now have two places in close proximity to do the same thing?

In T54943#554769, @William Reynish (billreynish) wrote:

@Ludvik Koutny (rawalanche): I know that, but my point was that we can solve this in a more consistent way that works for both RMB and LMB select modes, if we just make this a toggle for the Move tool, so that you can click and drag on any element to move it without selecting first.

The RMB feature you refer to, you have been using as though it was a tweak tool - what i’m saying is that I’m not sure this feature was ever meant to be that.

In T54943#554605, @William Reynish (billreynish) wrote:

@Ludvik Koutny (rawalanche): Well, that right-click drag feature is a way to engage the translate operator, just like tapping G. I don't particularly mind either way, but I'm not sure this feature was ever intended to work as you suggest? I don't think it ever acted that way, even going back to 2.4x and earlier where we had the left click gestures to engage this.

If you would like to drag and release to move, you could just enable the move tool. I also thought that we could add a 'Tweak' toggle for the Move tool so that you can just click and drag on elements to select and move them with one gesture, so you don't have to first select, then move.

Other apps have this kind of thing, sometimes as a separate tool, and other times as a tool setting.

In T54943#553583, @William Reynish (billreynish) wrote:

@Ludvik Koutny (rawalanche): I'm not sure what you mean. If you use any of the transform tools, you drag and release to translate. The action ends when the user releases the mouse button.

In T57843#554108, @William Reynish (billreynish) wrote:

Hmm, to add further flavour, changing the 3D Cursor to Click makes it so it doesn't move under your mouse cursor. This may be a bit more difficult to fix than I thought.

I want to remind you that in 2.8, "Release confirms" in preferences is still set to be disabled by default, which results in quite default jarring behavior of tools for the new users, especially transform tools such as move, rotate and scale. Every time such an action is performed, the mode stick even upon releasing the mouse button, making it feel like the mouse has malfunctioned, requiring another click to confirm the action.

Yes, if there's not enough horizontal space, then let's just do two rows, but please don't keep it the way it currently is. It's beyond ugly.

Try this:

Is there any ETA on 2.8 tool system properly working with LMB? I'd like to start re-making my custom keymap for 2.8

What Blender truly needs is a proper tool for instancing and scattering objects. This looks just like a random object painter tool. There are already dozen of ways to do this in Blender, but there is not a single way to for example scatter 10 000 high poly trees along with 20 000 000 high poly grass patches. That's why you don't see pretty much any large scale environments ever done in Blender.

I'll spam this here too: https://devtalk.blender.org/t/angular-snap-needs-to-be-decoupled-from-incremental-snap/2161

I second the comment above. For me, local view-specific cursor position is a problem rather than help. Every single time I isolate selection, and then go back to global view, the cursor is in the wrong position. I'd simply completely remove the idea of global/local view specific cursor, and have one cursor position regardless of 3D view mode.

In T54943#541206, @William Reynish (billreynish) wrote:

Ludvik: I don't know what you mean. Release already confirms. If you enable the Move tool and drag, releasing then confirms the movement.

One of the defaults that definitely should be changed for 2.8 is that "Release confirms" in Preferences should be off. Current state has this really weird behavior where if you drag an item, it sticks to your mouse until you click again to drop it. This feels much more like a bug or mouse malfunction rather than a feature.

Unfortunately, there is an annoying usability issue with rotate widget (and rotate mode in general):

Meters and Centimeters is what I am used to. In fact, this is the first time in 27 years of my life that I got to know that "metre" and "centimetre" are actually valid words, and not a typo. I fact, even google doesn't think so, and considers it a typo :D :

One very unfortunate name in 2.8 is "Ornaments" in Overlays pop-over menu. Ornament refers to something very specific: https://www.google.com/search?tbm=isch&source=hp&biw=1920&bih=1058&ei=6jqzW7LsFIWQrgTfjpToAw&q=ornament&oq=ornament&gs_l=img.3..35i39k1j0l9.2998.3656.0.3943.11.11.0.0.0.0.125.732.5j3.8.0....0...1ac.1.64.img..3.8.727.0...0.6uDX_eHTVbA

Yep, I agree that rectangle select is a standard name for it, but in context of all the others listed, "Region" is the most appropriate name.

In T56939#538694, @Bastien Montagne (mont29) wrote:

That does not really sounds like a bug to me, but will let @Brecht Van Lommel (brecht) decide here.

Ah, nevermind then. I assumed that Shot Management addon wouldn't exactly be a 3D view specific one.

In T54582#536259, @Julien Kaspar (JulienKaspar) wrote:

I think it could very well work in an overhauled sidebar but the pinning will still be useful to implement in that one then. Sometimes you would want to have the interface of an addon that is more complex than a tool like Blenrig visible on the side even when going fullscreen but while also having the transform properties visible at the same time. So pinning them makes them both visible without switching tabs constantly in the future sidebar.
it's just a shame of not being able to use the space in the toolbar if available space on the sidebar would run out. The current way is more clean but the things that were removed were able to be more useful where they were.

I support the idea of left toolbar being exclusively dedicated to tools. The mockup by @Julien Kaspar (JulienKaspar) looks like a step back in a scope of cleanup that has been done since 2.8 development started. It would allow the left toolbar to again become "everything bar" of random buttons, which was a big pain in 2.79.

"We could combine Extrude Region, Extrude Individual, Extrude Along Normals into same tool, and simply add a tool setting to switch between the various extrusion methods"

In T56702#535982, @Julien Kaspar (JulienKaspar) wrote:

Another thing I noticed is when assigning Ctrl + RMB to setting the 3D Cursor, then there needs to be a new shortcut for the lasso tool. Actually I'd like the lasso selection to get a simple key like B & C for Box & Circle select. These work fine for them so it can work for Lasso select as well.
But maybe that's not really possible since most are already taken in Edit Mode and reassigning it to a key might require reassigning of other keys as well.
Maybe the shortcut for the 3D Cursor can be Ctrl + Alt + RMB but this likely just involves too many keys.

@Brecht Van Lommel (brecht)
Click anywhere is useful. I actually love how fluidly Blender allows you to work, not having to always travel your mouse cursor all the way to the transform gizmo to start working. Being 8 year 3ds Max user and only 1 year Blender user, not having to travel my mouse to gizmo to do transforms was very relieving. Click anywhere pretty much unifies current freeform transform tools (GRS) and gizmo based tools into one.

In T56702#535655, @Julien Kaspar (JulienKaspar) wrote:

True, I think users that don't have a keyboard or are used to a more industry standard approach are better served.
And as long as all major tools have easy shortcuts to quickly switch between them, it can still work very fluently. I also like the suggestion that when using the operators instead, the related tools light up to show the connection so that the shortcuts and tools are not entirely disconnected in the old way of using Blender.
I also like the idea of the difference of tapping the G key to set the tool as active and holding G to execute it immediately, as described in the Tool Design Task. This can also work nicely.

But I think it's important to tread carefully (And I know you are) when changing essential operators into mandatory tools such as select, 3D cursor and all transform tools since these become on a basic level slower versions of the old operators because of this inherent switching between them which is forced on every user and wasn't there before.
It's not as bad as having pan, zoom & rotate of the view as mandatory tools but a selection tool is very uncomfortably close but as far as I can see at this point, with how everything works, regrettably necessary. Maybe this as perfect of a solution that we can get for LMB select.

I agree with all of these. Very good choices.

In D3206#75836, @Campbell Barton (campbellbarton) wrote:

Unfortunately we won't be accepting new modifiers that instance geometry many times.

This is inefficient and in general we should be using an instancing system for this (duplicators):

Added section in the anti-features page for this:
https://wiki.blender.org/index.php/Dev:Source/Architecture/AntiFeatures#Modifiers_that_Instance_Geometry

Shouldn't this be consulted with William? It seems that the purpose of status bar is lacking a coherent vision. There's now way too much clutter. Re-introducing per-editor status bars is a big step backwards :(

In T55386#510416, @Sergey Barabanov (huggaida) wrote:

• in edit mode press LMB to cycles between v/e/f (for example alt+LMB- cycles backwards). Since people used to Click/doubleclick LMB you will see how it easy to learn clicking once to switch from ver to edge, doubleckick to v->f

In T55386#509928, @justin barrett (justinbarrett) wrote:

In T55386#509748, @DIGVIJAY (DJAY) wrote:

hey, nice work guys. keep it up.

just for the suggestion ;

1. if the Properties editor's tab will be on the right side instead of the left it will be good
   
   and
2. it will be much easier and faster if the clicking is removed means just by hovering the mouse or as zebus (ofuscado) said by mouse wheel to the Properties editor's tabs (Render, Modifier, physics etc) it will open the relative tabs settings.
   
   
   

I agree, for single workspaces this very logical to have the buttons on the right...
A concern for me is dual monitor and mouse over events...I tend to have mine on monitor 1 with it dressed to the right...if I move to my second monitor I may accidentally activate an unwanted property mode....
I still agree with them being on the right though.

Currently, having search on tilde and view menu on hold tilde makes very little sense. Search and viewport switching are extremely different actions. Having them on same key doesn't make much sense.

When I've designed Corona UI, I've found out that just a simple introduction of proper vertical and horizontal UI element alignment can greatly aid readability of multi column layouts. So it's not that multi column layouts are inherently messy and less readable, but that they require a good, grid like alignment to be readable :)

In T54943#508047, @Campbell Barton (campbellbarton) wrote:

In T54943#508025, @William Reynish (billreynish) wrote:

They should, yes. Currently, Blenders has no way to distinguish the various windows, but we are aware of the issue, and it can be solved.

What would be the logic for solving this?

For preferences it's obvious, for two windows each the same size on a different monitor - its not. maybe this should get its own design task.

In T54711#506861, @Okavango (Okavango) wrote:

@William Reynish (billreynish) , @Campbell Barton (campbellbarton)

Guys, you might wanna check this out. This might be the first functional App Template, and with a lot of nice UI concepts for 2.8 to take inspiration from:

https://blenderartists.org/t/blender-pro-improving-blenders-interface-and-usability/1113152

Hi, any news on this bug? It really makes it impossible to use Blender as generator of fluid simulations for use in other apps. This should be high priority, because all the work spent by someone to make Blender support VDB is negated by this unwise file naming. I mean if you are doing sims to be used in Blender, you can just use the default point cache. VDB makes sense mainly because of interoperability with other 3D packages, yet this interoperability is broken for exactly this reason :(

I think that one of the included material preset should be thin, translucent foliage for materials such as tree leaves and grass blades (almost no high poly tree models have leaf meshes with thickness, otherwise it would be ridiculously highpoly model).

In T54963#505360, @KiJeon (0o00o0oo) wrote:

@Ludvik Koutny (rawalanche) It looks like context-sensitive menu is being developed as a whole anyways for 2.8 according to T55162.

In T55162#505355, @Campbell Barton (campbellbarton) wrote:

Regarding using number keys to select submodes.

While it is elegant in some ways to press a key to enter the mode, then the same key again to select a sub-mode,
I think users muscle memory for each individual number key won't be all that accurate, meaning the user will have to be extra careful not to accidentally enter a different mode.
It also means you don't end up with muscle memory for quickly tapping the sub-mode key (since it moves about depending on your mode).

Suggest to use a single, more easily accessible key for sub-mode switching.

In T55162#504999, @William Reynish (billreynish) wrote:

We discussed the number keys and decided to simplify it, so that the number keys simply reflect the main mode selector. This way, the order can be the same and be mirrored both in the mode selector and in the number keys. Other modes also have submodes and we want to make this work in a consistent way.

In T55162#504971, @Manuel Grad (manitwo) wrote:

@Ludvik Koutny (rawalanche) sorry, it wasn't my intention to suggest you're dissmissing exotic keyboard layouts. I just wanted to say that the number of users that would have to change the new proposed default would probably be pretty high. And the thing with defaults is that probably 95% of the people tend to stick with it. So they won't have a button for Object Mode. How many countries are affected by this? How many keyboard layouts are commonly used all over the world that don't have that key on that position? I don't know the answer. Does the Blender Foundation have statistics where the users are coming from?