Selection Options #109075

Open
opened 2023-06-17 12:18:44 +02:00 by Lukas Sneyd · 1 comment

Design for expansion of selection and adjacent features.

Introduction
I made a build for 3.60 that is mostly about selection, check out the source if you want #109150

Here's a video about my build that I will reference throughout.

I will be updating my build and it's individual features to 3.6 over the next week or two, then I'll update them to main after that. I'll link to the pull requests of each individual feature, they don't have much in the way of description and are behind the main build I made, but I will be updating them.

Edges and Faces
At 0:42 in the video above.
#109309

Give some options in the keymap for more control over how user can box/circle/lasso select edges and faces.

A dropdown for Edge Select with up to 3 options:
Default does Blender does, and Circle doesn't have this option
Touch will select anything the selection area touches
Enclose will select edges that have both ends inside the selection area

All 3 tools have 4 options for selecting Faces:
Default does what Blender does
Touch will select anything the selection area touches
Enclose will select a face if all their verts are inside
Center will select a face if you touch their center

X-Ray
At 2:38 in the video above.
#109318
#109319

Blender doesn't select unseen mesh. You select what you can see. If user wants to box/circle/lasso select something on the other side of a mesh, they'd either turn on X-Ray or move the camera until it's visible. With objects Blender always selects through, and it can't be turned off. Give user control over this, and provide some convenience features.

Make a popover for the X-Ray button. Move the X-Ray settings here from the Shading Popover. Give them new names so it's more clear that wireframe and solid have separate X-Ray properties.

If user wants to box/circle/lasso select unseen mesh without X-Ray, they can use Select Through. They can decide which tools and modes will use it.

If they don't want to change how X-Ray affects box/circle/lasso selection, they can use Automatic X-Ray. When they start to drag select it will turn X-Ray on, and when the selection is done X-Ray will turn off. They can decide which tools and modes will use it.

Include some operators. User can show any combination of them in the Header. If everything necessary for the tool and mode is enabled, the button for the operator will be lit up. It's modular, so there are many ways for the user to setup their shortcuts. Make new icons for Auto X-Ray and Select Through, the ones in my build were made by Alexey Adamitsky.

Viewport Facing Select
At 4:17 in the video above.
#109357

Blender does select unseen Mesh, and not in a good way like Select Through. If user can see some verts of an edge or face, they're potentially selectable regardless of their visibility. If it isn't truly random which unseen edges and faces this applies to, it may as well be. The 3 drag selection tools select the same wrong things, but if the viewport camera is moved or rotated, this will usually mean that different unseen edges and faces are now selectable.

The opposite is also a problem, where user cannot select visible mesh. If user zooms out, has a complex mesh, or a shallow angle on it, selection bitmap will only capture some of the mesh and give a patchy bit of what the user wanted. Long term, need to increase resolution of selection bitmap, whatever that would mean. Maybe Vulkan affects this in a positive way, maybe it has nothing to do with it.

For now I made Viewport-Facing Select to deal with this. Put it in Toolsettings. It works in near select, X-Ray, or both. When user drag selects with box/circle/lasso, it compares mesh normals to the viewport. If they aren't facing each other within the threshold, they won't be selected. Has a range from +/- 0.999999. Greater or equal to 0 means the mesh normal is pointed in the direction user has it set to. The higher they set the threshold, the more the mesh needs to be facing in that direction. A value of 1 should mean the viewport and mesh are aligned, but was only working from the front perspective (numpad 1) and from nowhere else regardless of ortho. Max threshold of 0.999999 is functionally the same as having it at 1 except it works from any angle. Negative values can select unseen mesh.

All Verts setting saves performance without compromise, because Blender doesn't select unseen verts. They're dimensionless, and since there's only one position for them to be drawn in, they shouldn't be in the selection bitmap unless they're visible.

