Maniphest T56278

Blender 2.8 selection inconsistent between mouse and pen.
Closed, Resolved
Actions

Assigned To
Campbell Barton (campbellbarton)
Authored By
Jean Da Costa (jeacom256)
Aug 8 2018, 7:42 PM
Tags
  • BF Blender
Subscribers
Campbell Barton (campbellbarton)
derek watts (dwatts1)
Jean Da Costa (jeacom256)
Philipp Oeser (lichtwerk)

Description

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.

Revisions and Commits

rB Blender
rBef09aff61cdc Preferences: add threshold for cursor motion

Related Objects

Mentioned Here
rB57395061042f: UI: scale cursor motion threshold by DPI

Event Timeline

Jean Da Costa (jeacom256) created this task.Aug 8 2018, 7:42 PM
Jean Da Costa (jeacom256) added a project: BF Blender: 2.8.
Bastien Montagne (mont29) changed the task status from Unknown Status to Unknown Status.Aug 9 2018, 11:00 AM
Bastien Montagne (mont29) claimed this task.
Bastien Montagne (mont29) added a subscriber: Bastien Montagne (mont29).

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 (jeacom256) added a comment.Aug 9 2018, 7:47 PM

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 (jeacom256) changed the task status from Unknown Status to Unknown Status.Jan 20 2019, 12:35 PM

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 (mont29) removed Bastien Montagne (mont29) as the assignee of this task.Jan 20 2019, 2:17 PM
Bastien Montagne (mont29) removed a project: BF Blender: 2.8.
Bastien Montagne (mont29) removed a subscriber: Bastien Montagne (mont29).
Philipp Oeser (lichtwerk) assigned this task to Campbell Barton (campbellbarton).Mar 19 2019, 1:33 PM
Philipp Oeser (lichtwerk) lowered the priority of this task from 90 to Normal.
Philipp Oeser (lichtwerk) added subscribers: Campbell Barton (campbellbarton), Philipp Oeser (lichtwerk).

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.

@Campbell Barton (campbellbarton): should this be increased a bit? (made a preference?)

Campbell Barton (campbellbarton) added a comment.EditedMar 19 2019, 5:21 PM

@Philipp Oeser (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 rB57395061042fe336dae7ee33e3ae11e53d068194 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 (jeacom256) added a comment.Mar 19 2019, 6:06 PM
In T56278#644235, @Campbell Barton (campbellbarton) wrote:

@Philipp Oeser (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 rB57395061042fe336dae7ee33e3ae11e53d068194 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.

@Campbell Barton (campbellbarton) 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.

Campbell Barton (campbellbarton) changed the task status from Unknown Status to Resolved by committing rBef09aff61cdc: Preferences: add threshold for cursor motion.Mar 20 2019, 12:20 PM
Campbell Barton (campbellbarton) added a commit: rBef09aff61cdc: Preferences: add threshold for cursor motion.
derek watts (dwatts1) added a subscriber: derek watts (dwatts1).Nov 14 2019, 9:18 PM

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.