Fix #128018: BMesh: Single vert selection history for box/circle/lasso #128033

YimingWu · 2024-09-23T14:47:53+02:00

YimingWu commented

2024-09-23 14:47:53 +02:00

In box/circle/lasso selection, newly selected vertices won't be registered
as a BMEditSelection even if there's only 1 vertex selected. This patch
changes the logic into: If there's only one vertex selected additionally
using box/circle/lasso tool, then also record selection history using
BM_select_history_store. This makes it more convenient for people who
would like to use those selection tools to select and isolate one vertex at
a time. If there's more than one vertices selected with those tools, no
new history would be added since the selection order would be arbitrary.

Note: this requires meshobject_foreachScreenVert and similar iteration
helper funcitions to be single threaded (which existing code also relies on)
to work correctly. If selection code needs to be multi-threaded in the
future then atomics can be used.

In box/circle/lasso selection, newly selected vertices won't be registered as a `BMEditSelection` even if there's only 1 vertex selected. This patch changes the logic into: If there's only one vertex selected additionally using box/circle/lasso tool, then also record selection history using `BM_select_history_store`. This makes it more convenient for people who would like to use those selection tools to select and isolate one vertex at a time. If there's more than one vertices selected with those tools, no new history would be added since the selection order would be arbitrary. Note: this requires `meshobject_foreachScreenVert` and similar iteration helper funcitions to be single threaded (which existing code also relies on) to work correctly. If selection code needs to be multi-threaded in the future then atomics can be used.

YimingWu added the

Module

Modeling

label 2024-09-23 14:47:53 +02:00

YimingWu added 1 commit 2024-09-23 14:48:03 +02:00

Fix #128018 : BMesh: Single vert selection history for box/circle/lasso cc45ba3d23

In box/circle/lasso selection, newly selected vertices won't be registered
as a `BMEditSelection` even if there's only 1 vertex selected. This patch
changes the logic into: If there's only one vertex selected additionally
using box/circle/lasso tool, then also record selection history using
`BM_select_history_store`. This makes it more convenient for people who
would like to use those selection tools to select and isolate one vertex at
a time. If there's more than one vertices selected with those tools, no
new history would be added since the selection order would be arbitrary.

Note: this requires `meshobject_foreachScreenVert` and similar iteration
helper funcitions to be single threaded (which existing code also relies on)
to work correctly. If selection code needs to be multi-threaded in the
future then atomics can be used.

YimingWu added this to the Modeling project 2024-09-23 14:48:08 +02:00

Campbell Barton commented

2024-09-24 08:00:35 +02:00

This feature was intentionally not supported and I think it would be better not not to support it because it means using box select sometimes sets elements active. If this were to be followed consistently, it would mean box selecting an object or pose-bone would activate it too, which has other implications regarding selecting objects for parenting or applying active settings to other objects.

This feature was intentionally not supported and I think it would be better not not to support it because it means using box select *sometimes* sets elements active. If this were to be followed consistently, it would mean box selecting an object or pose-bone would activate it too, which has other implications regarding selecting objects for parenting or applying active settings to other objects.

👍 1

Campbell Barton referenced this pull request

2024-09-24 08:02:15 +02:00

Invalid selection order error in edit mode #128018

YimingWu commented

2024-09-24 11:26:44 +02:00

Hummm... consistency-wise indeed it would be best to not support history for box select. Thanks for the explanation :D I guess we can close this PR for now.

YimingWu closed this pull request

2024-09-24 11:26:46 +02:00

Paul Kotelevets commented

2024-10-04 20:03:34 +02:00

First-time contributor

Indeed, there is such kind of a problem in software that set box selection by default - workflow-wise box selection blocks picking actions, delimiting them by threshold, and thresholds is not motorics-friendly mechanics in general.

Which has several consequences - for example, such a mechanics forces users to select single elements with pressholding-driven mIcRoBox selection instead of a proper singleclick picking (could be noticed in 3dsMax, for example) which cause a slowdown and also is critical for a software which is build around an active element paradigm.