Front Verts will select verts based on their normals,. Some of the verts at the edge of a mesh are excluded. Verts of Front Face will fix that, it selects verts if they're part of a face with a viewport facing normal. There's also rear facing counterparts to these, they do the opposite where they'll select stuff pointed away from the viewport. Not sure if they're useful but it's easy to include.

The settings for edges work the same as verts. Using edge normals will exclude things the user probably wants to select, and Edges of Front Face will correct that. Same goes for face settings, except Front Faces are what give accurate selection. Faces of Front Vert will select faces that have at least one vert with a viewport facing normal. This means it can select unseen faces, which is what I'm trying to avoid, but maybe it's useful for something.

Sometimes user will be able to see a face even though it has a rear-facing normal, and VFS won't select it. Usually this is because they are dealing with two triangles that have no business sharing the same quad, but that's going to happen from time to time, and they'll need a way to select them. Besides turning this feature off temporarily, triangulating or otherwise fixing the mesh, single-clicking, or rotating the camera, they can drop the VFS threshold into the negative. How negative they go depends on what they're willing to live with, and it gets worse the lower they go. I keep it at zero, because at least I have a chance of noticing things I didn't select. Hard to keep track of random selections that you can't see. It's not perfect, but it's predicable, and should work with most geometry.

Object Origin
At 7:35 in the video above.
#109373

My implementation of this feature is incomplete, but functional. Circle and lasso are forced to select objects by their origin, while box cannot do this. Put a checkbox in the Keymap so user can control this. Call it Select Object Origin. With my build box origin seems ok, but circle is a little off and lasso has enough problems with non-origin that I left it out. There's an addon that does this fine though from what I've been told. I looked at it but I couldn't figure out how to give object mode access to vert info, just kept getting errors so I left it at that for now. Addon is called X-Ray Selection Tools

Unsolved Mesh Select Issues
At 8:32 in the video above

Intersect doesn't work with Touch or Enclose face in X-Ray and Select Through. Don't know why, looked at it a few times, doesn't make sense to me. With my build it will fallback to a Center select instead. Figured it's better to do something close to what is expected rather than nothing.

Enclose face works in near select, but it's hard to use if user can't see all the verts of a face. If there is a visible face, but some of it's verts that would otherwise be on screen are behind something else, the selection bitmap thinks they don't exist. This means that it also thinks that part of these faces are outside the selection area, even though they aren't, and they get excluded from selection. One thing user can try is avoiding the selection bitmap entirely. Turn on Select Through, and set Viewport Facing Select to work in X-Ray, Verts of Front Face, Edges of Front Face, and Front Faces. Threshold at zero is best in my opinion. Now they get a decent result, but have to deal with the baggage that comes with Select Through and VFS. They don't always get everything they can see, at least when encountering some weird faces that have triangles pointing in very different directions. Also, they're going to select like X-Ray so if there's something that is facing the viewport, but they don't have line of sight, they're going to select it without actually seeing it.

Drag Direction
At 9:56 in the video above.
#109726

Blender let's you assign a direction to click-drag in the Keymap. There are 8 of them, which is nice, but it's confusing and inaccurate if all you need are 2. Provide some alternatives in Preferences->Input->Mouse. I'd like to put them at the top of the keymap in that preferences area, but I noticed how that thing will disappear if you load a keymap or use one other than the default. Didn't look into it yet.

Keymap Drag Direction has 3 options. Eight, which is what Blender does, Left Right, and Up Down. The tradeoff for the new ones is that they're exclusive. If you use Left Right, the only Keymap items Blender will match with are Any, Left, and Right. Unless something has been manually set to a direction, there shouldn't be anything besides View Axis, the ones where you hold ALT and Middlemouse while dragging in the direction that corresponds to the view you want.

With Blender's way, try to set Box select to Extend when dragging left aka West, and Subtract when dragging right aka East. If user doesn't initiate a mouse drag within 45 degrees of left or right, they get a Tweak Event instead of what they expected. There's a way to make this work better using the keymap alone. They can set Extend to Any, and Subtract to East, Northeast, and Southeast. The Keymap item set to Any needs to be after the other 3 or they'll be undetectable. Not intuitive, and I didn't figure out this was possible until after making this feature.

