Is exposing another threshold setting really a better solution? It'd promote a worse UX, IMHO. It'd probably be better if both bisect and merge used the same threshold, or (preferably) if bisect didn't even touch verts that aren't on the bisect plane at all (i.e. only merged any stray dupes that happen to be connected to the generated edge).

@ronan ducluzeau (zeauro) It's not that simple in complex scenes, where you have objects close together, because there clicks just go through and you tend to cycle active object or deselect. It's very uncomfortable behavior, though I think this is more towards how selection is handled.

Please specify the concrete version where a problem occurs instead of "newest version". At this time, this issue is already fixed in "newest versions" (2.91.2, 2.92 Beta and master).

2.79 couldn't have picked Local because that required "double-tapping"; MMB always picked Global axes. This changed with 2.80 where the first "tap" locks axes from the chosen orientation instead of Global. But it looks like MMB wasn't fully adjusted to that transition.

I know, I'm just pointing out that "industry standard" is a poor argument. We should reason in practical terms. As in, not "do what others do", but "do the sensible thing" (regardless of whether it's what others do or not).

I don't think "industry standard" has much weight here, it just follows from common sense: dashed - you have holes in the fence - you let in stuff from outside; solid - you don't.

Default cube is 2x2x2. Setting its Z scale to 3 makes its Z dimension 6.

There's a single "loose" edge in your object (not connected to any faces), which is what's causing the crash. This issue was fixed by rBc2a01a6c118ed03fa48aa4f537fe9e5cf711b536 (note that despite the name it doesn't only concern Smart UV Project). The fix should also be included in the upcoming 2.91.1 corrective release.

It's as if it's maximized (ctrl+alt+space maximized, the characteristic icon appears when hovering over top right corner), but at the same time isn't, since header and main bar are visible.

Could be. I mean, it'd look the same either way.

You can clearly see on that screenshot that the round cube is split into eight pieces. Those edges are not connected, thus you get four different insets instead of one.

Which 4 faces? I can't reproduce the problem. Perhaps you could attach a screenshot or a sample .blend file with faces in question already selected?

This is the bug tracker. For usage support request, please use other resources.

@Falk David (filedescriptor) Skin resizing even respects proportional editing, it should support the choice of pivot correctly. Compare the behavior to 2.91, for example.

Actually, transforming isn't the trigger, I think there's just a belated update. Toggling edit mode would also trigger the new "sharp" edges to show.

In D9180#251525, @Harley Acheson (harley) wrote:

The behavior is user-selected, so having the actual drag direction indicated felt silly. I know whether I am dragging left or right and the border did not help in indicating change of behavior.

I think the task description is inaccurate. Current 2.92 isn't broken, 2.91 is. There's been a fix (rBe4e7dfc1d8c0486530e5cabd2e448bf79b2fdb0b) that's slated as a candidate for a corrective release of 2.91. For now simply don't use mixed snapping (i.e. disable Incremental and only use Vertex).

No, it's not. Guys, please keep that kind of discussion to the BA thread, so as participants are only pinged as necessary per the patch.

Clean Vertex Group Weights does not delete vertex groups, that is not its function. It's supposed to unassign vertices from groups when they've weight below limit. And it does just that.

When you import an OBJ the imported object(s) are selected, but none of them is made active. Mode switching works off of active object. So you need to click an imported object to be able to switch to sculpt mode.

@Hans Goudey (HooglyBoogly) Done. I left the one UI image; gizmo shots were outdated and aren't representative of the dynamic anyway.

Probably rB6fda30cc54d2: Fix T83177: Industry Compatible keymap: MMB-dragging to transform engages axis…

You're clicking MMB before releasing shift (easily happens when pressing in quick succession). Meaning that what actually happens is Shift+MMB, and so you exclude Z axis instead of locking it ;)

Something seems to be wrong with the custom split normals layer. Clearing that makes Limited Dissolve operate predictably again.

By the description it would seem that you've disabled "Global Undo" in User Preferences -> System. If you enable it back on, the undo and redo options should work once again.

@Robert Guetzkow (rjg) I'm talking about difference in behavior between MMB and X/Y/Z locking. The manual makes no mention of that, and in fact leaves strong impression that they're supposed to be interchangeable (and I would expect them to be). Pre 2.80 it used to be that MMB only ever locked global axes, so its behavior was limited and understandable. However, as this is no longer the case, that it differs from X/Y/Z locking is questionable, to say the least.

The manual says otherwise. MMB is quite clearly documented as an alternative to X, Y, Z.

Sorry, I did mean connect the two verts with the knife. The workaround for this simplified case is of course to just use the Connect Vertex Path operator, which does work (so I think should the knife as well), but it becomes a speed bump on an actual mesh.

IMHO, this should be quite straightforward UX: user enters local view, user exists local view, and nothing else interferes with that. Otherwise it immediately feels, for the user, like loss of control, which means loss of trust for the tool.

It does work, it just doesn't automatically pick up the current orientation. You can still set it in the redo panel after the fact. The issue is already fixed in 2.92: T82777: Current transform orientation not taken into account when using 'Align to transform orientation' AGAIN

Alternatively, just change the name of the attribute to 'data', that'd also prompt a crash.

Yes, mode switching validates selection, thus enabling exclusive face selection mode while having a lone edge selected deselects that edge. This is why I maintain that such selection shouldn't be created by the op in the first place (i.e. that this behavior is actually a bug in the op). The thing is, the examples are equivalent: in both cases the stray edge is being selected due to flushing from vertices regardless of selection mode. It's just that the second example shows more clearly why this is a problem.

Indeed, relying on undo to make progress is intolerable UX. Not to mention that in a scene with a few thousand objects, undoing a selection is even slower than making a selection :-\

@Luciano Muñoz Sessarego (looch): there are more than two. Snapping - both transform snapping, and Snap To operators - also can use active as pivot or base point, either directly or indirectly. Align to Transform Orientation as well.

@Luciano Muñoz Sessarego (looch) any operation that forces you to lose your current selection is a destructive operation. Selection is work, and may not be trivial to create. In fact, it is only trivial in trivial cases. Losing selection means losing work.

Array sizes, image sizes, frame numbers, sample counts, data indices (materials slots, vertex groups...)...

It's not different, it's the same thing just better illustraded. That edge is getting selected regardless of mode you're in. For face mode, that's not even a correct selection state - you can't achieve such selection through normal means (and should not be able to).

How the type of custom property is determined is described in the manual. I.e. to change it from int to float you simply need to set Property Value in the editor to a float, that is, append a '.0' to the value. While I agree that it'd be much more user-friendly to have a type selector in the editor (especially given the fact that such selector is already there for aggregate values), I don't think the developers would see this as a bug. That is, unless you've found a case where changing an int to a float does not effect a change in type.

I agree that clumping all the UI elements can be problematic: too long to scan to find the required setting. That said, tucking them away under more collapsibles can also be problematic - too many inputs just to get at them. Personally, I think a long-term solution would be to further improve and organize the snapping system, perhaps even as far as making it less rigid (i.e. individual settings for move, rotate, and scale) which would naturally require only being as cluttered as it has to be. That'd be no small task though, would take some planning and experimentation.

Should I open a new one?..

Because the Bump needs that data :)

