Click over a Gizmo to select items underneath it #63996
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
12 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#63996
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Sometimes gizmos may be covering items underneath which the user intends to select:
![Screenshot 2019-04-29 at 20.19.41.png](https://archive.blender.org/developer/F6992565/Screenshot_2019-04-29_at_20.19.41.png)
It should be possible to click over a Gizmo to select items underneath it.
We can solve this by differentiating between a click and a drag, just like we do outside the gizmos.
To make this work well, we need to change the input, so that the drag threshold is more reasonable for mouse and trackpad input.
This requires us to add separate drag thresholds for Mouse, Pen and Keyboard.
Added subscriber: @WilliamReynish
Added subscriber: @ideasman42
Am yet far from having a full understanding on that issue, but from initial investigation it looks like this is the same kind of can of worms as #63994.
Basically, if I got things right, select is done on CLICK event, which will never be sent since the
GIZMOGROUP_OT_gizmo_tweak
operator is triggered on PRESS event. I quickly tried to re-add a CLICK event from that operator in 'cancel' cases, but that does not work, since that operators finishes immediately and passes over control to transform operator.@ideasman42 only idea I have here is that transform operator should detect when there is no transform (no drag) performed, and then return OPERATOR_CANCELLED instead of OPERATOR_FINISHED. That could be detected by the gizmo handling code, which could then add a fake 'RELEASE' and/or 'CLICK' events? Kind of a random idea, am still diving into the gizmo handling code…
Added subscriber: @niewinny
@mont29 I was thinking we could give gizmos control over the key bindings that activate them (on click / drag / key modifiers ... etc).
I didn't plan how this would work though, assume gizmos could have an event flag.
There is the down side that gizmos wouldn't activate immediately (since they would need to exceed the drag threshold).
Added subscriber: @GavinScott
If this is implemented, would it be possible to allow click-through a gizmo to hit the underlying geometry for selection, but at the same time ignore clicks on a gizmo that would hit the background and thus result in a deselect all? I think this might prevent some accidental deselects (accidental selects might be equally likely, but this would at least eliminate one of the two issues). If I really want to deselect by clicking on the background then I can move the mouse far enough away to make sure it happens and there's no ambiguity.
The issue would be reaching for the gizmo and mousing down and then changing your mind and releasing the mouse without moving it, which then turns into a click to select that you might not have intended. Over geometry there's really nothing you can do but perform the select since there's no way to know the user's intention, but when there's nothing behind the gizmo I think it would be reasonable to simply swallow the click without turning it into a click on the background/deselect.
This change can be made easily by changing the gizmos to use a Tweak event.
I've tested it, but this does make the gizmo less responsive to use. To me it became annoying if you only intend to do a very small movement.
I am unsure how to progress, or even if we should or not. It seems that, to support this well, element selection should take precedence, but if no element is underneath the gizmo, it should ideally remain as responsive as before. Might be too tricky and fiddly to sort out in the short term? Unless there are other solutions that I can't think of.
More thoughts:
It turns out that it is quite easy to solve the main issue, which is the ability to shift-click to select multiple items through the gizmos.
To do this, we just need to change the keymap slightly, so that it gizmos don't react to 'any' modifier keys. This works well for shift-clicking.
The tradeoff is that then we lose shift-clicking for doing two-axis constraining, which we already cover with the little squares.
Personally I think that's a good tradeoff for the default left click keymap. Right click and 2.79 keymap could continue working as before.
If it gonna be hardcoded It will be a huge problem for custom maps that are using press instead of click for LMB
or current select tool setup for LMB(it will detect selection before tweak action)
It would be perfect if there will be the ability to set hotkeys for gizmos the same way we can do it for all other things
so the user can decide what action he can start gizmo with if pressed on the gizmo, if he wants to activate it or another operator (like select)
@niewinny It's not hardcoded, it's in the keymap.
Those aren't always available, if you have location/scale/rotation all enabled for eg.
Further, this prevents all future use of modifier keys with gizmos.
We can make it so only gizmos that request modifier keys take the events.
@ideasman42 Yes, or the event could fall through the gizmo when the gizmo doesn't use it?
Added subscriber: @mont29
This issue was referenced by
13f292d10d
Changed status from 'Open' to: 'Resolved'
Added subscriber: @Rawalanche
I am confused as to how detecting modifier key solves this? Modifier key is not always held when selecting an item which can be covered by a gizmo. Sometimes you just want to select a single vertex, which is being occluded by a gizmo. Not add it to the selection, just select it. That case would not be covered then since simple selection does not involve any modifier key. What happened to differentiation between click and click-drag? That's how for example 3ds Max solves it, and it works very well.
@Rawalanche Yes, that is one way to solve it, for LMB select.
One issue with that, is that the default drag threshold is actually just too high for using tweak events for gizmos. 10 pixels is actually a lot of movement before something starts to react, and it makes using gizmos feel sluggish.
We could simply lower the drag threshold to something more reasonable. I tried a value of 3px which seems to work ok.
This value also seems to work better for nodes and sequencer strips, both of which react a lot faster when dragging on them.
Changed status from 'Resolved' to: 'Open'
This was automatically closed, which wasn't intended by statement "Needed to resolve".
@WilliamReynish from talking in blender.chat it seemed like you weren't so confident about using drag for gizmos - which is the solution being proposed in this task.
@ideasman42 Well as I said, with a drag threshold of 10 pixels, gizmos feel unreasonably slow and sluggish. My proposal would be to lower the drag threshold to 3 pixels instead.
The distance used to be 2, but was increased to 10 because of tablet users.
e815784aa6
We could try something in between (~4-6), but think a larger distance will get increasingly annoying/noticeable.
@ideasman42 No, afaik that is for click event detection, not drag events. 10 pixels is way too high for drag events.
Currently click/drag detection uses the same threshold.
Added subscriber: @StroBlend
You mean in case there is already a selection and you want to override it by selecting a vertex behind the gizmo ? Does this happens really often ?
In this case we need to click an empty space or press "a" key to deselect everything then do the new selection. That's not a big deal because most of time you prefer to be sure to have nothing selected before doing a new selection.
Lowering the drag threshold can do the trick but it requires some test because having a sluggish gizmo is very annoying
Yes, it's not a big deal. Yet for some reason this particular thing was the reason Blender had absolutely ridiculous input mapping for over 20 years. So now that it's finally being addressed, let's address it properly.
One way to go about it could be to have hardcoded, lower click/drag distinction value just for that particular case of selecting vertices under a gizmo.
3ds Max gizmos never felt sluggish to me. I've just measured the drag distance, and in 3ds Max it's 3px. I also think that it's important to scale that by monitor DPI scaling, so that it doesn't mess pen tablets up. It works well at 100% dpi scaling, but it may be tricky at higher values.
In my personal keymap. I use click-drag with 3px radius also for viewport orbit navigation, so that I can use Alt+LMB drag to navigate viewport while still using Alt+LMB click to select edge loops. And I have to say, that 3px threshold is not noticeable at all when starting viewport navigation drag.
This issue was referenced by
8778dd0c8b
Changed status from 'Open' to: 'Resolved'
Added subscriber: @Znio.G
eaxcatly this breaks my custom keymap for select tool which was used as a tweak mode with the gizmos and now selection feel sluggish since i have to use click event instead of press :(
@Znio.G you can customize this in the keymap
@WilliamReynish
i already tried, the issue is also in the default Left Click and ICK, u can't use select tool for tweaking as it selects underneath the gimzo's axes the moment u drag this was possible before and in 2.79....i think the select tool should be an exception for this as it's much faster to click drag once than 2x clicks....the select tool is now broken for Left Click Select.
and that includes the Industry compatible keymap here.
The Select tool should really be called the Tweak tool. It is meant for clicking and dragging to directly move items. There is a reason why it is separate from the Move tool.
Added subscriber: @chaos-4
What about using Right Clicking only on gizmos? Is this too stupid?
This doesn't force Right Click selection, though in a way it defeats the purpose of the Left Click Only.
Left Click select created a lot of problems only because of its ambiguity. You even had to start messing around with thresholds and dragging.
As the Right Click has become a pretty useless button in terms of user interaction, why not use it only for gizmos when the mouse is over any of them?
When the mouse is far, it could work as normal, showing the Context menu. Left Click could continue to be used for everything else in all of the interface as expected.
The Right Click on gizmos could be the only exception to the rule, and it would be for a good reason, allowing clicking and dragging without ambiguity, it could be even faster to use.
If the Left Click Only decision is solid as rock, why not give the user a new option to use the Right Click for gizmos as it is provided for Selection? Currently gizmos are always stuck to be used on Left Click only, no matter the button used to select.
Left/Right dilemma was always about selection, but never about gizmos.
Added subscriber: @Uendel
Added subscriber: @JPSavariault
In some other applications, selection is perform at mouse button release, except "ray-trace"/"Paint" selection.
You can set up mouse clicks and keyboard short cuts performing different actions for "at press" and "at release".
In the case of using Gizmo:
You can solve some other inconsistency that way by introducing "at press" and "at release".
One other annoying thing is "box", "lasso" and "circle" select are using LMB... ??? I don't get it ??? I'm confused.
Last, even if you set RMB select in preferences, you can still move with RMB... ??? I don't get it ??? I'm confused ...again.
If we set RMB to select, it should not move what you have selected. Add another key "press/toggle combo" to allow "select and tweak" like, for example, the bevel tool where you use A, S, P…
As for consistency, we should have all these various parameters available using the press/toggle combo.
Just by adding to the "lasso select" an "Ignore Back Face” key toggle, it is one-step to unify ergonomics.
Removed subscriber: @Uendel