Why is this enabled by default? Why is this not mentioned in release notes?

While the old way may indeed have accidental "benefits", tools really, really should not create invalid selection state. https://docs.blender.org/api/current/bmesh.html#keeping-a-correct-state

That which you show in that example, I believe, is actually a bug. When you bevel the vertices like this, the selection readout at the bottom right will state that 20 edges are selected, where in fact there are (should be) 24. If, after such bevel, you switch to edge mode and back to vertex mode, then all 24 edges will be selected, and the behavior would revert to transforming the whole selection.

This is not a bug. It is a (perhaps slightly unfortunate) consequence of Blender's selection propagation. When you're in Vertex mode, you have a fully contiguous selection: edges between the circles are also selected. Since it is contiguous, there's only one "origin", therefore the selection is transformed as a whole. When you switch from Vertex to Edge mode, that edge selection is preserved, so you again have contiguous selection. It is when you switch to Face mode the selection becomes disjoint, and each selected "island" has its own "individual origin" for transform.

It's not off at all (save for floating point precision). Relative offset measures off of the bounding box. That object without the array has it's Z dimensions at 0.022. 20 times 0.022 is 0.440, plus the dimension again would be 0.462 - that's exactly the dimensions for 2 copies. For five copies like in your file the expected Z dimension for 5 copies is 5*20*0.022 + 0.022, which is 2.222, which is what it is in your file.

Thanks for clarification. So it's not a bug per se? I wonder if that could be made an option for the texture node itself, to allow for selective sacrifices of performance to quality.

Technically that may not even be a bug, though it is rather amusing. The K key activates the Knife modal operator, not the Knife tool, therefore the active tool remains Loop Cut. Since Knife is modal it consumes mouse events, so the active tool's state remains the same. It's a clash of the "new" active tool system and the "old" modal operator system.

@Paul Kotelevets (1D_Inc) basing this off of X-Ray is really not a good option. As I keep repeating, these are different behaviors. X-Ray allows picking of occluded geometry (its one of is goals), but this is not something you want for Select Through. You want picking to only work on unoccluded geometry for Select Through. Furthermore, both modes are not mutually exclusive. You may still want to use (semi-)transparent geometry view to actually pick some faces inside your model. If you were to unify Select Through with X-Ray like you suggest, we'd have to adjust quite a few settings every time a "true" X-Ray view was needed.

Neither is possible. The properties you see and edit are those of the active object.

This is not a bug. When you invert selection, active object isn't changed, which means you're still viewing (and changing) the active object's properties, even though it may be deselected.

In T73479#862641, @William Reynish (billreynish) wrote:

@Campbell Barton (campbellbarton) there is no need for a change in behavior. This is new behavior. Like I mentioned, existing wireframe and x-ray could just stay as they are and ignore/gray out/hide the new setting when they're enabled.

In T73479#862402, @Campbell Barton (campbellbarton) wrote:

In T73479#862148, @Stanislav Blinov (radcapricorn) wrote:

To whomever saying that this is exactly what current x-ray does in Blender: it's not, due to one key difference which is face dots.

While somewhat related, this complicates discussion significantly.

We could change selection behavior regarding face-dots with/without select-through.

For that reason I rather keep this out of the discussion.

To the task at hand:

Please leave the snark out of this, there's no need to trivialize the issue. Keypresses do add up as hours go by. "I don't need it, therefore no one needs it" is not an argument.
Sadly, that "primitive" in Blender right now does not require single box "strike". It requires enabling wireframe and paying close attention to what your box encompasses, and usually having to make additional selections after you're done with wireframe. I thought I expressed that quite clear already. In practice, sometimes it gets to a point where it's faster to select a loop, mark a seam, and then use it as a temporary delimiter for "select linked". For the last time - select through is not for peeking inside an object, it's exactly the way to not have to do that when doing so serves no purpose other than allowing selection tools to select occluded geometry. Therefore Blender's existing wireframe/x-ray views are in no way, shape, or form, a replacement for it. They're a poor alternative.

Like I said before, typical scenario is that select through is normally enabled (meaning, you infrequently disable it when needed). So for my example above, all that would've been needed is to switch to side view and drag a box selection. No switching to vertex mode. No entering wireframe or x-ray. Literally just two actions: view and select. If your workflow is different, you'll keep it normally disabled. That's all there is to it.
Again like I said before, my point is that x-ray and wireframe as they are in Blender are in no way a substitute or a replacement for select through. That said, they can be left as is (while graying out or hiding the "select through" option).

In T73479#862245, @Paul Kotelevets (1D_Inc) wrote:

Ok, a real work sample.
...
But I respect your desire to speed up work with primitives.