With the new ways I made there's 3 operators that will set drag direction. If a Keymap item is undetectable, it will warn the user about it. Not ideal, but nothing bad will happen, it's just telling them that this Keymap item won't do anything because Blender can't see it anymore.

Drag detection has some perpindicular bias. If the user is on the Left Right setting, and they drag up or down far enough before moving to the right, they're going to get the Left Keymap item instead of the Right Keymap item that they intended. If they're on Up Down, and move horizontally before going up, they would get the Down Keymap. With Blender's Eight way, assuming they set it like I described, the dominant Keymap item is the one that is set to the Any direction. The Left Right and Up down options are a lot more precise so it's hard for this to happen. The Eight way calculation rounds to the nearest int, so it treats every mouse drag within 45 degrees of a cardinal direction like it went straight vertical or horizontal. This problem can be mitigated by increasing drag theshold in Userprefs->Input->Mouse.

Selection Radius
At 12:48 in the video above.
#109729

Single-click an edge, vertex, or facedot and there's a pretty big area the user can grab it from. Faces in near select have zero radius, so the cursor needs to be right on top of them. Make this adjustable and consistent. Preferences->Editing->Miscellaneous-> Adjustable Click Select is where I put it, but that is not a good spot. It makes faces act the same as the others, and the user can change the size of the selection radius. Blender gives unselected mesh a slight bias, this can be turned off. Very minor detail that would not likely be noticed.

Conclusion
Nothing is really done all the way, but it is closing some gaps. Lot's of things can be moved, renamed, tweaked. That's what I'd like to do, and maybe some of it can make it into real Blender.

Design for expansion of selection and adjacent features. **Introduction** I made a build for 3.60 that is mostly about selection, check out the source if you want #109150 [Here's a video about my build that I will reference throughout.](https://www.youtube.com/watch?v=HVrFCOa7RO8) I will be updating my build and it's individual features to 3.6 over the next week or two, then I'll update them to main after that. I'll link to the pull requests of each individual feature, they don't have much in the way of description and are behind the main build I made, but I will be updating them. **Edges and Faces** At 0:42 in the video above. #109309 Give some options in the keymap for more control over how user can box/circle/lasso select edges and faces. A dropdown for Edge Select with up to 3 options: Default does Blender does, and Circle doesn't have this option Touch will select anything the selection area touches Enclose will select edges that have both ends inside the selection area All 3 tools have 4 options for selecting Faces: Default does what Blender does Touch will select anything the selection area touches Enclose will select a face if all their verts are inside Center will select a face if you touch their center **X-Ray** At 2:38 in the video above. #109318 #109319 Blender doesn't select unseen mesh. You select what you can see. If user wants to box/circle/lasso select something on the other side of a mesh, they'd either turn on X-Ray or move the camera until it's visible. With objects Blender always selects through, and it can't be turned off. Give user control over this, and provide some convenience features. Make a popover for the X-Ray button. Move the X-Ray settings here from the Shading Popover. Give them new names so it's more clear that wireframe and solid have separate X-Ray properties. If user wants to box/circle/lasso select unseen mesh without X-Ray, they can use Select Through. They can decide which tools and modes will use it. If they don't want to change how X-Ray affects box/circle/lasso selection, they can use Automatic X-Ray. When they start to drag select it will turn X-Ray on, and when the selection is done X-Ray will turn off. They can decide which tools and modes will use it. Include some operators. User can show any combination of them in the Header. If everything necessary for the tool and mode is enabled, the button for the operator will be lit up. It's modular, so there are many ways for the user to setup their shortcuts. Make new icons for Auto X-Ray and Select Through, the ones in my build were made by Alexey Adamitsky. **Viewport Facing Select** At 4:17 in the video above. #109357 Blender _does_ select unseen Mesh, and not in a good way like Select Through. If user can see some verts of an edge or face, they're potentially selectable regardless of their visibility. If it isn't truly random which unseen edges and faces this applies to, it may as well be. The 3 drag selection tools select the same wrong things, but if the viewport camera is moved or rotated, this will usually mean that different unseen edges and faces are now selectable. The opposite is also a problem, where user cannot select visible mesh. If user zooms out, has a complex mesh, or a shallow angle on it, selection bitmap will only capture some of the mesh and give a patchy bit of what the user wanted. Long term, need to increase resolution of selection bitmap, whatever that would mean. Maybe Vulkan affects this in a positive way, maybe it has nothing to do with it. For now I made Viewport-Facing Select to deal with this. Put it in Toolsettings. It works in near select, X-Ray, or both. When user drag selects with box/circle/lasso, it compares mesh normals to the viewport. If they aren't facing each other within the threshold, they won't be selected. Has a range from +/- 0.999999. Greater or equal to 0 means the mesh normal is pointed in the direction user has it set to. The higher they set the threshold, the more the mesh needs to be facing in that direction. A value of 1 should mean the viewport and mesh are aligned, but was only working from the front perspective (numpad 1) and from nowhere else regardless of ortho. Max threshold of 0.999999 is functionally the same as having it at 1 except it works from any angle. Negative values can select unseen mesh. All Verts setting saves performance without compromise, because Blender doesn't select unseen verts. They're dimensionless, and since there's only one position for them to be drawn in, they shouldn't be in the selection bitmap unless they're visible. Front Verts will select verts based on their normals,. Some of the verts at the edge of a mesh are excluded. Verts of Front Face will fix that, it selects verts if they're part of a face with a viewport facing normal. There's also rear facing counterparts to these, they do the opposite where they'll select stuff pointed away from the viewport. Not sure if they're useful but it's easy to include. The settings for edges work the same as verts. Using edge normals will exclude things the user probably wants to select, and Edges of Front Face will correct that. Same goes for face settings, except Front Faces are what give accurate selection. Faces of Front Vert will select faces that have at least one vert with a viewport facing normal. This means it can select unseen faces, which is what I'm trying to avoid, but maybe it's useful for something. Sometimes user will be able to see a face even though it has a rear-facing normal, and VFS won't select it. Usually this is because they are dealing with two triangles that have no business sharing the same quad, but that's going to happen from time to time, and they'll need a way to select them. Besides turning this feature off temporarily, triangulating or otherwise fixing the mesh, single-clicking, or rotating the camera, they can drop the VFS threshold into the negative. How negative they go depends on what they're willing to live with, and it gets worse the lower they go. I keep it at zero, because at least I have a chance of noticing things I didn't select. Hard to keep track of random selections that you can't see. It's not perfect, but it's predicable, and should work with most geometry. **Object Origin** At 7:35 in the video above. #109373 My implementation of this feature is incomplete, but functional. Circle and lasso are forced to select objects by their origin, while box cannot do this. Put a checkbox in the Keymap so user can control this. Call it Select Object Origin. With my build box origin seems ok, but circle is a little off and lasso has enough problems with non-origin that I left it out. There's an addon that does this fine though from what I've been told. I looked at it but I couldn't figure out how to give object mode access to vert info, just kept getting errors so I left it at that for now. Addon is called [X-Ray Selection Tools](https://captain-cirno.gumroad.com/l/DaLdj) **Unsolved Mesh Select Issues** At 8:32 in the video above Intersect doesn't work with Touch or Enclose face in X-Ray and Select Through. Don't know why, looked at it a few times, doesn't make sense to me. With my build it will fallback to a Center select instead. Figured it's better to do something close to what is expected rather than nothing. Enclose face works in near select, but it's hard to use if user can't see all the verts of a face. If there is a visible face, but some of it's verts that would otherwise be on screen are behind something else, the selection bitmap thinks they don't exist. This means that it also thinks that part of these faces are outside the selection area, even though they aren't, and they get excluded from selection. One thing user can try is avoiding the selection bitmap entirely. Turn on Select Through, and set Viewport Facing Select to work in X-Ray, Verts of Front Face, Edges of Front Face, and Front Faces. Threshold at zero is best in my opinion. Now they get a decent result, but have to deal with the baggage that comes with Select Through and VFS. They don't always get everything they can see, at least when encountering some weird faces that have triangles pointing in very different directions. Also, they're going to select like X-Ray so if there's something that is facing the viewport, but they don't have line of sight, they're going to select it without actually seeing it. **Drag Direction** At 9:56 in the video above. #109726 Blender let's you assign a direction to click-drag in the Keymap. There are 8 of them, which is nice, but it's confusing and inaccurate if all you need are 2. Provide some alternatives in Preferences->Input->Mouse. I'd like to put them at the top of the keymap in that preferences area, but I noticed how that thing will disappear if you load a keymap or use one other than the default. Didn't look into it yet. Keymap Drag Direction has 3 options. Eight, which is what Blender does, Left Right, and Up Down. The tradeoff for the new ones is that they're exclusive. If you use Left Right, the only Keymap items Blender will match with are Any, Left, and Right. Unless something has been manually set to a direction, there shouldn't be anything besides View Axis, the ones where you hold ALT and Middlemouse while dragging in the direction that corresponds to the view you want. With Blender's way, try to set Box select to Extend when dragging left aka West, and Subtract when dragging right aka East. If user doesn't initiate a mouse drag within 45 degrees of left or right, they get a Tweak Event instead of what they expected. There's a way to make this work better using the keymap alone. They can set Extend to Any, and Subtract to East, Northeast, and Southeast. The Keymap item set to Any needs to be after the other 3 or they'll be undetectable. Not intuitive, and I didn't figure out this was possible until after making this feature. With the new ways I made there's 3 operators that will set drag direction. If a Keymap item is undetectable, it will warn the user about it. Not ideal, but nothing bad will happen, it's just telling them that this Keymap item won't do anything because Blender can't see it anymore. Drag detection has some perpindicular bias. If the user is on the Left Right setting, and they drag up or down far enough before moving to the right, they're going to get the Left Keymap item instead of the Right Keymap item that they intended. If they're on Up Down, and move horizontally before going up, they would get the Down Keymap. With Blender's Eight way, assuming they set it like I described, the dominant Keymap item is the one that is set to the Any direction. The Left Right and Up down options are a lot more precise so it's hard for this to happen. The Eight way calculation rounds to the nearest int, so it treats every mouse drag within 45 degrees of a cardinal direction like it went straight vertical or horizontal. This problem can be mitigated by increasing drag theshold in Userprefs->Input->Mouse. **Selection Radius** At 12:48 in the video above. #109729 Single-click an edge, vertex, or facedot and there's a pretty big area the user can grab it from. Faces in near select have zero radius, so the cursor needs to be right on top of them. Make this adjustable and consistent. Preferences->Editing->Miscellaneous-> Adjustable Click Select is where I put it, but that is not a good spot. It makes faces act the same as the others, and the user can change the size of the selection radius. Blender gives unselected mesh a slight bias, this can be turned off. Very minor detail that would not likely be noticed. **Conclusion** Nothing is really done all the way, but it is closing some gaps. Lot's of things can be moved, renamed, tweaked. That's what I'd like to do, and maybe some of it can make it into real Blender.
Lukas Sneyd added the
Type
Design
label 2023-06-17 12:18:45 +02:00
Iliya Katushenock added this to the Modeling project 2023-07-11 11:42:57 +02:00
Author

I was told to tag you guys. I don't know what I'm supposed to do, but I will try this. Thanks for your time
@ideasman42 @harley

I was told to tag you guys. I don't know what I'm supposed to do, but I will try this. Thanks for your time @ideasman42 @harley
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
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
EEVEE & Viewport
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
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
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
EEVEE & Viewport
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
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
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
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#109075
No description provided.