Active element paradigm assumes nice picking selections being available most of the time, so the best way to use it is to use Tweak tool and B C and Ctrl+Rmb for Box, Circle and Lasso respectively.

Indeed, there is such kind of a problem in software that set box selection by default - workflow-wise box selection blocks picking actions, delimiting them by threshold, and thresholds is not motorics-friendly mechanics in general. Which has several consequences - for example, such a mechanics forces users to select single elements with pressholding-driven mIcRoBox selection instead of a proper singleclick picking (could be noticed in 3dsMax, for example) which cause a slowdown and also is critical for a software which is build around an active element paradigm. Active element paradigm assumes nice picking selections being available most of the time, so the best way to use it is to use Tweak tool and `B` `C` and `Ctrl+Rmb` for Box, Circle and Lasso respectively.

Campbell Barton commented

2024-10-05 02:05:26 +02:00

Indeed, there is such kind of a problem in software that set box selection by default - workflow-wise box selection blocks picking actions, delimiting them by threshold, and thresholds is not motorics-friendly mechanics in general.

@1D_Inc picking with a single click (even when box selection is enabled) will set active.

> Indeed, there is such kind of a problem in software that set box selection by default - workflow-wise box selection blocks picking actions, delimiting them by threshold, and thresholds is not motorics-friendly mechanics in general. @1D_Inc picking with a single click (even when box selection is enabled) will set active.

Paul Kotelevets commented

2024-10-05 13:50:01 +02:00

First-time contributor

picking with a single click (even when box selection is enabled) will set active.

@ideasman42 this is true, it is technically possible.

However, in practice there is quite a deep difference between "technically possible" and "the most efficient" solution types.

In Box selection tool picking action is delimited with a threshold which forms an input speed barrier which is impossible to break due to incompatibility with human motorics, also such a system forces users to use microbox selections in order to achieve predictable result in any software where it is used. After 10 years of using such a system, the user's work speed is close to the speed of the first day, each time you'll try to speed up trying to produce more actions in given time threshold delimiting system will hit your hands with a ruler of an input mistakes.

Here is a video with short workflow speed comparison of a quality of a picking actions in Tweak and Box tools.
Even on a primitive use case it is easy to detect how much slower, less predictable and less efficient picking actions became being delimited by threshold during using Box tool. On a complex use cases it is predictably even worse. For sure it also influences and massively slows down everything which depends on picking actions - like loops/rings selection, shortest path picking, vertex path connecting and active element picking.

This is why threshold delimited actions belongs to the group of a speed breaking/jamming solutions , alongside with doubleclicks, doubletaps, timing actions, pressholdings (endurance consuming actions), motorics actions, low feedback actions, etc, and it is better to avoid using them in general, especially in the areas where workflow speed (measured by the number of actions per minute) is important.

> picking with a single click (even when box selection is enabled) will set active. @ideasman42 this is true, it is technically possible. However, in practice there is quite a deep difference between "technically possible" and "the most efficient" solution types. In Box selection tool picking action is delimited with a threshold which forms an input speed barrier which is impossible to break due to incompatibility with human motorics, also such a system forces users to use microbox selections in order to achieve predictable result in any software where it is used. After 10 years of using such a system, the user's work speed is close to the speed of the first day, each time you'll try to speed up trying to produce more actions in given time threshold delimiting system will hit your hands with a ruler of an input mistakes. Here is a video with short workflow speed comparison of a quality of a picking actions in Tweak and Box tools. Even on a primitive use case it is easy to detect how much slower, less predictable and less efficient picking actions became being delimited by threshold during using Box tool. On a complex use cases it is predictably even worse. For sure it also influences and massively slows down everything which depends on picking actions - like loops/rings selection, shortest path picking, vertex path connecting and active element picking. This is why threshold delimited actions belongs to the group of a speed breaking/jamming solutions , alongside with doubleclicks, doubletaps, timing actions, pressholdings (endurance consuming actions), motorics actions, low feedback actions, etc, and it is better to avoid using them in general, especially in the areas where workflow speed (measured by the number of actions per minute) is important.

1D_Box picking speed comparison.mp4

2.5 MiB

Paul Kotelevets referenced this pull request

2024-10-05 15:06:42 +02:00

Transform: Simplify Modal Map #128507

Paul Kotelevets commented

2024-10-07 03:11:44 +02:00

First-time contributor

@ideasman42 updated the post.
I am trying to explain how did it happen that despite the fact that picking selections are technically available for Box tool, users fall into using microbox selections for selecting single elements, and trying to resolve issues inherent to using it.
Picking selections are simply not very... usable in that way.

This threshold delimeting box selecting mechanics speedbreaking issue has been known since 90's, we spent several years in order to find a solution to workflow accelerating problem before discovering it in 2009 in Blender.

Upd
(When we learned Blender, we discovered that it was composed in a way that excludes threshold delimiting problem instead of cloning existing solution that contains it, so we thought that person who designed Blender in that way is aware of this issue, so he tried to aviod it on purpose and succeed)

@ideasman42 updated the post. I am trying to explain how did it happen that despite the fact that picking selections are technically available for Box tool, users fall into using microbox selections for selecting single elements, and trying to resolve issues inherent to using it. Picking selections are simply not very... usable in that way. This threshold delimeting box selecting mechanics speedbreaking issue has been known since 90's, we spent several years in order to find a solution to workflow accelerating problem before discovering it in 2009 in Blender. Upd (When we learned Blender, we discovered that it was composed in a way that excludes threshold delimiting problem instead of cloning existing solution that contains it, so we thought that person who designed Blender in that way is aware of this issue, so he tried to aviod it on purpose and succeed)

👀 1

YimingWu commented

2024-10-07 07:30:08 +02:00

I personally won't have problems with keeping selection history for box select on 1 element and to me it's convenient & easier to use for the reasons above...

Paul Kotelevets commented

2024-10-08 00:48:46 +02:00

First-time contributor

Just wanted to mention that this local problem is just a part of a more global well known problem.

YimingWu commented

2024-10-08 05:53:41 +02:00

I'll put the summary of the discussion with @ideasman42 in chat about this problem:

The "accidental box select" may be handled in the event level, could be coupled with a timer to determine whether this is really a drag or click.
Box selection should not be needed to perform single select since single select works well.
If we need visual confirmation before selecting via box/circle/lasso select, it's basically a related topic of this anti-feature "Pre Selection Highlighting" . The selection mechanism in Blender should be determinant enough to not require pre-visual confirmation.

For future discussion of this particular problem, considering posting on right click select or blender artists. Thanks!

I'll put the summary of the discussion with @ideasman42 in chat about this problem: - The "accidental box select" may be handled in the event level, could be coupled with a timer to determine whether this is really a drag or click. - Box selection should not be needed to perform single select since single select works well. - If we need visual confirmation before selecting via box/circle/lasso select, it's basically a related topic of [this anti-feature "Pre Selection Highlighting"](https://web.archive.org/web/20230209120223/https://wiki.blender.org/wiki/Reference/AntiFeatures) . The selection mechanism in Blender should be determinant enough to not require pre-visual confirmation. For future discussion of this particular problem, considering posting on right click select or blender artists. Thanks!

Paul Kotelevets commented

2024-10-08 13:06:54 +02:00

First-time contributor

A "timer"?
Do you mean - to delimit box selection from picking, making it secondary with timing in literally Box selection tool which primary goal is providing comfortable Box selecting? )

Where such a mechanics could be seen being successfully applied?

Also not sure how jamming picking issue could be related to preselection highlighting - even if an element will be highlighted, jamming picking will still not allow to pick it in a predictable way

A "timer"? Do you mean - to delimit box selection from picking, making it secondary with timing in literally Box selection tool which primary goal is providing comfortable Box selecting? ) Where such a mechanics could be seen being successfully applied? Also not sure how jamming picking issue could be related to preselection highlighting - even if an element will be highlighted, jamming picking will still not allow to pick it in a predictable way

Pull request closed

Please reopen this pull request to perform a merge.

Sign in to join this conversation.

No reviewers

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Fix #128018: BMesh: Single vert selection history for box/circle/lasso #128033

Pull request closed