@michael campbell (3di) that's not the way it works. This isn't about the amount of data (it can be, but not in this case), it's about the size of resultant shader (i.e. code size), and complexity of computation. This is the real downside of visual programming with black boxes (which is what a node-based shader constructor is) - very easy to dramatically increase complexity. It's not at all WYSIWYG. The whole tree that's connected to the Height input of the Bump node is duplicated, twice, under the hood. So if you have one node feeding it, you really have three. If you have 11 like in your example file, you really have 33. Each noise node evaluates noise not once, but per octave (Detail setting), and each evaluation is quite costly. With settings from your example, the four noise nodes would run these expensive computations for a total of 2+7+2+2 = 13 times. Or 39 total taking duplication in mind. All the Add nodes introduce dependencies in the overall shader computation, reducing parallelization in the GPU (depends on hardware and driver). There is only so much code you can feed to the GPU before it can no longer keep up.
You can try this yourself: unplug the bump, group the nodes feeding it, add two more instances, Add them together using a mix node and feed result into base color. You will get a comparable slowdown (and that's before considering that the Bump node itself, which would be skipped entirely in this configuration, has its own overhead). Reduce Detail level on each noise node to 1, and you'll notice significant improvement in performance, even in the bloated graph.

Updated per review.

Updated per review;

@Dalai Felinto (dfelinto) I've attached an example file in the description, so that we're on the same page.

In D9180#244144, @Paul Kotelevets (1D_Inc) wrote:

In D9180#244142, @Stanislav Blinov (radcapricorn) wrote:

Once you add anything direction-dependent to the UI, the ability to flip direction comes in a package, it's not negotiable. There's nothing to "feel" or "think" about there.

It sounds logical, but does not work like that. Can you name a software that have flipping option for a directional selection type? I can't remember such a software.
It may have been done unintentionally, but worked well.

@Paul Kotelevets (1D_Inc) Oh, I do see you mentioning lefties. What I don't see is the "UI Team" bringing forth any actual UI concerns. "We feel", "we think", "perhaps later" etc. That's not UI design, that's handwaving. This should be a non-issue. Once you add anything direction-dependent to the UI, the ability to flip direction comes in a package, it's not negotiable. There's nothing to "feel" or "think" about there.

@Zachman Also... Apart from not knowing how selection currently works, does the "UI Team" consider left-handed people? You know, those that would prefer to use their mouse with their left hand.

In D9180#243993, @Zachman wrote:

We discussed this patch in the UI team meeting today...

• This implies that the default for edge-select should be intersect rather than inner as it currently is.

@Germano Cavalcante (mano-wii), please don't do that. The two clamp options aren't called "Range" and "Implementation-defined". They're called "Range" and "Min Max".

With Continuous Grab, of course. Without it this behavior would be expected :) And no, nothing stands out with --debug-events. I.e. just now I ran a test by using a non-maximized window and simple move. By the time of warp failing, latest entries in the log are those of press and release of the G key.

By the sound of it the issue is the 'Emulate 3-Button Mouse' preference, which, if enabled, prohibits the use of alt+clicking for loop selection, as alt+LMB becomes MMB.

Live unwrap is enabled in your file. Note that there are two settings with this name. One is in the UV editor, which you indeed don't have enabled, another is in the 3D view tool settings (N panel, Tool -> Options), which you do have enabled. The former is for working with pinned vertices in the UV editor, the latter is for re-unwrapping every time you mark a seam.

Do you mean align as in "Object -> Transform -> Align to Transform Orientation"? If so, please try the current master, as this should be fixed now: T82777. (Note that with 2.91 you can still use the operator, just need to manually select the orientation in the redo panel after invoking it).

@Eric Jomphe (Velu) You can do this:

• make an Empty and put it in the desired orientation
• set pivot to Active Element
• select all your asset(s), keeping the Empty active
• enable Only Origins
• do a Object -> Transform -> Align to Transform Orientation, picking 'Local' as the orientation in the options

Further tests: invoking via hotkeys also can fail, and on other mouse-wrapping operators as well.

Perhaps the toolbar is not to blame after all. I've just ran another test: