Blender 2.8 selection inconsistent between mouse and pen. #56278

New Issue

Jean Da Costa · 2018-08-08T19:42:22+02:00

Jean Da Costa commented

2018-08-08 19:42:22 +02:00

System Information
AMD A4
Radeon hd 8370D

Blender Version
0f449541d2

Short description of error
Selection of overlapped objects will fail if the cursor has been moved.

Exact steps for others to reproduce the error
In a a row of objects, position the view is such a way that them got occluded, then try to select the object underneath.
It should select the next occluded object at each click and cycling back, and that happens unless you don't click at the exact same pixel all time.

But there's a problem :
We all know that's impossible to not move the pen while clicking with it so, it will require cirurgical precision to select with the graphic pen, and it's not the point if a graphic pen.

2018-08-08 14-27-17.mp4

**System Information** AMD A4 Radeon hd 8370D **Blender Version** 0f449541d2e **Short description of error** Selection of overlapped objects will fail if the cursor has been moved. **Exact steps for others to reproduce the error** In a a row of objects, position the view is such a way that them got occluded, then try to select the object underneath. It should select the next occluded object at each click and cycling back, and that happens unless you don't click at the exact same pixel all time. **But there's a problem** : We all know that's impossible to not move the pen while clicking with it so, it will require cirurgical precision to select with the graphic pen, and it's not the point if a graphic pen. [2018-08-08 14-27-17.mp4](https://archive.blender.org/developer/F4160501/2018-08-08_14-27-17.mp4)

Jean Da Costa commented

2018-08-08 19:42:22 +02:00

Added subscriber: @jeacom

Bastien Montagne commented

2018-08-09 11:00:06 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2018-08-09 11:00:06 +02:00

Changed status from 'Open' to: 'Archived'

Bastien Montagne closed this issue

2018-08-09 11:00:06 +02:00

Bastien Montagne self-assigned this 2018-08-09 11:00:06 +02:00

Bastien Montagne commented

2018-08-09 11:00:06 +02:00

Thanks for the report, but that is not a bug, that’s a limitation related to a specific input device… Also, I’m assuming you are aware of the ALT-RCLICK that pops up a menu to select any object below the click?

Thanks for the report, but that is not a bug, that’s a limitation related to a specific input device… Also, I’m assuming you are aware of the `ALT-RCLICK` that pops up a menu to select any object below the click?

Jean Da Costa commented

2018-08-09 19:47:07 +02:00

I an aware of the alt click and also aware that this is a downgrade compared to 2.7 and shoud be fixed since before it worked fine.

Alt+click has a negative side: when you have lots of objects and dont have time to name everything the alt+click menu just become a messy list that is even harder to use.

I an aware of the alt click and also aware that this is a downgrade compared to 2.7 and shoud be fixed since before it worked fine. Alt+click has a negative side: when you have lots of objects and dont have time to name everything the alt+click menu just become a messy list that is even harder to use.

Jean Da Costa commented

2019-01-20 12:35:27 +01:00

Changed status from 'Archived' to: 'Open'

Jean Da Costa reopened this issue

2019-01-20 12:35:27 +01:00

Jean Da Costa commented

2019-01-20 12:35:27 +01:00

As you might see on this post on devtalk, it's actually an undesirable behavior,
We need selection to behave consistently either by moving the mouse between clicks or not.
https://devtalk.blender.org/t/2-8-wireframes-selection-difficult/4927

As you might see on this post on devtalk, it's actually an undesirable behavior, We need selection to behave consistently either by moving the mouse between clicks or not. https://devtalk.blender.org/t/2-8-wireframes-selection-difficult/4927

Bastien Montagne removed their assignment 2019-01-20 14:17:41 +01:00

Bastien Montagne commented

2019-01-20 14:17:41 +01:00

Removed subscriber: @mont29

Philipp Oeser commented

2019-03-19 13:33:49 +01:00

Added subscribers: @ideasman42, @lichtwerk

Campbell Barton was assigned by Philipp Oeser

2019-03-19 13:33:49 +01:00

Philipp Oeser commented

2019-03-19 13:33:49 +01:00

Not sure if this would be considered a bug.

Can confirm this feels more sensitive than 2.79 though.
seems to be defined in mixed_bones_object_selectbuffer_extended()

if (len_manhattan_v2v2_int(mval, last_mval) < 3) {
	do_nearest = false;
}

If I increase the value from 3 to lets say 20 or so, I can comfortably select with my pen.

@ideasman42: should this be increased a bit? (made a preference?)

Not sure if this would be considered a bug. Can confirm this feels more sensitive than 2.79 though. seems to be defined in `mixed_bones_object_selectbuffer_extended()` ``` if (len_manhattan_v2v2_int(mval, last_mval) < 3) { do_nearest = false; } ``` If I increase the value from 3 to lets say 20 or so, I can comfortably select with my pen. @ideasman42: should this be increased a bit? (made a preference?)

Campbell Barton commented

2019-03-19 17:21:36 +01:00

@lichtwerk the purpose of this check is to cycle though items under the cursor when you're not moving it.

This should be a very small value - otherwise the users might move the cursor slightly to select a different item - instead of selecting what is now under the cursor - it will select the next item from all items near the cursor.

Would rather avoid a preference - although we could have one which is the distance allowed before the cursor is considered to have moved. (different from drag distance).

Committed 5739506104 adding WM_EVENT_CURSOR_MOTION_THRESHOLD which is now scaled by the DPI, if it's still needed the preference can be added there too.

@lichtwerk the purpose of this check is to cycle though items under the cursor when you're not moving it. This should be a very small value - otherwise the users might move the cursor slightly to select a different item - instead of selecting what is now under the cursor - it will select the *next* item from all items near the cursor. ---- Would rather avoid a preference - although we could have one which is the distance allowed before the cursor is considered to have moved. (different from drag distance). Committed 5739506104 adding `WM_EVENT_CURSOR_MOTION_THRESHOLD` which is now scaled by the DPI, if it's still needed the preference can be added there too.

Jean Da Costa commented

2019-03-19 18:06:30 +01:00

In #56278#644235, @ideasman42 wrote:
@lichtwerk the purpose of this check is to cycle though items under the cursor when you're not moving it.

This should be a very small value - otherwise the users might move the cursor slightly to select a different item - instead of selecting what is now under the cursor - it will select the next item from all items near the cursor.

Would rather avoid a preference - although we could have one which is the distance allowed before the cursor is considered to have moved. (different from drag distance).

Committed 5739506104 adding WM_EVENT_CURSOR_MOTION_THRESHOLD which is now scaled by the DPI, if it's still needed the preference can be added there too.

@ideasman42 notice that tablet pens can't hold the cursor still because electromagnetic noise plus the fact that holding a pen still in midair always hard, the muscles always twitch a bit, this effect is so evident that you can easily tell if someone is using a mouse or a pen in a recorded video. Because of that, I would set this threshold to at least 5 or 6 pixels.

> In #56278#644235, @ideasman42 wrote: > @lichtwerk the purpose of this check is to cycle though items under the cursor when you're not moving it. > > This should be a very small value - otherwise the users might move the cursor slightly to select a different item - instead of selecting what is now under the cursor - it will select the *next* item from all items near the cursor. > > ---- > > Would rather avoid a preference - although we could have one which is the distance allowed before the cursor is considered to have moved. (different from drag distance). > > Committed 5739506104 adding `WM_EVENT_CURSOR_MOTION_THRESHOLD` which is now scaled by the DPI, if it's still needed the preference can be added there too. @ideasman42 notice that tablet pens can't hold the cursor still because electromagnetic noise plus the fact that holding a pen still in midair always hard, the muscles always twitch a bit, this effect is so evident that you can easily tell if someone is using a mouse or a pen in a recorded video. Because of that, I would set this threshold to at least 5 or 6 pixels.

blender-admin commented

2019-03-20 12:14:13 +01:00

This issue was referenced by ef09aff61c

This issue was referenced by ef09aff61cdc4dc940a022c9e0c7c0ad9519780f

Campbell Barton commented

2019-03-20 12:20:31 +01:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2019-03-20 12:20:31 +01:00

derek watts commented

2019-11-14 21:18:56 +01:00

Added subscriber: @DerekWatts

derek watts commented

2019-11-14 21:18:56 +01:00

This problem is still evident when weight painting.

Armatures are nearly always occluded by geometry, meaning bones aren't the foremost objects, even though they're the weight painter's intended selection. This leads to a corner case where bones are inconsistently selectable, depending on the motion threshold, and often necessitate two clicks per selection.

Manually setting the armature to display 'In Front' leads to desired selection behavior and is visually indistinguishable from X-Ray viewport shading, but requires several steps to toggle on/off while painting, and thus is a poor workaround.

This problem is still evident when weight painting. Armatures are nearly always occluded by geometry, meaning bones aren't the foremost objects, even though they're the weight painter's intended selection. This leads to a corner case where bones are inconsistently selectable, depending on the motion threshold, and often necessitate two clicks per selection. Manually setting the armature to display 'In Front' leads to desired selection behavior and is visually indistinguishable from X-Ray viewport shading, but requires several steps to toggle on/off while painting, and thus is a poor workaround.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Blender 2.8 selection inconsistent between mouse and pen. #56278