Pick shortest path and other precision strategic selections are used way less often than bulk selection. Furthermore, why did you stop there? Four faces further and the problem I'm describing is immediately apparent - the dots get in the way of one another. Furthermore, that particular "shortest path" selection requires quite a few clicks, whereas the same selection can be done by tilting view once and dragging a box.
And then you're suggesting to add even more steps to selection, like switching modes, so select through becomes even more efficient.
Selection is the most performed task while modeling, it needs to be as efficient as it can get. That includes reducing amount of work required for any particular selection. Having to constantly switch to wireframe/x-ray and back, switch modes or hunt for dots increases that amount.

Inset tool itself has no bearing on this issue. All the reproduction is (in edit mode):

• select a different shape key
• perform any edit mode operation
• undo

To whomever saying that this is exactly what current x-ray does in Blender: it's not, due to one key difference which is face dots. Blender's current x-ray and wireframe modes are ill-suited for the problem they're trying to solve. They're supposed to let you see through the geometry and select occluded geometry. What they do instead is replace shading with horrendous face dots that clutter the view and make it difficult to discern the faces. What's worse, bulk selection tools (box, lasso) in these modes require user to be overly precise with selection, having to actually encompass those dots. So while they do let you select occluded geometry, they make it a way more difficult task than it needs to be. One doesn't need to go far to see it:

Perhaps it could be worded differently, I'll edit the title and description.

That thread talks about reordering collections, which is indeed possible. But we've no manual control over how objects are ordered, save for enabling alphabetical sorting. When it's disabled, the order is arbitrary (i.e. however objects end up being ordered by Blender internally).

As far as I can tell, the problems on your last two screenshots aren't due to creasing (well, not exactly); they're due to Auto-Smooth angle. Contrary to what you're describing, creasing values above 0.5 do work; but the more you crease, the more sharp the angle between newly created faces, to a point where it gets picked up by Auto-Smooth and so splits the normals.
Remember that creases are indeed relative, so the more geometry your base mesh has (and/or the more subdivision levels you add), they will affect the object differently.

That's because snapping to cursor, while it does transform selection, is not actually a transform operator, and doesn't respect Transform options :\

Please edit the task description (use Edit Task button on the top right), to fill out all required fields (OS, GPU, Blender Version), and provide the most relevant information: short description, steps to reproduce, screenshots, .blend file.

Objects are either ordered alphabetically (enabled by default) or arbitrarily (typically in order of being added to collection). If you want the latter behavior, you'll need to turn off alphabetical sorting.

Cannot reproduce on Linux with an i7-6700K and a GTX980Ti (both CPU and GPU rendering look the same in object and edit mode).

Fair enough, I've edited as well to make repro even simpler.

Your view clipping is set to very low value for Clip Start and very large value for Clip End. The former is especially significant. In camera view, the Camera's clipping parameters are used (which are set to more sane values). That's why the knife works there but not in regular viewport. This is not a bug. Simply adjust clipping parameters in the 3D viewport (sidebar, View, View, Clip Start/End).

This is not a debate, this is getting to the bottom of whether there's actually an issue. Bugs aren't a matter of personal opinion after all. Now that things are more clear, it would appear that the actual issue, for the time being at least, is lack of documentation.

The Camera is not set as the Scene's active camera, therefore there's nothing for the operator to align. This is not a bug. Go into Scene's properties and set the active camera, then it will work.

Doesn't it? Directly from the docs:

Edges where an angle between the faces is smaller than specified in the Angle button will be smoothed, when shading of these parts of the mesh is set to smooth.

Excuse me? If the mesh is flat-shaded, how come in (5) it becomes smooth-shaded? Please examine the steps carefully: I'm not setting Shade Smooth until step (8). So, by your own logic, (5) should not be happening, i.e. it's incorrect. But if it is correct, then (7) is wrong.

It certainly isn't working as intended, that operator should hide all unselected geometry (i.e. it should do precisely the inverse of Hide Selected). There was a fix for Hide Unselected semi-recently as per T71554, but it seems the core implementation is missing something.

Sides, not slides. I'm not exactly sure what it is that you're having an issue with. Selecting edges by face angles does what it says: selects edges which are on a similar angle between faces. Polygon sides is just that: polygons with the same number of sides, irrespective of angles.

Adding a backtrace from debug build:

I can still reproduce with latest master. On the default cube:

• Add a basis shape key
• Add another shape key and set value to non-zero
• Switch between edit and vertex paint modes a few (or a lot) of times, using the pie menu.

I don't think that that is the case. Re-baking with the whole mesh smooth-shaded without custom normals and sharp edges will still show the issue in Eevee (but not in Cycles), although of course the normals in general would be wrong.
E.g., with Auto-Smooth disabled one can still use the 'ObjectNM' material. Eevee will preview it without banding. But, baking tangent space normals with that material, switching back to the 'TangentNM' material and plugging the new texture instead of the original TS normal map will bring back banding in Eevee (but not Cycles). Even a few seams along triangulation edges would show in Eevee (on the flat sides).

The 'Wine_upload' object hasn't disappeared, it simply has enormous size (8.1km by 2.7km by 2.1km). You'll need to select it in the Outliner and then scale it down in 3D view. This is not a bug. For general Blender usage help please use other resources listed here.

On that screenshot I don't see the file as "clicked", unless the theme setting were changed in your installation. Selected (clicked) files should have a blue selection highlighting. That file looks like it's hovered, but not selected.

By clicking, moving, deleting, etc. you create undo steps, which have to be stored somewhere (i.e. in memory). This is not a bug nor a "memory leak".

That graphics card doesn't meet the minimum requirements (listed here). You can still use older Blender versions with that GPU, and may even be able to use 2.81 if you update the GPU drivers, but generally newer Blender versions unfortunately can no longer support such old cards.

@Jeroen Bakker (jbakker), I can still reproduce with latest master. Video.

I don't know about SculptGL, but one thing is true: if something doesn't work, it doesn't need to exist. Supporting legacy is impractical. It's infectious and counter-productive. If a scrap and rewrite is more sensible than maintenance, do it. Just do it!

@Pasang Bomjan (irex124) Alt, Ctrl+R in 2.80? While indeed it sounds like @Richard Thoulass (divaricatus) enabled the Loop Cut active tool, that key combination wouldn't do that in 2.80. Either it was activated via toolbar, or via the tools menu.

It's not just transform, simple mode switching can also bring unexpected results (see the video linked in the description).

One square, as in one face :) But it shows with your example too. After doing a ctrl+x, look at the stats. You should have one edge and one vert selected (should be impossible when an edge is selected), and switching to vertex mode will only have one corner vert selected.

"Special" case would be the parented one. Trivial case should be indistinguishable from copy-pasting the orientation.

This is a case-insensitive compare. Or that's what the name of this function, and the comment before it, state. That's why I removed the strcmp in the first place.

There's something very wrong with the geometry in that particular mesh. For example, there are edgeless faces (0 and 5). Attempting to cut an edge there manually (between verts 0 and 3) will also result in this freeze. Deleting both faces and trying to fill the hole with alt+f fills with "edgeless" faces again.

Neither 2.79b, nor 2.80 un-subdivide such a triangulated plane. As the documentation says, you may get some results from a non-grid, non-quad geometry, but you can't rely on that.

In T72906#843061, @Todd Gillissie (Gillissie) wrote:

...

5. Pressed Command-T to convert all quads to triangles.

...

Cannot confirm on Linux, Decimate's Un-Subdivide behaves the same between 2.79, 2.80 and 2.81 here.

@Robert Guetzkow (rjg) Is this documented somewhere? I can't find anything on this in the manual, but may be looking in the wrong place. What use is there for current behavior? Confusing UI should have a reason (connected socket with no visible connection).

It would seem that to work correctly, this should be

mat.node_tree.links.new(dot_product.outputs[1], subtract.inputs[0])

(first output is vector, second is scalar, but only one of them is displayed depending on operation).

Looks like a duplicate of T72226.

From the Wireframe modifier documentation:

For the collection the object in question is in, selectability is disabled. But since the object itself is already active, and that state survives de-selection, it can still be put into edit mode. Once selectability for the collection is re-enabled, the object can be selected and deleted. I'm not sure if this is a bug, looks like a corner case with the active vs. selected behavior.

Video demonstration here: https://youtu.be/ePgMHqJyZf4

The Task Manager may not be representative of the situation, nor is simple panning around. Since the Help -> Report a Bug button does paste the NVIDIA GPU info, it stands to reason Blender does use that GPU. A better way to verify this is to use the Help -> Save System Info function and read the resulting text file (look for the OpenGL section).

This is not a bug, you simply have hidden some geometry in edit mode. To reveal it, use the Mesh -> Show/Hide -> Reveal Hidden.

I can confirm this on Linux with a GTX980Ti and a common 1080 resolution. It does seem random though: selection works just fine from the "default" view, but can fail when the object is viewed from other positions/angles.

ATI Radeon HD4000, the one you specified in this report, does not meet the requirements.

Please look at the information on the requirements that I linked to. ATI (AMD) graphics cards supported by 2.81 need to be at least GCN 1st gen. The HD4000 predates that. That series is 12 years old now and doesn't support all the features that modern Blender versions rely on. You may be able to run older versions of Blender with that card, but 2.8x cannot support it.

That graphics card doesn't meet the minimum requirements for 2.81.

You've already reported the same in T72814.

Just for minimizing confusion, video added.

Some feedback after testing this on recent builds (I still think it's a feature that doesn't need to exist, but since it's already here, might as well at least help improve it):