Creating this design task as there are unresolved issues with D6322: Mesh: Select through which are more design issues.
This is a place holder, some topics to address:
Where this option is stored, accessed?
Which selection tools/operators should use this?
Which modes this should be supported in (edit, pose, grease pencil... etc)
How to display this option when in wire-frame display (when the user will always select-through)
How to access this from both active-tools & key-bindings?
How to make it obvious selecting-trough is enabled (draw style, cursor - this might help avoid confusion).
Should this be supported in object mode too?(the reverse since objects already select-through), IIRC we discussed having this option for box select too.
Related Topics
Note that there are topics being raised which relate to select-through, but might be best treated as separate topics since we could change behavior here with or without select-through.
Current behavior of X-ray.
Current usability toggling X-ray (Z-drag or Alt-Z).
Selecting faces by their centers.
Lasso select using object centers #64281 (Option to lasso-select using geometry instead of object centers.).
Creating this design task as there are unresolved issues with [D6322: Mesh: Select through](https://archive.blender.org/developer/D6322) which are more design issues.
This is a place holder, some topics to address:
- Where this option is stored, accessed?
- Which selection tools/operators should use this?
- Which modes this should be supported in (edit, pose, grease pencil... etc)
- How to display this option when in wire-frame display (when the user will always select-through)
- How to access this from both active-tools & key-bindings?
- How to make it obvious selecting-trough is enabled *(draw style, cursor - this might help avoid confusion)*.
- Should this be supported in object mode too?(the reverse since objects already select-through), IIRC we discussed having this option for box select too.
### Related Topics
Note that there are topics being raised which relate to select-through, but might be best treated as separate topics since we could change behavior here with or without select-through.
- Current behavior of X-ray.
- Current usability toggling X-ray (Z-drag or Alt-Z).
- Selecting faces by their centers.
- Lasso select using object centers #64281 (Option to lasso-select using geometry instead of object centers.).
Nice move) Indeed, this task require a lot of workflow design for different cases.
How to make it obvious selecting-trough is enabled
There is no proper solution for this. The problem is that such mode is far from self-explanatory by definition.
It can be some tiny gui element that you constantly will look on to check if it is enabled or not, or draw something around cursor/change it's shape , like in other programs.
It also does not allow you to see what was selected or will be selected, so it will always be necessary to rotate the model or go wireframe/X-ray to check the selection.
If to add an overlay of vertices / edges ontop of shadng to make this mode both obvious and allowing us to control what will be selected, we will get Limit Selection to Visible realization.
I know many cases when people assigned LSTV to a hotkey to obtain quick visual through selections instead of wireframe in gamedev (personally, I'm working moslty with deadly hard mess from CAD software, so I have to stick on wireframe).
That's why Select Through it is an excellent example of a failed industry standard solution. It was invented too long ago, so it is pretty much obsolete concept, that creates more problems than it solves.
Should this be supported in object mode too?
All this time already works in the object mode. Do you mean - vice versa - provide the ability to limit selection with visible for object mode? That's actually interesting.
Nice move) Indeed, this task require a lot of workflow design for different cases.
> How to make it obvious selecting-trough is enabled
There is no proper solution for this. The problem is that such mode is far from self-explanatory by definition.
It can be some tiny gui element that you constantly will look on to check if it is enabled or not, or [draw something around cursor/change it's shape ](https://blender.community/c/rightclickselect/wgfbbc/), like in other programs.
It also does not allow you to see what was selected or will be selected, so it will always be necessary to rotate the model or go wireframe/X-ray to check the selection.
If to add an overlay of vertices / edges ontop of shadng to make this mode both obvious and allowing us to control what will be selected, we will get Limit Selection to Visible realization.
I know many cases when people assigned LSTV to a hotkey to obtain quick visual through selections instead of wireframe in gamedev (personally, I'm working moslty with deadly hard mess from CAD software, so I have to stick on wireframe).
That's why Select Through it is an excellent example of a failed industry standard solution. It was invented too long ago, so it is pretty much obsolete concept, that creates more problems than it solves.
> Should this be supported in object mode too?
All this time already works in the object mode. Do you mean - vice versa - provide the ability to limit selection with visible for object mode? That's actually interesting.
The main issue, is that this option conflicts with Blender's current paradigm, which is 'you select what you can see'.
With the linked patch, this conflict is there. If you disable Select Through, and then enable X-Ray, it does select through. Same with Wireframe view and other examples.
I don't see a great solution to this without removing Blender's core selection paradigm, or offering some sort of preference, or making the option feel broken, since if often won't work as expected.
The main issue, is that this option conflicts with Blender's current paradigm, which is 'you select what you can see'.
With the linked patch, this conflict is there. If you disable Select Through, and then enable X-Ray, it *does* select through. Same with Wireframe view and other examples.
I don't see a great solution to this without removing Blender's core selection paradigm, or offering some sort of preference, or making the option feel broken, since if often won't work as expected.
So blender's current paradigm already fails on loop and ring selection. While selecting a loop you don't really see what's being selected until you rotate your view to other side. Also same for select all and select linked selects everything on active context even you don't see any of them. And in many situation (like topological problems), loop selection may fail.
But even though there is no topological problem, how 'you select what you can see` paradigm applies to loop, ring, select all, select linked selection commands? If they are counted as an exception, why wouldn't be another one as long as it's toggle-able?
So blender's current paradigm already fails on loop and ring selection. While selecting a loop you don't really see what's being selected until you rotate your view to other side. Also same for select all and select linked selects everything on active context even you don't see any of them. And in many situation (like topological problems), loop selection may fail.
But even though there is no topological problem, how 'you select what you can see` paradigm applies to loop, ring, select all, select linked selection commands? If they are counted as an exception, why wouldn't be another one as long as it's toggle-able?
The main issue, is that this option conflicts with Blender's current paradigm, which is 'you select what you can see'.
This is not true.
Box select already selects hidden objects. And it works great.
Seleting things in the outliner selects things hidden in 3d view
Select all selects hidden elements
This select through behaviour is sort of a defacto standard and that has proven in many other tools to be faster than it's possible right now in blender. Blender is evolving at a great pace, and evolving means changes. This is a central element in nearly every workflow scenario. It should be implemented in the fastest way possible. Having multistep setups needed for activating this is wrong. And the visual clutter introduced by wireframe view is slowing you down. And adding central face dots adds to that clutter even more. And even with selections in wireframe mode you have to rotate the view to check if the selection is right.
This is really a feature many of us are hoping for.
> The main issue, is that this option conflicts with Blender's current paradigm, which is 'you select what you can see'.
This is not true.
- Box select already selects hidden objects. And it works great.
- Seleting things in the outliner selects things hidden in 3d view
- Select all selects hidden elements
This select through behaviour is sort of a defacto standard and that has proven in many other tools to be faster than it's possible right now in blender. Blender is evolving at a great pace, and evolving means changes. This is a central element in nearly every workflow scenario. It should be implemented in the fastest way possible. Having multistep setups needed for activating this is wrong. And the visual clutter introduced by wireframe view is slowing you down. And adding central face dots adds to that clutter even more. And even with selections in wireframe mode you have to rotate the view to check if the selection is right.
This is really a feature many of us are hoping for.
How to make it obvious selecting-trough is enabled
The selection-color for vertices, edges and faces could change if select-trough is turned on.
The cursor get a small rendition of what selection mode is chosen and the color of that could change accordingly to the current mode.
Distinguishing between "select trough" and"select visible" with additional symbols next to the cursor would be possible too, but this way it's cleaner and I don't think it's needed. People who activated it and forgot about the what was active mode get a feedback by the selection color, that's all what is needed I think.
>How to make it obvious selecting-trough is enabled
The selection-color for vertices, edges and faces could change if select-trough is turned on.
The cursor get a small rendition of what selection mode is chosen and the color of that could change accordingly to the current mode.
Distinguishing between "select trough" and"select visible" with additional symbols next to the cursor would be possible too, but this way it's cleaner and I don't think it's needed. People who activated it and forgot about the what was active mode get a feedback by the selection color, that's all what is needed I think.
@Debuk already pointed out the importance of this feature. In the Devtal thread you can see there are at least 10 people who registered on the platform just to ask for it.
And tens of thousands use "Select Through" by default (Maya, 3ds Max, Cinema 4D, Softimage maybe others too)
There is a reason for that and I'm glad you're not ignoring us.
Where this option is stored, accessed?
From my point of view (Maya old-timer) a simple checkbox in the preferences (maybe in the Editing section) to turn it globally on/off is enough.
I think you either use it all the time or you don't use it at all.
In Maya there is a checkbox in the preferences called "Camera-based selection", select only what's visible like currently in Blender. I haven't see anyone use it though :)
Which selection tools/operators should use this?
"Select Through" is only for Box select and Lasso select.
Circle select and Click select are not affected. In Maya paint select (circle select) selects only what is on the front surface even if you are in wireframe mode.
How to display this option when in wire-frame display (when the user will always select-through)
How to access this from both active-tools & key-bindings?
How to make it obvious selecting-trough is enabled (draw style, cursor - this might help avoid confusion).
I think if its a preferences option no other changes are needed.
@Debuk already pointed out the importance of this feature. In the [Devtal thread](https://devtalk.blender.org/t/decoupling-x-ray-and-limit-selection-to-visible/3498/77) you can see there are at least 10 people who registered on the platform just to ask for it.
And tens of thousands use "Select Through" by default (Maya, 3ds Max, Cinema 4D, Softimage maybe others too)
There is a reason for that and I'm glad you're not ignoring us.
> * Where this option is stored, accessed?
From my point of view (Maya old-timer) a simple checkbox in the preferences (maybe in the Editing section) to turn it globally on/off is enough.
I think you either use it all the time or you don't use it at all.
In Maya there is a checkbox in the preferences called "Camera-based selection", select only what's visible like currently in Blender. I haven't see anyone use it though :)
> * Which selection tools/operators should use this?
"Select Through" is only for Box select and Lasso select.
Circle select and Click select are not affected. In Maya paint select (circle select) selects only what is on the front surface even if you are in wireframe mode.
> * How to display this option when in wire-frame display (when the user will always select-through)
> * How to access this from both active-tools & key-bindings?
> * How to make it obvious selecting-trough is enabled (draw style, cursor - this might help avoid confusion).
I think if its a preferences option no other changes are needed.
I think this should just be in the User Preferences. I don't think it's something that people would want to turn on and off often, but more of a... well, user preference.
I think this should just be in the User Preferences. I don't think it's something that people would want to turn on and off often, but more of a... well, user preference.
Box/Circle/Lasso. Personally I don't think the Tweak tool needs it.
Which modes this should be supported in (edit, pose, grease pencil... etc)
All the modes where Box/Circle/Lasso selection tools exist? Makes sense to me.
Should this be supported in object mode too?
Sure.
In #73479#861717, @Debuk wrote:
This select through behaviour is sort of a defacto standard and that has proven in many other tools to be faster than it's possible right now in blender. This is really a feature many of us are hoping for.
Indeed..
In #73479#861818, @Oskar3d wrote:
From my point of view (Maya old-timer) a simple checkbox in the preferences
In #73479#861828, @z01ks wrote:
I think this should just be in the User Preferences.
No, preferences is not ideal for this setting. This is a tool setting that is enabled/disabled several times in a section, therefore it makes sense to be located in the tool settings. In most dcc apps that's where it's located because of that.
> Where this option is stored, accessed?
Tool Settings (checkbox).
> Which selection tools/operators should use this?
Box/Circle/Lasso. Personally I don't think the Tweak tool needs it.
> Which modes this should be supported in (edit, pose, grease pencil... etc)
All the modes where Box/Circle/Lasso selection tools exist? Makes sense to me.
> Should this be supported in object mode too?
Sure.
___
> In #73479#861717, @Debuk wrote:
> This select through behaviour is sort of a defacto standard and that has proven in many other tools to be faster than it's possible right now in blender.
> **This is really a feature many of us are hoping for.**
Indeed..
___
> In #73479#861818, @Oskar3d wrote:
> From my point of view (Maya old-timer) a simple checkbox in the preferences
> In #73479#861828, @z01ks wrote:
> I think this should just be in the User Preferences.
No, preferences is not ideal for this setting. This is a tool setting that is enabled/disabled several times in a section, therefore it makes sense to be located in the tool settings. In most dcc apps that's where it's located because of that.
In #73479#861687, @WilliamReynish wrote:
The main issue, is that this option conflicts with Blender's current paradigm, which is 'you select what you can see'.
Exactly.
Consistency - this is all Blender's mesh selecting paradigm about.
> In #73479#861687, @WilliamReynish wrote:
> The main issue, is that this option conflicts with Blender's current paradigm, which is 'you select what you can see'.
Exactly.
Consistency - this is all Blender's mesh selecting paradigm about.
This "feature" is only useful in Edit mode and it conflicts with xray which already does the job, but the problem with xray is that you have to fiddle with the slider. for example in Object mode you want it 0.5 but in edit mode u need it at 1.0.
So the obvious solution is xray needs preset values or a way to set it per mode, no need to add more extra options and subsequently a hoykey if it can be solved by an existent one.
This "feature" is only useful in Edit mode and it conflicts with xray which already does the job, but the problem with xray is that you have to fiddle with the slider. for example in Object mode you want it 0.5 but in edit mode u need it at 1.0.
So the obvious solution is xray needs preset values or a way to set it per mode, no need to add more extra options and subsequently a hoykey if it can be solved by an existent one.
In #73479#861995, @CobraA wrote:
This "feature" is only useful in Edit mode and it conflicts with xray which already does the job, but the problem with xray is that you have to fiddle with the slider. for example in Object mode you want it 0.5 but in edit mode u need it at 1.0.
So the obvious solution is xray needs preset values or a way to set it per mode, no need to add more extra options and subsequently a hoykey if it can be solved by an existent one.
True, xray = 1.0 is equal to LSTV off for edit mode.
Nice solution)
> In #73479#861995, @CobraA wrote:
> This "feature" is only useful in Edit mode and it conflicts with xray which already does the job, but the problem with xray is that you have to fiddle with the slider. for example in Object mode you want it 0.5 but in edit mode u need it at 1.0.
> So the obvious solution is xray needs preset values or a way to set it per mode, no need to add more extra options and subsequently a hoykey if it can be solved by an existent one.
True, xray = 1.0 is equal to LSTV off for edit mode.
Nice solution)
It's not so much that it's popular or not - I know that other apps work a different way.
The issue is that there is an inherent conflict. If you check the patch, you can disable Select Through, which means it should only select front faces. But if you switch to Wireframe or X-ray modes, it will still select through, even though the user turned off Select Through. The way it works in the patch, is that it's essentially 'select through even if something is not visible', and it only works one way - having Select Through set to Off doesn't ensure that you won't select through.
It's not so much that it's popular or not - I know that other apps work a different way.
The issue is that there is an inherent conflict. If you check the patch, you can disable Select Through, which means it should only select front faces. But if you switch to Wireframe or X-ray modes, it *will* still select through, even though the user turned off Select Through. The way it works in the patch, is that it's essentially 'select through even if something is not visible', and it only works one way - having Select Through set to Off doesn't ensure that you won't select through.
@Oskar3d@z01ks@CobraA@1D_Inc
Guys look, this is a tool setting and needs to be implemented like -> this
Nothing more, nothing less. No need for endless debate. It's that simple.
@Oskar3d @z01ks @CobraA @1D_Inc
Guys look, this is a tool setting and needs to be implemented like -> [this ](http://i.imgur.com/hhBJVuS.gif)
Nothing more, nothing less. No need for endless debate. It's that simple.
In #73479#862023, @ThinkingPolygons wrote: @Oskar3d@z01ks@CobraA@1D_Inc
Guys look, this is a tool setting and needs to be implemented like -> this
Nothing more, nothing less. No need for endless debate. It's that simple.
You always try to copy other Software then you should use that software instead, Blender already have xray that does the job just need to be set per mode which also be needed in paint modes for mask selection.
> In #73479#862023, @ThinkingPolygons wrote:
> @Oskar3d @z01ks @CobraA @1D_Inc
> Guys look, this is a tool setting and needs to be implemented like -> [this ](http://i.imgur.com/hhBJVuS.gif)
> Nothing more, nothing less. No need for endless debate. It's that simple.
You always try to copy other Software then you should use that software instead, Blender already have xray that does the job just need to be set per mode which also be needed in paint modes for mask selection.
@WilliamReynish Maybe we can just call it with a different name like "View-based selection" or "Only select visible elements" as @ThinkingPolygons showed, and show the option only in edit mode.
This way it won't conflict with Wireframe or X-ray modes, because the elements are always visible there. "Only select visible elements" on or off, ether way they will be selected, because they are visible (as is the current behavior) so nothing changes for Wireframe or X-ray.
@CobraA nope, x-ray doesn't do the job. With xray = 1.0 you still see the wireframe/vertex/edges/face dots behind.
We are use to selecting elements we don't see, in most cases we know where they are. It's difficult to explain to users who haven't tried it, but I believe such an option won't hurt and a lot of users could benefit from it.
@WilliamReynish Maybe we can just call it with a different name like "View-based selection" or "Only select visible elements" as @ThinkingPolygons showed, and show the option only in edit mode.
This way it won't conflict with Wireframe or X-ray modes, because the elements are always visible there. "Only select visible elements" on or off, ether way they will be selected, because they are visible (as is the current behavior) so nothing changes for Wireframe or X-ray.
@CobraA nope, x-ray doesn't do the job. With xray = 1.0 you still see the wireframe/vertex/edges/face dots behind.
We are use to selecting elements we don't see, in most cases we know where they are. It's difficult to explain to users who haven't tried it, but I believe such an option won't hurt and a lot of users could benefit from it.
in most cases we know where they are. It's difficult to explain to users who haven't tried it, but I believe such an option won't hurt and a lot of users could benefit from it.
I remember this in 3dsmax 4.
It is also hard to explain to users who have been accustomed to this for decades, that it is not actually needed to guess what you will get after making a selection anymore.
There are no cases to show when it is needed except a cylinder.
There are a lot of such things in industry standards software, because there were nothing except 3dsmax for reference.
> In #73479#862061, @Oskar3d wrote:
> in most cases we know where they are. It's difficult to explain to users who haven't tried it, but I believe such an option won't hurt and a lot of users could benefit from it.
I remember this in 3dsmax 4.
It is also hard to explain to users who have been accustomed to this for decades, that it is not actually needed to guess what you will get after making a selection anymore.
There are no cases to show when it is needed except a cylinder.
There are a lot of such things in industry standards software, because there were nothing except 3dsmax for reference.
In #73479#862061, @Oskar3d wrote: @CobraA nope, x-ray doesn't do the job. With xray = 1.0 you still see the wireframe/vertex/edges/face dots behind.
We are use to selecting elements we don't see, in most cases we know where they are. It's difficult to explain to users who haven't tried it, but I believe such an option won't hurt and a lot of users could benefit from it.
When you say "We" you mean users who used to the other Softwares way like Max,Maya & C4D which i used few of them too.
Blender has always set elements visible with that option and it works exactly as xray = 1.0 and it's arguably better choice from my view, don't forget Blender is not just a modeling software it has other modes with selection tools like i have said.
> In #73479#862061, @Oskar3d wrote:
> @CobraA nope, x-ray doesn't do the job. With xray = 1.0 you still see the wireframe/vertex/edges/face dots behind.
> We are use to selecting elements we don't see, in most cases we know where they are. It's difficult to explain to users who haven't tried it, but I believe such an option won't hurt and a lot of users could benefit from it.
When you say "We" you mean users who used to the other Softwares way like Max,Maya & C4D which i used few of them too.
Blender has always set elements visible with that option and it works exactly as xray = 1.0 and it's arguably better choice from my view, don't forget Blender is not just a modeling software it has other modes with selection tools like i have said.
To whomever saying that this is exactly what current x-ray does in Blender: it's not, due to one key difference which is face dots. Blender's current x-ray and wireframe modes are ill-suited for the problem they're trying to solve. They're supposed to let you see through the geometry and select occluded geometry. What they do instead is replace shading with horrendous face dots that clutter the view and make it difficult to discern the faces. What's worse, bulk selection tools (box, lasso) in these modes require user to be overly precise with selection, having to actually encompass those dots. So while they do let you select occluded geometry, they make it a way more difficult task than it needs to be. One doesn't need to go far to see it:
The dots are not only useless here, they're outright detrimental: you have to spend more time figuring out which dots belong where and targeting them carefully with your mouse than actually making a selection.
Suggesting to "just use" the x-ray value of 1.0 doesn't help, since the dots don't go anywhere even then, and the problem of having to surround them with box/lasso remains.
In more practical examples, however, select-through is very useful. Every time you start a model from simple shapes, you almost always want to be selecting in bulk, including occluded faces. There's no practical reason to clutter the view just for that. User can easily tell where the geometry is, whether their selection tool would pick it up. At least, so long as the software does not make the job more difficult (dots again).
How do you select half a cylinder in Blender currently?
position view accordingly
enable x-ray/wireframe
carefully drag a box selection making sure that all dots are encompassed
disable x-ray/wireframe
How is it done with "select through" enabled?
position view accordingly
drag a box selection encompassing just the quarter facing you, quite lazily; the only thing to make sure is that you don't cross an extra face from the other quarter with your box, which is not a problem at all
Two fewer steps, and much less precision and stress required. The comparison is valid, as in current Blender X-ray/wireframe is normally disabled, while if "select through" option existed, it would be normally enabled. Later, when the model becomes more complex, one may turn the setting off.
"Select through" having no effect in wireframe mode is a non-issue. Implementation could gray out the setting, or even not show it in wireframe view.
To whomever saying that this is exactly what current x-ray does in Blender: it's not, due to one key difference which is face dots. Blender's current x-ray and wireframe modes are ill-suited for the problem they're trying to solve. They're supposed to let you see through the geometry and select occluded geometry. What they do instead is replace shading with horrendous face dots that clutter the view and make it difficult to discern the faces. What's worse, bulk selection tools (box, lasso) in these modes require user to be overly precise with selection, having to actually encompass those dots. So while they do let you select occluded geometry, they make it a way more difficult task than it needs to be. One doesn't need to go far to see it:
The dots are not only useless here, they're outright detrimental: you have to spend more time figuring out which dots belong where and targeting them carefully with your mouse than actually making a selection.
Suggesting to "just use" the x-ray value of 1.0 doesn't help, since the dots don't go anywhere even then, and the problem of having to surround them with box/lasso remains.
In more practical examples, however, select-through is very useful. Every time you start a model from simple shapes, you almost always want to be selecting in bulk, including occluded faces. There's no practical reason to clutter the view just for that. User can easily tell where the geometry is, whether their selection tool would pick it up. At least, so long as the software does not make the job more difficult (dots again).
How do you select half a cylinder in Blender currently?
- position view accordingly
- enable x-ray/wireframe
- carefully drag a box selection making sure that all dots are encompassed
- disable x-ray/wireframe
How is it done with "select through" enabled?
- position view accordingly
- drag a box selection encompassing just the quarter facing you, quite lazily; the only thing to make sure is that you don't cross an extra face from the other quarter with your box, which is not a problem at all
Two fewer steps, and much less precision and stress required. The comparison is valid, as in current Blender X-ray/wireframe is normally disabled, while if "select through" option existed, it would be normally enabled. Later, when the model becomes more complex, one may turn the setting off.
"Select through" having no effect in wireframe mode is a non-issue. Implementation could gray out the setting, or even not show it in wireframe view.
You are definitely using them wrong. They are needed for precise selection and depth picking (like Pick shortest path)
How do you select half a cylinder in Blender currently?
Vertex mode - Z - select. It is simple.
> In #73479#862148, @Stan_Pancakes wrote:
> The dots are not only useless here,
You are definitely using them wrong. They are needed for precise selection and depth picking (like Pick shortest path)
> How do you select half a cylinder in Blender currently?
Vertex mode - Z - select. It is simple.
In #73479#862002, @WilliamReynish wrote:
It's not so much that it's popular or not - I know that other apps work a different way.
The issue is that there is an inherent conflict. If you check the patch, you can disable Select Through, which means it should only select front faces. But if you switch to Wireframe or X-ray modes, it will still select through, even though the user turned off Select Through. The way it works in the patch, is that it's essentially 'select through even if something is not visible', and it only works one way - having Select Through set to Off doesn't ensure that you won't select through.
Maybe that there are shortcomings with the existing patch itself. But that conflict you are referring to is solvable. Lets add a preference "Auto-Select-Through" that switches to select through in Xray and Wireframe mode if checked. Activate the chosen indicator ( eg the proposed cursor icons and selection colors) for Select through in xray and wireframe and we're done. People who love it the old way can continue to and the new feature is nicely interwoven with the rest of blender.
If it's not activated change the wireframe and xray to select frontfaces only. And if that's not possible for some reason make the "AutoSelectThrough" mandatory for these two viewtypes.
In #73479#861847, @TheRedWaxPolice wrote:
Which selection tools/operators should use this?
Box/Circle/Lasso. Personally I don't think the Tweak tool needs it.
I agree. Not needed for the Tweak Tool
In #73479#861847, @TheRedWaxPolice wrote:
No, preferences is not ideal for this setting. This is a tool setting that is enabled/disabled several times in a section, therefore it makes sense to be located in the tool settings. In most dcc apps that's where it's located because of that.
+1. No good idea to have it just in the prefs. A checkbox / toggle and a shortcut assignable would be enough.
In #73479#862030, @CobraA wrote:
You always try to copy other Software then you should use that software instead
With that sort of argumentation, we wouldn't even have a save dialog, or a menuentry for it in the file menu, we would also have no filemenu nor would we have Ctrl+S as a shortcut for triggering it. This all existed in other apps before and these things are also defacto standards just like the proposed select through implementation. This is being asked for so often because it's more efficient. Not because someone wants blender to be a copy of another tool. How does this sort of thinking fit to open source. Is eg. using OpenVDB about copying Dreamworks tools or any other software utilizing it?
I think @Stan_Pancakes describes the problems with the current solution pretty well.
I fully agree with it.
> In #73479#862002, @WilliamReynish wrote:
> It's not so much that it's popular or not - I know that other apps work a different way.
>
> The issue is that there is an inherent conflict. If you check the patch, you can disable Select Through, which means it should only select front faces. But if you switch to Wireframe or X-ray modes, it *will* still select through, even though the user turned off Select Through. The way it works in the patch, is that it's essentially 'select through even if something is not visible', and it only works one way - having Select Through set to Off doesn't ensure that you won't select through.
Maybe that there are shortcomings with the existing patch itself. But that conflict you are referring to is solvable. Lets add a preference "Auto-Select-Through" that switches to select through in Xray and Wireframe mode if checked. Activate the chosen indicator ( eg the proposed cursor icons and selection colors) for Select through in xray and wireframe and we're done. People who love it the old way can continue to and the new feature is nicely interwoven with the rest of blender.
If it's not activated change the wireframe and xray to select frontfaces only. And if that's not possible for some reason make the "AutoSelectThrough" mandatory for these two viewtypes.
> In #73479#861847, @TheRedWaxPolice wrote:
>Which selection tools/operators should use this?
>Box/Circle/Lasso. Personally I don't think the Tweak tool needs it.
I agree. Not needed for the Tweak Tool
> In #73479#861847, @TheRedWaxPolice wrote:
> No, preferences is not ideal for this setting. This is a tool setting that is enabled/disabled several times in a section, therefore it makes sense to be located in the tool settings. In most dcc apps that's where it's located because of that.
+1. No good idea to have it just in the prefs. A checkbox / toggle and a shortcut assignable would be enough.
> In #73479#862030, @CobraA wrote:
> You always try to copy other Software then you should use that software instead
With that sort of argumentation, we wouldn't even have a save dialog, or a menuentry for it in the file menu, we would also have no filemenu nor would we have Ctrl+S as a shortcut for triggering it. This all existed in other apps before and these things are also defacto standards just like the proposed select through implementation. This is being asked for so often because it's more efficient. Not because someone wants blender to be a copy of another tool. How does this sort of thinking fit to open source. Is eg. using OpenVDB about copying Dreamworks tools or any other software utilizing it?
I think @Stan_Pancakes describes the problems with the current solution pretty well.
I fully agree with it.
In #73479#862062, @1D_Inc wrote:
It is also hard to explain to users who have been accustomed to this for decades, that it is not actually needed to guess what you will get after making a selection anymore.
There are no cases to show when it is needed except a cylinder.
I wouldn't say guessing, its more like knowing. If that's not the case there are x-ray and wireframe modes in the other software products as well.
You've tried it, you don't like it and that's fine. In Max,Maya & C4D you can choose to use it or not, its an option. What's the danger of Blender offering to its users that option too? As developers mentioned, its a trivial thing to code it.
@CobraA By "We" I meant the people who like this feature (I guess this includes native Blender users too).
don't forget Blender is not just a modeling software it has other modes with selection tools like i have said.
I think what the main problem for people who want this feature is edit mesh mode. (correct me if I'm wrong) So this option could appear for Box and Lasso tools when you edit meshes.
> In #73479#862062, @1D_Inc wrote:
> It is also hard to explain to users who have been accustomed to this for decades, that it is not actually needed to guess what you will get after making a selection anymore.
> There are no cases to show when it is needed except a cylinder.
I wouldn't say guessing, its more like knowing. If that's not the case there are x-ray and wireframe modes in the other software products as well.
You've tried it, you don't like it and that's fine. In Max,Maya & C4D you can choose to use it or not, its an option. What's the danger of Blender offering to its users that option too? As developers mentioned, its a trivial thing to code it.
@CobraA By "We" I meant the people who like this feature (I guess this includes native Blender users too).
> don't forget Blender is not just a modeling software it has other modes with selection tools like i have said.
I think what the main problem for people who want this feature is edit mesh mode. (correct me if I'm wrong) So this option could appear for Box and Lasso tools when you edit meshes.
With that sort of argumentation, we wouldn't even have a save dialog, or a menuentry for it in the file menu, we would also have no filemenu nor would we have Ctrl+S as a shortcut for triggering it. This all existed in other apps before and these things are also defacto standards just like the proposed select through implementation. This is being asked for so often because it's more efficient. Not because someone wants blender to be a copy of another tool. How does this sort of thinking fit to open source. Is eg. using OpenVDB about copying Dreamworks tools or any other software utilizing it?
This thread is turning into a mess, if you want that kind of conversation take it to the forums not here, undestood.
you should first know the context of my comment .
For you information it's not allowed to reference other Softwares here on the bug tracker, and any comment who do that should be deleted by the Admins.
If you try to bring any idea to Blender then see how it could fit with what paradigms Blender already have and not a blant copy like Thinking polygon has done over and over.
> With that sort of argumentation, we wouldn't even have a save dialog, or a menuentry for it in the file menu, we would also have no filemenu nor would we have Ctrl+S as a shortcut for triggering it. This all existed in other apps before and these things are also defacto standards just like the proposed select through implementation. This is being asked for so often because it's more efficient. Not because someone wants blender to be a copy of another tool. How does this sort of thinking fit to open source. Is eg. using OpenVDB about copying Dreamworks tools or any other software utilizing it?
>
>
This thread is turning into a mess, if you want that kind of conversation take it to the forums not here, undestood.
you should first know the context of my comment .
For you information it's not allowed to reference other Softwares here on the bug tracker, and any comment who do that should be deleted by the Admins.
If you try to bring any idea to Blender then see how it could fit with what paradigms Blender already have and not a blant copy like Thinking polygon has done over and over.
Pick shortest path and other precision strategic selections are used way less often than bulk selection. Furthermore, why did you stop there? Four faces further and the problem I'm describing is immediately apparent - the dots get in the way of one another. Furthermore, that particular "shortest path" selection requires quite a few clicks, whereas the same selection can be done by tilting view once and dragging a box.
And then you're suggesting to add even more steps to selection, like switching modes, so select through becomes even more efficient.
Selection is the most performed task while modeling, it needs to be as efficient as it can get. That includes reducing amount of work required for any particular selection. Having to constantly switch to wireframe/x-ray and back, switch modes or hunt for dots increases that amount.
Pick shortest path and other precision strategic selections are used way less often than bulk selection. Furthermore, why did you stop there? Four faces further and the problem I'm describing is immediately apparent - the dots get in the way of one another. Furthermore, that particular "shortest path" selection requires quite a few clicks, whereas the same selection can be done by tilting view once and dragging a box.
And then you're suggesting to add even more steps to selection, like switching modes, so select through becomes even more efficient.
Selection is the most performed task while modeling, it needs to be as efficient as it can get. That includes reducing amount of work required for any particular selection. Having to constantly switch to wireframe/x-ray and back, switch modes or hunt for dots increases that amount.
@CobraA No this thread is not turning into a mess. From what I get the description this is about discussing advantages and drawbacks for designing and improving a specific tool. And just saying something has been in there somehow, just to wipe away different approaces is not helpful in any sense. Your argumentation is just about conservation. And I think your agresssive tone was and still is damaging here. I gave you some examples why your argumentation makes no sense, that's all I will say to that sort of comments.
@CobraA No this thread is not turning into a mess. From what I get the description this is about discussing advantages and drawbacks for designing and improving a specific tool. And just saying something has been in there somehow, just to wipe away different approaces is not helpful in any sense. Your argumentation is just about conservation. And I think your agresssive tone was and still is damaging here. I gave you some examples why your argumentation makes no sense, that's all I will say to that sort of comments.
In #73479#862234, @Stan_Pancakes wrote:
Furthermore, that particular "shortest path" selection requires quite a few clicks, whereas the same selection can be done by tilting view once and dragging a box.
Ok, a real work sample.
But I respect your desire to speed up work with primitives.
> In #73479#862234, @Stan_Pancakes wrote:
> Furthermore, that particular "shortest path" selection requires quite a few clicks, whereas the same selection can be done by tilting view once and dragging a box.
Ok, a real work sample.
But I respect your desire to speed up work with primitives.
In #73479#862244, @Debuk wrote: @CobraA No this thread is not turning into a mess. From what I get the description this is about discussing advantages and drawbacks for designing and improving a specific tool. And just saying something has been in there somehow, just to wipe away different approaces is not helpful in any sense. Your argumentation is just about conservation. And I think your agresssive tone was and still is damaging here. I gave you some examples why your argumentation makes no sense, that's all I will say to that sort of comments.
Now you want to turn it personal, what agressive tone? I said you should know the context first, is that agressive to you? huh
My argument is valid because rules are rules and if you and the other knew them better then we wouldn't be debating about this., you're twist my words as if they are against making any improvements and yes I am for conservation because i don't like features creep ,sure Devs agree on that too..
> In #73479#862244, @Debuk wrote:
> @CobraA No this thread is not turning into a mess. From what I get the description this is about discussing advantages and drawbacks for designing and improving a specific tool. And just saying something has been in there somehow, just to wipe away different approaces is not helpful in any sense. Your argumentation is just about conservation. And I think your agresssive tone was and still is damaging here. I gave you some examples why your argumentation makes no sense, that's all I will say to that sort of comments.
Now you want to turn it personal, what agressive tone? I said you should know the context first, is that agressive to you? huh
My argument is valid because rules are rules and if you and the other knew them better then we wouldn't be debating about this., you're twist my words as if they are against making any improvements and yes I am for conservation because i don't like features creep ,sure Devs agree on that too..
In #73479#862245, @1D_Inc wrote:
Ok, a real work sample.
...
But I respect your desire to speed up work with primitives.
That sample has nothing to do with "select through" though, the whole point of which is to not have to rely on wireframe and dots when it's possible. Currently in Blender there's no other way. Yes, for that particular selection you need wireframe and dots. For this you wouldn't need either if "select through" existed:
But with wireframe/x-ray the necessity to encompass the dots does get in the way here (a few faces weren't selected, even though the box selection did intersect them; just not enough to capture their dot).
> In #73479#862245, @1D_Inc wrote:
> Ok, a real work sample.
> ...
> But I respect your desire to speed up work with primitives.
That sample has nothing to do with "select through" though, the whole point of which is to not have to rely on wireframe and dots when it's possible. Currently in Blender there's no other way. Yes, for that particular selection you need wireframe and dots. For this you wouldn't need either if "select through" existed:
But with wireframe/x-ray the necessity to encompass the dots **does** get in the way here (a few faces weren't selected, even though the box selection did intersect them; just not enough to capture their dot).
What about workflow design though?
Do you propose something like
enable through selection mode - make through selection - disable through selection mode - add visible faces to selection, to avoid using wireframe mode
or
disable facedots - make through boх selection - enable facedots - add a couple internal faces to a selection?
Through selection selects everything through with box selection in any mode, no facedots method blocks through selection for single click even in wireframe and through mode.
And all this is necessary for editing primitives?
It is solved with vertices mode.
What about workflow design though?
Do you propose something like
enable through selection mode - make through selection - disable through selection mode - add visible faces to selection, to avoid using wireframe mode
or
disable facedots - make through boх selection - enable facedots - add a couple internal faces to a selection?
Through selection selects everything through with box selection in any mode, no facedots method blocks through selection for single click even in wireframe and through mode.
And all this is necessary for editing primitives?
Like I said before, typical scenario is that select through is normally enabled (meaning, you infrequently disable it when needed). So for my example above, all that would've been needed is to switch to side view and drag a box selection. No switching to vertex mode. No entering wireframe or x-ray. Literally just two actions: view and select. If your workflow is different, you'll keep it normally disabled. That's all there is to it.
Again like I said before, my point is that x-ray and wireframe as they are in Blender are in no way a substitute or a replacement for select through. That said, they can be left as is (while graying out or hiding the "select through" option).
Necessary? No. Convenient and faster? Yes. For primitives? No, for everything that has a surface. Model from my example is certainly not a primitive.
Like I said before, typical scenario is that select through is normally enabled (meaning, you **infrequently** disable it when needed). So for my example above, all that would've been needed is to switch to side view and drag a box selection. No switching to vertex mode. No entering wireframe or x-ray. Literally just two actions: view and select. If your workflow is different, you'll keep it normally disabled. That's all there is to it.
Again like I said before, my point is that x-ray and wireframe **as they are** in Blender are in no way a substitute or a replacement for select through. That said, they can be left as is (while graying out or hiding the "select through" option).
Necessary? No. Convenient and faster? Yes. For primitives? No, for everything that has a surface. Model from my example is certainly not a primitive.
In #73479#862253, @CobraA wrote:
yes I am for conservation because i don't like features creep ,sure Devs agree on that too..
I personally think a debate should be open to discuss differing approaches and generally look for the solution with the most advantages and I think the devs agree on that too.
rules are rules and if you and the other knew them better
For your information I didn't name any other software so I don't get why you write things like this. And it's ridiculous to think these mentioned rules are there to hinder users to bring in their expertise from other software generally and include thoughts about the market as a whole or present standards. But I am not really interested in discussing this any further. To get this to an end I will leave it with this, if hope you feel better now that you said this, can we get back to the topic discussed in here please.
Blender already have xray that does the job just need to be set per mode which also be needed in paint modes for mask selection.
This is what makes no sense. The current solution has quite some drawbacks, the select through method is bound to wireframes views. I understand why it once was developed like that. But typical mesh densities for all common use cases tend into the same direction. Meshes get more and more polys. And this solution suffers from that. Especially in complex scenes. And using it needs more steps. And any sort of of depth visualization is gone in pure wireframe and the xray is also too cluttered by the wireframes to leave it on. And the face dots increase that problem. That all are benefits from the alternative proposed and discussed here.
> In #73479#862253, @CobraA wrote:
> yes I am for conservation because i don't like features creep ,sure Devs agree on that too..
I personally think a debate should be open to discuss differing approaches and generally look for the solution with the most advantages and I think the devs agree on that too.
> rules are rules and if you and the other knew them better
For your information I didn't name any other software so I don't get why you write things like this. And it's ridiculous to think these mentioned rules are there to hinder users to bring in their expertise from other software generally and include thoughts about the market as a whole or present standards. But I am not really interested in discussing this any further. To get this to an end I will leave it with this, if hope you feel better now that you said this, can we get back to the topic discussed in here please.
> Blender already have xray that does the job just need to be set per mode which also be needed in paint modes for mask selection.
This is what makes no sense. The current solution has quite some drawbacks, the select through method is bound to wireframes views. I understand why it once was developed like that. But typical mesh densities for all common use cases tend into the same direction. Meshes get more and more polys. And this solution suffers from that. Especially in complex scenes. And using it needs more steps. And any sort of of depth visualization is gone in pure wireframe and the xray is also too cluttered by the wireframes to leave it on. And the face dots increase that problem. That all are benefits from the alternative proposed and discussed here.
In #73479#862301, @Stan_Pancakes wrote:
Necessary? No. Convenient and faster? Yes. For primitives? No, for everything that has a surface. Model from my example is certainly not a primitive.
Everything that requires single box strike to select is primitive.
I would like to have such problems, but we rarely edit simple models.
Literally, we even made scripts to select object's vertices with another object's volume or surface for special cases we faced with
So, do you propose a checkbox somewhere? What it will do - just enable through selection or also turn off a facedots as well?
Our proposal stays the same - separate Xray setup for object and edit modes.
But it will cover only our demands.
> In #73479#862301, @Stan_Pancakes wrote:
> Necessary? No. Convenient and faster? Yes. For primitives? No, for everything that has a surface. Model from my example is certainly not a primitive.
Everything that requires single box strike to select is primitive.
I would like to have such problems, but we rarely edit simple models.
Literally, we even made scripts to select object's vertices with another object's volume or surface for special cases we faced with
So, do you propose a checkbox somewhere? What it will do - just enable through selection or also turn off a facedots as well?
Our proposal stays the same - separate Xray setup for object and edit modes.
But it will cover only our demands.
Please leave the snark out of this, there's no need to trivialize the issue. Keypresses do add up as hours go by. "I don't need it, therefore no one needs it" is not an argument.
Sadly, that "primitive" in Blender right now does not require single box "strike". It requires enabling wireframe and paying close attention to what your box encompasses, and usually having to make additional selections after you're done with wireframe. I thought I expressed that quite clear already. In practice, sometimes it gets to a point where it's faster to select a loop, mark a seam, and then use it as a temporary delimiter for "select linked". For the last time - select through is not for peeking inside an object, it's exactly the way to not have to do that when doing so serves no purpose other than allowing selection tools to select occluded geometry. Therefore Blender's existing wireframe/x-ray views are in no way, shape, or form, a replacement for it. They're a poor alternative.
Yes, I do propose a checkbox, in tool options. As to what will it do - IMHO either way is fine (i.e. leave the wireframe/x-ray views untouched and only gray out the "select through" setting while you're in those views), or do what Benjamin's implementation already does and disable the dots.
That separate x-ray views for object and edit modes would be a welcome addition is not in question - they certainly would. But those have nothing to do with this design task. At all.
Please leave the snark out of this, there's no need to trivialize the issue. Keypresses do add up as hours go by. "I don't need it, therefore no one needs it" is not an argument.
Sadly, that "primitive" in Blender **right now** does not require **single box "strike"**. It requires enabling wireframe **and** paying close attention to what your box encompasses, and usually having to make additional selections after you're done with wireframe. I thought I expressed that quite clear already. In practice, sometimes it gets to a point where it's faster to select a loop, mark a seam, and then use it as a temporary delimiter for "select linked". For the last time - select through is not for peeking inside an object, it's exactly the way to **not have to do that** when doing so serves no purpose other than allowing selection tools to select occluded geometry. Therefore Blender's existing wireframe/x-ray views are in no way, shape, or form, a replacement for it. They're a poor alternative.
Yes, I do propose a checkbox, in tool options. As to what will it do - IMHO either way is fine (i.e. leave the wireframe/x-ray views untouched and only gray out the "select through" setting while you're in those views), or do what Benjamin's implementation already does and disable the dots.
That separate x-ray views for object and edit modes would be a welcome addition is not in question - they certainly would. But those have **nothing** to do with **this** design task. At all.
Tool Settings; Under Options, add a new "Select" panel, and store this setting there. That new panel will come useful for future design tasks, as there are other selection-related globals that Blender would benefit from down the line (e.g. selecting by angle, to which existing Select Linked Flat faces is highly inadequate; but that's for another task).
Which selection tools/operators should use this?
All bulk selection operators, that is box, lasso, circle. Click selection/tweak tool should stick to non-occluded geometry unless wireframe/x-ray modes are enabled.
Which modes this should be supported in (edit, pose, grease pencil... etc)
Except object mode, all other modes where occluded/non-occluded selection is applicable.
How to display this option when in wire-frame display (when the user will always select-through)
Option 1: gray out or hide the setting, meaning the setting has no effect in wireframe.
Option 2: allow the setting to have an effect, disabling face dots (and face dot selection requirement) if it's enabled, reverting to regular wireframe if it's disabled.
How to access this from both active-tools & key-bindings?
No need. This setting would be adjusted rarely.
How to make it obvious selecting-trough is enabled (draw style, cursor - this might help avoid confusion).
As proposed by @Debuk above, additional mouse pointer icons. Alternative selection color scheme (themed) could be an option as well.
Should this be supported in object mode too?(the reverse since objects already select-through, relates to #64281: Option to lasso-select using geometry instead of object centers.), IIRC we discussed having this option for box select too
No. Object mode should be solved separately.
To the task at hand:
> Where this option is stored, accessed?
Tool Settings; Under Options, add a new "Select" panel, and store this setting there. That new panel will come useful for future design tasks, as there are other selection-related globals that Blender would benefit from down the line (e.g. selecting by angle, to which existing Select Linked Flat faces is highly inadequate; but that's for another task).
> Which selection tools/operators should use this?
All bulk selection operators, that is box, lasso, circle. Click selection/tweak tool should stick to non-occluded geometry unless wireframe/x-ray modes are enabled.
> Which modes this should be supported in (edit, pose, grease pencil... etc)
Except object mode, all other modes where occluded/non-occluded selection is applicable.
> How to display this option when in wire-frame display (when the user will always select-through)
Option 1: gray out or hide the setting, meaning the setting has no effect in wireframe.
Option 2: allow the setting to have an effect, disabling face dots (and face dot selection requirement) if it's enabled, reverting to regular wireframe if it's disabled.
> How to access this from both active-tools & key-bindings?
No need. This setting would be adjusted rarely.
> How to make it obvious selecting-trough is enabled (draw style, cursor - this might help avoid confusion).
As proposed by @Debuk above, additional mouse pointer icons. Alternative selection color scheme (themed) could be an option as well.
> Should this be supported in object mode too?(the reverse since objects already select-through, relates to #64281: Option to lasso-select using geometry instead of object centers.), IIRC we discussed having this option for box select too
No. Object mode should be solved separately.
In #73479#861538, @1D_Inc wrote:
Nice move) Indeed, this task require a lot of workflow design for different cases.
How to make it obvious selecting-trough is enabled
There is no proper solution for this. The problem is that such mode is far from self-explanatory by definition.
It can be some tiny gui element that you constantly will look on to check if it is enabled or not, or draw something around cursor/change it's shape , like in other programs.
Agree there isn't an obvious one-right-way, perhaps changing the color of the border or lasso help, cursor etc. Just suggestions - so users have a hint the behavior is modified if the option isn't in front of them.
Should this be supported in object mode too?
All this time already works in the object mode. Do you mean - vice versa - provide the ability to limit selection with visible for object mode? That's actually interesting.
Right, updated the main task.
In #73479#861699, @serhatErgen wrote:
So blender's current paradigm already fails on loop and ring selection. While selecting a loop you don't really see what's being selected until you rotate your view to other side. Also same for select all and select linked selects everything on active context even you don't see any of them. And in many situation (like topological problems), loop selection may fail.
But even though there is no topological problem, how 'you select what you can see` paradigm applies to loop, ring, select all, select linked selection commands? If they are counted as an exception, why wouldn't be another one as long as it's toggle-able?
The main issue, is that this option conflicts with Blender's current paradigm, which is 'you select what you can see'.
This is not true.
Box select already selects hidden objects. And it works great.
Seleting things in the outliner selects things hidden in 3d view
Select all selects hidden elements
While technically true, I don't think this is a reasonable argument, The same could be said for select-linked, select-all, select-more... Border and lasso select are projecting selected elements in screen-space, which is different to topology based selection functions.
How to make it obvious selecting-trough is enabled
The selection-color for vertices, edges and faces could change if select-trough is turned on.
Changing selection color is fraught with a surprising number of problems, we ran into this when tweaking the theme color early in 2.80, Since we already have color for edge crease, sharpness, selected .. selected-active. I would leave the selection color alone.
The cursor get a small rendition of what selection mode is chosen and the color of that could change accordingly to the current mode.
Distinguishing between "select trough" and"select visible" with additional symbols next to the cursor would be possible too, but this way it's cleaner and I don't think it's needed. People who activated it and forgot about the what was active mode get a feedback by the selection color, that's all what is needed I think.
From my point of view (Maya old-timer) a simple checkbox in the preferences (maybe in the Editing section) to turn it globally on/off is enough.
I think you either use it all the time or you don't use it at all.
In Maya there is a checkbox in the preferences called "Camera-based selection", select only what's visible like currently in Blender. I haven't see anyone use it though :)
This means you cant quickly change it, as part of your work-flow, basically whatever the default is - is all most users will ever know.
Which selection tools/operators should use this?
"Select Through" is only for Box select and Lasso select.
Circle select and Click select are not affected. In Maya paint select (circle select) selects only what is on the front surface even if you are in wireframe mode.
This seems like you're just suggesting Blender copy other software, without justifying why - besides other software having many users.
How to display this option when in wire-frame display (when the user will always select-through)
How to access this from both active-tools & key-bindings?
How to make it obvious selecting-trough is enabled (draw style, cursor - this might help avoid confusion).
I think if its a preferences option no other changes are needed.
I assume you would have this enabled by default too, this is quite a big change.
You need to be more spesific tool settings are displayed in multiple places.
Your other points seem reasonable.
In #73479#861995, @CobraA wrote:
This "feature" is only useful in Edit mode and it conflicts with xray which already does the job, but the problem with xray is that you have to fiddle with the slider. for example in Object mode you want it 0.5 but in edit mode u need it at 1.0.
So the obvious solution is xray needs preset values or a way to set it per mode, no need to add more extra options and subsequently a hoykey if it can be solved by an existent one.
This seems more like a usability issue with X-ray, agree different values are preferable in object/edit mode.
However adding options because current features have poor usability is something I'd rather avoid.
In #73479#862023, @ThinkingPolygons wrote: @Oskar3d@z01ks@CobraA@1D_Inc
Guys look, this is a tool setting and needs to be implemented like -> this
Nothing more, nothing less. No need for endless debate. It's that simple.
It's not so simple. How would this be accessed for selection via key bindings?
In #73479#862148, @Stan_Pancakes wrote:
To whomever saying that this is exactly what current x-ray does in Blender: it's not, due to one key difference which is face dots.
While somewhat related, this complicates discussion significantly.
We could change selection behavior regarding face-dots with/without select-through.
For that reason I rather keep this out of the discussion.
In #73479#862148, @Stan_Pancakes wrote:
How do you select half a cylinder in Blender currently?
position view accordingly
enable x-ray/wireframe
carefully drag a box selection making sure that all dots are encompassed
disable x-ray/wireframe
How is it done with "select through" enabled?
position view accordingly
drag a box selection encompassing just the quarter facing you, quite lazily; the only thing to make sure is that you don't cross an extra face from the other quarter with your box, which is not a problem at all
Two fewer steps, and much less precision and stress required. The comparison is valid, as in current Blender X-ray/wireframe is normally disabled, while if "select through" option existed, it would be normally enabled. Later, when the model becomes more complex, one may turn the setting off.
You could make the same argument for how difficult it is to move a vertex.
enter edit-mode.
drag the vertex.
exit-edit mode.
... In practice you almost never do that, similar with view options. You can tap Alt-Z to enable X-ray... make the selection, and keep working. While it's possible you need to immediately disable it, this is the case for most options which toggle behavior.
We should be conscious of the burden of adding options for users too, that there are settings which control selection which users need to carry round in there head (as we can't have all settings visible at all times).
Blender developers have to review bug reports from users who change settings and manage to end up in confusing situations. Or load files from someone else who left the settings in a non-standard configuration - and think it's a bug in Blender. I can only assume not every user that runs into these problems reports bugs. So keep in mind there is a 'cost' to adding options which tends not to be taken into account when users propose adding additional features.
I believe we're experiencing this with some of the 2.8x features - X-ray geometry fading slider for example. Something already raised in replies to this task,
> In #73479#861538, @1D_Inc wrote:
> Nice move) Indeed, this task require a lot of workflow design for different cases.
>
>> How to make it obvious selecting-trough is enabled
>
> There is no proper solution for this. The problem is that such mode is far from self-explanatory by definition.
> It can be some tiny gui element that you constantly will look on to check if it is enabled or not, or [draw something around cursor/change it's shape ](https://blender.community/c/rightclickselect/wgfbbc/), like in other programs.
Agree there isn't an obvious one-right-way, perhaps changing the color of the border or lasso help, cursor etc. Just suggestions - so users have a hint the behavior is modified if the option isn't in front of them.
>> Should this be supported in object mode too?
>
> All this time already works in the object mode. Do you mean - vice versa - provide the ability to limit selection with visible for object mode? That's actually interesting.
Right, updated the main task.
----
> In #73479#861699, @serhatErgen wrote:
> So blender's current paradigm already fails on loop and ring selection. While selecting a loop you don't really see what's being selected until you rotate your view to other side. Also same for select all and select linked selects everything on active context even you don't see any of them. And in many situation (like topological problems), loop selection may fail.
>
> But even though there is no topological problem, how 'you select what you can see` paradigm applies to loop, ring, select all, select linked selection commands? If they are counted as an exception, why wouldn't be another one as long as it's toggle-able?
Also...
> In #73479#861717, @Debuk wrote:
>> The main issue, is that this option conflicts with Blender's current paradigm, which is 'you select what you can see'.
>
> This is not true.
> - Box select already selects hidden objects. And it works great.
> - Seleting things in the outliner selects things hidden in 3d view
> - Select all selects hidden elements
While technically true, I don't think this is a reasonable argument, The same could be said for select-linked, select-all, select-more... Border and lasso select are projecting selected elements in screen-space, which is different to topology based selection functions.
----
> In #73479#861727, @Debuk wrote:
>>How to make it obvious selecting-trough is enabled
>
> The selection-color for vertices, edges and faces could change if select-trough is turned on.
Changing selection color is fraught with a surprising number of problems, we ran into this when tweaking the theme color early in 2.80, Since we already have color for edge crease, sharpness, selected .. selected-active. I would leave the selection color alone.
> The cursor get a small rendition of what selection mode is chosen and the color of that could change accordingly to the current mode.
>
> 
>
> Distinguishing between "select trough" and"select visible" with additional symbols next to the cursor would be possible too, but this way it's cleaner and I don't think it's needed. People who activated it and forgot about the what was active mode get a feedback by the selection color, that's all what is needed I think.
Seems a reasonable option.
----
> In #73479#861818, @Oskar3d wrote:
>> * Where this option is stored, accessed?
>
> From my point of view (Maya old-timer) a simple checkbox in the preferences (maybe in the Editing section) to turn it globally on/off is enough.
> I think you either use it all the time or you don't use it at all.
> In Maya there is a checkbox in the preferences called "Camera-based selection", select only what's visible like currently in Blender. I haven't see anyone use it though :)
This means you cant quickly change it, as part of your work-flow, basically whatever the default is - is all most users will ever know.
>> * Which selection tools/operators should use this?
>
> "Select Through" is only for Box select and Lasso select.
> Circle select and Click select are not affected. In Maya paint select (circle select) selects only what is on the front surface even if you are in wireframe mode.
>
This seems like you're just suggesting Blender copy other software, without justifying why - besides other software having many users.
>> * How to display this option when in wire-frame display (when the user will always select-through)
>> * How to access this from both active-tools & key-bindings?
>> * How to make it obvious selecting-trough is enabled (draw style, cursor - this might help avoid confusion).
>
> I think if its a preferences option no other changes are needed.
I assume you would have this enabled by default too, this is quite a big change.
----
> In #73479#861847, @TheRedWaxPolice wrote:
>> Where this option is stored, accessed?
>
> Tool Settings (checkbox).
You need to be more spesific tool settings are displayed in multiple places.
Your other points seem reasonable.
----
> In #73479#861995, @CobraA wrote:
> This "feature" is only useful in Edit mode and it conflicts with xray which already does the job, but the problem with xray is that you have to fiddle with the slider. for example in Object mode you want it 0.5 but in edit mode u need it at 1.0.
> So the obvious solution is xray needs preset values or a way to set it per mode, no need to add more extra options and subsequently a hoykey if it can be solved by an existent one.
This seems more like a usability issue with X-ray, agree different values are preferable in object/edit mode.
However adding options because current features have poor usability is something I'd rather avoid.
----
> In #73479#862023, @ThinkingPolygons wrote:
> @Oskar3d @z01ks @CobraA @1D_Inc
> Guys look, this is a tool setting and needs to be implemented like -> [this ](http://i.imgur.com/hhBJVuS.gif)
> Nothing more, nothing less. No need for endless debate. It's that simple.
It's not so simple. How would this be accessed for selection via key bindings?
----
> In #73479#862148, @Stan_Pancakes wrote:
> To whomever saying that this is exactly what current x-ray does in Blender: it's not, due to one key difference which is face dots.
While somewhat related, this complicates discussion significantly.
We could change selection behavior regarding face-dots with/without select-through.
For that reason I rather keep this out of the discussion.
----
> In #73479#862148, @Stan_Pancakes wrote:
> How do you select half a cylinder in Blender currently?
> - position view accordingly
> - enable x-ray/wireframe
> - carefully drag a box selection making sure that all dots are encompassed
> - disable x-ray/wireframe
>
> How is it done with "select through" enabled?
> - position view accordingly
> - drag a box selection encompassing just the quarter facing you, quite lazily; the only thing to make sure is that you don't cross an extra face from the other quarter with your box, which is not a problem at all
>
> Two fewer steps, and much less precision and stress required. The comparison is valid, as in current Blender X-ray/wireframe is normally disabled, while if "select through" option existed, it would be normally enabled. Later, when the model becomes more complex, one may turn the setting off.
You could make the same argument for how difficult it is to move a vertex.
- enter edit-mode.
- drag the vertex.
- exit-edit mode.
... In practice you almost never do that, similar with view options. You can tap Alt-Z to enable X-ray... make the selection, and keep working. While it's possible you need to immediately disable it, this is the case for most options which toggle behavior.
We should be conscious of the burden of adding options for users too, that there are settings which control selection which users need to carry round in there head (as we can't have all settings visible at all times).
Blender developers have to review bug reports from users who change settings and manage to end up in confusing situations. Or load files from someone else who left the settings in a non-standard configuration - and think it's a bug in Blender. I can only assume not every user that runs into these problems reports bugs. So keep in mind there is a 'cost' to adding options which tends not to be taken into account when users propose adding additional features.
I believe we're experiencing this with some of the 2.8x features - X-ray geometry fading slider for example. Something already raised in replies to this task,
In #73479#862148, @Stan_Pancakes wrote:
To whomever saying that this is exactly what current x-ray does in Blender: it's not, due to one key difference which is face dots.
While somewhat related, this complicates discussion significantly.
We could change selection behavior regarding face-dots with/without select-through.
For that reason I rather keep this out of the discussion.
How does it complicate the discussion, exactly? Let me try expressing this once more: existing x-ray and wireframe modes, as they are in Blender right now, are not a substitute for select-through. Select-through is needed for cases when you do not even need to see the occluded geometry, and to select faces without having to hunt for dots: simple intersection with the box/lasso is all that's needed for both occluded and unoccluded geometry. The arguments such as "just use x-ray for this" or that "you can't see what you select" are inapplicable here: the whole point is to not even have to see it. When you already know what you're selecting, you don't need a special shading mode. While accidental selections with this setting are indeed possible, they're no more frequent than accidental selections with, say, existing click-selection in Blender (e.g. when clicking close to two edges, either one might be selected). They are not an issue so long as user understands what they're doing. And when they don't - they can "accidentally" toggle all sorts of things and start reporting not-a-bugs.
Two fewer steps, and much less precision and stress required. The comparison is valid, as in current Blender X-ray/wireframe is normally disabled, while if "select through" option existed, it would be normally enabled. Later, when the model becomes more complex, one may turn the setting off.
You could make the same argument for how difficult it is to move a vertex.
enter edit-mode.
drag the vertex.
exit-edit mode.
... In practice you almost never do that, similar with view options. You can tap Alt-Z to enable X-ray... make the selection, and keep working. While it's possible you need to immediately disable it, this is the case for most options which toggle behavior.
No, this is not at all equivalent. I've said this probably four times already: select-through, for people that would use it, would be a setting that is normally enabled. For prolonged periods of time. With your analogy that means you're already in edit mode, have been for some time, will not be exiting edit mode any time soon, and all you have to do to move a vertex is select it and move it, or tweak it. That's it.
You will be working in solid mode. You will be selecting non-occluded geometry predominantly with click-selections, ring/loop/path selections, expansion/conversion, and other operators. You will be using box, lasso and circle knowingly, relying on the fact that those would select through the object. You will not have to switch shading modes just to have the ability to box-select occluded geometry. You will not have to stare at quite messy x-ray or wireframe views sprinkled with face dots just to have the ability to box-select occluded geometry. At some point your model will become sufficiently complex such that you'd be relying more on un-occluded selection, that's when you simply turn the setting off. Or split it into pieces and keep working as is.
We should be conscious of the burden of adding options for users too, that there are settings which control selection which users need to carry round in there head (as we can't have all settings visible at all times).
Of course.
Blender developers have to review bug reports from users who change settings and manage to end up in confusing situations... So keep in mind there is a 'cost' to adding options which tends not to be taken into account when users propose adding additional features.
Of course there is. Which is why it's important to establish what it is that's being proposed, before weighing all the pros and cons. Dismissing it because it's "like x-ray with value of 1.0", like some people suggested, when it clearly isn't, is just counter-productive.
It's not so simple. How would this be accessed for selection via key bindings?
You keep bringing this up and I don't understand the question. Which key bindings do you mean? This is a "global", if you will, that would affect behavior of box, lasso and circle select tools. No access via keybindings required. Similar to Auto-Merge: the setting is there, you adjust it rarely on an as-needed basis.
> In #73479#862402, @ideasman42 wrote:
>> In #73479#862148, @Stan_Pancakes wrote:
>> To whomever saying that this is exactly what current x-ray does in Blender: it's not, due to one key difference which is face dots.
>
> While somewhat related, this complicates discussion significantly.
>
> We could change selection behavior regarding face-dots with/without select-through.
>
> For that reason I rather keep this out of the discussion.
How does it complicate the discussion, exactly? Let me try expressing this once more: existing x-ray and wireframe modes, __as they are in Blender right now__, are not a substitute for select-through. Select-through is needed for cases when you do not even need to see the occluded geometry, and to select faces without having to hunt for dots: simple intersection with the box/lasso is all that's needed for both occluded and unoccluded geometry. The arguments such as "just use x-ray for this" or that "you can't see what you select" are inapplicable here: the whole point is **to not even have to** see it. When you already know what you're selecting, you don't need a special shading mode. While accidental selections with this setting are indeed possible, they're no more frequent than accidental selections with, say, existing click-selection in Blender (e.g. when clicking close to two edges, either one might be selected). They are not an issue so long as user understands what they're doing. And when they don't - they can "accidentally" toggle all sorts of things and start reporting not-a-bugs.
>> Two fewer steps, and much less precision and stress required. The comparison is valid, as in current Blender X-ray/wireframe is normally disabled, while if "select through" option existed, it would be normally enabled. Later, when the model becomes more complex, one may turn the setting off.
>
> You could make the same argument for how difficult it is to move a vertex.
>
> - enter edit-mode.
> - drag the vertex.
> - exit-edit mode.
>
> ... In practice you almost never do that, similar with view options. You can tap Alt-Z to enable X-ray... make the selection, and keep working. While it's possible you need to immediately disable it, this is the case for most options which toggle behavior.
No, this is not at all equivalent. I've said this probably four times already: select-through, for people that would use it, would be a setting that is normally enabled. For prolonged periods of time. With your analogy that means you're already in edit mode, have been for some time, will not be exiting edit mode any time soon, and all you have to do to move a vertex is select it and move it, or tweak it. That's it.
You will be working in solid mode. You will be selecting non-occluded geometry predominantly with click-selections, ring/loop/path selections, expansion/conversion, and other operators. You will be using box, lasso and circle **knowingly**, **relying** on the fact that those would select through the object. You will not have to switch shading modes __just to have the ability__ to box-select occluded geometry. You will not have to stare at quite messy x-ray or wireframe views sprinkled with face dots __just to have the ability__ to box-select occluded geometry. At some point your model will become sufficiently complex such that you'd be relying more on un-occluded selection, that's when you simply turn the setting off. Or split it into pieces and keep working as is.
> We should be conscious of the burden of adding options for users too, that there are settings which control selection which users need to carry round in there head (as we can't have all settings visible at all times).
Of course.
> Blender developers have to review bug reports from users who change settings and manage to end up in confusing situations... So keep in mind there is a 'cost' to adding options which tends not to be taken into account when users propose adding additional features.
Of course there is. Which is why it's important to establish what it is that's being proposed, before weighing all the pros and cons. Dismissing it because it's "like x-ray with value of 1.0", like some people suggested, when it clearly isn't, is just counter-productive.
> It's not so simple. How would this be accessed for selection via key bindings?
You keep bringing this up and I don't understand the question. Which key bindings do you mean? This is a "global", if you will, that would affect behavior of box, lasso and circle select tools. No access via keybindings required. Similar to Auto-Merge: the setting is there, you adjust it rarely on an as-needed basis.
In #73479#862148, @Stan_Pancakes wrote:
To whomever saying that this is exactly what current x-ray does in Blender: it's not, due to one key difference which is face dots.
While somewhat related, this complicates discussion significantly.
We could change selection behavior regarding face-dots with/without select-through.
For that reason I rather keep this out of the discussion.
How does it complicate the discussion, exactly?
Because changing this behavior has it's own sets of pros and cons which need to be discussed.
It's not so simple. How would this be accessed for selection via key bindings?
You keep bringing this up and I don't understand the question. Which key bindings do you mean? This is a "global", if you will, that would affect behavior of box, lasso and circle select tools. No access via keybindings required. Similar to Auto-Merge: the setting is there, you adjust it rarely on an as-needed basis.
If this is always available in the "Options" popover, as you say, it can work - however this isn't what was proposed, in both the patch submission and video linked from the statement I was replying to - it was an option for an active tool.
> In #73479#862441, @Stan_Pancakes wrote:
>> In #73479#862402, @ideasman42 wrote:
>>> In #73479#862148, @Stan_Pancakes wrote:
>>> To whomever saying that this is exactly what current x-ray does in Blender: it's not, due to one key difference which is face dots.
>>
>> While somewhat related, this complicates discussion significantly.
>>
>> We could change selection behavior regarding face-dots with/without select-through.
>>
>> For that reason I rather keep this out of the discussion.
>
> How does it complicate the discussion, exactly?
Because changing this behavior has it's own sets of pros and cons which need to be discussed.
>> It's not so simple. How would this be accessed for selection via key bindings?
>
> You keep bringing this up and I don't understand the question. Which key bindings do you mean? This is a "global", if you will, that would affect behavior of box, lasso and circle select tools. No access via keybindings required. Similar to Auto-Merge: the setting is there, you adjust it rarely on an as-needed basis.
If this is always available in the "Options" popover, as you say, it can work - however this isn't what was proposed, in both the patch submission and video linked from the statement I was replying to - it was an option for an active tool.
@ideasman42 there is no need for a change in behavior. This is new behavior. Like I mentioned, existing wireframe and x-ray could just stay as they are and ignore/gray out/hide the new setting when they're enabled.
@ideasman42 there is no need for a change in behavior. This is **new** behavior. Like I mentioned, existing wireframe and x-ray could just stay as they are and ignore/gray out/hide the new setting when they're enabled.
Campbell Barton
changed title from 3D View Select Through (design task) to 3D View Selection Occlusion (Select Through) 2020-01-30 02:38:57 +01:00
In #73479#862402, @ideasman42 wrote:
... In practice you almost never do that, similar with view options. You can tap Alt-Z to enable X-ray... make the selection, and keep working. While it's possible you need to immediately disable it, this is the case for most options which toggle behavior.
We should be conscious of the burden of adding options for users too, that there are settings which control selection which users need to carry round in there head (as we can't have all settings visible at all times).
I completely agree here and what you have mentioned on the patch thread too, that's why i am more on the conservative side because you raised good points for a user point of view.
> In #73479#862402, @ideasman42 wrote:
> ... In practice you almost never do that, similar with view options. You can tap Alt-Z to enable X-ray... make the selection, and keep working. While it's possible you need to immediately disable it, this is the case for most options which toggle behavior.
>
> We should be conscious of the burden of adding options for users too, that there are settings which control selection which users need to carry round in there head (as we can't have all settings visible at all times).
I completely agree here and what you have mentioned on the patch thread too, that's why i am more on the conservative side because you raised good points for a user point of view.
@ideasman42 ok this discussion exploded quickly - so I just wanted to add a few thoughts from my perspective while I wrote that patch..
I come from a background of doing 3d game art oursourcing, so we have almost complete control over the meshes we produce here. Most of the stuff we do are meshes ->bevel via a modifier and subd on top. The input meshes are often not all that complex / dense. So this is probably also an explanation why for instance @1D_Inc has so different requirements, as they seem to deal with very dense, and messy geometry.
Actually I'd be happy to just add such a selection behaviour with an addon, but this is such a computing intensive problem that its really not feasable to solve this that way. Maybe if BMesh would support foreach_get/foreach_set methods one could achive workable speeds for this tho - so instead of changing this on the application level, just create some more sophisiticated apis and let the users deal with this.
First off some answers from the other ticket:
Even in the case when the user knows this is enabled, there is some chance for accidents - as the result of the selection may be unexpected, any tools that run afterwards may operate on an unexpected result.
Well, true but there are lots of tools which have a high chance of accidents. While its indeed better to not add more of this - it could be mitigiated with somehow draw all the selected elements.
This interferes with edit-mesh drawing, removing face dots so it's not clear if you're in face select mode or not.
Well we dont have face dots on regular non x-ray mode and its not an issue..
How to access this from both active-tools & key-bindings?
This is a good question, I placed it on the active tools because it felt quite fitting there. I do understand that its not really correct though - it might fit more to the other 'options' panel with mirror/automerge etc. But to me this felt too much like a feature hotpot there as, its already a weird mix of stuff.
How to make it obvious selecting-trough is enabled?
I did not care much about this, as Im just used to this behaviour for years.
But sure that is an area which would benefit from icons and/or different selection border drawing. There is also the idea to just draw the occluded selected elements too. But i guess this would need a fair bit of tinkering to come up with a solution which works with all the modes.
The issue is that there is an inherent conflict. If you check the patch, you can disable Select Through, which means it should only select front faces. But if you switch to Wireframe or X-ray modes, it will still select through, even though the user turned off Select Through. The way it works in the patch, is that it's essentially 'select through even if something is not visible', and it only works one way - having Select Through set to Off doesn't ensure that > you won't select through.
I agree this feels a bit weak, but this is mostly because I wanted to avoid altering the current selection behaviour. Its actually simple to connect that in whatever way we want..
Anyhow Im curious to see if something will come out of this..
@ideasman42 ok this discussion exploded quickly - so I just wanted to add a few thoughts from my perspective while I wrote that patch..
I come from a background of doing 3d game art oursourcing, so we have almost complete control over the meshes we produce here. Most of the stuff we do are meshes ->bevel via a modifier and subd on top. The input meshes are often not all that complex / dense. So this is probably also an explanation why for instance @1D_Inc has so different requirements, as they seem to deal with very dense, and messy geometry.
Actually I'd be happy to just add such a selection behaviour with an addon, but this is such a computing intensive problem that its really not feasable to solve this that way. Maybe if BMesh would support foreach_get/foreach_set methods one could achive workable speeds for this tho - so instead of changing this on the application level, just create some more sophisiticated apis and let the users deal with this.
First off some answers from the other ticket:
> Even in the case when the user knows this is enabled, there is some chance for accidents - as the result of the selection may be unexpected, any tools that run afterwards may operate on an unexpected result.
Well, true but there are lots of tools which have a high chance of accidents. While its indeed better to not add more of this - it could be mitigiated with somehow draw all the selected elements.
> This interferes with edit-mesh drawing, removing face dots so it's not clear if you're in face select mode or not.
Well we dont have face dots on regular non x-ray mode and its not an issue..
> How to access this from both active-tools & key-bindings?
This is a good question, I placed it on the active tools because it felt quite fitting there. I do understand that its not really correct though - it might fit more to the other 'options' panel with mirror/automerge etc. But to me this felt too much like a feature hotpot there as, its already a weird mix of stuff.
> How to make it obvious selecting-trough is enabled?
I did not care much about this, as Im just used to this behaviour for years.
But sure that is an area which would benefit from icons and/or different selection border drawing. There is also the idea to just draw the occluded selected elements too. But i guess this would need a fair bit of tinkering to come up with a solution which works with all the modes.
Could look something like this:
@WilliamReynish
> The issue is that there is an inherent conflict. If you check the patch, you can disable Select Through, which means it should only select front faces. But if you switch to Wireframe or X-ray modes, it *will* still select through, even though the user turned off Select Through. The way it works in the patch, is that it's essentially 'select through even if something is not visible', and it only works one way - having Select Through set to Off doesn't ensure that > you won't select through.
I agree this feels a bit weak, but this is mostly because I wanted to avoid altering the current selection behaviour. Its actually simple to connect that in whatever way we want..
---
Anyhow Im curious to see if something will come out of this..
I come from a background of doing 3d game art oursourcing, so we have almost complete control over the meshes we produce here. Most of the stuff we do are meshes ->bevel via a modifier and subd on top. The input meshes are often not all that complex / dense. So this is probably also an explanation why for instance @1D_Inc has so different requirements, as they seem to deal with very dense, and messy geometry.
Yes, this is a matter of priorities.
We are not against adding Select Through ability to Blender as an accessible option, but its design should not violate existing capabilities, since it depends on the specific case of the workflow.
> In #73479#862583, @kioku wrote:
> I come from a background of doing 3d game art oursourcing, so we have almost complete control over the meshes we produce here. Most of the stuff we do are meshes ->bevel via a modifier and subd on top. The input meshes are often not all that complex / dense. So this is probably also an explanation why for instance @1D_Inc has so different requirements, as they seem to deal with very dense, and messy geometry.
Yes, this is a matter of priorities.
We are not against adding Select Through ability to Blender as an accessible option, but its design should not violate existing capabilities, since it depends on the specific case of the workflow.
This interferes with edit-mesh drawing, removing face dots so it's not clear if you're in face select mode or not.
Well we dont have face dots on regular non x-ray mode and its not an issue..
In non x-ray mode this is communicated with wire thickness and changes to highlight intensity of edges/faces.
> In #73479#862583, @kioku wrote:
>> This interferes with edit-mesh drawing, removing face dots so it's not clear if you're in face select mode or not.
> Well we dont have face dots on regular non x-ray mode and its not an issue..
In non x-ray mode this is communicated with wire thickness and changes to highlight intensity of edges/faces.
I agree this feels a bit weak, but this is mostly because I wanted to avoid altering the current selection behaviour. Its actually simple to connect that in whatever way we want..
Anyhow Im curious to see if something will come out of this..
The thing is, I simply don't know of a way to resolve that conflict in a reasonable way. There would need to be some sort of toggle or switch to say 'stop selecting the items that are visible - instead use the Select Through toggle and ignore X-ray, Wireframe or other things' - and only show the Select Through toggle in that case. But to me that's very weak and messy.
In principle I am not against adding a Select Through toggle, but am not happy with adding lots of complexity to handle this conflict in behavior. Of course if we can think of a good/reasonable solution then it probably will be fine, so as far as I am concerned that is the main obstacle.
> In #73479#862583, @kioku wrote:
>
> I agree this feels a bit weak, but this is mostly because I wanted to avoid altering the current selection behaviour. Its actually simple to connect that in whatever way we want..
>
> Anyhow Im curious to see if something will come out of this..
The thing is, I simply don't know of a way to resolve that conflict in a reasonable way. There would need to be some sort of toggle or switch to say 'stop selecting the items that are visible - instead use the Select Through toggle and ignore X-ray, Wireframe or other things' - and only show the Select Through toggle in that case. But to me that's very weak and messy.
In principle I am not against adding a Select Through toggle, but am not happy with adding lots of complexity to handle this conflict in behavior. Of course if we can think of a good/reasonable solution then it probably will be fine, so as far as I am concerned that is the main obstacle.
Alternatively we could make a change to X-ray mode so you have a way to make it not show backfiring geometry at all. It could also become easier to toggle via the Z-key.
Making improvements and changes to X-ray can help us avoid the conflicting collision in behavior.
Alternatively we could make a change to X-ray mode so you have a way to make it not show backfiring geometry at all. It could also become easier to toggle via the Z-key.
Making improvements and changes to X-ray can help us avoid the conflicting collision in behavior.
While technically true, I don't think this is a reasonable argument, The same could be said for select-linked, select-all, select-more... Border and lasso select are projecting selected elements in screen-space, which is different to topology based selection functions.
Yes thats not the same technically, but so your argumentation is rather on the technical side and is about categorizing it based on technical approaches. William was speaking of a sort of global philosophy for blender, and that philosophy is already broken. Technical reasons like being based on screenspace calcuations or topological queries may define restricted possibilities but should not define paradigms for what the ux should be. They may correlate per incident though. But after all technical reasons are unimportant from a users perspective. That was my point. But overall this is not the most important thing though.
For some reasons we partially don't get to the how and stick to the why. Why should we include this in blender if it already can be done?
Because the proposed change is capable to eliminate some of the existing drawbacks.
And that while it is possible to respect the current way of doing it. It does neither replace it nor can't it be combined. And it is already implemented to a large degree, thanks to @kioku. It helps at a very central element of a DCC, the selection behaviour, and aligns it better with other tools out there. And this helps the users with multiple DCCs. And it serves blenders needs. It make switching to blender easier and more attractive by respecting defacto standards out there. And in the long run this should raise funds and the number of volunteers and core developers.
But beside this its mainly about existing drawbacks. So let me rephrase some of these drawbacks once more:
Wireframe and X-Ray are the only modes where Select-Through is possible right now.
In both modes we are not talking of hidden lines we have all backwires of the active object.
The real wireframe mode is the one with the most drawbacks.
Any sort of depth information is gone as any surface shading is taken away.
Wires and Backwires overlap
FaceDots are present
Lines are darker and more prominent.
Objects whose projections to the viewplane collide with the current mesh make readability even worse
And it's also partly true for the X-Ray mode.
Semitransparent shading increases that here and dense meshes also kill the shading information. Shapes are harder read for the user.
In Semitransparent shading options behind the current one also let the shading disappear.
FaceDots are also present also for opacity 1
Backwires are overlapping with Frontwires also for opacity 1
Lines are darker
During a box and lasso selection the image typically stands still, an the longer you are selecting portions that the knowledge which edge is foreground and which one is background fades from memory.
Working on nonconcave objects makes that even worse.
Obviously there are quite some of your users who are accustomed to work that way. And it also seems the case that there are usescases where all is ok as it is. But that's not true for others.
Don't get me wrong I also can see some cases where I find eg. face dots really good. They are indeed the only possibility to decide if something is an intended backface-selection click. But personally this is far from the most typical case for me, that I really want to make a backface click and that it couldn't get selected differently. I'd wish for this facedots that I could just activate them with a sticky key held down during a selection. And for deactivating facedots, selecting based on overlap with the selection marker is preferred over face centers.
The thing is that while I am selecting something, my main concern is to get a totally different problem solved. I am working on an object, I am concerned about details, shapes, forms or topology. And then I have to switch to one of these Look-Through modes, but for my intended task at that time that's not a good choice. And I really don't want an x-ray view permanently.
I always get the feel that we are all struggling to communicate this problem clearly. I hope this makes clear that it's not about copying. It's about making something better, and as using a defacto standard is not the worst idea from a users perspective if that solves the problem.
For these problems its a good alternative what is proposed here. It's working on different viewportshading types than the current one. They don't interfere. It works in preferable modes where the viewport is not drawing hidden lines, where there are thinner greyish lines during edits. If I want to box select part of mesh I select through, check with a flick if everything seems ok and continue with the intended edit. For creative workflows on models this is a favorable approach. I can respect everyone here who has other topics he works on and there it might not interfere as much. But I also don't want to take away anything for them, nor do i want to copy another app.
I think with some small changes we might have a fitting solution that combines the current way and the proposed one to fit all needs. That's how I see it.
>While technically true, I don't think this is a reasonable argument, The same could be said for select-linked, select-all, select-more... Border and lasso select are projecting selected elements in screen-space, which is different to topology based selection functions.
Yes thats not the same technically, but so your argumentation is rather on the technical side and is about categorizing it based on technical approaches. William was speaking of a sort of global philosophy for blender, and that philosophy is already broken. Technical reasons like being based on screenspace calcuations or topological queries may define restricted possibilities but should not define paradigms for what the ux should be. They may correlate per incident though. But after all technical reasons are unimportant from a users perspective. That was my point. But overall this is not the most important thing though.
For some reasons we partially don't get to the how and stick to the why.
**Why should we include this in blender if it already can be done?**
Because the proposed change is capable to eliminate some of the existing drawbacks.
And that while it is possible to respect the current way of doing it. It does neither replace it nor can't it be combined. And it is already implemented to a large degree, thanks to @kioku. It helps at a very central element of a DCC, the selection behaviour, and aligns it better with other tools out there. And this helps the users with multiple DCCs. And it serves blenders needs. It make switching to blender easier and more attractive by respecting defacto standards out there. And in the long run this should raise funds and the number of volunteers and core developers.
But beside this its mainly about existing drawbacks. So let me rephrase some of these drawbacks once more:
Wireframe and X-Ray are the only modes where Select-Through is possible right now.
In both modes we are not talking of hidden lines we have all backwires of the active object.
The real wireframe mode is the one with the most drawbacks.
- Any sort of depth information is gone as any surface shading is taken away.
- Wires and Backwires overlap
- FaceDots are present
- Lines are darker and more prominent.
- Objects whose projections to the viewplane collide with the current mesh make readability even worse
And it's also partly true for the X-Ray mode.
- Semitransparent shading increases that here and dense meshes also kill the shading information. Shapes are harder read for the user.
- In Semitransparent shading options behind the current one also let the shading disappear.
- FaceDots are also present also for opacity 1
- Backwires are overlapping with Frontwires also for opacity 1
- Lines are darker
---
- During a box and lasso selection the image typically stands still, an the longer you are selecting portions that the knowledge which edge is foreground and which one is background fades from memory.
- Working on nonconcave objects makes that even worse.
Obviously there are quite some of your users who are accustomed to work that way. And it also seems the case that there are usescases where all is ok as it is. But that's not true for others.
Don't get me wrong I also can see some cases where I find eg. face dots really good. They are indeed the only possibility to decide if something is an intended backface-selection click. But personally this is far from the most typical case for me, that I really want to make a backface click and that it couldn't get selected differently. I'd wish for this facedots that I could just activate them with a sticky key held down during a selection. And for deactivating facedots, selecting based on overlap with the selection marker is preferred over face centers.
The thing is that while I am selecting something, my main concern is to get a totally different problem solved. I am working on an object, I am concerned about details, shapes, forms or topology. And then I have to switch to one of these Look-Through modes, but for my intended task at that time that's not a good choice. And I really don't want an x-ray view permanently.
I always get the feel that we are all struggling to communicate this problem clearly. I hope this makes clear that it's not about copying. It's about making something better, and as using a defacto standard is not the worst idea from a users perspective if that solves the problem.
For these problems its a good alternative what is proposed here. It's working on different viewportshading types than the current one. They don't interfere. It works in preferable modes where the viewport is not drawing hidden lines, where there are thinner greyish lines during edits. If I want to box select part of mesh I select through, check with a flick if everything seems ok and continue with the intended edit. For creative workflows on models this is a favorable approach. I can respect everyone here who has other topics he works on and there it might not interfere as much. But I also don't want to take away anything for them, nor do i want to copy another app.
I think with some small changes we might have a fitting solution that combines the current way and the proposed one to fit all needs. That's how I see it.
In #73479#862402, @ideasman42 wrote:
Changing selection color is fraught with a surprising number of problems, we ran into this when tweaking the theme color early in 2.80, Since we already have color for edge crease, sharpness, selected .. selected-active. I would leave the selection color alone.
Ok if that is problematic to achieve it makes no sense. The cursor icon change might be enough, but I'd have found it good to have some more prominent visual feedback. Different selection color would have done this.
Is it an option to have these color different colors applied to the lasso line, the box selection marker and the paint select circle itself? If we would color code these for the current modes it might be as good.
> In #73479#862402, @ideasman42 wrote:
>Changing selection color is fraught with a surprising number of problems, we ran into this when tweaking the theme color early in 2.80, Since we already have color for edge crease, sharpness, selected .. selected-active. I would leave the selection color alone.
Ok if that is problematic to achieve it makes no sense. The cursor icon change might be enough, but I'd have found it good to have some more prominent visual feedback. Different selection color would have done this.
Is it an option to have these color different colors applied to the lasso line, the box selection marker and the paint select circle itself? If we would color code these for the current modes it might be as good.
The thing is, I simply don't know of a way to resolve that conflict in a reasonable way. There would need to be some sort of toggle or switch to say 'stop selecting the items that are visible - instead use the Select Through toggle and ignore X-ray, Wireframe or other things' - and only show the Select Through toggle in that case. But to me that's very weak and messy.
The other way around is much more simple: show and use the setting outside of wireframe and/or x-ray. When wireframe and/or x-ray are active, gray it out or hide it, and ignore it. No conflict required. This is not a setting that needs much communication from the UI. While @kioku's implementation does provide special behavior in wireframe/x-ray, it's not at all required, as the whole point of this feature is to not have to switch shading modes just to get the ability to select occluded geometry.
Despite @1D_Inc's self-important "reservations", predictable geometry is not at all that uncommon.
> In #73479#862641, @WilliamReynish wrote:
> The thing is, I simply don't know of a way to resolve that conflict in a reasonable way. There would need to be some sort of toggle or switch to say 'stop selecting the items that are visible - instead use the Select Through toggle and ignore X-ray, Wireframe or other things' - and only show the Select Through toggle in that case. But to me that's very weak and messy.
The other way around is much more simple: show and use the setting outside of wireframe and/or x-ray. When wireframe and/or x-ray are active, gray it out or hide it, and ignore it. No conflict required. This is not a setting that needs much communication from the UI. While @kioku's implementation does provide special behavior in wireframe/x-ray, it's not at all required, as the whole point of this feature is **to not have to switch shading modes** just to get the ability to select occluded geometry.
Despite @1D_Inc's self-important "reservations", predictable geometry is not at all that uncommon.
I agree this feels a bit weak, but this is mostly because I wanted to avoid altering the current selection behaviour. Its actually simple to connect that in whatever way we want..
Anyhow Im curious to see if something will come out of this..
The thing is, I simply don't know of a way to resolve that conflict in a reasonable way. There would need to be some sort of toggle or switch to say 'stop selecting the items that are visible - instead use the Select Through toggle and ignore X-ray, Wireframe or other things' - and only show the Select Through toggle in that case. But to me that's very weak and messy.
In principle I am not against adding a Select Through toggle, but am not happy with adding lots of complexity to handle this conflict in behavior. Of course if we can think of a good/reasonable solution then it probably will be fine, so as far as I am concerned that is the main obstacle.
Hi @WilliamReynish : I am not sure if I got you. Is there a problem with this idea?
Let's say we have a Select Through mode and a toggle icon next to the Xray.
Switching to Wireframe or Xray will always activate the Select Through mode
Perhaps it's technically needed to make the select through option mandatory, and lock the toggle icon.
Perhaps toogles can't be locked in their active state, we should then changethe Select Through toggle to a "Select FrontFacing Elements only"
All indicators that show we are in Xray mode should apply.
Just as if we'd have activated it manually.
switch Cursor Icons, lasso color etc.
If it is techically possible with an reasonable effort to differentiate between front facing elements and hidden ones for these modes, we could add an option to deactivate that in the userprefs.
if not possible: I also think won't hurt if it would be mandatory.
if possible: we could make hidden lines and verts more greyish to better communicate that they are deactivated.
> In #73479#862641, @WilliamReynish wrote:
>> In #73479#862583, @kioku wrote:
>>
>> I agree this feels a bit weak, but this is mostly because I wanted to avoid altering the current selection behaviour. Its actually simple to connect that in whatever way we want..
>>
>> Anyhow Im curious to see if something will come out of this..
>
> The thing is, I simply don't know of a way to resolve that conflict in a reasonable way. There would need to be some sort of toggle or switch to say 'stop selecting the items that are visible - instead use the Select Through toggle and ignore X-ray, Wireframe or other things' - and only show the Select Through toggle in that case. But to me that's very weak and messy.
>
> In principle I am not against adding a Select Through toggle, but am not happy with adding lots of complexity to handle this conflict in behavior. Of course if we can think of a good/reasonable solution then it probably will be fine, so as far as I am concerned that is the main obstacle.
Hi @WilliamReynish : I am not sure if I got you. Is there a problem with this idea?
Let's say we have a Select Through mode and a toggle icon next to the Xray.
- Switching to Wireframe or Xray will always activate the Select Through mode
- Perhaps it's technically needed to make the select through option mandatory, and lock the toggle icon.
- Perhaps toogles can't be locked in their active state, we should then changethe Select Through toggle to a "Select FrontFacing Elements only"
- All indicators that show we are in Xray mode should apply.
- Just as if we'd have activated it manually.
- switch Cursor Icons, lasso color etc.
If it is techically possible with an reasonable effort to differentiate between front facing elements and hidden ones for these modes, we could add an option to deactivate that in the userprefs.
- if not possible: I also think won't hurt if it would be mandatory.
- if possible: we could make hidden lines and verts more greyish to better communicate that they are deactivated.
Select Through is needed for special type of modeling when topology is predictable for user (like gamedev modeling). It is widespread behaviour in industry standards software, so, as industry standard solution, it is more about popularity.
The proposal is about
The ability for box/lasso tools to select backface geometry on shaded model without backface display.
The ability for box/lasso tools to select faces in wireframe/Xray mode by their bounds (with no facedots display).
Possible Xray solutions:
A) Split Xray settings for object and edit modes (will also satisfy LSTV demands)
B) Add the ability to fade with slider backfacing wiremesh display in Xray mode down to zero.
C) Add Xray/Wiremesh mode facedot center disabling setting, what will make possible faces boundary selection.
This way this entire Select through mode will be an Xray setup, so it can be used or detected as turned on Xray mode.
It is also possible to use it temporarily (switch it) or work constantly in that mode if it is needed, depending on a workflow type, since users that will make such setup don't need regular Xray as it is messy to them.
Possible non-Xray solutions:
Apply a patch and... It's hard to say without an comprehensible workflow research videos, since workflow is not obvious for everyone and something can be missed.
Is everything right?
Ok, summarizing.
- Select Through is needed for special type of modeling when topology is predictable for user (like gamedev modeling). It is widespread behaviour in industry standards software, so, as industry standard solution, it is more about popularity.
**The proposal is about**
1) The ability for box/lasso tools to select backface geometry on shaded model without backface display.
2) The ability for box/lasso tools to select faces in wireframe/Xray mode by their bounds (with no facedots display).
**Possible Xray solutions:**
A) Split Xray settings for object and edit modes (will also satisfy LSTV demands)
B) Add the ability to fade with slider backfacing wiremesh display in Xray mode down to zero.
C) Add Xray/Wiremesh mode facedot center disabling setting, what will make possible faces boundary selection.
This way this entire Select through mode will be an Xray setup, so it can be used or detected as turned on Xray mode.
It is also possible to use it temporarily (switch it) or work constantly in that mode if it is needed, depending on a workflow type, since users that will make such setup don't need regular Xray as it is messy to them.
**Possible non-Xray solutions:**
Apply a patch and... It's hard to say without an comprehensible workflow research videos, since workflow is not obvious for everyone and something can be missed.
Is everything right?
Select Through is needed for special type of modeling when topology is predictable for user (like gamedev modeling). It is widespread behaviour in industry standards software, so, as industry standard solution, it is more about popularity.
It's more about speed and minimizing distraction, thats why its popular.
The ability for box/lasso tools to select backface geometry on shaded model without backface display.
The ability for box/lasso tools to select faces in wireframe/Xray mode by their bounds.
box/lasso/paint(circle)
Regarding Possible Xray / Non-Xray solutions
While it's possible to add it wherever we want, some solutions make more sense than others.
I am not sure if a select through mode is generally well placed under an Xray label, especially if Xray is able to be set to non Xray. But overall these are related and the basic thought might be a idea worth thinking about.
If these funtions were grouped somehow, it would make sense to have a sort of preset dropdown for typical/common setups.
Sorry, can't reply to that in more detail right now, I am running out of time.
>Select Through is needed for special type of modeling when topology is predictable for user (like gamedev modeling). It is widespread behaviour in industry standards software, so, as industry standard solution, it is more about popularity.
It's more about speed and minimizing distraction, thats why its popular.
>The ability for box/lasso tools to select backface geometry on shaded model without backface display.
>The ability for box/lasso tools to select faces in wireframe/Xray mode by their bounds.
box/lasso/paint(circle)
Regarding Possible Xray / Non-Xray solutions
While it's possible to add it wherever we want, some solutions make more sense than others.
I am not sure if a select through mode is generally well placed under an Xray label, especially if Xray is able to be set to non Xray. But overall these are related and the basic thought might be a idea worth thinking about.
If these funtions were grouped somehow, it would make sense to have a sort of preset dropdown for typical/common setups.
Sorry, can't reply to that in more detail right now, I am running out of time.
It's more about speed and minimizing distraction, thats why its popular.
I generally switched to wireframe selection due to support wider range of workflows, that includes both gamedev and messy meshes editing, but as workflow designer I understand distracting and visual overload issues.
box/lasso/paint(circle)
Yes, all non-picking selection types.
Regarding Possible Xray / Non-Xray solutions
Well, speaking of terminology, Xray is "view and select through" mode, but I don't see a seruois issue if it will be possible to set it to a "just select through" setup.
It will still be an Xray mode for selection, so it still can be called as an Xray mode in general.
Also I would like to prefer some of that Xray solutions personally, regardless of Select Through semantic overload issue, as they expand the Xray mode in a positive way, which I would like to see in Blender for any kind of a workflow.
So I like it, it would be nice if this generalizes the solution.
> In #73479#863009, @Debuk wrote:
> It's more about speed and minimizing distraction, thats why its popular.
I generally switched to wireframe selection due to support wider range of workflows, that includes both gamedev and messy meshes editing, but as workflow designer I understand distracting and visual overload issues.
> box/lasso/paint(circle)
Yes, all non-picking selection types.
> Regarding Possible Xray / Non-Xray solutions
Well, speaking of terminology, Xray is "view and select through" mode, but I don't see a seruois issue if it will be possible to set it to a "just select through" setup.
It will still be an Xray mode for selection, so it still can be called as an Xray mode in general.
Also I would like to prefer some of that Xray solutions personally, regardless of Select Through semantic overload issue, as they expand the Xray mode in a positive way, which I would like to see in Blender for any kind of a workflow.
So I like it, it would be nice if this generalizes the solution.
@1D_Inc basing this off of X-Ray is really not a good option. As I keep repeating, these are different behaviors. X-Ray allows picking of occluded geometry (its one of is goals), but this is not something you want for Select Through. You want picking to only work on unoccluded geometry for Select Through. Furthermore, both modes are not mutually exclusive. You may still want to use (semi-)transparent geometry view to actually pick some faces inside your model. If you were to unify Select Through with X-Ray like you suggest, we'd have to adjust quite a few settings every time a "true" X-Ray view was needed.
@1D_Inc basing this off of X-Ray is really not a good option. As I keep repeating, these are different behaviors. X-Ray allows picking of occluded geometry (its one of is goals), but this is not something you want for Select Through. You want picking to only work on unoccluded geometry for Select Through. Furthermore, both modes are not mutually exclusive. You may still want to use (semi-)transparent geometry view to actually pick some faces inside your model. If you were to unify Select Through with X-Ray like you suggest, we'd have to adjust quite a few settings every time a "true" X-Ray view was needed.
Xray as word is mainly describing that it's a LookTrough Mode to me. The fact that occluded elements can be selected by this is not really communicated by that and is rather "just" known by it's users. And using it for activating cases where you no longer can't look through is an unfortunate choide of words I think. But lets ignore that for a moment. Perhaps there is a better word that could remedy that.
In #73479#863017, @1D_Inc wrote:
Also I would like to prefer some of that Xray solutions personally, regardless of Select Through semantic overload issue, as they expand the Xray mode in a positive way, which I would like to see in Blender for any kind of a workflow.
So I like it, it would be nice if this generalizes the solution.
So lets assume these settings were all combined under a single on/off toggle.
It is really important to see that every user would want two or more different setups for that in his workflow and he wants to trigger them fast and not fiddle with settings all the time. @CobraA, @ideasman42 and @Stan_Pancakes, (if it's now Xray opacity or backwire opacity) all stated in this design task that this is the case.
And if we respect all suggested differences and put them all together into a set of checkboxes and sliders there would be roughly these:
Xray OpacitySlider
FaceDots On/Off
Backwires On/Off Or BackWire OpacitySlider
DarkenedLineOverdraw On/Off
But if we leave them separate, and use the fact that different viewport shadings (including Xray) have different properties per default. The setup would naturally be much simpler.
If we'd combine these the only possible solution I could come up with would be a dropdownlist with common defaultcombinations for that.
Then we'd have a single button/shortcut for that and could choose from a handful of different default setups.
But overall I that's the reasons why I personally think that @Stan_Pancakes is right. If we don't combine these many of these settings would be obsolete.
eg. activating a select through by checkbox in solid viewportshading would per default lead to
Backwires off
DarkenedLineOverdraw off
FaceDots off
and Xref could be activated separately.
And as I already stated, add a forced activation of Select-Through in Wireframe and Xray modes keep the current modes intact and embedded into the new controlmethods. I must say it still Sounds like the easiest way to me.
But perhaps there is another way that can be controlled as fast or the preset idea is liked by everyone here.
Would be nice to get a little feedback here from @ideasman42 , what of these directions is more favored.
( Edit: The DarkenedLineOverdraw Checkbox and FaceDots Checkbox could be combined, no need to have them separate)
Hi @1D_Inc,
> Well, speaking of terminology
Xray as word is mainly describing that it's a LookTrough Mode to me. The fact that occluded elements can be selected by this is not really communicated by that and is rather "just" known by it's users. And using it for activating cases where you no longer can't look through is an unfortunate choide of words I think. But lets ignore that for a moment. Perhaps there is a better word that could remedy that.
> In #73479#863017, @1D_Inc wrote:
> Also I would like to prefer some of that Xray solutions personally, regardless of Select Through semantic overload issue, as they expand the Xray mode in a positive way, which I would like to see in Blender for any kind of a workflow.
> So I like it, it would be nice if this generalizes the solution.
So lets assume these settings were all combined under a single on/off toggle.
It is really important to see that every user would want two or more different setups for that in his workflow and he wants to trigger them **fast** and not fiddle with settings all the time. @CobraA, @ideasman42 and @Stan_Pancakes, (if it's now Xray opacity or backwire opacity) all stated in this design task that this is the case.
And if we respect all suggested differences and put them all together into a set of checkboxes and sliders there would be roughly these:
- Xray OpacitySlider
- FaceDots On/Off
- Backwires On/Off Or BackWire OpacitySlider
- DarkenedLineOverdraw On/Off
```
```
But if we leave them separate, and use the fact that different viewport shadings (including Xray) have different properties per default. The setup would naturally be much simpler.
If we'd combine these the only possible solution I could come up with would be a dropdownlist with common defaultcombinations for that.
Then we'd have a single button/shortcut for that and could choose from a handful of different default setups.
But overall I that's the reasons why I personally think that @Stan_Pancakes is right. If we don't combine these many of these settings would be obsolete.
eg. activating a select through by checkbox in solid viewportshading would per default lead to
- Backwires off
- DarkenedLineOverdraw off
- FaceDots off
and Xref could be activated separately.
And as I already stated, add a forced activation of Select-Through in Wireframe and Xray modes keep the current modes intact and embedded into the new controlmethods. I must say it still Sounds like the easiest way to me.
But perhaps there is another way that can be controlled as fast or the preset idea is liked by everyone here.
Would be nice to get a little feedback here from @ideasman42 , what of these directions is more favored.
*( Edit: The DarkenedLineOverdraw Checkbox and FaceDots Checkbox could be combined, no need to have them separate)*
So lets assume these settings were all combined under a single on/off toggle.
Sort of. Like Xray setups preset system.
> In #73479#863407, @Debuk wrote:
> Hi @1D_Inc,
> So lets assume these settings were all combined under a single on/off toggle.
Sort of. Like Xray setups preset system.
If you switch to Eevee go to edit mode, Xray then behaves just like 2.7's limit selection to visible. the same for the other engines rendered modes, it's just solid mode that needs some tweaks. Why would u add more complexities to selection tools modes...etc when the solution is so simple.
If you switch to Eevee go to edit mode, Xray then behaves just like 2.7's **limit selection to visible**. the same for the other engines rendered modes, it's just solid mode that needs some tweaks. Why would u add more complexities to selection tools modes...etc when the solution is so simple.
In #73479#863495, @CobraA wrote:
If you switch to Eevee go to edit mode, Xray then behaves just like 2.7's limit selection to visible. the same for the other engines rendered modes.
Because LSTV does not solve semantic overload problem. Also rendering mode is hardware consuming one)
> In #73479#863495, @CobraA wrote:
> If you switch to Eevee go to edit mode, Xray then behaves just like 2.7's **limit selection to visible**. the same for the other engines rendered modes.
Because LSTV does not solve semantic overload problem. Also rendering mode is hardware consuming one)
Let me explain a situation to all sides of this dialogue.
>Industry Standard Software users
You are trying to ask for mode that is completely unobvious for developers from the point of use because Blender successfully survives all this time it exists without such mode.
So it took some time to clarify an issue, and we has got short and clear description of a problem in Blender terms both for workflow requirements and possible behavior/appearance.
Workflow requirements + possible appearance make up an understandable image of feature for proper design, and identifying it is special type of work in software development.
>Devs
We were working on a hype around Blender for decades, building features and proper marketing, and we've got it - we've got a lot of people from other software!
So now there will be a lot of such requests (like moving pivot point when there is only origin, ability to select something that is invisible, or killind complex multirefrenced modeling to force complex scene setups),
and you need to take into account an actual workflow behind such requests to satisfy them.
It is impossible to create software that exceeds industry standards, completely following industry standards guidelines, and the only way to make a proper feature design is to take all workflows into account,
placing a feature to a complete workflows map.
WD (workflow designes) are special people who are not just uses, but observes and investigates industry standards software on purpose for its weak places to find/make/test
better solution in opensorce software, which work is to build a competitive advantage for companies, can understand and explain such demands from workflow point of view.
Let me explain a situation to all sides of this dialogue.
**>Industry Standard Software users**
You are trying to ask for mode that is completely unobvious for developers from the point of use because Blender successfully survives all this time it exists without such mode.
So it took some time to clarify an issue, and we has got short and clear description of a problem in Blender terms both for workflow requirements and possible behavior/appearance.
Workflow requirements + possible appearance make up an understandable image of feature for proper design, and identifying it is special type of work in software development.
**>Devs**
We were working on a hype around Blender for decades, building features and proper marketing, and we've got it - we've got a lot of people from other software!
So now there will be a lot of such requests (like moving pivot point when there is only origin, ability to select something that is invisible, or killind complex multirefrenced modeling to force complex scene setups),
and you need to take into account an actual workflow behind such requests to satisfy them.
It is impossible to create software that exceeds industry standards, completely following industry standards guidelines, and the only way to make a proper feature design is to take all workflows into account,
placing a feature to a complete workflows map.
WD (workflow designes) are special people who are not just uses, but observes and investigates industry standards software on purpose for its weak places to find/make/test
better solution in opensorce software, which work is to build a competitive advantage for companies, can understand and explain such demands from workflow point of view.
> In #73479#863428, @1D_Inc wrote:
>> In #73479#863407, @Debuk wrote:
>> Hi @1D_Inc,
>
>> So lets assume these settings were all combined under a single on/off toggle.
>
> Sort of. Like Xray setups preset system.
An interesting example of the implementation of such functionality for discussion:
https://gumroad.com/l/viewport_presets
Yes, that's nice, indeed. Btw thanks for the link. And it's quite comparable to what I thought of for the select through presets dropdown.
I would see this rather be a task on its own, there are other places in the gui where such a preset idea fits well to kill unwanted fiddling with too many options too. With a very narrow scope it would fit here aswell, just has the potential to be too much for this design task. If it's an interesting idea for the devs they could make it it's own design task or we could shift that discussion over to devtalk.
> In #73479#864447, @1D_Inc wrote:
> An interesting example of the implementation of such functionality for discussion:
> https://gumroad.com/l/viewport_presets
Yes, that's nice, indeed. Btw thanks for the link. And it's quite comparable to what I thought of for the select through presets dropdown.
I would see this rather be a task on its own, there are other places in the gui where such a preset idea fits well to kill unwanted fiddling with too many options too. With a very narrow scope it would fit here aswell, just has the potential to be too much for this design task. If it's an interesting idea for the devs they could make it it's own design task or we could shift that discussion over to devtalk.
What if we came at this from the perspective of creating a sort of selection API? Right now, we use editor state flags (x-ray mode, etc) to drive selection behavior, where we could be using operator properties that, on invoke, are set to match those flags. If we went that route, we'd be able to add an 'override global settings' property, letting users swap between their preferred behavior and the default behavior by toggling a single option. X-ray mode wouldn't change, we wouldn't have to worry about tracking a new editor state, and we'd have a framework for future selection features.
UI-wise, The override option, and an overflow popover with the settings it pertains to, could be added to the tool header. It'd follow a fairly standard progressive disclosure model, so new users wouldn't be overwhelmed with options, and it'd allow for easy state signaling (doubly so if the color of the selection outline changes when overrides are enabled). If we end up finding a set of popular presets, we could throw those into a pie menu for easy access. For modal shortcuts, we could stick common options in the QWERT row.
What if we came at this from the perspective of creating a sort of selection API? Right now, we use editor state flags (x-ray mode, etc) to drive selection behavior, where we could be using operator properties that, on invoke, are set to match those flags. If we went that route, we'd be able to add an 'override global settings' property, letting users swap between their preferred behavior and the default behavior by toggling a single option. X-ray mode wouldn't change, we wouldn't have to worry about tracking a new editor state, and we'd have a framework for future selection features.
UI-wise, The override option, and an overflow popover with the settings it pertains to, could be added to the tool header. It'd follow a fairly standard progressive disclosure model, so new users wouldn't be overwhelmed with options, and it'd allow for easy state signaling (doubly so if the color of the selection outline changes when overrides are enabled). If we end up finding a set of popular presets, we could throw those into a pie menu for easy access. For modal shortcuts, we could stick common options in the `QWERT` row.
In #73479#865440, @ThatAsherGuy wrote:
What if we came at this from the perspective of creating a sort of selection API?
We will end with this addon's functionality, but through rewriting entire selection API.
> In #73479#865440, @ThatAsherGuy wrote:
> What if we came at this from the perspective of creating a sort of selection API?
We will end with this addon's functionality, but through rewriting entire selection API.
I'm probably not entitled to contribute to this discussion, because I'm just yet another user coming from Maya and bunch of other 3d authoring systems. And since I'm selecting with Left mouse button, you are of course free to cancel my account now. However I have some experience with user interaction design and usability testing.
Some parts of this thread have excellent arguments that I didn't fully understand before. I can now see, why the Blender team is strongly opposed to selecting something invisible, because that it "might" confuse some people.
I derive two major points from this discussion:
User Testing
I'm not sure if the Blender team defined what the target audience should be. (But I'm certain there are plenty of wiki pages on that topic). "Experienced blender users" would be a terrible answer. To the UX designers of the Blender team I can highly recommend Alan Cooper's "About Face", p. 246ff chapter on "What perpetual intermediates need”.
I believe believe that all user interaction design without user testing is fundamentally flawed and doomed to fail. I am also willing to bet that if you test the current implementation as of 2.8 with 30 people (10 experienced blender users, 10 with some experience in any 3d software, 10 beginners) more than half of the people would rate the experience as unexpected and confusing. (The test should be an intermediate task like selecting some components of a model like the Pixar lamp).
For me cutting out a selection of a 3d-model with a box selection should include hidden objects because...
the same happens in Blender's Object mode (And please don't change that)
this is the default behavior in... blah blah blah
My mental model for box selection is closer to cutting a cake with a knife than touching the visible frosting with my finger (that would be clicking).
But as I said, all personal arguments are flawed. Ask 30 non-experts(!) at two day blender training, and you will have your answer.
Using X-Ray mode
I'm probably "holding it wrong", but even after countless hours of mesh modelling I find the face dots in X-Ray utterly cumbersome and error prone. I learned to live and sometimes love a lot of other Blender peculiarities. So maybe I will come around in a couple of years. But are you really sure that these dots are still a good idea? This thread already suggests that a lot of conservative Blender users can't let go but the UX designers are now eager to move on. So why keep it alive for x-ray mode?
A compromise that would be consistent with "don't select invisible stuff" and "selection in X-ray+face dots is annoying" would be a new checkbox like this:
Disabling the checkbox would switch to full face selection mode.
On a side node: Thanks again for finally bringing usability to Blender. The current visual design of 2.8 (especially the vector icon set) is one of the design jobs I have seen in years. It's just incredible that this is coming from an open source project.
I'm probably not entitled to contribute to this discussion, because I'm just yet another user coming from Maya and bunch of other 3d authoring systems. And since I'm selecting with Left mouse button, you are of course free to cancel my account now. However I have some experience with user interaction design and usability testing.
Some parts of this thread have excellent arguments that I didn't fully understand before. I can now see, why the Blender team is strongly opposed to selecting something invisible, because that it "might" confuse some people.
I derive two major points from this discussion:
**User Testing**
I'm not sure if the Blender team defined what the target audience should be. (But I'm certain there are plenty of wiki pages on that topic). "Experienced blender users" would be a terrible answer. To the UX designers of the Blender team I can highly recommend Alan Cooper's "About Face", p. 246ff chapter on "What perpetual intermediates need”.
I believe believe that all user interaction design without user testing is fundamentally flawed and doomed to fail. I am also willing to bet that if you test the current implementation as of 2.8 with 30 people (10 experienced blender users, 10 with some experience in any 3d software, 10 beginners) more than half of the people would rate the experience as unexpected and confusing. (The test should be an intermediate task like selecting some components of a model like the Pixar lamp).
For me cutting out a selection of a 3d-model with a box selection should include hidden objects because...
- the same happens in Blender's Object mode (And please don't change that)
- this is the default behavior in... blah blah blah
- My mental model for box selection is closer to cutting a cake with a knife than touching the visible frosting with my finger (that would be clicking).
But as I said, all personal arguments are flawed. Ask 30 non-experts(!) at two day blender training, and you will have your answer.
**Using X-Ray mode**
I'm probably "holding it wrong", but even after countless hours of mesh modelling I find the face dots in X-Ray utterly cumbersome and error prone. I learned to live and sometimes love a lot of other Blender peculiarities. So maybe I will come around in a couple of years. But are you really sure that these dots are still a good idea? [This thread ](https://devtalk.blender.org/t/edit-mesh-face-dots-poll/5858/48) already suggests that a lot of conservative Blender users can't let go but the UX designers are now eager to move on. So why keep it alive for x-ray mode?
A compromise that would be consistent with "don't select invisible stuff" and "selection in X-ray+face dots is annoying" would be a new checkbox like this:
Disabling the checkbox would switch to full face selection mode.
___
On a side node: Thanks again for finally bringing usability to Blender. The current visual design of 2.8 (especially the vector icon set) is one of the design jobs I have seen in years. It's just incredible that this is coming from an open source project.
This thread already suggests that a lot of conservative Blender users can't let go but the UX designers are now eager to move on. So why keep it alive for x-ray mode?
Facedots are not about being conservative.
They have two main benefits:
Direct selection of the part of the mesh located inside the mesh (complex modeling, architectural modeling)
Visually reveal the topological structure of the mesh (messy meshes cleanup)
The presence of Facedots makes Blender able to provide several workflows that other programs cannot handle.
For example, Blender is the best tool for Sketchup/CAD/BIM geometry cleanup (Sketchup's geometry is kind of legendary messy at CG industry level).
A compromise
For sure, facedots are not needed for some types of modeling workflows. This thread is about satisfying such workflows demands without corrupting others.
It seems, your proposal refers to the second point of the summarizing post
> In #73479#879563, @pixtur wrote:
> [This thread ](https://devtalk.blender.org/t/edit-mesh-face-dots-poll/5858/48) already suggests that a lot of conservative Blender users can't let go but the UX designers are now eager to move on. So why keep it alive for x-ray mode?
Facedots are not about being conservative.
They have two main benefits:
- Direct selection of the part of the mesh located inside the mesh (complex modeling, architectural modeling)
- Visually reveal the topological structure of the mesh (messy meshes cleanup)
The presence of Facedots makes Blender able to provide several workflows that other programs cannot handle.
For example, Blender is the best tool for Sketchup/CAD/BIM geometry cleanup (Sketchup's geometry is kind of legendary messy at CG industry level).
> A compromise
For sure, facedots are not needed for some types of modeling workflows. This thread is about satisfying such workflows demands without corrupting others.
It seems, your proposal refers to the second point of the [summarizing post ](https://developer.blender.org/T73479#862991)
Should this be supported in object mode too?(the reverse since objects already select-through), IIRC we discussed having this option for box select too.
If we are going to stick with the "select what you can see" paradigm, I think Object mode should be consistent with Edit mode. The X-ray toggle confuses new users when they are in Object mode because they are already selecting through. Having 2 opposite ways to enable/disable select through isn't good design. Consistency is key here. But yes, I think we should support this in both modes for all selection tools.
Which selection tools/operators should use this?
To be consistent, I think all selection tools should use this.
Which modes this should be supported in (edit, pose, grease pencil... etc)
I think all modes that have relevant selection tools and hidden objects should be supported, which will make consistency with Object mode more important.
> Should this be supported in object mode too?(the reverse since objects already select-through), IIRC we discussed having this option for box select too.
If we are going to stick with the "select what you can see" paradigm, I think Object mode should be consistent with Edit mode. The X-ray toggle confuses new users when they are in Object mode because they are already selecting through. Having 2 opposite ways to enable/disable select through isn't good design. Consistency is key here. But yes, I think we should support this in both modes for all selection tools.
> Which selection tools/operators should use this?
To be consistent, I think all selection tools should use this.
> Which modes this should be supported in (edit, pose, grease pencil... etc)
I think all modes that have relevant selection tools and hidden objects should be supported, which will make consistency with Object mode more important.
Here is a nice workaround example with some depictive use cases for edit mode.
https://devtalk.blender.org/t/decoupling-x-ray-and-limit-selection-to-visible/3498/92?u=1d_inc
I have posted this mockup to death already but I am going to post it here as well because it simply solves all the questions asked above. It's just that someone still keeps artificially making this a problem:
Where this option is stored, accessed?:
Right here. It would be the same button, but it would do different thing based on if its sub-option is active or not.
Which selection tools/operators should use this?
All selection operators in edit mode. Object mode already is, and should always remain select through.
Which modes this should be supported in (edit, pose, grease pencil... etc)
Every single mode which currently does not select all the content inside the selection box if current xray is off. In other words, any mode which currently uses any form of view occlusion for the selection.
How to display this option when in wire-frame display (when the user will always select-through)
The button (with the two overlapping rectangles) will be highlighted to indicate select through is on.
How to access this from both active-tools & key-bindings?
This must NOT be a per tool option, it needs to be a global option like the current xray is. Therefore it would be identical to what happens if you currently assign a hotkey to the xray button. There's no need to bring the tools into this, as current Xray implementation works independent of the tools as well, and works just fine.
How to make it obvious selecting-trough is enabled (draw style, cursor - this might help avoid confusion).
See #4
Should this be supported in object mode too?(the reverse since objects already select-through), IIRC we discussed having this option for box select too.
No, see #2. There has not been any select visible only option in object level mode in any other DCC and no one ever requested it. Please don't add bloat features no one needs just to achieve some unnecessary superficial parity between the modes.
All that really needs to happen here is for Xray button to become select-through button with Xray sub-option. This new select-through button would be what the user actually maps to a hotkey to toggle select through on and off when necessary while the Xray sub-option would be more of a persistent workflow preference, where user chooses if he wants to use the "Select only what you se paradigm" which introduces face dots and transparent drawing, or if the user wants to use "Simple select through" paradigm, where face area is used for selection evaluation and mesh transparency drawing is not required.
This also does not introduce any new paradigm to Blender's UI, since toggle with a set of sub option already exists in form of "Show Gizmo" and "Show Overlays" buttons which are coincidentally next to the Xray (proposed select through) button. These UI elements also work in a way that they toggle the set of sub-options present in their popover on and off.
I have posted this mockup to death already but I am going to post it here as well because it simply solves all the questions asked above. It's just that someone still keeps artificially making this a problem:
1. Where this option is stored, accessed?:
Right here. It would be the same button, but it would do different thing based on if its sub-option is active or not.
2. Which selection tools/operators should use this?
All selection operators in edit mode. Object mode already is, and should always remain select through.
3. Which modes this should be supported in (edit, pose, grease pencil... etc)
Every single mode which currently does not select all the content inside the selection box if current xray is off. In other words, any mode which currently uses any form of view occlusion for the selection.
4. How to display this option when in wire-frame display (when the user will always select-through)
The button (with the two overlapping rectangles) will be highlighted to indicate select through is on.
5. How to access this from both active-tools & key-bindings?
This must NOT be a per tool option, it needs to be a global option like the current xray is. Therefore it would be identical to what happens if you currently assign a hotkey to the xray button. There's no need to bring the tools into this, as current Xray implementation works independent of the tools as well, and works just fine.
6. How to make it obvious selecting-trough is enabled (draw style, cursor - this might help avoid confusion).
See #4
7. Should this be supported in object mode too?(the reverse since objects already select-through), IIRC we discussed having this option for box select too.
No, see #2. There has not been any select visible only option in object level mode in any other DCC and no one ever requested it. Please don't add bloat features no one needs just to achieve some unnecessary superficial parity between the modes.
All that really needs to happen here is for Xray button to become select-through button with Xray sub-option. This new select-through button would be what the user actually maps to a hotkey to toggle select through on and off when necessary while the Xray sub-option would be more of a persistent workflow preference, where user chooses if he wants to use the "Select only what you se paradigm" which introduces face dots and transparent drawing, or if the user wants to use "Simple select through" paradigm, where face area is used for selection evaluation and mesh transparency drawing is not required.
This also does not introduce any new paradigm to Blender's UI, since toggle with a set of sub option already exists in form of "Show Gizmo" and "Show Overlays" buttons which are coincidentally next to the Xray (proposed select through) button. These UI elements also work in a way that they toggle the set of sub-options present in their popover on and off.
In #73479#911001, @Rawalanche wrote:
These UI elements also work in a way that they toggle the set of sub-options present in their popover on and off.
Not entirely sure how this should work. In short:
When button is pressed, but checkbox is not filled, it will display Xray, but will not perform select through,
and when button is pressed and checkbox is filled, it will display no Xray, but will perform select through,
both for object and edit modes?
> In #73479#911001, @Rawalanche wrote:
> These UI elements also work in a way that they toggle the set of sub-options present in their popover on and off.
Not entirely sure how this should work. In short:
When button is pressed, but checkbox is not filled, it will display Xray, but will not perform select through,
and when button is pressed and checkbox is filled, it will display no Xray, but will perform select through,
both for object and edit modes?
In #73479#911001, @Rawalanche wrote:
These UI elements also work in a way that they toggle the set of sub-options present in their popover on and off.
Not entirely sure how this should work. In short:
When button is pressed, but checkbox is not filled, it will display Xray, but will not perform select through,
and when button is pressed and checkbox is filled, it will display no Xray, but will perform select through,
both for object and edit modes?
No, wrong.
When the button is pressed, but checkbox is not filled, it will perform select through using face area (instead of face center dots) and won't make display transparent.
When the button is pressed and checkbox is filled, then it will be exactly same as when the button is pressed now, in official blender builds. So that occluded faces are drawn transparently and face dots are used to select them.
Above applies to edit mode.
In Object Mode, the button should not exist at all, since select through is always present. If you want to make your scene visually transparent (what Xray should actually be for) in object mode, you would just adjust the Xray value on the display popover:
This would make it extremely clear that you are modifying only visual aspect of the editor, not actual selection.
This Xray amount value in display settings would then also be used in Edit Mode when the Xray checkbox is enabled to define how transparent the occluded face drawing is when Xray checkbox is as you said "filled".
Right now, in official Blender builds, if you click "Xray" button, it's actually hardcoded function to do two separate things. It changes the selection methodology and also drawing of your viewport mesh. You can actually see that Xray button actually toggles the Xray checkbox in the Shading popover. It's two separate features, one concerning selection method and other concerning viewport shading style combined into one feature. This forced conflation of the two is the biggest problem here.
I think what confused you is that I forgot to mention that the button itself would be renamed from Xray to Select Through. So that toggling the top level button would say "I want to select through the mesh" and then the checkbox in the popover would be toggle between "I want to select through using Xray drawing and face dots" vs "I want to select through without Xray drawing and using face area"
> In #73479#911051, @1D_Inc wrote:
>> In #73479#911001, @Rawalanche wrote:
>> These UI elements also work in a way that they toggle the set of sub-options present in their popover on and off.
>
> Not entirely sure how this should work. In short:
> When button is pressed, but checkbox is not filled, it will display Xray, but will not perform select through,
> and when button is pressed and checkbox is filled, it will display no Xray, but will perform select through,
> both for object and edit modes?
>
No, wrong.
When the button is pressed, but checkbox is not filled, it will perform select through using face area (instead of face center dots) and won't make display transparent.
When the button is pressed and checkbox is filled, then it will be exactly same as when the button is pressed now, in official blender builds. So that occluded faces are drawn transparently and face dots are used to select them.
Above applies to edit mode.
In Object Mode, the button should not exist at all, since select through is always present. If you want to make your scene visually transparent (what Xray should actually be for) in object mode, you would just adjust the Xray value on the display popover:
This would make it extremely clear that you are modifying only **visual** aspect of the editor, not actual selection.
This Xray amount value in display settings would then also be used in Edit Mode when the Xray checkbox is enabled to define how transparent the occluded face drawing is when Xray checkbox is as you said "filled".
Right now, in official Blender builds, if you click "Xray" button, it's actually hardcoded function to do two separate things. It changes the selection methodology and also drawing of your viewport mesh. You can actually see that Xray button actually toggles the Xray checkbox in the **Shading** popover. It's two separate features, one concerning selection method and other concerning viewport shading style combined into one feature. This forced conflation of the two is the biggest problem here.
I think what confused you is that I forgot to mention that the button itself would be renamed from Xray to Select Through. So that toggling the top level button would say "I want to select through the mesh" and then the checkbox in the popover would be toggle between "I want to select through using Xray drawing and face dots" vs "I want to select through without Xray drawing and using face area"
Just chiming in to say as useful as it sounds it would be much appreciated if kept optional - I like selecting what I can see without any side effects, so the sync between xray and selection occlusion suits me fine.
Just chiming in to say as useful as it sounds it would be much appreciated if kept optional - I like selecting what I can see without any side effects, so the sync between xray and selection occlusion suits me fine.
I'm with Ludvik on this one: I transitioned from Maya to Blender about 2 months ago, and by far the biggest pain point for my workflow has been the lack of a discrete backface/occluded selection mode. I don't think xray needs to change, for executing precise selection it's valuable. Maya has an xray mode, but it also has a separate toggle in preferences to globally enable selection of occluded geometry. These are separate controls and don't force the user to use tools that don't fit their needs.
I basically alwayswant backface selection enabled on a fully opaque mesh with no face centers. Having a separate mode (xray) I need to constantly toggle adds unnecessary clicks to my modelling, increases the chance I'll forget and transform only front-facing elements, alters the viewport in a way I don't want/need (transparency), and changes face selection in a way I don't want/need (face centers).
I'm with Ludvik on this one: I transitioned from Maya to Blender about 2 months ago, and by far the biggest pain point for my workflow has been the lack of a discrete backface/occluded selection mode. I don't think xray needs to change, for executing precise selection it's valuable. Maya has an xray mode, but it also has a separate toggle in preferences to globally enable selection of occluded geometry. These are separate controls and don't force the user to use tools that don't fit their needs.
I basically *always*want backface selection enabled on a fully opaque mesh with no face centers. Having a separate mode (xray) I need to constantly toggle adds unnecessary clicks to my modelling, increases the chance I'll forget and transform only front-facing elements, alters the viewport in a way I don't want/need (transparency), and changes face selection in a way I don't want/need (face centers).
In #73479#911076, @Rawalanche wrote:
I think what confused you is that I forgot to mention that the button itself would be renamed from Xray to Select Through.
No, wrong.
According to summarizing post , this topic is about solving two problems:View Selection Occlusion/select throughproblem and*Face boundary selection//.
I was confused because you called "Face boundary select"checkbox as"Select through" for some reason.
I'm with Ludvik on this one: I transitioned from Maya to Blender about 2 months ago...
I basically always want backface selection enabled on a fully opaque mesh with no face centers.
Well, such inconsistency took it's place because it was assumed that Xray can replace LSTV mode because of... some reason.
So it is one of that pretty much fresh inconsistencies that was brought since 2.8.
For sure, you will need to reproduce Maya behavior since current solution is not good even by Blender standards, and also because Maya approach fits most of workflows that can be performed in Maya.
Attempts have already been made to remove the Facedots concept from Blender by developers about a year ago, for some reason, before even asking what they are actually needed for,
maybe because there are some people which type of work they perform allow them to not to use facedots, like Maya or Max users.
However, they were moved back because face edit mode is for faces editing, and facedots provides the ability of some workflows, difficult to reproduce in Maya or 3dsMax, because of lack of facedots there.
Such problems arise because instead of designing a process with investigating and studying a proper range of workflows behind tools, some assumption is made during development, which is forced until it becomes critical.
Workflow design matter is pretty much fragile - there are a lot of things that possible, but not so much that are versatile, and it is incredibly hard to find the best combination that is almost perfect for every possible use case - a bit wrong assumption, and you've got inconsistency like that, ruining usability experience for some workflows.
> In #73479#911076, @Rawalanche wrote:
> I think what confused you is that I forgot to mention that the button itself would be renamed from Xray to Select Through.
No, wrong.
According to [summarizing post ](https:*developer.blender.org/T73479#862991), this topic is about solving two problems:*View Selection Occlusion/select through*problem and*Face boundary selection//.
I was confused because you called **"Face boundary select"**checkbox as**"Select through"** for some reason.
> I'm with Ludvik on this one: I transitioned from Maya to Blender about 2 months ago...
> I basically always want backface selection enabled on a fully opaque mesh with no face centers.
Well, such inconsistency took it's place because it was assumed that Xray can replace LSTV mode because of... some reason.
So it is one of that pretty much fresh inconsistencies that was brought since 2.8.
For sure, you will need to reproduce Maya behavior since current solution is not good even by Blender standards, and also because Maya approach fits most of workflows that can be performed in Maya.
Attempts have already been made to remove the Facedots concept from Blender by developers about a year ago, for some reason, before even asking what they are actually needed for,
maybe because there are some people which type of work they perform allow them to not to use facedots, like Maya or Max users.
However, they were moved back because face edit mode is for faces editing, and facedots provides the ability of some workflows, difficult to reproduce in Maya or 3dsMax, because of lack of facedots there.
Such problems arise because instead of designing a process with investigating and studying a proper range of workflows behind tools, some assumption is made during development, which is forced until it becomes critical.
Workflow design matter is pretty much fragile - there are a lot of things that possible, but not so much that are versatile, and it is incredibly hard to find the best combination that is almost perfect for every possible use case - a bit wrong assumption, and you've got inconsistency like that, ruining usability experience for some workflows.
According to summarizing post, this topic is about solving two problems:
View Selection Occlusion/select through problem and Face boundary selection.
@1D_Inc:
This "summarizing post" is made by yourself and it's standpoints and range are at least partially affected by your personal opinion, what is so far absolutely fine. But please don't use that as argument against other opinions.
What this design is all about is dependent on how the implemention of this idea is planned, mainly because the context may differ. So if it takes place within the XRAY mode itself would have other implications on eg what to do with the facedots than if it would be just available in solid shading mode.
Beside that this discussion reached a point long ago where it would have been neccessary to hear which general route this design should rather follow to get the problem solved AND have a chance to be accepted. Otherwise it's just an in length discussed misfit in the end.
>According to summarizing post, this topic is about solving two problems:
>View Selection Occlusion/select through problem and Face boundary selection.
@1D_Inc:
This "summarizing post" is made by yourself and it's standpoints and range are at least partially affected by your personal opinion, what is so far absolutely fine. But please don't use that as argument against other opinions.
What this design is all about is dependent on how the implemention of this idea is planned, mainly because the context may differ. So if it takes place within the XRAY mode itself would have other implications on eg what to do with the facedots than if it would be just available in solid shading mode.
Beside that this discussion reached a point long ago where it would have been neccessary to hear which general route this design should rather follow to get the problem solved AND have a chance to be accepted. Otherwise it's just an in length discussed misfit in the end.
In #73479#911076, @Rawalanche wrote:
I think what confused you is that I forgot to mention that the button itself would be renamed from Xray to Select Through.
No, wrong.
According to summarizing post , this topic is about solving two problems: View Selection Occlusion/select through problem and Face boundary selection.
I was confused because you called "Face boundary select"checkbox as"Select through" for some reason.
I'm with Ludvik on this one: I transitioned from Maya to Blender about 2 months ago...
I basically always want backface selection enabled on a fully opaque mesh with no face centers.
Well, such inconsistency took it's place because it was assumed that Xray can replace LSTV mode because of... some reason.
So it is one of that pretty much fresh inconsistencies that was brought since 2.8.
For sure, you will need to reproduce Maya behavior since current solution is not good even by Blender standards, and also because Maya approach fits most of workflows that can be performed in Maya.
Attempts have already been made to remove the Facedots concept from Blender by developers about a year ago, for some reason, before even asking what they are actually needed for,
maybe because there are some people which type of work they perform allow them to not to use facedots, like Maya or Max users.
However, they were moved back because face edit mode is for faces editing, and facedots provides the ability of some workflows, difficult to reproduce in Maya or 3dsMax, because of lack of facedots there.
Such problems arise because instead of designing a process with investigating and studying a proper range of workflows behind tools, some assumption is made during development, which is forced until it becomes critical.
Workflow design matter is pretty much fragile - there are a lot of things that possible, but not so much that are versatile, and it is incredibly hard to find the best combination that is almost perfect for every possible use case - a bit wrong assumption, and you've got inconsistency like that, ruining usability experience for some workflows.
You still don't seem to get it. What I propose would basically mean that by default absolutely nothing would change for you. You could use your xray and face dot mode exactly the same way as before, and it would be that way by default. Only change for you would be that next to the button currently named as Xray would be a small popover button with a single sub option. It would take about 16px of horizontal space on the 3D view top bar, and you could completely ignore it. This popover dropdown button would contain a single option which would save many of us hours of wasted work and frustration every week. If this change was introduced quietly without you knowing, I am sure it would take you at least a couple of days before you'd even notice the new little dropdown button, just due to how little impact it'd actually have on your Blender usage.
I don't understand what do you possibly have to gain by arguing against a workflow you personally won't use anyway and against a change which would not impact your personally in pretty much any way, since the current behavior would still remain the default. Like the only motivation to do this I can think of is evil.
> In #73479#911565, @1D_Inc wrote:
>> In #73479#911076, @Rawalanche wrote:
>> I think what confused you is that I forgot to mention that the button itself would be renamed from Xray to Select Through.
>
> No, wrong.
> According to [summarizing post ](https://developer.blender.org/T73479#862991), this topic is about solving two problems:
> *View Selection Occlusion/select through* problem and *Face boundary selection*.
> I was confused because you called **"Face boundary select"**checkbox as**"Select through"** for some reason.
>
>> I'm with Ludvik on this one: I transitioned from Maya to Blender about 2 months ago...
>> I basically always want backface selection enabled on a fully opaque mesh with no face centers.
>
> Well, such inconsistency took it's place because it was assumed that Xray can replace LSTV mode because of... some reason.
> So it is one of that pretty much fresh inconsistencies that was brought since 2.8.
> For sure, you will need to reproduce Maya behavior since current solution is not good even by Blender standards, and also because Maya approach fits most of workflows that can be performed in Maya.
> Attempts have already been made to remove the Facedots concept from Blender by developers about a year ago, for some reason, before even asking what they are actually needed for,
> maybe because there are some people which type of work they perform allow them to not to use facedots, like Maya or Max users.
> However, they were moved back because face edit mode is for faces editing, and facedots provides the ability of some workflows, difficult to reproduce in Maya or 3dsMax, because of lack of facedots there.
> Such problems arise because instead of designing a process with investigating and studying a proper range of workflows behind tools, some assumption is made during development, which is forced until it becomes critical.
> Workflow design matter is pretty much fragile - there are a lot of things that possible, but not so much that are versatile, and it is incredibly hard to find the best combination that is almost perfect for every possible use case - a bit wrong assumption, and you've got inconsistency like that, ruining usability experience for some workflows.
You still don't seem to get it. What I propose would basically mean that by default absolutely nothing would change for you. You could use your xray and face dot mode exactly the same way as before, and it would be that way by default. Only change for you would be that next to the button currently named as Xray would be a small popover button with a single sub option. It would take about 16px of horizontal space on the 3D view top bar, and you could completely ignore it. This popover dropdown button would contain a single option which would save many of us hours of wasted work and frustration every week. If this change was introduced quietly without you knowing, I am sure it would take you at least a couple of days before you'd even notice the new little dropdown button, just due to how little impact it'd actually have on your Blender usage.
I don't understand what do you possibly have to gain by arguing against a workflow you personally won't use anyway and against a change which would not impact your personally in pretty much any way, since the current behavior would still remain the default. Like the only motivation to do this I can think of is evil.
I don't understand what do you possibly have to gain by arguing against a workflow you personally won't use anyway.
I am not arguing against your proposal anywhere.
I just said that the problem it is solving does not completely match the name of the checkbox, which makes such a name a little confusing.
That does not mean, that I don't like the entire concept behind it)
What I think about your solution - I really like such minimalistic approach, a very nice design job!
In my opinion it nicely fits as solution for paragraph C from summarizing post.
Let me remind:
Possible Xray solutions:
A) Split Xray settings for object and edit modes (will also satisfy LSTV demands)
B) Add the ability to fade with slider backfacing wiremesh display in Xray mode down to zero. C) Add Xray/Wiremesh mode facedot center disabling setting, what will make possible faces boundary selection.
I would like to propose to invert checkbox action (so the current default behavior of X Ray is when the checkbox is empty), and name it "X-ray faces selection" or "Face area selection" to directly indicate its functionality.
So if user need faces area selection ability, he enables that ability by filling checkbox, and if user don't need it at some point, he disables it. That could be more consistent behavior. How do you think?
In #73479#911872, @Debuk wrote:
This "summarizing post" is made by yourself and it's standpoints and range are at least partially affected by your personal opinion, what is so far absolutely fine. But please don't use that as argument against other opinions.
It is summarizing post, it can't be used as argument against opinions. Sort of a protocol.
> In #73479#911892, @Rawalanche wrote:
> I don't understand what do you possibly have to gain by arguing against a workflow you personally won't use anyway.
I am not arguing against your proposal anywhere.
I just said that the problem it is solving does not completely match the name of the checkbox, which makes such a name a little confusing.
That does not mean, that I don't like the entire concept behind it)
What I think about your solution - I really like such minimalistic approach, a very nice design job!
In my opinion it nicely fits as solution for paragraph C from summarizing post.
Let me remind:
>**Possible Xray solutions:**
>
>A) Split Xray settings for object and edit modes (will also satisfy LSTV demands)
>B) Add the ability to fade with slider backfacing wiremesh display in Xray mode down to zero.
>**C) Add Xray/Wiremesh mode facedot center disabling setting, what will make possible faces boundary selection.**
I would like to propose to invert checkbox action (so the current default behavior of X Ray is when the checkbox is empty), and name it "X-ray faces selection" or "Face area selection" to directly indicate its functionality.
So if user need faces area selection ability, he *enables* that ability by filling checkbox, and if user don't need it at some point, he *disables* it. That could be more consistent behavior. How do you think?
_______________________________
> In #73479#911872, @Debuk wrote:
> This "summarizing post" is made by yourself and it's standpoints and range are at least partially affected by your personal opinion, what is so far absolutely fine. But please don't use that as argument against other opinions.
It is summarizing post, it can't be used as argument against opinions. Sort of a protocol.
I was looking through possible solution realizations for paragraph C, like that one .
It is interesting approach - to create special subset of selecting tools, but they refers to Xray (because it is an addon, and have limitations), that makes through selection result different from regular one.
So I thought about combinations of cases to satisfy, to provide the ability to check possible solutions for compliance.
I applied my proposal of the checkbox state invertion in this table, to make it enabling faces area selection, and got such a table.
Every row represents available selection mode, so there are 5 of them.
Display mode
faces selection type
selection mode
default overlays
checkbox
Result
1
xray
facedot
through
any
off
Xray with facedots selection
2
xray
area
through
any
on
Xray with area selection and no facedots
3
shaded
area
occlude
facedots off
off
Shaded with occluded area selection and no facedots
4
shaded
facedot
occlude
facedots on
off
Shaded with occluded area selection and facedots display
5
shaded
area
through
any
on
Shaded with through area selection and no facedots
This way, a checkbox, proposed by @Rawalanche, will override overlays to perform area faces selection for every type of selection tool.
Is everything complete?
I was looking through possible solution realizations for **paragraph C**, like [that one ](https://blenderartists.org/t/box-select-x-ray/1212316/80?u=1d_inc).
It is interesting approach - to create special subset of selecting tools, but they refers to Xray (because it is an addon, and have limitations), that makes through selection result different from regular one.
So I thought about combinations of cases to satisfy, to provide the ability to check possible solutions for compliance.
I applied my proposal of the checkbox state invertion in this table, to make it enabling faces area selection, and got such a table.
Every row represents available selection mode, so there are 5 of them.
| |Display mode |faces selection type |selection mode |default overlays| checkbox| Result|
| -- | -- | -- | -- | -- | -- | -- |
|1 |xray |facedot |through | any| off| Xray with facedots selection
|2 |xray |area |through |any| on|Xray with area selection and no facedots
|3 |shaded |area |occlude |facedots off| off| Shaded with occluded area selection and no facedots
|4 |shaded |facedot |occlude | facedots on| off| Shaded with occluded area selection and facedots display
|5 |shaded |area |through |any| on| Shaded with through area selection and no facedots
This way, a checkbox, proposed by @Rawalanche, will override overlays to perform area faces selection for every type of selection tool.
Is everything complete?
In #73479#913853, @1D_Inc wrote:
I was looking through possible solution realizations for paragraph C, like that one .
It is interesting approach - to create special subset of selecting tools, but they refers to Xray (because it is an addon, and have limitations), that makes through selection result different from regular one.
So I thought about combinations of cases to satisfy, to provide the ability to check possible solutions for compliance.
I applied my proposal of the checkbox state invertion in this table, to make it enabling faces area selection, and got such a table.
Every row represents available selection mode, so there are 5 of them.
| |Display mode |faces selection type |selection mode |default overlays| checkbox| Result|
|1 |xray |facedot |through | any| off| Xray with facedots selection
|2 |xray |area |through |any| on|Xray with area selection and no facedots
|3 |shaded |area |occlude |facedots off| off| Shaded with occluded area selection and no facedots
|4 |shaded |facedot |occlude | facedots on| off| Shaded with occluded facedots selection
|5 |shaded |area |through |any| on| Shaded with through area selection and no facedots
This way, a checkbox, proposed by @ludvignygren, will override overlays to perform area faces selection for every type of selection tool.
Is everything complete?
The point of this is to be simple. More does not always mean better. Some of these combinations do not make sense.
Makes sense
Does only partially make sense. If you have Xray display you see occluded faces but you can not select them by a single click as multiple face areas may overlap, so only box select would work there.
Makes sense
Does not make sense. There is not benefit of using the face dots for selection if you don't see occluded faces. The whole reason face dots were ever created was exactly that. If you don't have any transparency but you still use face dots to select you literally get worst of the both wordls.
Makes sense.
Now, the 3 out of 5 options that make sense can be easily mapped to my mockup above.
Would be when icon button is enabled and sub-option checkbox is enabled.
Would be when icon button is disabled (and therefore sub option is frozen).
Would be when icon button is enabled and sub-option checkbox is disabled.
> In #73479#913853, @1D_Inc wrote:
> I was looking through possible solution realizations for **paragraph C**, like [that one ](https://blenderartists.org/t/box-select-x-ray/1212316/80?u=1d_inc).
>
> It is interesting approach - to create special subset of selecting tools, but they refers to Xray (because it is an addon, and have limitations), that makes through selection result different from regular one.
> So I thought about combinations of cases to satisfy, to provide the ability to check possible solutions for compliance.
> I applied my proposal of the checkbox state invertion in this table, to make it enabling faces area selection, and got such a table.
> Every row represents available selection mode, so there are 5 of them.
>
> | |Display mode |faces selection type |selection mode |default overlays| checkbox| Result|
> |1 |xray |facedot |through | any| off| Xray with facedots selection
> |2 |xray |area |through |any| on|Xray with area selection and no facedots
> |3 |shaded |area |occlude |facedots off| off| Shaded with occluded area selection and no facedots
> |4 |shaded |facedot |occlude | facedots on| off| Shaded with occluded facedots selection
> |5 |shaded |area |through |any| on| Shaded with through area selection and no facedots
>
> This way, a checkbox, proposed by @ludvignygren, will override overlays to perform area faces selection for every type of selection tool.
> Is everything complete?
The point of this is to be simple. More does not always mean better. Some of these combinations do not make sense.
1. Makes sense
2. Does only partially make sense. If you have Xray display you see occluded faces but you can not select them by a single click as multiple face areas may overlap, so only box select would work there.
3. Makes sense
4. Does not make sense. There is not benefit of using the face dots for selection if you don't see occluded faces. The whole reason face dots were ever created was exactly that. If you don't have any transparency but you still use face dots to select you literally get worst of the both wordls.
5. Makes sense.
Now, the 3 out of 5 options that make sense can be easily mapped to my mockup above.
1. Would be when icon button is enabled and sub-option checkbox is enabled.
3. Would be when icon button is disabled (and therefore sub option is frozen).
5. Would be when icon button is enabled and sub-option checkbox is disabled.
In #73479#913909, @Rawalanche wrote:
4. Does not make sense. There is not benefit of using the face dots for selection if you don't see occluded faces. The whole reason face dots were ever created was exactly that. If you don't have any transparency but you still use face dots to select you literally get worst of the both wordls.
This is your opinion only (and you are extremely opinionated). 4 is how I do my selecting. It has the speed advantages of shaded selection without having to switch shading modes, and the 'hitbox size' advantage with certain geometry of not accidentally overlapping the corner of a face. But the situational advantages are a moot point because...
...Cirno's addon that Paul linked to should be considered the gold standard for box selection. It's not just some idea or a rough proof of concept, it is working proof that you can have all the features, including dots or face area, or contained or overlapped edges, in x-ray or in shaded, without ruining anyone's workflow. Anyone can use any workflow and it doesn't interfere with someone else's flow. If only it were implemented in C in the standard Box Select tool instead of Python we could have the speed of native selection and the flexibility of options. Just pick sensible defaults and let the tweakers change what they will.
> In #73479#913909, @Rawalanche wrote:
> 4. Does not make sense. There is not benefit of using the face dots for selection if you don't see occluded faces. The whole reason face dots were ever created was exactly that. If you don't have any transparency but you still use face dots to select you literally get worst of the both wordls.
This is your opinion only (and you are extremely opinionated). 4 is how I do my selecting. It has the speed advantages of shaded selection without having to switch shading modes, and the 'hitbox size' advantage with certain geometry of not accidentally overlapping the corner of a face. But the situational advantages are a moot point because...
...Cirno's addon that Paul linked to should be considered the gold standard for box selection. It's not just some idea or a rough proof of concept, it is *working proof* that you can have *all the features*, including dots or face area, or contained or overlapped edges, in x-ray or in shaded, *without* ruining anyone's workflow. Anyone can use any workflow and it doesn't interfere with someone else's flow. If only it were implemented in C in the standard Box Select tool instead of Python we could have the speed of native selection and the flexibility of options. Just pick sensible defaults and let the tweakers change what they will.
What many (all?) of these ideas, mockups and suggested solutions don't address is that this is much more fundamental than just being about how X-ray works.
The basic paradigm in Blender is that you can select what you see. So, in Wireframe view, you can select any wire you click on, also on backfaces.
Blender could work differently, but most of the suggestions here conflict with the concept of you can select what you see. So the issue is not out of spite or anything like that, but because of this inherent conflict between two incompatible paradigms.
The only solution I can think of to address this conflict is a setting in Preferences called Decouple Selection from Visibility. Once this is set, we could show tool settings to Select Through or not.
This could address the conflict, but it would then be something users would have to enable in Preferences, and tools would have to check for this preference before showing the tool setting.
What many (all?) of these ideas, mockups and suggested solutions don't address is that this is much more fundamental than just being about how X-ray works.
The basic paradigm in Blender is that *you can select what you see*. So, in Wireframe view, you can select any wire you click on, also on backfaces.
Blender *could* work differently, but most of the suggestions here conflict with the concept of *you can select what you see*. So the issue is not out of spite or anything like that, but because of this inherent conflict between two incompatible paradigms.
The only solution I can think of to address this conflict is a setting in Preferences called *Decouple Selection from Visibility*. Once this is set, we could show tool settings to *Select Through* or not.
This could address the conflict, but it would then be something users would have to enable in Preferences, and tools would have to check for this preference before showing the tool setting.
In #73479#913909, @Rawalanche wrote:
2. Does only partially make sense.
Maybe so. Just put it as an option, because it is ISS related, to present a full cycle of possible options.
4 Does not make sense.
The problem is that facedots are used not only for direct access, but also for analysing topology structure.
Thats why Blender is that good for fixing messy imported meshes at industry level - it allow you to see the topological issues directly. That's one of the points of the facedots concept.
Here is a brief example of topology problems that facedots reveals, but it is a secret, please don't tell anyone.
Now, the 3 out of 5 options that make sense can be easily mapped to my mockup above.
Would be when icon button is enabled and sub-option checkbox is enabled.
Would be when icon button is enabled and sub-option checkbox is disabled.
I know, this is inversion I proposed - to enable checkbox if you need to enable Faces area selection.
It could be more consistent, if you enabling faces area selection by enabling checkbox, instead of disabling it. That's the idea behind such invertion.
Would be when icon button is disabled (and therefore sub option is frozen).
Not anymore, we've got a mode to satisfy, and it pretty much fits the conditions)
So I expanded your proposal a bit. However, I will not insist on that one.
In #73479#913930, @WilliamReynish wrote:
The only solution I can think of to address this conflict is a setting in Preferences called Decouple Selection from Visibility.
We are currently discussing the checkbox that requires such an option.
Or may be such an option.
> In #73479#913909, @Rawalanche wrote:
> 2. Does only partially make sense.
Maybe so. Just put it as an option, because it is ISS related, to present a full cycle of possible options.
> 4 Does not make sense.
The problem is that facedots are used not only for direct access, but also for analysing topology structure.
Thats why Blender is that good for fixing messy imported meshes at industry level - it allow you to see the topological issues directly. That's one of the points of the facedots concept.
Here is a brief example of topology problems that facedots reveals, but it is a secret, please don't tell anyone.
> Now, the 3 out of 5 options that make sense can be easily mapped to my mockup above.
> 1. Would be when icon button is enabled and sub-option checkbox is enabled.
> 5. Would be when icon button is enabled and sub-option checkbox is disabled.
I know, this is inversion I proposed - to enable checkbox if you need to enable Faces area selection.
It could be more consistent, if you *enabling* faces area selection by *enabling* checkbox, instead of *disabling* it. That's the idea behind such invertion.
> 3. Would be when icon button is disabled (and therefore sub option is frozen).
Not anymore, we've got a mode to satisfy, and it pretty much fits the conditions)
So I expanded your proposal a bit. However, I will not insist on that one.
> In #73479#913930, @WilliamReynish wrote:
> The only solution I can think of to address this conflict is a setting in Preferences called Decouple Selection from Visibility.
We are currently discussing the checkbox that requires such an option.
Or may **be** such an option.
In #73479#913999, @1D_Inc wrote:
The problem is that facedots are used not only for direct access, but also for analysing topology structure.
Thats why Blender is that good for fixing messy imported meshes at industry level - it allow you to see the topological issues directly. That's one of the points of the facedots.
Here is a brief example of topology problems that facedots reveals, but it is a secret, please don't tell anyone.
This is just a byproduct of facedots. It's kind of like turning a bug into a feature. I come from 3ds Max and I myself have learned to utilize many of the design flaws as features in minority of use cases, but that changed nothing about the fact that in majority of cases, it was a flaw. There could easily be a mode or drawing style which would show you overlapping edges even without face dots :) Or if face dots sole purpose was a debug drawing of overlapping edges, that'd also work. But their main purpose is to modify a selection method, not to display overlapping edges. Making overlapping edges visible is really just a side effect.
> In #73479#913999, @1D_Inc wrote:
> The problem is that facedots are used not only for direct access, but also for analysing topology structure.
> Thats why Blender is that good for fixing messy imported meshes at industry level - it allow you to see the topological issues directly. That's one of the points of the facedots.
> Here is a brief example of topology problems that facedots reveals, but it is a secret, please don't tell anyone.
> 
This is just a byproduct of facedots. It's kind of like turning a bug into a feature. I come from 3ds Max and I myself have learned to utilize many of the design flaws as features in minority of use cases, but that changed nothing about the fact that in majority of cases, it was a flaw. There could easily be a mode or drawing style which would show you overlapping edges even without face dots :) Or if face dots sole purpose was a debug drawing of overlapping edges, that'd also work. But their main purpose is to modify a selection method, not to display overlapping edges. Making overlapping edges visible is really just a side effect.
In #73479#913930, @WilliamReynish wrote:
What many (all?) of these ideas, mockups and suggested solutions don't address is that this is much more fundamental than just being about how X-ray works.
The basic paradigm in Blender is that you can select what you see. So, in Wireframe view, you can select any wire you click on, also on backfaces.
Blender could work differently, but most of the suggestions here conflict with the concept of you can select what you see. So the issue is not out of spite or anything like that, but because of this inherent conflict between two incompatible paradigms.
The only solution I can think of to address this conflict is a setting in Preferences called Decouple Selection from Visibility. Once this is set, we could show tool settings to Select Through or not.
This could address the conflict, but it would then be something users would have to enable in Preferences, and tools would have to check for this preference before showing the tool setting.
Yes, you sound like a broken record about that already. What's even more fundamental than "select what you see" is a question if such paradigm is even valid. There were many flawed paradigms in Blender over its history, removal of which led to more productivity and better ease of use. There are quite a few other DCCs out there which don't have "select what you see" paradigm, and I have never seen members of their userbase requesting that to change. Here we have Blender, which does have the aforementioned paradigm, and along with that, a 123 reply long thread of people wanting it to change.
But to expand on your proposed solution, specifically:
The only solution I can think of to address this conflict is a setting in Preferences called Decouple Selection from Visibility. Once this is set, we could show tool settings to Select Through or not.
If that was the case, then a good way to go about it would be for this user preference to redefine what this button does:
...so that once Decouple Selection from Visibility is enabled, this button would toggle select through instead of Xray, and Xray drawing (not modifying the selection method) would remain as an option here, in shading popover:
But it would be very unfortunate if select through option ended up in the tool settings. Such mistake was already done in case of free origin transform, which was crammed into the tool options, which is inappropriate place for it. I really hope the same mistake won't be repeated here.
> In #73479#913930, @WilliamReynish wrote:
> What many (all?) of these ideas, mockups and suggested solutions don't address is that this is much more fundamental than just being about how X-ray works.
>
> The basic paradigm in Blender is that *you can select what you see*. So, in Wireframe view, you can select any wire you click on, also on backfaces.
>
> Blender *could* work differently, but most of the suggestions here conflict with the concept of *you can select what you see*. So the issue is not out of spite or anything like that, but because of this inherent conflict between two incompatible paradigms.
>
> The only solution I can think of to address this conflict is a setting in Preferences called *Decouple Selection from Visibility*. Once this is set, we could show tool settings to *Select Through* or not.
>
> This could address the conflict, but it would then be something users would have to enable in Preferences, and tools would have to check for this preference before showing the tool setting.
Yes, you sound like a broken record about that already. What's even more fundamental than "select what you see" is a question if such paradigm is even valid. There were many flawed paradigms in Blender over its history, removal of which led to more productivity and better ease of use. There are quite a few other DCCs out there which don't have "select what you see" paradigm, and I have never seen members of their userbase requesting that to change. Here we have Blender, which does have the aforementioned paradigm, and along with that, a 123 reply long thread of people wanting it to change.
But to expand on your proposed solution, specifically:
> The only solution I can think of to address this conflict is a setting in Preferences called *Decouple Selection from Visibility*. Once this is set, we could show tool settings to *Select Through* or not.
If that was the case, then a good way to go about it would be for this user preference to redefine what this button does:
...so that once *Decouple Selection from Visibility* is enabled, this button would toggle select through instead of Xray, and Xray **drawing** (not modifying the selection method) would remain as an option here, in shading popover:
But it would be very unfortunate if select through option ended up in the tool settings. Such mistake was already done in case of free origin transform, which was crammed into the tool options, which is inappropriate place for it. I really hope the same mistake won't be repeated here.
In #73479#914018, @Rawalanche wrote:
I come from 3ds Max.
So, you are also from 3dsmax. That's nice)
"Facedots? Vertex extrude? Pivot point? 123? Multimaterial?"
Yes, I remember that way of thinking.
> In #73479#914018, @Rawalanche wrote:
>I come from 3ds Max.
So, you are also from 3dsmax. That's nice)
"Facedots? Vertex extrude? Pivot point? 123? Multimaterial?"
Yes, I remember that way of thinking.
In #73479#913930, @WilliamReynish wrote:
The basic paradigm in Blender is that you can select what you see. So, in Wireframe view, you can select any wire you click on, also on backfaces.
I need to put something related on the table here and now, because I know it would slip through otherwise, namely: Ignore backfacing geometry for selection while in Solid view mode if Backface Culling is enabled.
Select edges in Wireframe Viewport Shading even on backfaces is ok because you are seeing them, but why backfaces are selectable in Solid Viewport Shading mode when Backface Culling is enabled? They also block any selection of the actually visible mesh: vertices, edges or faces. Just consider this scenario: while editing the interior of a high rise building, you'll select the invisible ceiling whenever you try to select the walls of the last floor. There is no way of doing so intuitively now, you have to enable xray and deal with erratic selections on stacked meshes like this, or hide the backfacing geometry beforehand. I see this like the perfect example of why you should only be able to select what you can see, and is really frustating: although being against that philosophy of the program which block certain features like the one being discussed here, is still present.
A few months ago, Backface Culling was added as an option to Snapping in order to avoid a similar issue: the inability to snap to something you are seeing through culled geometry. I hope "Select through culled geometry while in Solid Viewport Shading mode" will be considered to be added as an option for any Select Tool as well, and be located on the Tool Settings, exposed on the Viewport Header, and activated by default.
> In #73479#913930, @WilliamReynish wrote:
> The basic paradigm in Blender is that *you can select what you see*. So, in Wireframe view, you can select any wire you click on, also on backfaces.
I need to put something related on the table here and now, because I know it would slip through otherwise, namely: Ignore backfacing geometry for selection while in Solid view mode if Backface Culling is enabled.
Select edges in Wireframe Viewport Shading even on backfaces is ok because you are seeing them, but why backfaces are selectable in Solid Viewport Shading mode when Backface Culling is enabled? They also block any selection of the actually visible mesh: vertices, edges or faces. Just consider this scenario: while editing the interior of a high rise building, you'll select the invisible ceiling whenever you try to select the walls of the last floor. There is no way of doing so intuitively now, you have to enable xray and deal with erratic selections on stacked meshes like this, or hide the backfacing geometry beforehand. I see this like the perfect example of why you should only be able to select what you can see, and is really frustating: although being against that philosophy of the program which block certain features like the one being discussed here, is still present.
A few months ago, Backface Culling was added as an option to Snapping in order to avoid a similar issue: the inability to snap to something you are seeing through culled geometry. I hope "Select through culled geometry while in Solid Viewport Shading mode" will be considered to be added as an option for any Select Tool as well, and be located on the Tool Settings, exposed on the Viewport Header, and activated by default.
In #73479#913930, @WilliamReynish wrote:
The basic paradigm in Blender is that you can select what you see. So, in Wireframe view, you can select any wire you click on, also on backfaces.
Ignore backfacing geometry for selection while in Solid view mode if Backface Culling is enabled.
A very nice point! Indeed, architectural interior design is built on the principle of nesting. That will be very useful to have an access to mesh through walls and ceiling, for example, during modeling a room space .
> In #73479#914792, @franMarz wrote:
>> In #73479#913930, @WilliamReynish wrote:
>> The basic paradigm in Blender is that *you can select what you see*. So, in Wireframe view, you can select any wire you click on, also on backfaces.
> Ignore backfacing geometry for selection while in Solid view mode if Backface Culling is enabled.
A very nice point! Indeed, architectural interior design is built on the principle of nesting. That will be very useful to have an access to mesh through walls and ceiling, for example, during modeling a [room space ](https://youtu.be/Xdwvl9JFr2M?t=88).
Fixed №4 row in this table from selecting by facedots to area selection with facedots display (current default behavior).
Thanks, @Rawalanche, I've got the point)
The sentence structure was incorrect.
|4 |shaded |facedot |occlude | facedots on| off| Shaded with occluded area selection and facedots display
Fixed №4 row in this [table ](https://developer.blender.org/T73479#913853) from **selecting by facedot**s to **area selection with facedots display** (current default behavior).
Thanks, @Rawalanche, I've got the point)
The sentence structure was incorrect.
> |4 |shaded |facedot |occlude | facedots on| off| Shaded with occluded area selection and facedots display
From personal experience I know how this tool work in 3DsMax, Maya and Cinema4D but I've used it mainly in Modo and they did a really good job in designing the tool.
By default you can box/lasso select with "right mouse button" and drag, this will select only the visible elements. If you use the "middle mouse button" and drag instead then it will select through. This is a tool that need be access quickly when modeling so perhaps it can be activated by holding a key while using the box/lasso selection tool).
The way you know it's selecting through is that you are able to see the selection through the mesh. This will give you a visual indication of what you have selected, without that you are more likely going to make mistakes not knowing exactly what you are selecting.
Hope this helps. Good luck!
From personal experience I know how this tool work in 3DsMax, Maya and Cinema4D but I've used it mainly in Modo and they did a really good job in designing the tool.
By default you can box/lasso select with "right mouse button" and drag, this will select only the visible elements. If you use the "middle mouse button" and drag instead then it will select through. This is a tool that need be access quickly when modeling so perhaps it can be activated by holding a key while using the box/lasso selection tool).
The way you know it's selecting through is that you are able to see the selection through the mesh. This will give you a visual indication of what you have selected, without that you are more likely going to make mistakes not knowing exactly what you are selecting.
Hope this helps. Good luck!
In #73479#917390, @giuseppebufalo wrote:
This is a tool that need be access quickly when modeling so perhaps it can be activated by holding a key while using the box/lasso selection tool).
The way you know it's selecting through is that you are able to see the selection through the mesh. This will give you a visual indication of what you have selected, without that you are more likely going to make mistakes not knowing exactly what you are selecting.
I've seen similar realization in 1C game studio, they assigned LSTV toggle to a hotkey to select through.
I would suggest avoiding any kind of key holding because it quickly turns into finger push-ups during intense work.
Hope this helps. Good luck!
Thanks)
> In #73479#917390, @giuseppebufalo wrote:
> This is a tool that need be access quickly when modeling so perhaps it can be activated by holding a key while using the box/lasso selection tool).
> The way you know it's selecting through is that you are able to see the selection through the mesh. This will give you a visual indication of what you have selected, without that you are more likely going to make mistakes not knowing exactly what you are selecting.
I've seen similar realization in 1C game studio, they assigned LSTV toggle to a hotkey to select through.
I would suggest avoiding any kind of key holding because it quickly turns into finger push-ups during intense work.
> Hope this helps. Good luck!
Thanks)
There's very concerning lack of progress on this. I have again wasted hours and hours of time past two weeks just having to wrangle xray mode on and off again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again...
There's very concerning lack of progress on this. I have again wasted hours and hours of time past two weeks just having to wrangle xray mode on and off again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again...
In #73479#919446, @Rawalanche wrote:
just having to wrangle xray mode on and off
We also feel such discomfort from lots of "again" behavior from things that was added or removed recently.
You also assigned Burninate token to this design task, please, be careful with that.
> In #73479#919446, @Rawalanche wrote:
> just having to wrangle xray mode on and off
We also feel such discomfort from lots of "again" behavior from things that was added or removed recently.
You also assigned Burninate token to this design task, please, be careful with that.
In #73479#919446, @Rawalanche wrote:
just having to wrangle xray mode on and off
We also feel such discomfort from lots of "again" behavior from things that was added or removed recently.
You also assigned Burninate token to this design task, please, be careful with that.
Why? I did not even know it's named burninate. I don't think those tokens really mean anything. At least for me, the meaning of the fire icon is that it's urgent.
> In #73479#919725, @1D_Inc wrote:
>> In #73479#919446, @Rawalanche wrote:
>> just having to wrangle xray mode on and off
> We also feel such discomfort from lots of "again" behavior from things that was added or removed recently.
> You also assigned Burninate token to this design task, please, be careful with that.
> 
Why? I did not even know it's named burninate. I don't think those tokens really mean anything. At least for me, the meaning of the fire icon is that it's urgent.
Select Through is needed for special type of modeling when topology is predictable for user (like gamedev modeling).
It is widespread behaviour in industry standards software.
The proposal is about
The ability for box/lasso (non-picking) tools to select backface geometry on shaded model without backface display.
The ability for box/lasso (non-picking) tools to select faces in wireframe/Xray mode by their bounds (with no facedots display).
Possible Xray solutions:
A.1) Split Xray alpha settings for object and edit modes, since alpha = 1 is suitable only for edit mode, and satisfies LSTV - Limit Selection To Visible - demands. A.2) Add the ability to fade with slider backfacing wiremesh display in Xray mode down to zero.
A.1 and A.2 will make select through with facedots selection mode available.
B.1) Add Xray/Wiremesh mode facedot center disabling option, what will make possible faces area selection for all non-picking selecting tools and methods,
separating the selection mode from the display mode.
Possible design:
or better like this (because takes the same space, but makes option easily accessible, detectable and independent from Xray)
B.2) The option's behavior must satisfy the following conditions:
Display mode
faces selection type
selection mode
default overlays
option
Result
1
xray/wire
facedot
through
any
off
Xray/wire with facedots selection
2
xray/wire
area
through
any
on
Xray/wire with area selection and no facedots
3
solid
area
occlude
facedots off
off
Solid with occluded area selection and no facedots
4
solid
area
occlude
facedots on
off
Solid with occluded area selection and facedots display
5
solid
area
through
any
on
Solid with through area selection and no facedots
B.1 and B.2 will make select through mode detectable with no facedots display.
It is also possible to use it temporarily (switch it) or work constantly in that mode if it is needed, depending on a workflow type, because users who will use such option do not need regular Xray, in cases when Xray spoils the viewport.
Additional / Questionable / Offtop:
X.1) Ability to select visible with backface culling in shaded mode to satisfy selecting visible condition. An example of use is interior basemesh modeling.
X.2 ) Split Xray and Wireframe modes, since wireframe without Xray clones Flat shading mode, so it is more about visual style rather than shading mode. (questionable)
X.3) The reasons for separating the selection tools for the edit and object modes are not obvious.
Well, updating summarizing post?
- Select Through is needed for special type of modeling when topology is predictable for user (like gamedev modeling).
It is widespread behaviour in industry standards software.
**The proposal is about**
1) The ability for box/lasso (non-picking) tools to select backface geometry on shaded model without backface display.
2) The ability for box/lasso (non-picking) tools to select faces in wireframe/Xray mode by their bounds (with no facedots display).
**Possible Xray solutions:**
**A.1**) Split Xray alpha settings for object and edit modes, since alpha = 1 is suitable only for edit mode, and satisfies LSTV - Limit Selection To Visible - demands.
**A.2**) Add the ability to fade with slider backfacing wiremesh display in Xray mode down to zero.
A.1 and A.2 will make select through with facedots selection mode available.
**B.1**) Add Xray/Wiremesh mode facedot center disabling option, what will make possible faces area selection for all non-picking selecting tools and methods,
separating the selection mode from the display mode.
Possible design:
or better like this (because takes the same space, but makes option easily accessible, detectable and independent from Xray)
**B.2**) The option's behavior must satisfy the following conditions:
| |Display mode |faces selection type |selection mode |default overlays| option| Result|
| -- | -- | -- | -- | -- | -- | -- |
|1 |xray/wire |facedot |through | any| off| Xray/wire with facedots selection
|2 |xray/wire |area |through |any| on|Xray/wire with area selection and no facedots
|3 |solid |area |occlude |facedots off| off| Solid with occluded area selection and no facedots
|4 |solid |area |occlude | facedots on| off| Solid with occluded area selection and facedots display
|5 |solid |area |through |any| on| Solid with through area selection and no facedots
B.1 and B.2 will make select through mode detectable with no facedots display.
It is also possible to use it temporarily (switch it) or work constantly in that mode if it is needed, depending on a workflow type, because users who will use such option do not need regular Xray, in cases when Xray spoils the viewport.
Additional / Questionable / Offtop:
X.1) Ability to select visible with backface culling in shaded mode to satisfy selecting visible condition. An example of use is interior basemesh modeling.
X.2 ) Split Xray and Wireframe modes, since wireframe without Xray clones Flat shading mode, so it is more about visual style rather than shading mode. (questionable)
X.3) The reasons for separating the selection tools for the edit and object modes are not obvious.
I'd also add that the select through should only modify box/lasso/circle selection, but the single click selection should remain at the behavior of current occluded selection. So that single-clicking things like vertices or edges does not accidentally select elements on the back of the mesh. Select through without Xray should really only affect box/lasso/circle area selection modes.
And one more important thing, when select through is enabled but Xray is off, as requested by many, Wireframe mode should still draw a fully transparent wireframe, not occluded wireframe. Right now, wireframe display is tied to Xray mode, which causes issue because many "select through" users rely on ability to quickly switch to wireframe mode to occasionally have better awareness of what they are selecting. And please don't mention that the current Xray behavior already does that (preemptively anticipating William's reply), because the giant difference here is that in Blender, currently, it's mandatory, not optional.
Both of these things are important details that the original path from Kio did correctly, so they must not be omitted here either.
I'd also add that the select through should only modify box/lasso/circle selection, but the single click selection should remain at the behavior of current occluded selection. So that single-clicking things like vertices or edges does not accidentally select elements on the back of the mesh. Select through without Xray should really only affect box/lasso/circle area selection modes.
And one more important thing, when select through is enabled but Xray is off, as requested by many, Wireframe mode should still draw a fully transparent wireframe, not occluded wireframe. Right now, wireframe display is tied to Xray mode, which causes issue because many "select through" users rely on ability to quickly switch to wireframe mode to occasionally have better awareness of what they are selecting. And please don't mention that the current Xray behavior already does that (preemptively anticipating William's reply), because the giant difference here is that in Blender, currently, it's mandatory, not optional.
Both of these things are important details that the original path from Kio did correctly, so they must not be omitted here either.
In #73479#927544, @Rawalanche wrote:
So that single-clicking things like vertices or edges does not accidentally select elements on the back of the mesh.
Agree.
And one more important thing, when select through is enabled but Xray is off, as requested by many, Wireframe mode should still draw a fully transparent wireframe, not occluded wireframe.
Agree. I think that occluded mesh display just duplicates functionality of Flat Lighting viewport shading mode.
I didn't found other cases when occluded wire mesh display mode could be useful, and would like to know if such cases exist.
Changed Xray positions in table to Xray/Wire.
> In #73479#927544, @Rawalanche wrote:
> So that single-clicking things like vertices or edges does not accidentally select elements on the back of the mesh.
Agree.
> And one more important thing, when select through is enabled but Xray is off, as requested by many, Wireframe mode should still draw a fully transparent wireframe, not occluded wireframe.
Agree. I think that occluded mesh display just duplicates functionality of Flat Lighting viewport shading mode.
I didn't found other cases when occluded wire mesh display mode could be useful, and would like to know if such cases exist.
Changed Xray positions in table to Xray/Wire.
This is quite a discussion for such a simple and uncontroversial feature :) Anyway, here's my attempt to summarize it and add some suggestions.
Where this option is stored, accessed?
Tool settings in properties editor. (Image below)
Which selection tools/operators should use this?
Box, lasso, circle
Which modes this should be supported in (edit, pose, grease pencil... etc)
Any mode, where it would be useful.
How to display this option when in wire-frame display (when the user will always select-through)
I don't think there's anything to display since this feature only applies to solid shading. Wire and X-Ray function the same way as before.
How to access this from both active-tools & key-bindings?
Putting this in the tool setting means that it's very easy for users to add it to Quick Favourites or assign a shortcut. Additionally there could be a checkbox in the 3D viewport header.
How to make it obvious selecting-trough is enabled (draw style, cursor - this might help avoid confusion).
As suggested above selection border could have a different colour. Also temporarily enabling x-ray while dragging a selection like in Cirno's addon would make it really obvious and help to see what you're selecting. 3rd option is to have selection preview: elements (or objects) would light up as you drag the selection marquee to show what will be selected, if you release the mouse at that moment. This setting would highlight even occluded geometry with a pseudo x-ray shading (if that's technically possible).
Should this be supported in object mode too?(the reverse since objects already select-through), IIRC we discussed having this option for box select too.
Yes. An option to prevent occluded objects from getting selected in object mode would be useful.
Related Topics
In addition to giving the users explicit control when to use facedots or area selection, I think it also important to have control how area selection works in general. Basically there are 2 methods: a) selecting everything that at least partially intersects selection area, or b) selecting only the objects/subobjects that are entirely within the selection area. Right now there's no way to do that in Blender, but this functionality can be added without the need for additional shortcuts by checking the direction in which you drag the selection area. In this example dragging left to right selects everything, while dragging right to left selects only a few faces that are fully inside the area.
To indicate which method is used the selection border has a different appearance. Although selection preview would work even better. This feature should also apply to edge selection and object mode.
Another thing is Backface selection. Right now there's no way to disable it, even if Backface Culling is enabled, so there needs to be an option for that.
Here's a mock-up of how these features are presented in the UI. My formatting is probably all wrong and feature names are up for debate, but you get the idea.
Select by Facedots needs a separate checkbox for each shading mode to emulate current behaviour, where it's enabled automatically for Wireframe and X-Ray. I think this covers most of the issues discussed in this thread, but most importantly, it can be configured to make Blender function in a same way it does now by default.
I know these proposals go beyond the scope of this task, and maybe should be split into their own task. But the discussion already expanded into other areas, so I'm just putting them here in case it gives the developers some ideas.
This is quite a discussion for such a simple and uncontroversial feature :) Anyway, here's my attempt to summarize it and add some suggestions.
> Where this option is stored, accessed?
Tool settings in properties editor. (Image below)
>Which selection tools/operators should use this?
Box, lasso, circle
>Which modes this should be supported in (edit, pose, grease pencil... etc)
Any mode, where it would be useful.
>How to display this option when in wire-frame display (when the user will always select-through)
I don't think there's anything to display since this feature only applies to solid shading. Wire and X-Ray function the same way as before.
>How to access this from both active-tools & key-bindings?
Putting this in the tool setting means that it's very easy for users to add it to Quick Favourites or assign a shortcut. Additionally there could be a checkbox in the 3D viewport header.
>How to make it obvious selecting-trough is enabled (draw style, cursor - this might help avoid confusion).
As suggested above selection border could have a different colour. Also temporarily enabling x-ray while dragging a selection like in [Cirno's addon ](https://blenderartists.org/t/box-select-x-ray/1212316) would make it really obvious and help to see what you're selecting. 3rd option is to have selection preview: elements (or objects) would light up as you drag the selection marquee to show what will be selected, if you release the mouse at that moment. This setting would highlight even occluded geometry with a pseudo x-ray shading (if that's technically possible).
>Should this be supported in object mode too?(the reverse since objects already select-through), IIRC we discussed having this option for box select too.
Yes. An option to prevent occluded objects from getting selected in object mode would be useful.
**Related Topics**
In addition to giving the users explicit control when to use facedots or area selection, I think it also important to have control how area selection works in general. Basically there are 2 methods: a) selecting everything that at least partially intersects selection area, or b) selecting only the objects/subobjects that are entirely within the selection area. Right now there's no way to do that in Blender, but this functionality can be added without the need for additional shortcuts by checking the direction in which you drag the selection area. In this example dragging left to right selects everything, while dragging right to left selects only a few faces that are fully inside the area.
To indicate which method is used the selection border has a different appearance. Although selection preview would work even better. This feature should also apply to edge selection and object mode.
Another thing is Backface selection. Right now there's no way to disable it, even if Backface Culling is enabled, so there needs to be an option for that.
Here's a mock-up of how these features are presented in the UI. My formatting is probably all wrong and feature names are up for debate, but you get the idea.
Select by Facedots needs a separate checkbox for each shading mode to emulate current behaviour, where it's enabled automatically for Wireframe and X-Ray. I think this covers most of the issues discussed in this thread, but most importantly, it can be configured to make Blender function in a same way it does now by default.
I know these proposals go beyond the scope of this task, and maybe should be split into their own task. But the discussion already expanded into other areas, so I'm just putting them here in case it gives the developers some ideas.
In #73479#930321, @slowburn wrote:
This is quite a discussion for such a simple and uncontroversial feature :)
This proposal does not even support all selection modes, only tools. So this is a controversial solution for a simple and uncontroversal feature.
> In #73479#930321, @slowburn wrote:
> This is quite a discussion for such a simple and uncontroversial feature :)
>
This proposal does not even support all selection modes, only tools. So this is a controversial solution for a simple and uncontroversal feature.
Indeed, this proposal does not apply to internal types of mesh selection, like B and C shortcuts, which are used more often because they are faster to invoke.
Also, I don’t think that just putting everything on the checkboxes is the right way to design. Proposal by @Rawalanche seems to be more accurate and complete.
I like the idea of side-dependent selection, which is a fairly common solution, and was proposed many times, but it is a separate design task.
> In #73479#930906, @slowburn wrote:
>>all selection modes
> What do you mean?
Indeed, this proposal does not apply to internal types of mesh selection, like B and C shortcuts, which are used more often because they are faster to invoke.
Also, I don’t think that just putting everything on the checkboxes is the right way to design. Proposal by @Rawalanche seems to be more accurate and complete.
I like the idea of side-dependent selection, which is a fairly common solution, and was proposed many times, but it is a separate design task.
Modal selection can have the same features available as the selection tool, the only difference is that they are controlled with shortcuts, like these:
Default configuration would be synchronised with tool setting so it would work in the same way.
The problem is that right now there is no place in Blender's UI for global selection settings (because there are no setting, just hardcoded stuff like Facedot selection in X-Ray). So tool settings looks like the only area where multiple options could be put in one place. And it could be made to work globally across Blender. Of course a dedicated space would be even better.
Ludvik's proposal to put selection-specific options in the area used for shading and overlays seems like an ad-hoc solution. It works well in this specific case, but cannot be expanded to accommodate additional options. For example, if Backface selection toggle is added in the future, where should the option be located? Next to 'Backface Culling' in Shading menu? I guess it depends on what kind of long term approach devs want take for selection tools - if all setting should be in one place or scattered around the UI.
Modal selection can have the same features available as the selection tool, the only difference is that they are controlled with shortcuts, like these: 
Default configuration would be synchronised with tool setting so it would work in the same way.
The problem is that right now there is no place in Blender's UI for global selection settings (because there are no setting, just hardcoded stuff like Facedot selection in X-Ray). So tool settings looks like the only area where multiple options could be put in one place. And it could be made to work globally across Blender. Of course a dedicated space would be even better.
Ludvik's proposal to put selection-specific options in the area used for shading and overlays seems like an ad-hoc solution. It works well in this specific case, but cannot be expanded to accommodate additional options. For example, if Backface selection toggle is added in the future, where should the option be located? Next to 'Backface Culling' in Shading menu? I guess it depends on what kind of long term approach devs want take for selection tools - if all setting should be in one place or scattered around the UI.
Ludvik's proposal to put selection-specific options in the area used for shading and overlays seems like an ad-hoc solution. It works well in this specific case, but cannot be expanded to accommodate additional options. For example, if Backface selection toggle is added in the future, where should the option be located? Next to 'Backface Culling' in Shading menu? I guess it depends on what kind of long term approach devs want take for selection tools - if all setting should be in one place or scattered around the UI.
I did not put it there at all. The Xray button was put on that place by a dev team. What I am against is the way they combined a viewport shading changing feature and selection method changing feature into one feature which can not be toggled separately.
> In #73479#932334, @slowburn wrote:
> Ludvik's proposal to put selection-specific options in the area used for shading and overlays seems like an ad-hoc solution. It works well in this specific case, but cannot be expanded to accommodate additional options. For example, if Backface selection toggle is added in the future, where should the option be located? Next to 'Backface Culling' in Shading menu? I guess it depends on what kind of long term approach devs want take for selection tools - if all setting should be in one place or scattered around the UI.
I did not put it there at all. The Xray button was put on that place by a dev team. What I am against is the way they combined a viewport shading changing feature and selection method changing feature into one feature which can not be toggled separately.
In #73479#932334, @slowburn wrote:
Modal selection can have the same features available as the selection tool, the only difference is that they are controlled with shortcuts
Selection is selection, no matter which tool is used. It does not make sense to split modes per tools, since the same result is expected from any kind or way selection is performed.
The problem is that right now there is no place in Blender's UI for global selection settings.
There is no problem, because it is just selection, not a rocket science. Selection should be simple, predictable and satisfy some certain conditions to be good. This is the point of concise design.
Ludvik's proposal to put selection-specific options in the area used for shading and overlays seems like an ad-hoc solution. It works well in this specific case, but cannot be expanded to accommodate additional options.
As Ludvik said, Xray/Wireframe is already affecting the selection mode as well. This is part of the "you can select what you see" paradigm.
For example, if Backface selection toggle is added in the future, where should the option be located? Next to 'Backface Culling' in Shading menu?
It will not be a toggle. It will be a bugfix of a a very ancient problem, that breaks "you can select what you see" paradigm all this time.
> In #73479#932334, @slowburn wrote:
> Modal selection can have the same features available as the selection tool, the only difference is that they are controlled with shortcuts
Selection is selection, no matter which tool is used. It does not make sense to split modes per tools, since the same result is expected from any kind or way selection is performed.
> The problem is that right now there is no place in Blender's UI for global selection settings.
There is no problem, because it is just selection, not a rocket science. Selection should be simple, predictable and satisfy some certain conditions to be good. This is the point of concise design.
> Ludvik's proposal to put selection-specific options in the area used for shading and overlays seems like an ad-hoc solution. It works well in this specific case, but cannot be expanded to accommodate additional options.
As Ludvik said, Xray/Wireframe is already affecting the selection mode as well. This is part of the "you can select what you see" paradigm.
> For example, if Backface selection toggle is added in the future, where should the option be located? Next to 'Backface Culling' in Shading menu?
It will not be a toggle. It will be a bugfix of a a very ancient problem, that breaks "you can select what you see" paradigm all this time.
Ok, perhaps I didn't explain this properly in my proposal, but options that are placed in the tool settings are synchronized across all tools that share those options. Take a look at Drag option for example: if you set the Drag action to be Select Lasso, all tools will do a Lasso Select. So it's not tool-specific, but a global toggle. Select Through (or any other selection-related option) would work the same way. Here's how it would look like placed in the header:
Since Select Through is something you might want to toggle more often, depending on situation, it gets a separate button (which also works as a visual indicator, solving one of the design goals). Whereas Facedot selection is more of a general workflow preference, so it can be hidden in a drop-down menu. This is a simple and concise solution, that doesn't complicate selection process in any way, but places useful options always within reach in case you need them.
It will be a bugfix of a a very ancient problem, that breaks "you can select what you see" paradigm all this time.
It's not that simple. Even with Backface Culling enabled, only the solid shading of polygons is disabled, but vertices and edges are visible. So you can still select what you see, without braking any paradigm. I think it's better to take the same approach as with this task and clearly decouple selection behaviour from the shading mode.
> It does not make sense to split modes per tools
Ok, perhaps I didn't explain this properly in my proposal, but options that are placed in the tool settings are synchronized across all tools that share those options. Take a look at Drag option for example: if you set the Drag action to be Select Lasso, all tools will do a Lasso Select. So it's not tool-specific, but a global toggle. Select Through (or any other selection-related option) would work the same way. Here's how it would look like placed in the header:
Since Select Through is something you might want to toggle more often, depending on situation, it gets a separate button (which also works as a visual indicator, solving one of the design goals). Whereas Facedot selection is more of a general workflow preference, so it can be hidden in a drop-down menu. This is a simple and concise solution, that doesn't complicate selection process in any way, but places useful options always within reach in case you need them.
>It will be a bugfix of a a very ancient problem, that breaks "you can select what you see" paradigm all this time.
It's not that simple. Even with Backface Culling enabled, only the solid shading of polygons is disabled, but vertices and edges are visible. So you can still select what you see, without braking any paradigm. I think it's better to take the same approach as with this task and clearly decouple selection behaviour from the shading mode.
In #73479#935525, @slowburn wrote:
Ok, perhaps I didn't explain this properly in my proposal, but options that are placed in the tool settings are synchronized across all tools that share those options.
...
Here's how it would look like placed in the header:
That looks better, since it is available in fullscreen, that makes mode easily detectable.
But I am not sure what is the reason to see facedots, but not select by facedots in xray/wireframe. It will be rather confusing.
Also, this header will apply to the entire selection as a whole, even if it is assigned to each selection tool separately, that can be confusing as well.
Can you make action table for your proposal, like in that summarizing post to make things clear, and to be sure that there are no doubling options (like same selection behavior when option is turned on and off)?
It looks like combinations of all those options and modes are not mutually exclusive, and checking actual selection state according to this scheme requires a complex mindmap.
Since Select Through is something you might want to toggle more often, depending on situation, it gets a separate button (which also works as a visual indicator, solving one of the design goals).
Not sure, it will be used quite often (because of why?). It will be used mostly for depicting mode rather than toggling, since its area of use is general workflow-dependent.
This option is actually designed to avoid "again and again" toggling actions.
Basically, it will be turned on constantly while working with mesh with predictable backface geometry, and turned off while working with complex/unpredictable backface geometry,
because only wireframe/Xray/LSTV modes make selection predictable for such kind of models.
Whereas Facedot selection is more of a general workflow preference, so it can be hidden in a drop-down menu.
No, the scope of use facedots is case-dependent and is related to mesh fixing and topology control cases, and also dependent on model's complexity.
Facedots is topology checking tool, that works similar to checking normals tool, checking non-manifold tool or any other topology checking tools. If there are too many things to check, you just start using them on an ongoing basis.
I can tell the reason Blender has got facedots, it is related to Blender's mesh paradigm.
It will be a bugfix of a a very ancient problem, that breaks "you can select what you see" paradigm all this time.
It's not that simple. Even with Backface Culling enabled, only the solid shading of polygons is disabled, but vertices and edges are visible. So you can still select what you see, without braking any paradigm.
There is no ability to select visible vertices or edges in backface culling mode, like this, even if we see them:
As for the selection modes - I do not see the need to separate it between the object and the editing mode.
For instance, if I use tweak tool, or box selection, I use it independently of mode, because it is easy to remember what selection mode was used right now.
It’s rather inconvenient to lose the chosen selection mode each time you exit the editi mode to get the selection mode that you used, for example, an hour ago in object mode.
> In #73479#935525, @slowburn wrote:
> Ok, perhaps I didn't explain this properly in my proposal, but options that are placed in the tool settings are synchronized across all tools that share those options.
>...
>Here's how it would look like placed in the header:
> 
That looks better, since it is available in fullscreen, that makes mode easily detectable.
But I am not sure what is the reason to see facedots, but not select by facedots in xray/wireframe. It will be rather confusing.
Also, this header will apply to the entire selection as a whole, even if it is assigned to each selection tool separately, that can be confusing as well.
Can you make action table for your proposal, like in that [summarizing post ](https://developer.blender.org/T73479#926945) to make things clear, and to be sure that there are no doubling options (like same selection behavior when option is turned on and off)?
It looks like combinations of all those options and modes are not mutually exclusive, and checking actual selection state according to this scheme requires a complex mindmap.
> Since Select Through is something you might want to toggle more often, depending on situation, it gets a separate button (which also works as a visual indicator, solving one of the design goals).
Not sure, it will be used quite often (because of why?). It will be used mostly for depicting mode rather than toggling, since its area of use is general workflow-dependent.
This option is actually **designed** to avoid "again and again" toggling actions.
Basically, it will be turned on constantly while working with mesh with predictable backface geometry, and turned off while working with complex/unpredictable backface geometry,
because only wireframe/Xray/LSTV modes make selection predictable for such kind of models.
>Whereas Facedot selection is more of a general workflow preference, so it can be hidden in a drop-down menu.
No, the scope of use facedots is case-dependent and is related to mesh fixing and topology control cases, and also dependent on model's complexity.
Facedots is topology checking tool, that works similar to checking normals tool, checking non-manifold tool or any other topology checking tools. If there are too many things to check, you just start using them on an ongoing basis.
I can tell the reason Blender has got facedots, it is related to Blender's mesh paradigm.
>>It will be a bugfix of a a very ancient problem, that breaks "you can select what you see" paradigm all this time.
> It's not that simple. Even with Backface Culling enabled, only the solid shading of polygons is disabled, but vertices and edges are visible. So you can still select what you see, without braking any paradigm.
There is no ability to select visible vertices or edges in backface culling mode, like this, even if we see them:
________________________________________________
As for the selection modes - I do not see the need to separate it between the object and the editing mode.
For instance, if I use tweak tool, or box selection, I use it independently of mode, because it is easy to remember what selection mode was used right now.
It’s rather inconvenient to lose the chosen selection mode each time you exit the editi mode to get the selection mode that you used, for example, an hour ago in object mode.
But I am not sure what is the reason to see facedots, but not select by facedots in xray/wireframe.
This "Select by Facedots" toggle only applies to Box/Lasso/Circle, but you still need to use facedots to pick a specific face, with a single click. Otherwise you would need to click multiple times to select a face that's behind other geometry. That's how it works in 3ds max and it's always frustrating.
Also, this header will apply to the entire selection as a whole, even if it is assigned to each selection tool separately
What do you mean "separately"? As I said these settings would work as a global toggle, so that selecting is always consistent across all tools, including modal selection that's activated with a keyboard shortcut.
Here are all possible combinations in a table.
Shading
faces selection type
selection mode
result
1
xray/wire
facedot
through
xray/wire with facedot selection
2
xray/wire
area
through
xray/wire with area selection and visible facedots
3
solid
facedot
through
solid with select through by facedots
4
solid
facedot
occlude
solid with occluded selection by facedots
5
solid
area
through
solid with select through by area
6
solid
area
occlude
solid with occluded selection by area
In combination 5 and 6 facedots could be enabled as an overlay without affecting selection, the way it works right now.
Not sure, it will be used quite often (because of why?)
Occluded selection is still a useful mode, even if hidden geometry is simple and predictable. The point of this option is to eliminate needles switching to x-ray to select-through, when you can do a "blind" selection, but whether you actually need to select trough is a different matter. I guess it all depends on the user preference, model and other factors that are hard to predict. But even if it's used just a couple of times in an hour, I think it's reasonable to put it in a header because it also works as an indicator. Controlling facedot selection also shouldn't be a problem, since it's just one click away in a drop-down menu.
The main takeaway here is that there are as many different opinions and workflows, as there are users. So the goal is to add these options in a way that's easy to configure to fit any workflow.
There is no ability to select visible vertices or edges in backface culling mode, like this, even if we see them
Yeah, that's a strange problem, but having a Backface Selection toggle would actually fix it in this case.
As for the selection modes - I do not see the need to separate it between the object and the editing mode.
I agree that drag action should be kept the same when switching modes. Not sure why it was done this way.
>But I am not sure what is the reason to see facedots, but not select by facedots in xray/wireframe.
This "Select by Facedots" toggle only applies to Box/Lasso/Circle, but you still need to use facedots to pick a specific face, with a single click. Otherwise you would need to click multiple times to select a face that's behind other geometry. That's how it works in 3ds max and it's always frustrating.
>Also, this header will apply to the entire selection as a whole, even if it is assigned to each selection tool separately
What do you mean "separately"? As I said these settings would work as a global toggle, so that selecting is always consistent across all tools, including modal selection that's activated with a keyboard shortcut.
Here are all possible combinations in a table.
| | Shading | faces selection type | selection mode | result
| -- | -- | -- | -- | -- |
| 1 | xray/wire | facedot | through | xray/wire with facedot selection
| 2 | xray/wire | area | through | xray/wire with area selection and visible facedots
| 3 | solid | facedot | through | solid with select through by facedots
| 4 | solid | facedot | occlude | solid with occluded selection by facedots
| 5 | solid | area | through | solid with select through by area
| 6 | solid | area | occlude | solid with occluded selection by area
In combination 5 and 6 facedots could be enabled as an overlay without affecting selection, the way it works right now.
>Not sure, it will be used quite often (because of why?)
Occluded selection is still a useful mode, even if hidden geometry is simple and predictable. The point of this option is to eliminate needles switching to x-ray to select-through, when you can do a "blind" selection, but whether you actually *need* to select trough is a different matter. I guess it all depends on the user preference, model and other factors that are hard to predict. But even if it's used just a couple of times in an hour, I think it's reasonable to put it in a header because it also works as an indicator. Controlling facedot selection also shouldn't be a problem, since it's just one click away in a drop-down menu.
The main takeaway here is that there are as many different opinions and workflows, as there are users. So the goal is to add these options in a way that's easy to configure to fit any workflow.
>There is no ability to select visible vertices or edges in backface culling mode, like this, even if we see them
Yeah, that's a strange problem, but having a Backface Selection toggle would actually fix it in this case.
>As for the selection modes - I do not see the need to separate it between the object and the editing mode.
I agree that drag action should be kept the same when switching modes. Not sure why it was done this way.
But I am not sure what is the reason to see facedots, but not select by facedots in xray/wireframe.
That's how it works in 3ds max and it's always frustrating.
Yes, this mode is frustrating in 3dsmax because it is the only mode there.
Unlike in 3dsmax, our solution provides both possible wireframe modes - for face area selection without facedots display and for faces center selection with facedots display, with simple way to control it.
Abscense of facedots in witeframe can clearly visually split face area mode for non-picking selection types, which can be useful while working with predictable geometry.
What do you mean "separately"? As I said these settings would work as a global toggle, so that selecting is always consistent across all tools, including modal selection that's activated with a keyboard shortcut.
It is not good idea to place global toggle to some local tools.
If you use move or bevel tool, you still able to make selection with B or C, but can't define if select through mode is currentry in use, because toolbar preferences are occupied with move or bevel tool settings.
Here are all possible combinations in a table.
The problem is that this table is far from being complete in case of your proposal, since all binary combinations of all proposed checkboxes and options should be listed in it.
Our table is not just listening modes, it contains all possible combinations of options used in our proposal, that is why we can argue that it is minimalistic.
So your table should look like this.
Shading
faces selection type
selection mode
default overlays
option
wire checkbox
Xray checkbox
Solid checkbox
result
There will be way more than 6 combinations .
This will make it obvious that all these combinations of modes and options are not mutually exclusive.
Also row 3 is highly questionable
3
solid
facedot
through
solid with select through by facedots
That makes you need to precisely select faces by facedots centers that you don’t even see. Not sure how it should work in practice.
Backfacing geometry must be super predictable for this to work.
It is also makes impossible to define if selection is through, just looking at model, since facedots display can mean both through and occlude selection in this way.
Not sure, it will be used quite often (because of why?)
Occluded selection is still a useful mode, even if hidden geometry is simple and predictable. The point of this option is to eliminate needles switching to x-ray to select-through, when you can do a "blind" selection, but whether you actually need to select trough is a different matter. I guess it all depends on the user preference, model and other factors that are hard to predict. But even if it's used just a couple of times in an hour, I think it's reasonable to put it in a header because it also works as an indicator. Controlling facedot selection also shouldn't be a problem, since it's just one click away in a drop-down menu.
For sure occluded selection is useful mode, since this topic exists and we are making proper design. But button that we design will not be "pressed often". That's what i meant by "using often".
Drop down menu makes current selection mode unobvious, that will force to constantly check current options combination in order to understand what you will get with next selection.
This can be more confusing than useful, since it makes it hard to control possible combinations.
The main takeaway here is that there are as many different opinions and workflows, as there are users. So the goal is to add these options in a way that's easy to configure to fit any workflow.
From the point of selection there are just two cases to satisfy - predictable backface geometry and unpredictable backface geometry.
All possible use cases and workflows fits that condition.
There is no ability to select visible vertices or edges in backface culling mode, like this, even if we see them
Yeah, that's a strange problem, but having a Backface Selection toggle would actually fix it in this case.
Providing ability to make backface selection by default also fix that issue.
What is the point of making it as a toggle - to provide ability to not to select what you see as well? What are usecases for keeping it as a toggle?
I agree that drag action should be kept the same when switching modes. Not sure why it was done this way.
Yes, it looks like two unrelated things (edit mode and selection tool) are tied together.
> In #73479#937422, @slowburn wrote:
>> But I am not sure what is the reason to see facedots, but not select by facedots in xray/wireframe.
>That's how it works in 3ds max and it's always frustrating.
Yes, this mode is frustrating in 3dsmax because it is the only mode there.
Unlike in 3dsmax, our solution provides both possible wireframe modes - for face area selection without facedots display and for faces center selection with facedots display, with simple way to control it.
Abscense of facedots in witeframe can clearly visually split face area mode for non-picking selection types, which can be useful while working with predictable geometry.
> What do you mean "separately"? As I said these settings would work as a global toggle, so that selecting is always consistent across all tools, including modal selection that's activated with a keyboard shortcut.
It is not good idea to place global toggle to some local tools.
If you use move or bevel tool, you still able to make selection with B or C, but can't define if select through mode is currentry in use, because toolbar preferences are occupied with move or bevel tool settings.
> Here are all possible combinations in a table.
The problem is that this table is far from being complete in case of your proposal, since all binary combinations of all proposed checkboxes and options should be listed in it.
Our table is not just listening modes, it contains all possible combinations of options used in our proposal, that is why we can argue that it is minimalistic.
So your table should look like this.
| Shading | faces selection type | selection mode | default overlays| option | wire checkbox | Xray checkbox | Solid checkbox| result
| -- | -- | -- | -- | -- | -- | -- | -- | -- |
There will be [way more than 6 combinations ](https://en.wikipedia.org/wiki/Combination#Number_of_k-combinations_for_all_k).
This will make it obvious that all these combinations of modes and options are not mutually exclusive.
Also row 3 is highly questionable
|3 |solid |facedot |through |solid with select through by facedots
| -- | -- | -- | -- | -- |
That makes you need to precisely select faces by facedots centers that you don’t even see. Not sure how it should work in practice.
Backfacing geometry must be super predictable for this to work.
It is also makes impossible to define if selection is through, just looking at model, since facedots display can mean both through and occlude selection in this way.
>>Not sure, it will be used quite often (because of why?)
> Occluded selection is still a useful mode, even if hidden geometry is simple and predictable. The point of this option is to eliminate needles switching to x-ray to select-through, when you can do a "blind" selection, but whether you actually *need* to select trough is a different matter. I guess it all depends on the user preference, model and other factors that are hard to predict. But even if it's used just a couple of times in an hour, I think it's reasonable to put it in a header because it also works as an indicator. Controlling facedot selection also shouldn't be a problem, since it's just one click away in a drop-down menu.
For sure occluded selection is useful mode, since this topic exists and we are making proper design. But button that we design will not be "pressed often". That's what i meant by "using often".
Drop down menu makes current selection mode unobvious, that will force to constantly check current options combination in order to understand what you will get with next selection.
This can be more confusing than useful, since it makes it hard to control possible combinations.
> The main takeaway here is that there are as many different opinions and workflows, as there are users. So the goal is to add these options in a way that's easy to configure to fit any workflow.
From the point of selection there are just two cases to satisfy - predictable backface geometry and unpredictable backface geometry.
All possible use cases and workflows fits that condition.
>>There is no ability to select visible vertices or edges in backface culling mode, like this, even if we see them
> Yeah, that's a strange problem, but having a Backface Selection toggle would actually fix it in this case.
Providing ability to make backface selection by default also fix that issue.
What is the point of making it as a toggle - to provide ability to not to select what you see as well? What are usecases for keeping it as a toggle?
> I agree that drag action should be kept the same when switching modes. Not sure why it was done this way.
Yes, it looks like two unrelated things (edit mode and selection tool) are tied together.
Abscense of facedots in witeframe can clearly visually split face area mode for non-picking selection types
I think it was mentioned in this thread by a developer, that facedots in Wire/X-Ray are used to indicate face selection mode, so they can't even be disabled. Besides, combining those 2 modes would help to save quite a few clicks: you could use area selection for selecting multiple faces, and then immediately pick a specific face by a facedot, without having to switch to facedot selection mode.
If you use move or bevel tool, you still able to make selection with B or C, but can't define if select through mode is currentry in use, because toolbar preferences are occupied with move or bevel tool settings.
Ok, I see what you mean. Maybe the buttons could be placed in the middle of the header or on the right side, to separate them from tool settings. As I said, there is no obvious place to put selection settings in the UI, but they have to go somewhere.
The problem is that this table is far from being complete in case of your proposal, since all binary combinations of all proposed checkboxes and options should be listed in it.
My table lists all useful ways that these two options (Select Through and Select by Facedots) can affect the selection for each shading mode. Listing all binary combinations wouldn't show anything else that's important.
Also row 3 is highly questionable... That makes you need to precisely select faces by facedots centers that you don’t even see
Facedot positions can also be predictable. For example in this cylinder:
Here you would know exactly what you will select and It's impossible to make such selection by face area. I don't think it makes sense to artificially restrict or remove certain combinations because it won't simplify the UI in any way. And someone might find it useful in some rare corner case.
Drop down menu makes current selection mode unobvious, that will force to constantly check current options combination in order to understand what you will get with next selection.
I don't think people would have much difficulty to remember which checkbox they have clicked. But to make it really clear, the drop-down list can be replaced by a button that is toggled independently for each shading mode. Looking something like this:
So if facedot selection is enabled for x-ray for example, it would light up when x-ray shading is enabled. "ST" is just a placeholder for a proper icon here.
What is the point of making it as a toggle - to provide ability to not to select what you see as well?
That's one of the use cases. When modelling, I like to keep backfaces enabled to get a better sense for the overall shape of the model, if it's not fully enclosed. But then backfaces can get unintentionally selected and there's no way to prevent that in Blender. It's not that big of a deal, but it would be nice to have an option to toggle backface selection when I need it.
>Abscense of facedots in witeframe can clearly visually split face area mode for non-picking selection types
I think it was mentioned in this thread by a developer, that facedots in Wire/X-Ray are used to indicate face selection mode, so they can't even be disabled. Besides, combining those 2 modes would help to save quite a few clicks: you could use area selection for selecting multiple faces, and then immediately pick a specific face by a facedot, without having to switch to facedot selection mode.
>If you use move or bevel tool, you still able to make selection with B or C, but can't define if select through mode is currentry in use, because toolbar preferences are occupied with move or bevel tool settings.
Ok, I see what you mean. Maybe the buttons could be placed in the middle of the header or on the right side, to separate them from tool settings. As I said, there is no obvious place to put selection settings in the UI, but they have to go somewhere.
>The problem is that this table is far from being complete in case of your proposal, since all binary combinations of all proposed checkboxes and options should be listed in it.
My table lists all useful ways that these two options (Select Through and Select by Facedots) can affect the selection for each shading mode. Listing all binary combinations wouldn't show anything else that's important.
>Also row 3 is highly questionable... That makes you need to precisely select faces by facedots centers that you don’t even see
Facedot positions can also be predictable. For example in this cylinder:
Here you would know exactly what you will select and It's impossible to make such selection by face area. I don't think it makes sense to artificially restrict or remove certain combinations because it won't simplify the UI in any way. And someone might find it useful in some rare corner case.
>Drop down menu makes current selection mode unobvious, that will force to constantly check current options combination in order to understand what you will get with next selection.
I don't think people would have much difficulty to remember which checkbox they have clicked. But to make it really clear, the drop-down list can be replaced by a button that is toggled independently for each shading mode. Looking something like this:
So if facedot selection is enabled for x-ray for example, it would light up when x-ray shading is enabled. "ST" is just a placeholder for a proper icon here.
>What is the point of making it as a toggle - to provide ability to not to select what you see as well?
That's one of the use cases. When modelling, I like to keep backfaces enabled to get a better sense for the overall shape of the model, if it's not fully enclosed. But then backfaces can get unintentionally selected and there's no way to prevent that in Blender. It's not that big of a deal, but it would be nice to have an option to toggle backface selection when I need it.
I have bad experience with separate tweak took per each mode for each type of object.
So I was forced to chand tweak tool to «Tweak» from «Box select» in my startups for all (mesh, curves, bones, uv-editor, node editor, surface, metaball…) Ugh…
And for each separate viewport… It is very annoying.
Also I cant figure out, why box select is default for tweak tool for all objects. For nodes I move em oftener, And I dont want to press additional G.
For curves the same: I move nodes and drag handles.
For Grease pencil I use lasso selection with Ctrl+RMB-drag
So I prefer to have global tweak tool mode at least.
For me it is much more handy than set separate individual modes for each type of object.
Or at least full syncronization per object type and per editor type.
I have bad experience with separate tweak took per each mode for each type of object.
So I was forced to chand tweak tool to «Tweak» from «Box select» in my startups for all (mesh, curves, bones, uv-editor, node editor, surface, metaball…) Ugh…
And for each separate viewport… It is very annoying.
Also I can`t figure out, why box select is default for tweak tool for all objects.
For nodes I move em oftener, And I don`t want to press additional G.
For curves the same: I move nodes and drag handles.
For Grease pencil I use lasso selection with Ctrl+RMB-drag
So I prefer to have global tweak tool mode at least.
For me it is much more handy than set separate individual modes for each type of object.
Or at least full syncronization per object type and per editor type.
In #73479#938431, @slowburn wrote:
I think it was mentioned in this thread by a developer, that facedots in Wire/X-Ray are used to indicate face selection mode, so they can't even be disabled. Besides, combining those 2 modes would help to save quite a few clicks: you could use area selection for selecting multiple faces, and then immediately pick a specific face by a facedot, without having to switch to facedot selection mode.
Facedots are already disabled by default in solid mode, so there is no more corellation between facedots display and face mode anymore.
It is also done by developers.
Maybe the buttons could be placed in the middle of the header or on the right side, to separate them from tool settings.
Snaps or proportional editing have nothing to do with selection.
I think placement near Xray button from our proposal is better since shading influences selection as well.
Listing all binary combinations wouldn't show anything else that's important.
Either you or the developers will have to do this.
This can expose situations like that
Shading
faces selection type
selection mode
default overlays
option
Solid checkbox
result
solid
?
through
facedots off
on
on
?
Should a solid checkbox be unavilable in some cases?
Also row 3 is highly questionable... That makes you need to precisely select faces by facedots centers that you don’t even see
Facedot positions can also be predictable. For example in this cylinder:
And someone might find it useful in some rare corner case.
Indeed, a very rare case.
All such cases are very specific, are much faster to perform from wireframe shading mode (rather than setup selection back and forth), disallow to read through mode from model appearance and requires separate option.
It looks like LSTV mode but without ability to see backfacing.
Not sure if it's worth it.
I don't think people would have much difficulty to remember which checkbox they have clicked.
For sure, unless they have no other business, rather than keeping it in memory.
But to make it really clear, the drop-down list can be replaced by a button that is toggled independently for each shading mode. Looking something like this:
So if facedot selection is enabled for x-ray for example, it would light up when x-ray shading is enabled. "ST" is just a placeholder for a proper icon here.
That's interesting solution, it will make mode visually clear.
The same way behaves wireframe and Xray buttons (there was an idea to make them independent, since wireframe without xray is more about visual style rather than regular shading mode).
But, as it was told before, such modes are not mutually exclusive.
For example, what is the difference between this possible options combinations? I can see only two unique results.
But then backfaces can get unintentionally selected and there's no way to prevent that in Blender.
Not sure I understood that correctly, can you give an example? How you can get unintentionally selected what you can see?
In #73479#938454, @Vyach wrote:
Also I can`t figure out, why box select is default for tweak tool for all objects.
Yes, after selection goes some operation, so you have to switch to anything but box selection immediately after the very first selection anyway.
So I prefer to have global tweak tool mode at least.
Or at least full syncronization per object type and per editor type.
Tweak also allow to perform picking selection type, and it is the most common operation, that follows selection, so I agree that it could be a nice default.
> In #73479#938431, @slowburn wrote:
> I think it was mentioned in this thread by a developer, that facedots in Wire/X-Ray are used to indicate face selection mode, so they can't even be disabled. Besides, combining those 2 modes would help to save quite a few clicks: you could use area selection for selecting multiple faces, and then immediately pick a specific face by a facedot, without having to switch to facedot selection mode.
Facedots are already disabled by default in solid mode, so there is no more corellation between facedots display and face mode anymore.
It is also done by developers.
> Maybe the buttons could be placed in the middle of the header or on the right side, to separate them from tool settings.
Snaps or proportional editing have nothing to do with selection.
I think placement near Xray button from our proposal is better since shading influences selection as well.
> Listing all binary combinations wouldn't show anything else that's important.
Either you or the developers will have to do this.
This can expose situations like that
|Shading |faces selection type |selection mode |default overlays |option |Solid checkbox |result
| -- | -- | -- | -- | -- | -- | -- |
|solid |? |through |facedots off |on |on |?
Should a solid checkbox be unavilable in some cases?
>>Also row 3 is highly questionable... That makes you need to precisely select faces by facedots centers that you don’t even see
> Facedot positions can also be predictable. For example in this cylinder:
> And someone might find it useful in some rare corner case.
Indeed, a very rare case.
All such cases are very specific, are much faster to perform from wireframe shading mode (rather than setup selection back and forth), disallow to read through mode from model appearance and requires separate option.
It looks like LSTV mode but without ability to see backfacing.
Not sure if it's worth it.
> I don't think people would have much difficulty to remember which checkbox they have clicked.
For sure, unless they have no other business, rather than keeping it in memory.
> But to make it really clear, the drop-down list can be replaced by a button that is toggled independently for each shading mode. Looking something like this:
> 
> So if facedot selection is enabled for x-ray for example, it would light up when x-ray shading is enabled. "ST" is just a placeholder for a proper icon here.
That's interesting solution, it will make mode visually clear.
The same way behaves wireframe and Xray buttons (there was an idea to make them independent, since wireframe without xray is more about visual style rather than regular shading mode).
But, as it was told before, such modes are not mutually exclusive.
For example, what is the difference between this possible options combinations? I can see only two unique results.
> But then backfaces can get unintentionally selected and there's no way to prevent that in Blender.
Not sure I understood that correctly, can you give an example? How you can get unintentionally selected what you can see?
> In #73479#938454, @Vyach wrote:
> Also I can`t figure out, why box select is default for tweak tool for all objects.
Yes, after selection goes some operation, so you have to switch to anything but box selection immediately after the very first selection anyway.
> So I prefer to have global tweak tool mode at least.
> Or at least full syncronization per object type and per editor type.
Tweak also allow to perform picking selection type, and it is the most common operation, that follows selection, so I agree that it could be a nice default.
In #73479#938431, @slowburn wrote:
I think it was mentioned in this thread by a developer, that facedots in Wire/X-Ray are used to indicate face selection mode, so they can't even be disabled. Besides, combining those 2 modes would help to save quite a few clicks: you could use area selection for selecting multiple faces, and then immediately pick a specific face by a facedot, without having to switch to facedot selection mode.
Facedots are already disabled by default in solid mode, so there is no more corellation between facedots display and face mode anymore.
It is also done by developers.
Maybe the buttons could be placed in the middle of the header or on the right side, to separate them from tool settings.
Snaps or proportional editing have nothing to do with selection.
I think placement near Xray button from our proposal is better since shading influences selection as well.
Listing all binary combinations wouldn't show anything else that's important.
Either you or the developers will have to do this.
This can expose situations like that
|Shading |faces selection type |selection mode |default overlays |option |Solid checkbox |result
|solid |? |through |facedots off |on |on |?
Should a solid checkbox be unavilable in some cases?
Also row 3 is highly questionable... That makes you need to precisely select faces by facedots centers that you don’t even see
Facedot positions can also be predictable. For example in this cylinder:
And someone might find it useful in some rare corner case.
Indeed, a very rare case.
All such cases are very specific, are much faster to perform from wireframe shading mode (rather than setup selection back and forth), disallow to read through mode from model appearance and requires separate option.
It looks like LSTV mode but without ability to see backfacing.
Not sure if it's worth it.
I don't think people would have much difficulty to remember which checkbox they have clicked.
For sure, unless they have no other business, rather than keeping it in memory.
But to make it really clear, the drop-down list can be replaced by a button that is toggled independently for each shading mode. Looking something like this:
So if facedot selection is enabled for x-ray for example, it would light up when x-ray shading is enabled. "ST" is just a placeholder for a proper icon here.
That's interesting solution, it will make mode visually clear.
The same way behaves wireframe and Xray buttons (there was an idea to make them independent, since wireframe without xray is more about visual style rather than regular shading mode).
But, as it was told before, such modes are not mutually exclusive.
For example, what is the difference between this possible options combinations? I can see only two unique results.
But then backfaces can get unintentionally selected and there's no way to prevent that in Blender.
Not sure I understood that correctly, can you give an example? How you can get unintentionally selected what you can see?
In #73479#938454, @Vyach wrote:
Also I can`t figure out, why box select is default for tweak tool for all objects.
Yes, after selection goes some operation, so you have to switch to anything but box selection immediately after the very first selection anyway.
So I prefer to have global tweak tool mode at least.
Or at least full syncronization per object type and per editor type.
Tweak also allow to perform picking selection type, and it is the most common operation, that follows selection, so I agree that it could be a nice default.
I am sorry but having all the 4 factors exposed as UI controls is a complete UX nightmare no one should ever do. Blender actually needs removal of options in this case, not addition of new ones. If it was for me, I would not even add the Xray toggle that I did in my proposal, and I would simply kill the whole Xray and face dots thing and have one, proper, consistent selection mode.
The developers are already now in a denial about this feature by claiming it would complicate things, and you are just giving them ammunition to support their unfounded argument.
> In #73479#938574, @1D_Inc wrote:
>> In #73479#938431, @slowburn wrote:
>> I think it was mentioned in this thread by a developer, that facedots in Wire/X-Ray are used to indicate face selection mode, so they can't even be disabled. Besides, combining those 2 modes would help to save quite a few clicks: you could use area selection for selecting multiple faces, and then immediately pick a specific face by a facedot, without having to switch to facedot selection mode.
>
> Facedots are already disabled by default in solid mode, so there is no more corellation between facedots display and face mode anymore.
> It is also done by developers.
>
>> Maybe the buttons could be placed in the middle of the header or on the right side, to separate them from tool settings.
>
> Snaps or proportional editing have nothing to do with selection.
> I think placement near Xray button from our proposal is better since shading influences selection as well.
>
>> Listing all binary combinations wouldn't show anything else that's important.
>
> Either you or the developers will have to do this.
> This can expose situations like that
>
> |Shading |faces selection type |selection mode |default overlays |option |Solid checkbox |result
> |solid |? |through |facedots off |on |on |?
> Should a solid checkbox be unavilable in some cases?
>
>>>Also row 3 is highly questionable... That makes you need to precisely select faces by facedots centers that you don’t even see
>> Facedot positions can also be predictable. For example in this cylinder:
>> And someone might find it useful in some rare corner case.
>
> Indeed, a very rare case.
> All such cases are very specific, are much faster to perform from wireframe shading mode (rather than setup selection back and forth), disallow to read through mode from model appearance and requires separate option.
> It looks like LSTV mode but without ability to see backfacing.
> Not sure if it's worth it.
>
>> I don't think people would have much difficulty to remember which checkbox they have clicked.
> For sure, unless they have no other business, rather than keeping it in memory.
>
>> But to make it really clear, the drop-down list can be replaced by a button that is toggled independently for each shading mode. Looking something like this:
>> 
>> So if facedot selection is enabled for x-ray for example, it would light up when x-ray shading is enabled. "ST" is just a placeholder for a proper icon here.
>
> That's interesting solution, it will make mode visually clear.
> The same way behaves wireframe and Xray buttons (there was an idea to make them independent, since wireframe without xray is more about visual style rather than regular shading mode).
> But, as it was told before, such modes are not mutually exclusive.
> For example, what is the difference between this possible options combinations? I can see only two unique results.
> 
>
>
>> But then backfaces can get unintentionally selected and there's no way to prevent that in Blender.
> Not sure I understood that correctly, can you give an example? How you can get unintentionally selected what you can see?
>
>> In #73479#938454, @Vyach wrote:
>> Also I can`t figure out, why box select is default for tweak tool for all objects.
>
> Yes, after selection goes some operation, so you have to switch to anything but box selection immediately after the very first selection anyway.
>
>> So I prefer to have global tweak tool mode at least.
>> Or at least full syncronization per object type and per editor type.
>
> Tweak also allow to perform picking selection type, and it is the most common operation, that follows selection, so I agree that it could be a nice default.
I am sorry but having all the 4 factors exposed as UI controls is a complete UX nightmare no one should ever do. Blender actually needs removal of options in this case, not addition of new ones. If it was for me, I would not even add the Xray toggle that I did in my proposal, and I would simply kill the whole Xray and face dots thing and have one, proper, consistent selection mode.
The developers are already now in a denial about this feature by claiming it would complicate things, and you are just giving them ammunition to support their unfounded argument.
In #73479#938693, @Rawalanche wrote:
The developers are already now in a denial about this feature by claiming it would complicate things, and you are just giving them ammunition to support their unfounded argument.
That's why our proposal consists from a single ui button and several overlay options.
Also added some of the issues discussed in the summarizing post as well.
> In #73479#938693, @Rawalanche wrote:
> The developers are already now in a denial about this feature by claiming it would complicate things, and you are just giving them ammunition to support their unfounded argument.
That's why our proposal consists from a single ui button and several overlay options.
Also added some of the issues discussed in the [summarizing post ](https://developer.blender.org/T73479#926945) as well.
I would simply kill the whole Xray and face dots thing and have one, proper, consistent selection mode.
And what would that one, proper, consistent selection mode, that can satisfy everyone, be?
Regarding X-Ray, maybe it could be merged with Wireframe into a unified see-through mode, that is enabled with the same shortcut/button. And with the X-Ray slider you could set it up to look like a simple wireframe or an x-ray shading that we have now, based on your preference.
But getting rid of facedots is unrealistic, since they are used to reliably select faces that are overlapping each other in wireframe/x-ray.
That's why our proposal consists from a single ui button and several overlay options
Single ui button works well for controlling select through/occluded, but tying facedot selection to the overlay is flawed. If I want to use area selection with x-ray do I have to forego the ability to accurately select individual faces? Why can't I do both? These two modes don't interfere with each other.
>I would simply kill the whole Xray and face dots thing and have one, proper, consistent selection mode.
And what would that one, proper, consistent selection mode, that can satisfy everyone, be?
Regarding X-Ray, maybe it could be merged with Wireframe into a unified see-through mode, that is enabled with the same shortcut/button. And with the X-Ray slider you could set it up to look like a simple wireframe or an x-ray shading that we have now, based on your preference.
But getting rid of facedots is unrealistic, since they are used to reliably select faces that are overlapping each other in wireframe/x-ray.
>That's why our proposal consists from a single ui button and several overlay options
Single ui button works well for controlling select through/occluded, but tying facedot selection to the overlay is flawed. If I want to use area selection with x-ray do I have to forego the ability to accurately select individual faces? Why can't I do both? These two modes don't interfere with each other.
And what would that one, proper, consistent selection mode, that can satisfy everyone, be?
Regarding X-Ray, maybe it could be merged with Wireframe into a unified see-through mode, that is enabled with the same shortcut/button. And with the X-Ray slider you could set it up to look like a simple wireframe or an x-ray shading that we have now, based on your preference.
But getting rid of facedots is unrealistic, since they are used to reliably select faces that are overlapping each other in wireframe/x-ray.
Blender is only 3D DCC which has the concept of face dots. All the other DCCs don't have it and I have not seen a single user request it. Blender has it and there's a giant thread of people requesting it to go away. In none of those other DCCs people feel like they are being limited by insufficient selection system. In fact, most of games and movies AAA content has been made with them, not with Blender. And even despite such a track record, people still don't request something like face dots concept to save them time.
As I said, adding set of knobs to control something as basic as selection is an creation of a problem, not a solution for it.
This is wrong. Face dots are actually much less reliable selection method as long as your model case is not a 6 quad cube. People like to demonstrate how useful it is on two six face cubes, one being inside of other, but as soon as your model has at least moderate complexity (current gen game poly model), face dots become more of an issue than they are a solution. You end up doing exactly the same thing you'd end up doing if they weren't there. You box select a few, then turn your view around and deselect those mistakenly selected from an other angle. You can't afford to waste time click selecting faces one by one, and if you use face dots containment instead of face area overlap when box selecting, the reliability is actually reduced, significantly.
I mean even if you create Blender's UV sphere primitive and keep the UV segment counts at default, even that is already a case where it's borderline impossible to utilize face dots correctly because you can't reliably tell which face dots belong to front faces and which to the back faces. And even if you could, as soon as you need to select more than 3, you'd probably give up on click selecting and box select instead, where, once again, face dots become just useless annoyance. Face dots are synthetic solution to a problem which never existed in the first place. They are solution to a very small synthetic example, not a real world workflows.
Here's a typical example how brutal failure face dots workflow is in the most common scenario one does many times a day.
Imagine you want to face select a corner of cube. Basically 4 faces touching one edge of cube.
In a normal software, you would just box select a corner of cube from side view, and that would be it.
In Blender, you are faced with two bullshit solutions:
You have xray off, you box select the corner, and only the front face gets selected, not the side faces or the backface.
You enable xray, and suddenly your entire selection method has changed, so now you have to squint very intensively to find the face dots and make sure they are contained within the box selection. Not only that, but you actually need to start thinking about face dots and change your whole muscle memory to accommodate for them.
And this is even favoring situation because the front facing geometry is identical to the back one. If the back face was subdivided to 4 faces, it would be even that much more difficult. At the same time, if we had select through without face dots, these issues would never ever exist.
The problem becomes ever more low level if you think about it. Blender is the only 3D DCC where you need to waste your mental energy on something as essential as selection. You don't need to do that in almost any other mainstream DCC. There, the selection always remain consistent, so it gets saved in the intuitive/muscle memory and no longer wastes your mental energy because it's not constantly switched around.
> And what would that one, proper, consistent selection mode, that can satisfy everyone, be?
> Regarding X-Ray, maybe it could be merged with Wireframe into a unified see-through mode, that is enabled with the same shortcut/button. And with the X-Ray slider you could set it up to look like a simple wireframe or an x-ray shading that we have now, based on your preference.
> But getting rid of facedots is unrealistic, since they are used to reliably select faces that are overlapping each other in wireframe/x-ray.
1. Blender is only 3D DCC which has the concept of face dots. All the other DCCs don't have it and I have not seen a single user request it. Blender has it and there's a giant thread of people requesting it to go away. In none of those other DCCs people feel like they are being limited by insufficient selection system. In fact, most of games and movies AAA content has been made with them, not with Blender. And even despite such a track record, people still don't request something like face dots concept to save them time.
2. As I said, adding set of knobs to control something as basic as selection is an creation of a problem, not a solution for it.
3. This is wrong. Face dots are actually much less reliable selection method as long as your model case is not a 6 quad cube. People like to demonstrate how useful it is on two six face cubes, one being inside of other, but as soon as your model has at least moderate complexity (current gen game poly model), face dots become more of an issue than they are a solution. You end up doing exactly the same thing you'd end up doing if they weren't there. You box select a few, then turn your view around and deselect those mistakenly selected from an other angle. You can't afford to waste time click selecting faces one by one, and if you use face dots containment instead of face area overlap when box selecting, the reliability is actually reduced, significantly.
I mean even if you create Blender's UV sphere primitive and keep the UV segment counts at default, even that is already a case where it's borderline impossible to utilize face dots correctly because you can't reliably tell which face dots belong to front faces and which to the back faces. And even if you could, as soon as you need to select more than 3, you'd probably give up on click selecting and box select instead, where, once again, face dots become just useless annoyance. Face dots are synthetic solution to a problem which never existed in the first place. They are solution to a very small synthetic example, not a real world workflows.
Here's a typical example how brutal failure face dots workflow is in the most common scenario one does many times a day.
Imagine you want to face select a corner of cube. Basically 4 faces touching one edge of cube.
In a normal software, you would just box select a corner of cube from side view, and that would be it.
In Blender, you are faced with two bullshit solutions:
1. You have xray off, you box select the corner, and only the **front** face gets selected, not the side faces or the backface.
2. You enable xray, and suddenly your entire **selection method** has changed, so now you have to squint very intensively to find the face dots and make sure they are contained within the box selection. Not only that, but you actually need to start **thinking** about face dots and change your whole muscle memory to accommodate for them.
https://www.youtube.com/watch?v=THVtJrsiX0Y
And this is even favoring situation because the front facing geometry is identical to the back one. If the back face was subdivided to 4 faces, it would be even that much more difficult. At the same time, if we had select through without face dots, these issues would never ever exist.
The problem becomes ever more low level if you think about it. Blender is the only 3D DCC where you need to waste your mental energy on something as essential as selection. You don't need to do that in almost any other mainstream DCC. There, the selection always remain consistent, so it gets saved in the intuitive/muscle memory and no longer wastes your mental energy because it's not constantly switched around.
By all means, I encourage you to be an advocate for decoupling face dots from shading modes as much as you wish, I agree that people should not be forced to use face dots, but they also should not be forced to use face area. Face dot selection should be set independently from shading. All 3 things should be set independently from one-another: Select-through, shading, and face dots.
Kindly don't spread lies and advocate for the complete removal of a useful selection feature. You do not speak for everyone and your own personal workflow is not everyone's workflow.
> In #73479#939276, @Rawalanche wrote:
> 1. Blender is only 3D DCC which has the concept of face dots. All the other DCCs don't have it
How many times must I correct you before you stop repeating this **lie**?
https://i.imgur.com/zkARZ5U.png
(That's Maya, in case it wasn't obvious.)
By all means, I encourage you to be an advocate for decoupling face dots from shading modes as much as you wish, I agree that people should not be *forced* to use face dots, but they also should not be *forced* to use face area. Face dot selection should be set independently from shading. All 3 things should be set independently from one-another: Select-through, shading, and face dots.
Kindly don't spread lies and advocate for the complete removal of a useful selection feature. You do not speak for everyone and your own personal workflow is not everyone's workflow.
In #73479#939276, @Rawalanche wrote:
I am sorry but having all the 4 factors exposed as UI controls is a complete UX nightmare no one should ever do.
For sure.
In #73479#939276, @Rawalanche wrote:
This is wrong. Face dots are actually much less reliable selection method as long as your model case is not a 6 quad cube.
In #73479#939276, @Rawalanche wrote:
Imagine you want to face select a corner of cube. Basically 4 faces touching one edge of cube.
In #73479#939276, @Rawalanche wrote:
Not only that, but you actually need to start thinking about face dots and change your whole muscle memory to accommodate for them.
As it was told, facedots are needed to detect and work with cursed geometry. It is not the best selection mode for cubes.
Here is GIF with the right way to use facedots selection.
In #73479#939276, @Rawalanche wrote:
I did in my proposal, and I would simply kill the whole Xray and face dots thing and have one, proper, consistent selection mode.
Not sure if it is possible, since Xray with alpha = 1 provides LSTV abilies as well.
In #73479#939451, @ckohl_art wrote:
(That's Maya, in case it wasn't obvious.)
Nice example.
In #73479#939150, @slowburn wrote:
If I want to use area selection with x-ray do I have to forego the ability to accurately select individual faces? Why can't I do both? These two modes don't interfere with each other.
In #73479#939451, @ckohl_art wrote:
All 3 things should be set independently from one-another: Select-through, shading, and face dots.
Not sure if facedots are needed to be independent from select through, since they can indicate it.
However, A.1 and A.2 paragraphs of the summarizing post make it possible to select through by facedots.
> In #73479#939276, @Rawalanche wrote:
>I am sorry but having all the 4 factors exposed as UI controls is a complete UX nightmare no one should ever do.
For sure.
> In #73479#939276, @Rawalanche wrote:
> This is wrong. Face dots are actually much less reliable selection method as long as your model case is not a 6 quad cube.
> In #73479#939276, @Rawalanche wrote:
> Imagine you want to face select a corner of cube. Basically 4 faces touching one edge of cube.
> In #73479#939276, @Rawalanche wrote:
> Not only that, but you actually need to start thinking about face dots and change your whole muscle memory to accommodate for them.
As it was told, facedots are needed to detect and work with cursed geometry. It is not the best selection mode for cubes.
Here is GIF with the right way to use facedots selection.
> In #73479#939276, @Rawalanche wrote:
>I did in my proposal, and I would simply kill the whole Xray and face dots thing and have one, proper, consistent selection mode.
Not sure if it is possible, since Xray with alpha = 1 provides LSTV abilies as well.
> In #73479#939451, @ckohl_art wrote:
>(That's Maya, in case it wasn't obvious.)
Nice example.
> In #73479#939150, @slowburn wrote:
> If I want to use area selection with x-ray do I have to forego the ability to accurately select individual faces? Why can't I do both? These two modes don't interfere with each other.
> In #73479#939451, @ckohl_art wrote:
> All 3 things should be set independently from one-another: Select-through, shading, and face dots.
Not sure if facedots are needed to be independent from select through, since they can indicate it.
However, A.1 and A.2 paragraphs of the [summarizing post ](https://developer.blender.org/T73479#926945) make it possible to select through by facedots.
By all means, I encourage you to be an advocate for decoupling face dots from shading modes as much as you wish, I agree that people should not be forced to use face dots, but they also should not be forced to use face area. Face dot selection should be set independently from shading. All 3 things should be set independently from one-another: Select-through, shading, and face dots.
Kindly don't spread lies and advocate for the complete removal of a useful selection feature. You do not speak for everyone and your own personal workflow is not everyone's workflow.
I have genuinely not known there are face dots in Maya despite having it used in production for about 2 years and worked with people using it for at least 8. That goes to show you how useful they actually are. I've never ever seen anyone use it.
> In #73479#939451, @ckohl_art wrote:
>> In #73479#939276, @Rawalanche wrote:
>> 1. Blender is only 3D DCC which has the concept of face dots. All the other DCCs don't have it
>
> How many times must I correct you before you stop repeating this **lie**?
>
> https://i.imgur.com/zkARZ5U.png
> (That's Maya, in case it wasn't obvious.)
>
>
> By all means, I encourage you to be an advocate for decoupling face dots from shading modes as much as you wish, I agree that people should not be *forced* to use face dots, but they also should not be *forced* to use face area. Face dot selection should be set independently from shading. All 3 things should be set independently from one-another: Select-through, shading, and face dots.
>
> Kindly don't spread lies and advocate for the complete removal of a useful selection feature. You do not speak for everyone and your own personal workflow is not everyone's workflow.
I have genuinely not known there are face dots in Maya despite having it used in production for about 2 years and worked with people using it for at least 8. That goes to show you how useful they actually are. I've never ever seen anyone use it.
In #73479#879563, @pixtur wrote:
I believe believe that all user interaction design without user testing is fundamentally flawed and doomed to fail. I am also willing to bet that if you test the current implementation as of 2.8 with 30 people (10 experienced blender users, 10 with some experience in any 3d software, 10 beginners) more than half of the people would rate the experience as unexpected and confusing. (The test should be an intermediate task like selecting some components of a model like the Pixar lamp).
This quote is probably the most important point (not only) in this discussion!
> In #73479#879563, @pixtur wrote:
> I believe believe that all user interaction design without user testing is fundamentally flawed and doomed to fail. I am also willing to bet that if you test the current implementation as of 2.8 with 30 people (10 experienced blender users, 10 with some experience in any 3d software, 10 beginners) more than half of the people would rate the experience as unexpected and confusing. (The test should be an intermediate task like selecting some components of a model like the Pixar lamp).
This quote is probably the most important point (not only) in this discussion!
Let's make things consistent, if user checks on face centers, it should be visible in all modes that draw faces. If user disables face centers - they should be hidden in all selection modes (solid, xray, wireframe). This toggle should change how faces are selected.
We should add new toggle 'Camera based selection'. If disabled - laws of blender 'select what you see' are broken, tools like box selection and lasso can select through. This toggle could have subsetting in pulldown (affected tools: box select, lasso, circle select... ). This way we could make for example circle select always select only visible components.
How will it work? If face center are enabled when camera based selection is off, it will select through all face centers (simple and clear); if face centers are disabled, it will select through all faces touched. I guess we need few simple options that combined create good user experience (the experience that someone wants) and in this way we will limit our personal influence on others workflow.
If we really need distinction between face and edge mode, we could add separate theming options for wireframe (although we have buttons that show what component mode is active so what's the point?).
the same goes for camera based selection mode, if there is a button toggle activated it's hard to miss.
If distinction between camera based selection is really needed, we can change cursor (it would be subtle change like for example crosshair and crosshair in circle).
@down reply
I dont know how to adress this summarize table since I dont understand it.
In quick summary:
face center on: all modes drawing faces show face centers. Face can be selected only by center.
face center off: all modes hide face centers. Face can be selected by clicking on it (it would change how current xray works)
Let's make things consistent, if user checks on face centers, it should be visible in all modes that draw faces. If user disables face centers - they should be hidden in all selection modes (solid, xray, wireframe). This toggle should change how faces are selected.
We should add new toggle 'Camera based selection'. If disabled - laws of blender 'select what you see' are broken, tools like box selection and lasso can select through. This toggle could have subsetting in pulldown (affected tools: box select, lasso, circle select... <other selection tools>). This way we could make for example circle select always select only visible components.
How will it work? If face center are enabled when camera based selection is off, it will select through all face centers (simple and clear); if face centers are disabled, it will select through all faces touched. I guess we need few simple options that combined create good user experience (the experience that someone wants) and in this way we will limit our personal influence on others workflow.
If we really need distinction between face and edge mode, we could add separate theming options for wireframe (although we have buttons that show what component mode is active so what's the point?).
the same goes for camera based selection mode, if there is a button toggle activated it's hard to miss.
If distinction between camera based selection is really needed, we can change cursor (it would be subtle change like for example crosshair and crosshair in circle).
@down reply
I dont know how to adress this summarize table since I dont understand it.
In quick summary:
+ face center on: all modes drawing faces show face centers. Face can be selected only by center.
+ face center off: all modes hide face centers. Face can be selected by clicking on it (it would change how current xray works)
In #73479#951298, @Rongix wrote:
Let's make things consistent, if user checks on face centers, it should be visible in all modes that draw faces. This toggle should change how faces are selected.
Do you mean edges and vertices modes as well? Or do you mean "all face selection modes"?
How will it work? If face center are enabled when camera based selection is off, it will select through all face centers (simple and clear). if face centers are disabled, it will select through all faces touched.
Solid with occluded area selection and facedots display
Turning camera based selection on? Or is the proposed behavior different?
If we really need distinction between face and edge mode, we could add separate theming options for wireframe
There is such an option, called Edges in Overlays. Turn it off like this to see the difference between edges and no facedot faces. Personally, I keep it enabled since I have to use facedots.
(although we have buttons that show what component mode is active so what's the point?).
The point is that those buttons are small, and the mode is constantly changing during modeling. So this difference is necessary for visual feedback. This eliminates the need to constantly check small buttons.
If distinction between camera based selection is really needed, we can change cursor (it would be subtle change like for example crosshair and crosshair in circle).
I think it is possible to work comfortably with only small button indication in this case, since camera selection mode is not supposed to be changed often during work, so there is no need to check it constantly.
> In #73479#951298, @Rongix wrote:
>Let's make things consistent, if user checks on face centers, it should be visible in all modes that draw faces. This toggle should change how faces are selected.
Do you mean edges and vertices modes as well? Or do you mean "all face selection modes"?
> How will it work? If face center are enabled when camera based selection is off, it will select through all face centers (simple and clear). if face centers are disabled, it will select through all faces touched.
How will this make possible row 4 form the [summarizing post ](https://developer.blender.org/T73479#926945)?
| |Display mode |faces selection type |selection mode |default overlays| option| Result|
| -- | -- | -- | -- | -- | -- | -- |
|4 |solid |facedot |occlude | facedots on| off| Solid with occluded area selection and facedots display
Turning camera based selection on? Or is the proposed behavior different?
> If we really need distinction between face and edge mode, we could add separate theming options for wireframe
There is such an option, called Edges in Overlays. Turn it off like this to see the difference between edges and no facedot faces. Personally, I keep it enabled since I have to use facedots.
>(although we have buttons that show what component mode is active so what's the point?).
The point is that those buttons are small, and the mode is constantly changing during modeling. So this difference is necessary for visual feedback. This eliminates the need to constantly check small buttons.
> If distinction between camera based selection is really needed, we can change cursor (it would be subtle change like for example crosshair and crosshair in circle).
I think it is possible to work comfortably with only small button indication in this case, since camera selection mode is not supposed to be changed often during work, so there is no need to check it constantly.
if user checks on face centers, it should be visible in all modes that draw faces. This toggle should change how faces are selected.
This sounds all good and reasonable for drag selection modes (box/lasso/circle), but how would you pick individual faces in wireframe without facedots? There would be no way to distinguish between overlapping faces. There could be an option to disable facedots in x-ray/wireframe for people who don't want to use them at all, but there also needs to be an option to enable area selection even if facedot overlay is on.
I think it is possible to work comfortably with only small button indication in this case, since camera selection mode is not supposed to be changed often during work, so there is no need to check it constantly.
Maybe it's true for your own workflow, but it doesn't apply to everyone. It's much more important to have clear indication when select-through is enabled, because you can mess up your model if you select some occluded geometry without realizing, and then start editing.
>if user checks on face centers, it should be visible in all modes that draw faces. This toggle should change how faces are selected.
This sounds all good and reasonable for drag selection modes (box/lasso/circle), but how would you pick individual faces in wireframe without facedots? There would be no way to distinguish between overlapping faces. There could be an option to disable facedots in x-ray/wireframe for people who don't want to use them at all, but there also needs to be an option to enable area selection even if facedot overlay is on.
>I think it is possible to work comfortably with only small button indication in this case, since camera selection mode is not supposed to be changed often during work, so there is no need to check it constantly.
Maybe it's true for your own workflow, but it doesn't apply to everyone. It's much more important to have clear indication when select-through is enabled, because you can mess up your model if you select some occluded geometry without realizing, and then start editing.
There would be no way to distinguish between overlapping faces.
True. Usually user goes wire/xray to not only to see inner mesh structures, but also to select them precisely.
Maybe it's true for your own workflow, but it doesn't apply to everyone. It's much more important to have clear indication when select-through is enabled, because you can mess up your model if you select some occluded geometry without realizing, and then start editing.
Well, let me explain it in a bit offtop manner.
I am a workflow designer, that have to perform widest range of workflows possible - from web/gamedev and CAD to historic resotations and cursed mesh cleanup, that allow to observe the needs and problems of that range.
I am here to be sure that developers doesnot shrink it
(as they usually do, because they don’t even ask users what workflow the features requested by users are compatible with, limiting blender to some kind of "asset/character" modeling, which is the most understandable and obvious to majority).
I don't have "my own workflow", my job is investigate and compare workflows. Companies hires WDs to enhance pipelines.
If you doubt the solution proposed, as a worklow designer I can provide an evidence that this solution works and does not cause any problems for millions people during three decades
So, despite the fact that this solution has already been pretty much tested, our solution allows us to observe and control the mode indication directly, because Blender selection types are more complex because more flexible.
But I understand your concerns, indeed, UI / UX is always subject to mandatory testing, at least because in practice the user needs much less things than it seems even for wide range of workflows.
This is the way Blender got that much condensed UI.
> In #73479#952163, @slowburn wrote:
> There would be no way to distinguish between overlapping faces.
True. Usually user goes wire/xray to not only to see inner mesh structures, but also to select them precisely.
> Maybe it's true for your own workflow, but it doesn't apply to everyone. It's much more important to have clear indication when select-through is enabled, because you can mess up your model if you select some occluded geometry without realizing, and then start editing.
Well, let me explain it in a bit offtop manner.
I am a workflow designer, that have to perform widest range of workflows possible - from web/gamedev and CAD to historic resotations and cursed mesh cleanup, that allow to observe the needs and problems of that range.
I am here to be sure that developers doesnot shrink it
(as they usually do, because they don’t even ask users what workflow the features requested by users are compatible with, limiting blender to some kind of "asset/character" modeling, which is the most understandable and obvious to majority).
I don't have "my own workflow", my job is investigate and compare workflows. Companies hires WDs to enhance pipelines.
If you doubt the solution proposed, as a worklow designer I can provide an evidence that this solution works and does not cause any problems for millions people during three decades
- [3Dsmax, which uses a small checkbox for backface selection indication lost somewhere in UI, and everybody are ok even with that kind of a solution all this time](https://youtu.be/6CkUxxixse8)
So, despite the fact that this solution has already been pretty much tested, our solution allows us to observe and control the mode indication directly, because Blender selection types are more complex because more flexible.
But I understand your concerns, indeed, UI / UX is always subject to mandatory testing, at least because in practice the user needs much less things than it seems even for wide range of workflows.
This is the way Blender got that much condensed UI.
From an outside perspective, it sometimes seems that the people with the longest Blender experience feel entitled to scream the loudest. I'm sure you will find your workflow just perfect. In fact, I believe there are many users who use this workflow. But that does not make it the primary use-case for Blender by default. I'm just following this discussion and somehow I think it looks like the one who screams more often and more aggressively will get his/her right.
As a user who doesn't have much time, I would prefer the Blender Foundation to invest a few hours to build some click-dummy prototypes and just do a usability test (as described by usability experts like Steve Krug). Whatever the result of this test may be, it will be better than any solution you (or I) could come up with. It might not be a solution you like (it's probably not even a solution I would like), but it will be the better solution for Blender.
I sorry for the rant. We all just want the best for Blender.
And yes, I've been using Maya for 15 years. I miss many great features (like Vertex Face selection). Facedots are not among them. :-)
From an outside perspective, it sometimes seems that the people with the longest Blender experience feel entitled to scream the loudest. I'm sure you will find your workflow just perfect. In fact, I believe there are many users who use this workflow. But that does not make it the primary use-case for Blender by default. I'm just following this discussion and somehow I think it looks like the one who screams more often and more aggressively will get his/her right.
As a user who doesn't have much time, I would prefer the Blender Foundation to invest a few hours to build some click-dummy prototypes and just do a usability test (as described by usability experts like Steve Krug). Whatever the result of this test may be, it will be better than any solution you (or I) could come up with. It might not be a solution you like (it's probably not even a solution I would like), but it will be the better solution for Blender.
I sorry for the rant. We all just want the best for Blender.
And yes, I've been using Maya for 15 years. I miss many great features (like [Vertex Face selection](https://i.imgur.com/iHHeZnG.jpg)). Facedots are not among them. :-)
Nobody screams here, just a discussion without emojis and smileys.
As a user who doesn't have much time, I would prefer the Blender Foundation to invest a few hours to build some click-dummy prototypes and just do a usability test (as described by usability experts like Steve Krug). Whatever the result of this test may be, it will be better than any solution you (or I) could come up with. It might not be a solution you like (it's probably not even a solution I would like), but it will be the better solution for Blender.
This topic is a user request, Blender Foundation has no usability problems with occluded selection to test and fix, otherwise it would have already been fixed.
And yes, I've been using Maya for 15 years. I miss many great features (like Vertex Face selection)
However, our Maya users don't use that feature, they prefer to select edges with more than 2 faces to detect mesh issues.
Facedots are not among them. :-)
That's actually excellent :-)
> In #73479#952915, @pixtur wrote:
>to scream
Nobody screams here, just a discussion without emojis and smileys.
> As a user who doesn't have much time, I would prefer the Blender Foundation to invest a few hours to build some click-dummy prototypes and just do a usability test (as described by usability experts like Steve Krug). Whatever the result of this test may be, it will be better than any solution you (or I) could come up with. It might not be a solution you like (it's probably not even a solution I would like), but it will be the better solution for Blender.
This topic is a user request, Blender Foundation has no usability problems with occluded selection to test and fix, otherwise it would have already been fixed.
> And yes, I've been using Maya for 15 years. I miss many great features (like [Vertex Face selection](https://i.imgur.com/iHHeZnG.jpg))
However, our Maya users don't use that feature, they prefer to select edges with more than 2 faces to detect mesh issues.
> Facedots are not among them. :-)
That's actually excellent :-)
3Dsmax, which uses a small checkbox for backface selection indication lost somewhere in UI, and everybody are ok even with that kind of a solution all this time
Eh, that's debatable. 3ds max is not exactly a shining example of a 3d app that is beloved by its users. I've been using it for a long time (too long), and noticed that I have to toggle wireframe mode very often to check what I'm selecting, so I'm hoping that Blender could be an improvement in this regard. The way Cirno's addon works is a great example: switching to x-ray while you drag a selection allows you to see what will be selected, without having to push any extra buttons. Only improvement I would make is to switch only the active object to x-ray, instead of the whole scene, which can be jarring.
This is the way Blender got that much condensed UI.
I just hope that GSoC project for custom menus is completed successfully, and we don't have to depend on one-size-fits-all approach of the default blender UI.
>3Dsmax, which uses a small checkbox for backface selection indication lost somewhere in UI, and everybody are ok even with that kind of a solution all this time
Eh, that's debatable. 3ds max is not exactly a shining example of a 3d app that is beloved by its users. I've been using it for a long time (too long), and noticed that I have to toggle wireframe mode very often to check what I'm selecting, so I'm hoping that Blender could be an improvement in this regard. The way Cirno's addon works is a great example: switching to x-ray while you drag a selection allows you to see what will be selected, without having to push any extra buttons. Only improvement I would make is to switch only the active object to x-ray, instead of the whole scene, which can be jarring.
>This is the way Blender got that much condensed UI.
I just hope that GSoC project for custom menus is completed successfully, and we don't have to depend on one-size-fits-all approach of the default blender UI.
In #73479#953030, @slowburn wrote:
3ds max is not exactly a shining example of a 3d app that is beloved by its users.
For sure. This way max is a nice example for testing something that looks important, but is not important in practice, like in this case.
I've been using it for a long time (too long), and noticed that I have to toggle wireframe mode very often to check what I'm selecting, so I'm hoping that Blender could be an improvement in this regard. The way Cirno's addon works is a great example: switching to x-ray while you drag a selection allows you to see what will be selected, without having to push any extra buttons. Only improvement I would make is to switch only the active object to x-ray, instead of the whole scene, which can be jarring.
The problem is that Cirno addon's solution have nothing to do with occluded selection paradigm.
The problem of this problem is that we have to exactly define a problem - do we need industry standards occluded selection or do we need in fact just autoxray selection (no industry standards, blender only)
Hard to say. From one side there will be a lot of users from ISS that will require occluded selection. There will be those who are satisfied with Cirno addon's solution. And there are users that have to switch button anyway, because of unpredictable backface topology, that makes both occluded selection and Cirno's addon useless in that cases.
I just hope that GSoC project for custom menus is completed successfully, and we don't have to depend on one-size-fits-all approach of the default blender UI.
We will still have to make nice defaults. Because it is possible.
As a workflow designer, that works with lots of artists, I can imagine hell of excessively flexible UI. Artists always prefer mess if they have the ability to make it.
> In #73479#953030, @slowburn wrote:
> 3ds max is not exactly a shining example of a 3d app that is beloved by its users.
For sure. This way max is a nice example for testing something that looks important, but is not important in practice, like in this case.
> I've been using it for a long time (too long), and noticed that I have to toggle wireframe mode very often to check what I'm selecting, so I'm hoping that Blender could be an improvement in this regard. The way Cirno's addon works is a great example: switching to x-ray while you drag a selection allows you to see what will be selected, without having to push any extra buttons. Only improvement I would make is to switch only the active object to x-ray, instead of the whole scene, which can be jarring.
The problem is that Cirno addon's solution have nothing to do with occluded selection paradigm.
The problem of this problem is that we have to exactly define a problem - do we need industry standards occluded selection or do we need in fact just autoxray selection (no industry standards, blender only)
Hard to say. From one side there will be a lot of users from ISS that will require occluded selection. There will be those who are satisfied with Cirno addon's solution. And there are users that have to switch button anyway, because of unpredictable backface topology, that makes both occluded selection and Cirno's addon useless in that cases.
> I just hope that GSoC project for custom menus is completed successfully, and we don't have to depend on one-size-fits-all approach of the default blender UI.
We will still have to make nice defaults. Because it is possible.
As a workflow designer, that works with lots of artists, I can imagine hell of excessively flexible UI. Artists always prefer mess if they have the ability to make it.
I would not be surprised if this was still ignored as a target for 2.90 even despite overwhelming amount of discussion both here and on devtalk thread, as well as significant ease of implementation (it's a minor feature).
I would not be surprised if this was still ignored as a target for 2.90 even despite overwhelming amount of discussion both here and on devtalk thread, as well as significant ease of implementation (it's a minor feature).
In #73479#953125, @Rawalanche wrote:
I would not be surprised if this was still ignored as a target for 2.90 even despite overwhelming amount of discussion both here and on devtalk thread, as well as significant ease of implementation (it's a minor feature).
I guess that important the result of discussions, not the amount of them)
However, I think our proposal is pretty much solid.
> In #73479#953125, @Rawalanche wrote:
> I would not be surprised if this was still ignored as a target for 2.90 even despite overwhelming amount of discussion both here and on devtalk thread, as well as significant ease of implementation (it's a minor feature).
I guess that important the result of discussions, not the amount of them)
However, I think our [proposal ](https://developer.blender.org/T73479#926945) is pretty much solid.
do we need industry standards occluded selection or do we need in fact just autoxray selection (no industry standards, blender only)
Internally occluded selection should be implemented to work with any shading mode and then autoxray could be added as an additional option, purely for visual feedback.
However, I think our proposal is pretty much solid.
It's mostly solid, but you should add one more condition and try to find a solution.
2.1
xray/wire
area
through
facedots on
Xray/wire with area selection and facedots overlay for picking selection
>do we need industry standards occluded selection or do we need in fact just autoxray selection (no industry standards, blender only)
Internally occluded selection should be implemented to work with any shading mode and then autoxray could be added as an additional option, purely for visual feedback.
>However, I think our proposal is pretty much solid.
It's mostly solid, but you should add one more condition and try to find a solution.
| 2.1 |xray/wire |area | through |facedots on |Xray/wire with area selection and facedots overlay for picking selection |
| -- | -- | -- | -- | -- | -- |
It's mostly solid, but you should add one more condition and try to find a solution.
| 2.1 |xray/wire |area | through |facedots on |Xray/wire with area selection and facedots overlay for picking selection |
It is missed on a purpose, since it is confusing behaviour - you see facedots, you are in wire mode, but your faces selection mode is area.
You can't read mode from visual appearance in this case, so It will be easily confused with the default wire mode.
Can't see common usecases which clearly distinguish this mode as necessary.
> In #73479#953553, @slowburn wrote:
> It's mostly solid, but you should add one more condition and try to find a solution.
> | 2.1 |xray/wire |area | through |facedots on |Xray/wire with area selection and facedots overlay for picking selection |
It is missed on a purpose, since it is confusing behaviour - you see facedots, you are in wire mode, but your faces selection mode is area.
You can't read mode from visual appearance in this case, so It will be easily confused with the default wire mode.
Can't see common usecases which clearly distinguish this mode as necessary.
Got it working as an operator property instead of a tool setting. Can assign it to whatever you want in the keymap. I have both select visible and select through in box, lasso, and circle. Can use either one at any time, by that I mean when in edit mode without changing settings or something like that. Right now I'm using alt-drag, alt-shift-drag, alt-ctrl-drag for select through along with the default select visible mappings you get in 2.8 keymap.
Added an Xray Facedots option in the Overlay options. That way if someone wants to disable facedots entirely they can do so. Or they can have them on all the time. Or just in xray mode. It's a matter of what combination of the two checkboxes you click. I think it would work better as a dropdown sort of thing: both, Xray, none. Would that make it an enum instead of a bool?
Let me know what you think, I have very limited experience so any help or advice is appreciated
Hey what's up I saw this, was looking into updating this:
https://developer.blender.org/D6322
But I don't know how, gonna see how this DIFF stuff works tomorrow and give it a go.
In the meantime I'll post a link to the thread.
https://devtalk.blender.org/t/decoupling-x-ray-and-limit-selection-to-visible/3498/150
Got it working as an operator property instead of a tool setting. Can assign it to whatever you want in the keymap. I have both select visible and select through in box, lasso, and circle. Can use either one at any time, by that I mean when in edit mode without changing settings or something like that. Right now I'm using alt-drag, alt-shift-drag, alt-ctrl-drag for select through along with the default select visible mappings you get in 2.8 keymap.
Added an Xray Facedots option in the Overlay options. That way if someone wants to disable facedots entirely they can do so. Or they can have them on all the time. Or just in xray mode. It's a matter of what combination of the two checkboxes you click. I think it would work better as a dropdown sort of thing: both, Xray, none. Would that make it an enum instead of a bool?
Let me know what you think, I have very limited experience so any help or advice is appreciated
> In #73479#977218, @lcas wrote:
> Let me know what you think, I have very limited experience so any help or advice is appreciated
This summarizing post was the latest:
https://developer.blender.org/T73479#926945
Keep in mind still that it's just your summarizing post. It's summary of your personal opinion, not of the community consensus. For example for case 4, there's really no reason to ever have occluded selection with face dots ON. The whole point of face dots was to have an ability to select occluded faces. In case of being able to select only visible faces, face dots come only with all of their drawbacks and issues but none of their benefits.
> In #73479#977380, @1D_Inc wrote:
>> In #73479#977218, @lcas wrote:
>> Let me know what you think, I have very limited experience so any help or advice is appreciated
>
> This summarizing post was the latest:
> https://developer.blender.org/T73479#926945
Keep in mind still that it's just your summarizing post. It's summary of your personal opinion, not of the community consensus. For example for case 4, there's really no reason to ever have occluded selection with face dots ON. The whole point of face dots was to have an ability to select occluded faces. In case of being able to select only visible faces, face dots come only with all of their drawbacks and issues but none of their benefits.
Hi @lcas , nice to see some progress on this task. I've tried your build so here's my feedback:
For facedot controls make one checkbox for solid shading and other for wire/xray. That way they can be controlled independently for each shading mode. Adding a dropdown menu for 2 options is an overkill and would only add additional click to change a setting.
Controlling select-through only with the keymap is too complicated as it would double the amount of selection shortcuts to manage. And modefier keys are most likely already being used for other things by most users. For this feature to be usable it need to be controlled with a single button/shortcut that toggles it for all selection tools and modes in Blender. Also a button somewhere in the UI would work as an indicator to show if select-through is enabled. Maybe keymap option could still be used to override the global toggle, if that's even possible.
There's no way to control when to use facedots for selection. For picking a single polygon, facedot is usually more accurate, but for box and lasso selection it would be good to have an option to choose whether to select by facedots or by area.
Hi @lcas , nice to see some progress on this task. I've tried your build so here's my feedback:
- For facedot controls make one checkbox for solid shading and other for wire/xray. That way they can be controlled independently for each shading mode. Adding a dropdown menu for 2 options is an overkill and would only add additional click to change a setting.
- Controlling select-through only with the keymap is too complicated as it would double the amount of selection shortcuts to manage. And modefier keys are most likely already being used for other things by most users. For this feature to be usable it need to be controlled with a single button/shortcut that toggles it for all selection tools and modes in Blender. Also a button somewhere in the UI would work as an indicator to show if select-through is enabled. Maybe keymap option could still be used to override the global toggle, if that's even possible.
- There's no way to control when to use facedots for selection. For picking a single polygon, facedot is usually more accurate, but for box and lasso selection it would be good to have an option to choose whether to select by facedots or by area.
In #73479#977445, @Rawalanche wrote:
It's summary of your personal opinion
It contains your proposal as well.
For example for case 4, there's really no reason to ever have occluded selection with face dots ON.
This is default setup that is used to detect mesh issues. You will just not use this mode, so there is no problem.
In #73479#977466, @slowburn wrote:
Controlling select-through only with the keymap is too complicated as it would double the amount of selection shortcuts to manage.
Yes.
Also a button somewhere in the UI would work as an indicator to show if select-through is enabled.
The design of this option is provided in summarizing post.
There's no way to control when to use facedots for selection. For picking a single polygon, facedot is usually more accurate, but for box and lasso selection it would be good to have an option to choose whether to select by facedots or by area.
It is defined by shading mode.
> In #73479#977445, @Rawalanche wrote:
> It's summary of your personal opinion
It contains your proposal as well.
> For example for case 4, there's really no reason to ever have occluded selection with face dots ON.
This is default setup that is used to detect mesh issues. You will just not use this mode, so there is no problem.
> In #73479#977466, @slowburn wrote:
> Controlling select-through only with the keymap is too complicated as it would double the amount of selection shortcuts to manage.
Yes.
> Also a button somewhere in the UI would work as an indicator to show if select-through is enabled.
The design of this option is provided in summarizing post.
> There's no way to control when to use facedots for selection. For picking a single polygon, facedot is usually more accurate, but for box and lasso selection it would be good to have an option to choose whether to select by facedots or by area.
It is defined by shading mode.
I am using facedots display with occluded area selection for detecting mesh issues as well.
It is very useful since it clearly shows faces distribution.
I also prefer to use xray with no opacity instead of wireframe or select through because it show mesh.
I am using facedots display with occluded area selection for detecting mesh issues as well.
It is very useful since it clearly shows faces distribution.
I also prefer to use xray with no opacity instead of wireframe or select through because it show mesh.
We are using xray for surface-based kind of models with no inner structures, and wireframe for models with complex inner structures, when faces shading depicts level of inclosure (nesting) of mesh entities.
We are using xray for surface-based kind of models with no inner structures, and wireframe for models with complex inner structures, when faces shading depicts level of inclosure (nesting) of mesh entities.
Alright got a new build for people to check out, once I get what I can do finished I'll throw a diff over on https://developer.blender.org/D6322
I found these instructions for doing patches. Looks like I'll need to apply this to master, meaning 2.90. So there might be a few other things to do to make it work with that. https://wiki.blender.org/wiki/Tools/Patches
What's new:
I have a button in the header next to xray for toggling Select Through, using the icon for OBJECT_HIDDEN as a placeholder.
On that Select Through button there's a dropdown with one checkbox called 'Keymap Override'. It gives people like me the convenience of having select through in the keymap, while giving everyone else the button option.
Xray Facedots has been cleaned up. 1 checkbox for solid and 1 for xray. I agree about a dropdown being 1 extra click, not necessary. Slipped my mind because I was thinking about HOW to make it into a dropdown instead of a checkbox, rather than WHY ;)
Select Through can be disabled in Xray now. Pretty sure that wasn't the way it was before. This is a consequence/bonus of having both keymap and a header button to control Select Through. Or at least the way I implemented this behaviour made it happen unintentionally. It seems that Selection and Xray have been even further "Decoupled" to borrow from that thread title. Whether this is something people are wanting is something I'm interested in hearing
Haven't done anything for Area/Facedot selection options yet. Will look into it. No promises of course, not sure where that takes place, but I'm pretty sure that something @kio originally did has an effect because you can select by area in xray. In the official build you can only select by facedots in xray.
Check it out and let me know
Alright got a new build for people to check out, once I get what I can do finished I'll throw a diff over on
https://developer.blender.org/D6322
I found these instructions for doing patches. Looks like I'll need to apply this to master, meaning 2.90. So there might be a few other things to do to make it work with that.
https://wiki.blender.org/wiki/Tools/Patches
Here's a link to the build, will update the thread as well
https://www.dropbox.com/s/9vuth1b6ixol4qp/Blender%202.83.3b%20-%20Select%20Through%20Keymap%20Override.7z?dl=0
What's new:
I have a button in the header next to xray for toggling Select Through, using the icon for OBJECT_HIDDEN as a placeholder.
On that Select Through button there's a dropdown with one checkbox called 'Keymap Override'. It gives people like me the convenience of having select through in the keymap, while giving everyone else the button option.
Xray Facedots has been cleaned up. 1 checkbox for solid and 1 for xray. I agree about a dropdown being 1 extra click, not necessary. Slipped my mind because I was thinking about HOW to make it into a dropdown instead of a checkbox, rather than WHY ;)
Select Through can be disabled in Xray now. Pretty sure that wasn't the way it was before. This is a consequence/bonus of having both keymap and a header button to control Select Through. Or at least the way I implemented this behaviour made it happen unintentionally. It seems that Selection and Xray have been even further "Decoupled" to borrow from that thread title. Whether this is something people are wanting is something I'm interested in hearing
Haven't done anything for Area/Facedot selection options yet. Will look into it. No promises of course, not sure where that takes place, but I'm pretty sure that something @kio originally did has an effect because you can select by area in xray. In the official build you can only select by facedots in xray.
Check it out and let me know
In #73479#977445, @Rawalanche wrote:
For example for case 4, there's really no reason to ever have occluded selection with face dots ON.
This is default setup that is used to detect mesh issues. You will just not use this mode, so there is no problem.
Wow, this makes absolutely no sense whatsoever. If this is just about detecting mesh issues, then there's really no reason to have this at all. Instead of going into "mesh detecting mode of displaying face dots but not selecting through", you can just quickly get into the actual xray mode, and see literally the same thing. Furthermore, if you had this hypothetical "mesh issue detection mode" which would show you issues like 0 area faces between the edges of faces, then you'd still not be able to select many of them if you had select through off. You are literally describing just a matter of seeing the face dots. It doesn't matter what the mode which displays them is, if it's just a temporary error detection tool for you. What matters a lot though, is having an option of an additional nonsense mode, which could confuse many average users, whom did not have time to bury through 2 threads of 100+ posts.
My point is that you can have exactly what you want - an ability to see face dots to detect mesh issues - without need to have one additional possible combination of variables to confuse people with.
> In #73479#977520, @1D_Inc wrote:
>> In #73479#977445, @Rawalanche wrote:
>> For example for case 4, there's really no reason to ever have occluded selection with face dots ON.
> This is default setup that is used to detect mesh issues. You will just not use this mode, so there is no problem.
Wow, this makes absolutely no sense whatsoever. If this is just about detecting mesh issues, then there's really no reason to have this at all. Instead of going into "mesh detecting mode of displaying face dots but not selecting through", you can just quickly get into the actual xray mode, and see literally the same thing. Furthermore, if you had this hypothetical "mesh issue detection mode" which would show you issues like 0 area faces between the edges of faces, then you'd still not be able to select many of them if you had select through off. You are literally describing just a matter of seeing the face dots. It doesn't matter what the mode which displays them is, if it's just a temporary error detection tool for you. What matters a lot though, is having an option of an additional nonsense mode, which could confuse many average users, whom did not have time to bury through 2 threads of 100+ posts.
My point is that you can have exactly what you want - an ability to see face dots to detect mesh issues - without need to have one additional possible combination of variables to confuse people with.
In #73479#977897, @lcas wrote:
Select Through can be disabled in Xray now. Pretty sure that wasn't the way it was before.
Yeah, that's probably undesirable. People are asking for select-through mode in solid shading to eliminate needles switching to xray, but I've never seen anyone asking to disable select-through in xray mode. I think it would be best to have it always on in Wireframe/Xray shading and the button could be hidden or disabled in Wire/Xraym mode, if that's possible. Other solution would be to toggle this feature independently for each shading mode, so that you could replicate current behaviour, where it's disabled in solid shading, but gets automatically enabled in Xray.
As for the button itself, I think it would be better to move it out of the area that's used for overlays and shading modes:
Also it is visible in object mode as well, even though it doesn't seem to do anything. Do you think selection occlusion could be enabled in object mode?
Xray Facedots has been cleaned up. 1 checkbox for solid and 1 for xray.
Maybe rename first checkbox to "Wire/Xray" since it also affects wireframe mode
But overall the build works well. Global toggle works with all selection modes I tested, keymap override also works without issues.
There is still the issue with facedot selection, I hope you can find out how to control it.
> In #73479#977897, @lcas wrote:
> Select Through can be disabled in Xray now. Pretty sure that wasn't the way it was before.
Yeah, that's probably undesirable. People are asking for select-through mode in solid shading to eliminate needles switching to xray, but I've never seen anyone asking to disable select-through in xray mode. I think it would be best to have it always on in Wireframe/Xray shading and the button could be hidden or disabled in Wire/Xraym mode, if that's possible. Other solution would be to toggle this feature independently for each shading mode, so that you could replicate current behaviour, where it's disabled in solid shading, but gets automatically enabled in Xray.
As for the button itself, I think it would be better to move it out of the area that's used for overlays and shading modes:
Also it is visible in object mode as well, even though it doesn't seem to do anything. Do you think selection occlusion could be enabled in object mode?
>Xray Facedots has been cleaned up. 1 checkbox for solid and 1 for xray.
Maybe rename first checkbox to "Wire/Xray" since it also affects wireframe mode
But overall the build works well. Global toggle works with all selection modes I tested, keymap override also works without issues.
There is still the issue with facedot selection, I hope you can find out how to control it.
B.2) The option's behavior must satisfy the following conditions:
| |Display mode |faces selection type |selection mode |default overlays| option| Result|
|1 |xray/wire |facedot |through | any| off| Xray/wire with facedots selection
|2 |xray/wire |area |through |any| on|Xray/wire with area selection and no facedots
|3 |solid |area |occlude |facedots off| off| Solid with occluded area selection and no facedots
|4 |solid |facedot |occlude | facedots on| off| Solid with occluded area selection and facedots display
|5 |solid |area |through |any| on| Solid with through area selection and no facedots
Got all of these except #4, Select Visible by Facedots in Non-xray. Calling it 'solid shading' is a little innaccurate, technically xray is available in solid shading, but we all know what we mean, solid = non-xray. Same goes for wire vs xray, they are basically synonymous, except that you can disable xray in wireframe shading. Going forward I'll do my best to stick with 'xray' and 'non-xray' even though it doesn't REALLY matter and it sounds kinda weird saying non-xray.
Anyways, the way Blender is written, Select by Facedots always does a Select Through.
I tried messing around with it, combining part of the select facedots with part of select visible stuff. Just guessing which specific lines of it actually do the facedot selecting. Then tried doing the opposite, different ways of combining the select occluded with the facedot stuff. Guessing which part actually does the occluded filtering. But no luck so far. Mostly just a slew of errors on build, and then if it DOES build it will crash when testing the desired select mode. Going to get a debug going, but not expecting it to magically tell me how to fix it.
In addition to those conditions above (minus #4) I have:
6. Select Through by Facedots in Non-Xray (the opposite of what I want, probably not useful)
7. Select Visible by Area in Xray (you can see the "occluded" faces or dots, but choose to not select if desired)
Also have these toggle options in header popover/dropdown for quality of life:
Automatic - Select Through if Xray & Select Visible if Non-xray (replicate current Blender behaviour)
Keymap Override - Will give keymap settings priority regardless of the other settings (my preferred method)
Will probably add these options as well:
3. Tool Setting Override - Will give Tool Setting priority unless keymap override is on (I'll add tool setting back, so if someone wants each select mode to have their own select-through or visible independently, they can have it)
4. Select Facedot / Face Center Auto (if facedots are on, it will select by facedot, if they're off it will select by area)
This is assuming I can get your condition #4 working. I think Select Visible by Facedot could be pretty handy, but like I said having trouble getting it to work. I might decide to just set that aside and come back for later, or PLEASE someone else figure that out. In the meantime I would restrict facedot selection to Xray only, and Non-xray facedots would work like they currently do, as mesh checking or whatever else.
In #73479#978376, @slowburn wrote:
Also it is visible in object mode as well, even though it doesn't seem to do anything. Do you think selection occlusion could be enabled in object mode?
I think so, I'm going to work on that once I get Facedot Selection working without Select Through happening.
If it looks like it's a bit much, like a separate topic, or if it's just unlikely to be done right now, I'll turn the button off in Object mode.
And finally, kio said that it was already processor intensive in the other topic. It is definitely heavier now, I imagine anyway. So I'll do some testing with that, I see all these #Debug Time things in the script that probably have something to do with testing that, but who knows. I can always just make a complex enough mesh that it takes a second to complete a selection, and then compare that with normal blender.
> In #73479#926945, @1D_Inc wrote:
>
> **B.2**) The option's behavior must satisfy the following conditions:
>
> | |Display mode |faces selection type |selection mode |default overlays| option| Result|
> |1 |xray/wire |facedot |through | any| off| Xray/wire with facedots selection
> |2 |xray/wire |area |through |any| on|Xray/wire with area selection and no facedots
> |3 |solid |area |occlude |facedots off| off| Solid with occluded area selection and no facedots
> |4 |solid |facedot |occlude | facedots on| off| Solid with occluded area selection and facedots display
> |5 |solid |area |through |any| on| Solid with through area selection and no facedots
>
Got all of these except #4, Select Visible by Facedots in Non-xray. Calling it 'solid shading' is a little innaccurate, technically xray is available in solid shading, but we all know what we mean, solid = non-xray. Same goes for wire vs xray, they are basically synonymous, except that you can disable xray in wireframe shading. Going forward I'll do my best to stick with 'xray' and 'non-xray' even though it doesn't REALLY matter and it sounds kinda weird saying non-xray.
Anyways, the way Blender is written, Select by Facedots always does a Select Through.
I tried messing around with it, combining part of the select facedots with part of select visible stuff. Just guessing which specific lines of it actually do the facedot selecting. Then tried doing the opposite, different ways of combining the select occluded with the facedot stuff. Guessing which part actually does the occluded filtering. But no luck so far. Mostly just a slew of errors on build, and then if it DOES build it will crash when testing the desired select mode. Going to get a debug going, but not expecting it to magically tell me how to fix it.
In addition to those conditions above (minus #4) I have:
6. Select Through by Facedots in Non-Xray (the opposite of what I want, probably not useful)
7. Select Visible by Area in Xray (you can see the "occluded" faces or dots, but choose to not select if desired)
Also have these toggle options in header popover/dropdown for quality of life:
1. Automatic - Select Through if Xray & Select Visible if Non-xray (replicate current Blender behaviour)
2. Keymap Override - Will give keymap settings priority regardless of the other settings (my preferred method)
Will probably add these options as well:
3. Tool Setting Override - Will give Tool Setting priority unless keymap override is on (I'll add tool setting back, so if someone wants each select mode to have their own select-through or visible independently, they can have it)
4. Select Facedot / Face Center Auto (if facedots are on, it will select by facedot, if they're off it will select by area)
This is assuming I can get your condition #4 working. I think Select Visible by Facedot could be pretty handy, but like I said having trouble getting it to work. I might decide to just set that aside and come back for later, or PLEASE someone else figure that out. In the meantime I would restrict facedot selection to Xray only, and Non-xray facedots would work like they currently do, as mesh checking or whatever else.
> In #73479#978376, @slowburn wrote:
> Also it is visible in object mode as well, even though it doesn't seem to do anything. Do you think selection occlusion could be enabled in object mode?
I think so, I'm going to work on that once I get Facedot Selection working without Select Through happening.
If it looks like it's a bit much, like a separate topic, or if it's just unlikely to be done right now, I'll turn the button off in Object mode.
And finally, kio said that it was already processor intensive in the other topic. It is definitely heavier now, I imagine anyway. So I'll do some testing with that, I see all these #Debug Time things in the script that probably have something to do with testing that, but who knows. I can always just make a complex enough mesh that it takes a second to complete a selection, and then compare that with normal blender.
> In #73479#981138, @lcas wrote:
> Got all of these except #4, Select Visible by Facedots in Non-xray.
Sorry, it is a mistake. Description was right though.
It should represent default Blender behavior , so it should be
| |Display mode |faces selection type |selection mode |default overlays| option| Result|
| -- | -- | -- | -- | -- | -- | -- |
|4 |solid |**area** |occlude | facedots on| off| Solid with occluded area selection and facedots display
[Fixed that ](https://developer.blender.org/T73479#926945). Thanks for pointing.
Wow, no kidding? I didn't even read the description just the conditions.
If nobody else really wants it, I'm not going to bother reinventing the wheel so to speak, as far as the way Blender deals with Facedot Selection only working as Select Through. I probably need some real knowledge of scripting to go into that stuff.
If I can't figure out how to do Select Visible by Facedots, by say the end of the weekend, I'm just going to move on and tidy things up.
Then I'll see about Object Mode Select Visible real quick. Probably something for later unless it's really straightforward.
Wow, no kidding? I didn't even read the description just the conditions.
If nobody else really wants it, I'm not going to bother reinventing the wheel so to speak, as far as the way Blender deals with Facedot Selection only working as Select Through. I probably need some real knowledge of scripting to go into that stuff.
If I can't figure out how to do Select Visible by Facedots, by say the end of the weekend, I'm just going to move on and tidy things up.
Then I'll see about Object Mode Select Visible real quick. Probably something for later unless it's really straightforward.
In #73479#981152, @lcas wrote:
Wow, no kidding? I didn't even read the description just the conditions.
No kidding.
I participating too many development treads (way more than I would like to), and always run several deadlines, so it is easy to make such mistakes for me.
That's why I provided descriptions. Kind a self-check for cases like that.
If I can't figure out how to do Select Visible by Facedots, by say the end of the weekend, I'm just going to move on and tidy things up.
Indeed, such a mode will be hard to achieve and it is not looking necessary - wireframe/xray modes handles facedots selection type nicely.
It will also add system uncertainty (I can see facedots, it is solid shading mode, but I can't be sure if I am selecting by area or facedots) so let's keep the faces selection by the facedots exclusively for the wireframe/xray.
Select Through by Facedots in Non-Xray (the opposite of what I want, probably not useful)
Can be achived with A.2 of summarizing post. Indeed, probably will be not used often since it requires super predictable geometry.
Select Visible by Area in Xray (you can see the "occluded" faces or dots, but choose to not select if desired)
Sounds pretty much confusing) (I can see inner parts, but can't select them)
Tests are needed for both of them.
Will probably add these options as well:
Please, be careful with options and overrides, otherwise block-schemes will be needed for getting predictable selection result.
Conciseness is a sign of good design.
> In #73479#981152, @lcas wrote:
> Wow, no kidding? I didn't even read the description just the conditions.
No kidding.
I participating too many development treads (way more than I would like to), and always run several deadlines, so it is easy to make such mistakes for me.
That's why I provided descriptions. Kind a self-check for cases like that.
> If I can't figure out how to do Select Visible by Facedots, by say the end of the weekend, I'm just going to move on and tidy things up.
Indeed, such a mode will be hard to achieve and it is not looking necessary - wireframe/xray modes handles facedots selection type nicely.
It will also add system uncertainty (I can see facedots, it is solid shading mode, but I can't be sure if I am selecting by area or facedots) so let's keep the faces selection by the facedots exclusively for the wireframe/xray.
> 6. Select Through by Facedots in Non-Xray (the opposite of what I want, probably not useful)
Can be achived with A.2 of summarizing post. Indeed, probably will be not used often since it requires super predictable geometry.
> 7. Select Visible by Area in Xray (you can see the "occluded" faces or dots, but choose to not select if desired)
Sounds pretty much confusing) (I can see inner parts, but can't select them)
Tests are needed for both of them.
> Will probably add these options as well:
Please, be careful with options and overrides, otherwise block-schemes will be needed for getting predictable selection result.
Conciseness is a sign of good design.
There is no consensus on backface selection and facedots, because the discussion is about scrapping things that are being used by others. Blender shouldn't enforce a workflow upon people for the sake of a few who do not need it. Instead, it should provide the options for all, which includes the option not to use it! Since all combinations are requested, they should all be provided. The difficulty arises in coupling several options of display and selection to which each user has their own preferences, hence why these move to the preferences menu. Again any combination of select through, facedot, area selection and display settings are mentioned! The preferences should accompany setting selection (area/facedot & area type) and how these are activated by default when entering a certain display mode or selection mode. This is where the action scheme is put to use; to couple those modes that require multiple changes. Yet users can individually toggle the buttons and map them to shortcuts like the rest of the interface.
Area selection/ facedot selection (checkbox in dropdown)
By having the backface selection button in the interface, it shows the user that it's in use. The facedot selection and backface selection mode should be reflected in the icon itself, which changes per mode:
X-ray icon (used in the interface as default) it means backface selection is on/ off)
Grey with backface selection off
Blue with backface selection on
X-ray icon and facedot (just add dots to the default icon), it means facedot selection is on and backface selection is on/ off
Grey with backface selection off and facedot selection on
Blue with backface selection on and facedot selection on
Facedot selection turns on facedots, facedot display is turned off when the selection mode is off
Display modes act independently from selection and overlay, with the exception that X-ray and wireframe enable backface selection automatically thereby greying out/ removing the button
Preferences
Under Input? Here you set your prefered behavior (the naming is more of an indication to the use than to what should be exposed in the preference settings UI). It should toggle multiple settings for display/selection. This is were the action scheme comes in.
Facedot display & facedot selection
Facedot display sets facedot selection
Facedot display does not affect facedot selection
Facedot selection toggles facedot display
Facedot selection turns facedots on, but does not turn it off (I would skip this one).
Default to Facedot selection mode in Xray/Wireframe
On: sets facedot selection in Xray/Wireframe mode (and activates upon entering X-ray/Wireframe)
Off: defaults area selection
Select backface to toggle:
X-ray display
Wireframe display
Solid display with highlighted selection in which the selection highlight acts as an overlay (like in Modo I have come to understand? )
Select backface does not alter display mode (this effectively only sets backface selection)
Display modes that default to facedot display
X-ray
X-ray & Wireframe
Solid, X-ray & Wireframe
Do not display facedots by default
Allow global facedot display override: default facedot display in 4. is overruled by the facedot display toggle.
Enable backface selection with modifier keys: enabling this shows a drop down from which the preferred override keys can be assigned (this should be considered as stage 2 addition or something that could be in an addon):
hold alt/shift/control
LMB, RMB & MMB with dropdowns for: LSTV - Limit selection to visible & backface selection, to be able to differentiate between selection modes by mouse button
Area selection method:
Crossing: everything touched by the selection window is selected
Window: everything completely withi the window is selected
Direction: window or crossing depending on the input direction: left/ right
Seeing as how complex the preferences and possible combinations of functions are, as indicated in the discussion length - and all options have to be available - there isn't really a way to avoid UI clutter. So having this in the preferences under its own collapsable header will suffice as long as the default settings are clear enough for any user and advanced users can have it set their way. Besides, productivity and speed is more important than a minimalist preferences window, with proper grouping it shouldn't even be considered as being cluthering. Having the options there, without redundancy is all that matters.
We all need the functionality, the devs might as well add the individual buttons and functions and do another round of user feedback on the preferences later, that way there is no longer any hold up on this highly demanded workflow fix, because of some minor UI and preference quirrel!
PS. I don't use fadedots, I would already be happy with a like toggle to ignore backface for selection with alt+b, while leaving the default backface selection in X-ray on. I can, however, see the use of facedots in picking faces with fill selection and/ or shortest path with both visible and occluded faces.
There is no consensus on backface selection and facedots, because the discussion is about scrapping things that are being used by others. Blender shouldn't enforce a workflow upon people for the sake of a few who do not need it. Instead, it should provide the options for all, which includes the option not to use it! Since all combinations are requested, they should all be provided. The difficulty arises in coupling several options of display and selection to which each user has their own preferences, hence why these move to the preferences menu. Again any combination of select through, facedot, area selection and display settings are mentioned! The preferences should accompany setting selection (area/facedot & area type) and how these are activated by default when entering a certain display mode or selection mode. This is where the action scheme is put to use; to couple those modes that require multiple changes. Yet users can individually toggle the buttons and map them to shortcuts like the rest of the interface.
**Required UI elements:**
**Under Overlays**
* Facedots
**Under Selection**
* Ignore backfacing (select through) (current Xray button)
* Area selection/ facedot selection (checkbox in dropdown)
By having the backface selection button in the interface, it shows the user that it's in use. The facedot selection and backface selection mode should be reflected in the icon itself, which changes per mode:
1. X-ray icon (used in the interface as default) it means backface selection is on/ off)
* Grey with backface selection off
* Blue with backface selection on
2. X-ray icon and facedot (just add dots to the default icon), it means facedot selection is on and backface selection is on/ off
* Grey with backface selection off and facedot selection on
* Blue with backface selection on and facedot selection on
The dropdown with in the mockup by @Rawalanche with a checkbox for X-ray selection should state: facedot selection, this checkbox effectively switches between 1 and 2.
See: https://devtalk.blender.org/t/decoupling-x-ray-and-limit-selection-to-visible/3498/154 for the mockup.
**Combined behaviour**
1. Facedot selection turns on facedots, facedot display is turned off when the selection mode is off
2. Display modes act independently from selection and overlay, with the exception that X-ray and wireframe enable backface selection automatically thereby greying out/ removing the button
**Preferences**
Under Input? Here you set your prefered behavior (the naming is more of an indication to the use than to what should be exposed in the preference settings UI). It should toggle multiple settings for display/selection. This is were the action scheme comes in.
1. Facedot display & facedot selection
* Facedot display sets facedot selection
* Facedot display does not affect facedot selection
* Facedot selection toggles facedot display
* Facedot selection turns facedots on, but does not turn it off (I would skip this one).
2. Default to Facedot selection mode in Xray/Wireframe
* On: sets facedot selection in Xray/Wireframe mode (and activates upon entering X-ray/Wireframe)
* Off: defaults area selection
3. Select backface to toggle:
* X-ray display
* Wireframe display
* Solid display with highlighted selection in which the selection highlight acts as an overlay (like in Modo I have come to understand? )
* Select backface does not alter display mode (this effectively only sets backface selection)
4. Display modes that default to facedot display
* X-ray
* X-ray & Wireframe
* Solid, X-ray & Wireframe
* Do not display facedots by default
5. Allow global facedot display override: default facedot display in 4. is overruled by the facedot display toggle.
6. Enable backface selection with modifier keys: enabling this shows a drop down from which the preferred override keys can be assigned (this should be considered as stage 2 addition or something that could be in an addon):
* hold alt/shift/control
* LMB, RMB & MMB with dropdowns for: LSTV - Limit selection to visible & backface selection, to be able to differentiate between selection modes by mouse button
7. Area selection method:
* Crossing: everything touched by the selection window is selected
* Window: everything completely withi the window is selected
* Direction: window or crossing depending on the input direction: left/ right
Seeing as how complex the preferences and possible combinations of functions are, as indicated in the discussion length - and all options have to be available - there isn't really a way to avoid UI clutter. So having this in the preferences under its own collapsable header will suffice as long as the default settings are clear enough for any user and advanced users can have it set their way. Besides, productivity and speed is more important than a minimalist preferences window, with proper grouping it shouldn't even be considered as being cluthering. Having the options there, without redundancy is all that matters.
We all need the functionality, the devs might as well add the individual buttons and functions and do another round of user feedback on the preferences later, that way there is no longer any hold up on this highly demanded workflow fix, because of some minor UI and preference quirrel!
PS. I don't use fadedots, I would already be happy with a like toggle to ignore backface for selection with alt+b, while leaving the default backface selection in X-ray on. I can, however, see the use of facedots in picking faces with fill selection and/ or shortest path with both visible and occluded faces.
In #73479#995849, @Hologram wrote:
There is no consensus on backface selection and facedots.
Please, take into account summarizing post so as not to repeat the discussions that were already six months ago.
> In #73479#995849, @Hologram wrote:
> There is no consensus on backface selection and facedots.
Please, take into account [summarizing post ](https://developer.blender.org/T73479#926945) so as not to repeat the discussions that were already six months ago.
Well, its time to update summarizing post. Previous one .
Left the only design option. Mentioned CP/WP selection types as well.
Select Through is needed for special type of modeling when topology is predictable for user (like gamedev modeling).
It is widespread behaviour in industry standards software.
The proposal is about
The ability for box/lasso (non-picking) tools to select backface geometry on shaded model without backface display.
The ability for box/lasso (non-picking) tools to select faces in wireframe/Xray mode by their bounds (with no facedots display).
Possible Xray solutions:
A.1) Split Xray alpha settings for object and edit modes, since alpha = 1 is suitable only for edit mode, and satisfies LSTV - Limit Selection To Visible - demands. A.2) Add the ability to fade with slider backfacing wiremesh display in Xray mode down to zero.
A.1 and A.2 will make select through with facedots selection mode available.
B.1) Add Xray/Wiremesh mode facedot center disabling option, what will make possible faces area selection for all non-picking selecting tools and methods,
separating the selection mode from the display mode.
Possible design:
better like this (because takes the same space, but makes option easily accessible, detectable and independent from Xray)
B.2) The option's behavior must satisfy the following conditions:
Display mode
faces selection type
selection mode
default overlays
option
Result
1
xray/wire
facedot
through
any
off
Xray/wire with facedots selection
2
xray/wire
area
through
any
on
Xray/wire with area selection and no facedots
3
solid
area
occlude
facedots off
off
Solid with occluded area selection and no facedots
4
solid
area
occlude
facedots on
off
Solid with occluded area selection and facedots display
5
solid
area
through
any
on
Solid with through area selection and no facedots
B.1 and B.2 will make select through mode detectable with no facedots display.
It is also possible to use it temporarily (switch it) or work constantly in that mode if it is needed, depending on a workflow type, because users who will use such option do not need regular Xray, in cases when Xray spoils the viewport.
Additional / Questionable / Offtop:
X.1) Ability to select visible with backface culling in shaded mode to satisfy selecting visible condition. An example of use is interior basemesh modeling.
X.2 ) Split Xray and Wireframe modes, since wireframe without Xray clones Flat shading mode, so it is more about visual style rather than shading mode. (questionable)
X.3) The reasons for separating the selection tools for the edit and object modes are not obvious.
X.4) Types of selection (CP - crossing - selecting everything that is crossed with selection border / WP - window - everything that is completely included in the border)
and directional selection (border from right to left is CP, and from left to right is WP)
Well, its time to update summarizing post. [Previous one ](https://developer.blender.org/T73479#926945).
Left the only design option. Mentioned CP/WP selection types as well.
___________________________________________
- Select Through is needed for special type of modeling when topology is predictable for user (like gamedev modeling).
It is widespread behaviour in industry standards software.
**The proposal is about**
1) The ability for box/lasso (non-picking) tools to select backface geometry on shaded model without backface display.
2) The ability for box/lasso (non-picking) tools to select faces in wireframe/Xray mode by their bounds (with no facedots display).
**Possible Xray solutions:**
**A.1**) Split Xray alpha settings for object and edit modes, since alpha = 1 is suitable only for edit mode, and satisfies LSTV - Limit Selection To Visible - demands.
**A.2**) Add the ability to fade with slider backfacing wiremesh display in Xray mode down to zero.
A.1 and A.2 will make select through with facedots selection mode available.
**B.1**) Add Xray/Wiremesh mode facedot center disabling option, what will make possible faces area selection for all non-picking selecting tools and methods,
separating the selection mode from the display mode.
Possible design:
better like this (because takes the same space, but makes option easily accessible, detectable and independent from Xray)
**B.2**) The option's behavior must satisfy the following conditions:
| |Display mode |faces selection type |selection mode |default overlays| option| Result|
| -- | -- | -- | -- | -- | -- | -- |
|1 |xray/wire |facedot |through | any| off| Xray/wire with facedots selection
|2 |xray/wire |area |through |any| on|Xray/wire with area selection and no facedots
|3 |solid |area |occlude |facedots off| off| Solid with occluded area selection and no facedots
|4 |solid |area |occlude | facedots on| off| Solid with occluded area selection and facedots display
|5 |solid |area |through |any| on| Solid with through area selection and no facedots
B.1 and B.2 will make select through mode detectable with no facedots display.
It is also possible to use it temporarily (switch it) or work constantly in that mode if it is needed, depending on a workflow type, because users who will use such option do not need regular Xray, in cases when Xray spoils the viewport.
Additional / Questionable / Offtop:
X.1) Ability to select visible with backface culling in shaded mode to satisfy selecting visible condition. An example of use is interior basemesh modeling.
X.2 ) Split Xray and Wireframe modes, since wireframe without Xray clones Flat shading mode, so it is more about visual style rather than shading mode. (questionable)
X.3) The reasons for separating the selection tools for the edit and object modes are not obvious.
X.4) Types of selection (CP - crossing - selecting everything that is crossed with selection border / WP - window - everything that is completely included in the border)
and directional selection (border from right to left is CP, and from left to right is WP)
@1D_Inc To move the discussion forward I would like to visualize the different design proposals. But I have a difficult time to understand the UI-implications of the different options.
Can you help me to roll out these proposals as UI components? I'm using this Figma document:
A.1) Split Xray alpha settings for object and edit modes, since alpha = 1 is suitable only for edit mode, and satisfies LSTV - Limit Selection To Visible - demands.
As far as i understand this statement, it does not require any change on ui-components, right?
A.2) Add the ability to fade with slider backfacing wiremesh display in Xray mode down to zero.
To be honest, I don't understand neither the sentence nor the problem it's trying to solve.
B.1 better like this (because takes the same space, but makes option easily accessible, detectable and independent from Xray)
I'm not quite sure, if I understand this design proposal. Does it show a toggle icon (with a tooltip) or a drop-down icon (with a misleading icon)?
@1D_Inc Do you already have a set of options/checkboxes etc in mind how B2 could look like?
Offtopic:
How set in stone is the LSTV? It doesn't work in object mode, so I assume it should be a convention/default rather than a guideline. Isn't this like the "right vs left selection" discussion all over again and eventually will become an option?
@1D_Inc To move the discussion forward I would like to visualize the different design proposals. But I have a difficult time to understand the UI-implications of the different options.
Can you help me to roll out these proposals as UI components? I'm using [this Figma document](https://www.figma.com/file/bseq6jLsv7njvo0mNGvYP2/X-Ray-Designs?node-id=6%3A148):
> A.1) Split Xray alpha settings for object and edit modes, since alpha = 1 is suitable only for edit mode, and satisfies LSTV - Limit Selection To Visible - demands.
As far as i understand this statement, it does not require any change on ui-components, right?
> A.2) Add the ability to fade with slider backfacing wiremesh display in Xray mode down to zero.
To be honest, I don't understand neither the sentence nor the problem it's trying to solve.
> B.1 better like this (because takes the same space, but makes option easily accessible, detectable and independent from Xray)
I'm not quite sure, if I understand this design proposal. Does it show a toggle icon (with a tooltip) or a drop-down icon (with a misleading icon)?
@1D_Inc Do you already have a set of options/checkboxes etc in mind how B2 could look like?
____
Offtopic:
How set in stone is the LSTV? It doesn't work in object mode, so I assume it should be a convention/default rather than a guideline. Isn't this like the "right vs left selection" discussion all over again and eventually will become an option?
In #73479#996345, @pixtur wrote: @1D_Inc To move the discussion forward I would like to visualize the different design proposals. But I have a difficult time to understand the UI-implications of the different options.
Can you help me to roll out these proposals as UI components? I'm using this Figma document:
Will try my best.
The problem of this proposal is that it is have too many options spread around Blender, and it is dedicated only to facedots (it is not solving select through problem).
There will be a lot of issues - for example, it will allow to display facedots in Xray mode, but with no selection by facedots, which will be inconsistent, because of no ability to select backface geometry with picking types of selection, which will lead to uncertainty of the mode from its visual appearance.
If to add possible select through solution to this proposal, the complexity of the resulting system will be too high for comfortable work, because it will assume lots of tweaking of lots of options stored in different places.
A.1) Split Xray alpha settings for object and edit modes, since alpha = 1 is suitable only for edit mode, and satisfies LSTV - Limit Selection To Visible - demands.
As far as i understand this statement, it does not require any change on ui-components, right?
Offtopic:
How set in stone is the LSTV?
The problem of current realization is that setup that satisfying LSTV demands in edit mode (turning Xray on and setting alpha to 1) is useless in object mode, so there is need to constantly tweak Xray alpha slider value between object and edit modes.
There should be two separate Xray alpha sliders - separate for object mode and edit mode to have LSTV in edit mode satisfied and have Xray display in object mode untouched.
A.2) Add the ability to fade with slider backfacing wiremesh display in Xray mode down to zero.
To be honest, I don't understand neither the sentence nor the problem it's trying to solve.
In Xray mode + alpha=1 backfacing geometry is drawn on top of the model.
The ability to fade backface geometry display down to zero will bring the ability to select through without drawing backface geometry on top of the shaded model.
This will bring the ability of select through with facedots display, but with no backface geometry display distraction.
B.1 better like this (because takes the same space, but makes option easily accessible, detectable and independent from Xray)
I'm not quite sure, if I understand this design proposal. Does it show a toggle icon (with a tooltip) or a drop-down icon (with a misleading icon)?
It is a single icon with a tooltip temporarily called "Option".
@1D_Inc Do you already have a set of options/checkboxes etc in mind how B2 could look like?
Yes. It is that one single icon that was shown in B.1
"Option" from the table is that one "Option" from B.1
Technically, our proposal is designed to solve select through problem with a single button, including satisfying all critical use cases (table) and avoiding mode uncertainty or system complexity issues.
> In #73479#996345, @pixtur wrote:
> @1D_Inc To move the discussion forward I would like to visualize the different design proposals. But I have a difficult time to understand the UI-implications of the different options.
> Can you help me to roll out these proposals as UI components? I'm using [this Figma document](https://www.figma.com/file/bseq6jLsv7njvo0mNGvYP2/X-Ray-Designs?node-id=6%3A148):
Will try my best.
The problem of this proposal is that it is have too many options spread around Blender, and it is dedicated only to facedots (it is not solving select through problem).
There will be a lot of issues - for example, it will allow to display facedots in Xray mode, but with no selection by facedots, which will be inconsistent, because of no ability to select backface geometry with picking types of selection, which will lead to uncertainty of the mode from its visual appearance.
If to add possible select through solution to this proposal, the complexity of the resulting system will be too high for comfortable work, because it will assume lots of tweaking of lots of options stored in different places.
>> A.1) Split Xray alpha settings for object and edit modes, since alpha = 1 is suitable only for edit mode, and satisfies LSTV - Limit Selection To Visible - demands.
> As far as i understand this statement, it does not require any change on ui-components, right?
> Offtopic:
> How set in stone is the LSTV?
The problem of current realization is that setup that satisfying LSTV demands in edit mode (turning Xray on and setting alpha to 1) is useless in object mode, so there is need to constantly tweak Xray alpha slider value between object and edit modes.
There should be two separate Xray alpha sliders - separate for object mode and edit mode to have LSTV in edit mode satisfied and have Xray display in object mode untouched.
>> A.2) Add the ability to fade with slider backfacing wiremesh display in Xray mode down to zero.
> To be honest, I don't understand neither the sentence nor the problem it's trying to solve.
In Xray mode + alpha=1 backfacing geometry is drawn on top of the model.
The ability to fade backface geometry display down to zero will bring the ability to select through without drawing backface geometry on top of the shaded model.
This will bring the ability of select through with facedots display, but with no backface geometry display distraction.
>> B.1 better like this (because takes the same space, but makes option easily accessible, detectable and independent from Xray)
> I'm not quite sure, if I understand this design proposal. Does it show a toggle icon (with a tooltip) or a drop-down icon (with a misleading icon)?
It is a single icon with a tooltip temporarily called "Option".
> @1D_Inc Do you already have a set of options/checkboxes etc in mind how B2 could look like?
Yes. It is that one single icon that was shown in B.1
"Option" from the table is that one "Option" from B.1
Technically, our proposal is designed to solve select through problem with a single button, including satisfying all critical use cases (table) and avoiding mode uncertainty or system complexity issues.
Just to clarify: The title for this icon would be something like...
"Select faces only at dots"
(Or if inverted "Allow face selection outside dots")
I'm sure there must be better labels for it.
To be honest I personally would disable this option and can't see any use case to switch it on again.
It sounds like investing a lot of prominent screen space for a user preferences that is unlikely to change frequently.
Just to clarify: The title for this icon would be something like...
- "Select faces only at dots"
(Or if inverted "Allow face selection outside dots")
I'm sure there must be better labels for it.
To be honest I personally would disable this option and can't see any use case to switch it on again.
It sounds like investing a lot of prominent screen space for a user preferences that is unlikely to change frequently.
@1D_Inc I think this proposal is overcomplicating a quite simple request, allow me to explain: select through is simple, in terms of UI it could be as much as toggling it or have it mapped to a modifier key during selection. The issue at hand is that some people resist, because of the Limit Selection To Visible (LSTV) paradigm which is then used to bring up all sorts of display discussions, which in turn brings up facedot display and this brings up facedot selection vs area selection. So the entire thing is a cascading issue.
In #73479#996005, @1D_Inc wrote: The proposal is about
The ability for box/lasso (non-picking) tools to select backface geometry on shaded model without backface display.
The ability for box/lasso (non-picking) tools to select faces in wireframe/Xray mode by their bounds (with no facedots display).
The overall proposal is actually about four things: display overlays (facedot), selection modes, select through and selection shading/display mode. Selection display mode is also a form of viewport overlay and is shown upon entering a selection command.
Facedot display overlay
On
Off
Selection modes
Facedot selection (requires 1A)
Window selection (everything fully within the selection window is selected = Area selection)
Crossing selection (everything touched by the selection window is selected = Area selection)
Hybrid selection (combination of Window selection and crossing selection, which is dependent on the mouse gesture direction = Area selection)
Select backfacing/ Select occluded
Yes
No
Selection shading/ display mode in viewport
By active shading/ display mode, selection does not affect the display mode (i.e. no X-ray display when in solid shading)
X-ray display
Transparent selection highlight, which unlike 4A and 4B is applied after selection (front and backface selection are both highlighted, this requires any occluded geometry that is selected to display through the geometry in front)
Possible Xray solutions:
A.1) Split Xray alpha settings for object and edit modes, since alpha = 1 is suitable only for edit mode, and satisfies LSTV - Limit Selection To Visible - demands.
Object and edit mode could be set to behave similarly, so what I have mentioned here applies to both. You could have the same "Selection shading/ display mode in viewport" options for Edit and Object mode to make them behave independently, with the By active shading/ display mode as object mode default (which is the way it is currently and which is what is requested as desired method for select through apart from the facedot and window/crossing selection).
A.2) Add the ability to fade with slider backfacing wiremesh display in Xray mode down to zero.
I would opt to put the "Selection shading/ display mode in viewport" options on buttons and hide the X-ray mode slider when the "By active shading/ display mode" is ticked.
The fact that LSTV is a paradigm in Blender, yet a proven method elsewhere, sounds to me like it's time for a paradigm change. With the options I presented above, LSTV can always be enabled anyways (and perhaps could remain so by default?), no big deal.
Possible design:
better like this (because takes the same space, but makes option easily accessible, detectable and independent from Xray)
The X-ray button toggles select through: Yes/No, if the button is blue, select through is on. The icon itself could change to reflect the selection mode with facedots,etc. (but this is a fairly minor thing).
The dropdown should show: Facedot selection and "4. Selection shading/ active display mode".
However, in other packages, selection mode (Window/Crossing) has a distinct button to set the Window/ Crossing mode, such a button could live alongside the other selection buttons, to the right of "intersect existing selection"
Perhaps the facedot selection toggle could also reside there instead, on the 'selection bar'
In principle, facedot selection should toggle the facedot overlay for apparent reasons and would disable the use of the facedot display overlay. However, facedot display could also work independently without the facedots aiding in selection (in mesh inspection mode), this requires toggling the overlay manually from the overlay dropdown.
Optionally
For clarity to differentiate between facedot overlay without facedot selection and facedot overlay with facedot selection, next to displaying an icon for selection mode, the facedot selection mode could affect the facedot overlay.
For instance, the facedots overlay could have opacity in the former and have no opacity in the latter. Other alternatives are: changing the facedot icon in the viewport (solid/hollow dot) and/or resizing the facedot. This fixes select through with area selection in X-ray display mode without overcomplicating (UI) development regarding how this or that mode could be avoided. Display modes should work regardless of selection method and overlays are just overlays, right?
B.2) The option's behavior must satisfy the following conditions:
| |Display mode |faces selection type |selection mode |default overlays| option| Result|
|1 |xray/wire |facedot |through | any| off| Xray/wire with facedots selection
|2 |xray/wire |area |through |any| on|Xray/wire with area selection and no facedots
|3 |solid |area |occlude |facedots off| off| Solid with occluded area selection and no facedots
|4 |solid |area |occlude | facedots on| off| Solid with occluded area selection and facedots display
|5 |solid |area |through |any| on| Solid with through area selection and no facedots
I think my proposal satisfies all of these now.
Additional / Questionable / Offtop:
X.1) Ability to select visible with backface culling in shaded mode to satisfy selecting visible condition. An example of use is interior basemesh modeling.
Am I correct to state that this requires a "do not display backfaces" button?
X.4) Types of selection (CP - crossing - selecting everything that is crossed with selection border / WP - window - everything that is completely included in the border)
and directional selection (border from right to left is CP, and from left to right is WP)
This one should be in the preferences; here you need to allow for the Hybrid Window/Crossing mode, to avoid confusion. I think that, just like in other packages, it makes more sense to just toggle between Window/Crossing in the interface, unless the Hybrid mode is checked in the preferences, which may remove the button from the interface if checked. The hybrid mode is enabled for a valid user reason in that case.
In #73479#996345, @pixtur wrote: @1D_Inc To move the discussion forward I would like to visualize the different design proposals. But I have a difficult time to understand the UI-implications of the different options.
Can you help me to roll out these proposals as UI components? I'm using this Figma document:
Will try my best.
The problem of this proposal is that it is have too many options spread around Blender, and it is dedicated only to facedots (it is not solving select through problem).
There will be a lot of issues - for example, it will allow to display facedots in Xray mode, but with no selection by facedots, which will be inconsistent, because of no ability to select backface geometry with picking types of selection, which will lead to uncertainty of the mode from its visual appearance.
If to add possible select through solution to this proposal, the complexity of the resulting system will be too high for comfortable work, because it will assume lots of tweaking of lots of options stored in different places.
This is a wrong assumption, how often does one change these settings? You either change the shading mode altogether without affecting selection, or you change selection display, which is more of a preference that remains most likely untouched. Similarly, facedot selection (those who use this probably won't touch area selection all that much and vice versa), circumstantial Window/Crossing (again, no issue in Max, just tick a button) and select trough are all single toggles. Since there are four interrelated topics contained in one request, it does not mean that all of these have one consistent logical placing in the menus as they have different functionality. From this follows it would be illogical to everyone — apart from those who have read through this design task and other forum threads. Selection options should be in a selection grouping, display overlays in display overlays, etc. This makes for a clear mental map of the interface. And again, you probably won't tweak multiple of these settings if at all.
**Offtopic
What I like about agile development is it gives users the option to preview and use new functionality even though it has not yet fully chrystalised in terms of its interface. The interface may change eventually, that's okay, we atleast we have the functionality. Blender's development seems to be the reverse on many very, very simple and basic things. Instead of rolling out a simple toggle for enabling backface selection — even though the selection isn't snown in the viewport, industry proven, etc.... and an entirely different discussion — it seems as though every tiny thing should be conceived first, yet, you won't know how everything ends up if you don't try it out first as well. Is focussing on a clean interface first and foremost hampering development of missing functionality, definitely?
It is analogous to having to travel from A to B by bus and you have to be on B at a certain time, but then the busdriver is not showing, because he couldn't decide on whether to take the yellow or the blue bus.
Lots of users need this really basic functionality, yet all that happens is "Look at the interface", well, that certainly doesn't solve any modeling issues!
The adiditon of these small things is actually what would make Blender more industry ready imo.//
@1D_Inc I think this proposal is overcomplicating a quite simple request, allow me to explain: select through is simple, in terms of UI it could be as much as toggling it or have it mapped to a modifier key during selection. The issue at hand is that some people resist, because of the Limit Selection To Visible (LSTV) paradigm which is then used to bring up all sorts of display discussions, which in turn brings up facedot display and this brings up facedot selection vs area selection. So the entire thing is a cascading issue.
> In #73479#996005, @1D_Inc wrote:
> **The proposal is about**
> 1) The ability for box/lasso (non-picking) tools to select backface geometry on shaded model without backface display.
> 2) The ability for box/lasso (non-picking) tools to select faces in wireframe/Xray mode by their bounds (with no facedots display).
The overall proposal is actually about four things: display overlays (facedot), selection modes, select through and selection shading/display mode. Selection display mode is also a form of viewport overlay and is shown upon entering a selection command.
1) **Facedot display overlay**
- On
- Off
2) **Selection modes**
- Facedot selection (*requires 1A*)
- Window selection (everything fully within the selection window is selected = Area selection)
- Crossing selection (everything touched by the selection window is selected = Area selection)
- Hybrid selection (combination of Window selection and crossing selection, which is dependent on the mouse gesture direction = Area selection)
3) **Select backfacing/ Select occluded**
- Yes
- No
4) **Selection shading/ display mode in viewport**
- By active shading/ display mode, selection does not affect the display mode (i.e. no X-ray display when in solid shading)
- X-ray display
# Transparent selection highlight, which unlike 4A and 4B is applied after selection (front and backface selection are both highlighted, this requires any occluded geometry that is selected to display through the geometry in front)
> **Possible Xray solutions:**
>
> **A.1**) Split Xray alpha settings for object and edit modes, since alpha = 1 is suitable only for edit mode, and satisfies LSTV - Limit Selection To Visible - demands.
Object and edit mode could be set to behave similarly, so what I have mentioned here applies to both. You could have the same "Selection shading/ display mode in viewport" options for Edit and Object mode to make them behave independently, with the By active shading/ display mode as object mode default (which is the way it is currently and which is what is requested as desired method for select through apart from the facedot and window/crossing selection).
> **A.2**) Add the ability to fade with slider backfacing wiremesh display in Xray mode down to zero.
I would opt to put the "Selection shading/ display mode in viewport" options on buttons and hide the X-ray mode slider when the "By active shading/ display mode" is ticked.
The fact that LSTV is a paradigm in Blender, yet a proven method elsewhere, sounds to me like it's time for a paradigm change. With the options I presented above, LSTV can always be enabled anyways (and perhaps could remain so by default?), no big deal.
> Possible design:
> better like this (because takes the same space, but makes option easily accessible, detectable and independent from Xray)
>
> 
The X-ray button toggles select through: Yes/No, if the button is blue, select through is on. The icon itself could change to reflect the selection mode with facedots,etc. (but this is a fairly minor thing).
The dropdown should show: Facedot selection and "4. Selection shading/ active display mode".
However, in other packages, selection mode (Window/Crossing) has a distinct button to set the Window/ Crossing mode, such a button could live alongside the other selection buttons, to the right of "intersect existing selection"
Perhaps the facedot selection toggle could also reside there instead, on the 'selection bar'
In principle, facedot selection should toggle the facedot overlay for apparent reasons and would disable the use of the facedot display overlay. However, facedot display could also work independently without the facedots aiding in selection (in mesh inspection mode), this requires toggling the overlay manually from the overlay dropdown.
*Optionally*
For clarity to differentiate between facedot overlay without facedot selection and facedot overlay with facedot selection, next to displaying an icon for selection mode, the facedot selection mode could affect the facedot overlay.
For instance, the facedots overlay could have opacity in the former and have no opacity in the latter. Other alternatives are: changing the facedot icon in the viewport (solid/hollow dot) and/or resizing the facedot. This fixes select through with area selection in X-ray display mode without overcomplicating (UI) development regarding how this or that mode could be avoided. Display modes should work regardless of selection method and overlays are just overlays, right?
> **B.2**) The option's behavior must satisfy the following conditions:
>
> | |Display mode |faces selection type |selection mode |default overlays| option| Result|
> |1 |xray/wire |facedot |through | any| off| Xray/wire with facedots selection
> |2 |xray/wire |area |through |any| on|Xray/wire with area selection and no facedots
> |3 |solid |area |occlude |facedots off| off| Solid with occluded area selection and no facedots
> |4 |solid |area |occlude | facedots on| off| Solid with occluded area selection and facedots display
> |5 |solid |area |through |any| on| Solid with through area selection and no facedots
I think my proposal satisfies all of these now.
> Additional / Questionable / Offtop:
>
> X.1) Ability to select visible with backface culling in shaded mode to satisfy selecting visible condition. An example of use is interior basemesh modeling.
Am I correct to state that this requires a "do not display backfaces" button?
> X.4) Types of selection (CP - crossing - selecting everything that is crossed with selection border / WP - window - everything that is completely included in the border)
> and directional selection (border from right to left is CP, and from left to right is WP)
This one should be in the preferences; here you need to allow for the Hybrid Window/Crossing mode, to avoid confusion. I think that, just like in other packages, it makes more sense to just toggle between Window/Crossing in the interface, unless the Hybrid mode is checked in the preferences, which may remove the button from the interface if checked. The hybrid mode is enabled for a valid user reason in that case.
> In #73479#996441, @1D_Inc wrote:
>> In #73479#996345, @pixtur wrote:
>> @1D_Inc To move the discussion forward I would like to visualize the different design proposals. But I have a difficult time to understand the UI-implications of the different options.
>> Can you help me to roll out these proposals as UI components? I'm using [this Figma document](https://www.figma.com/file/bseq6jLsv7njvo0mNGvYP2/X-Ray-Designs?node-id=6%3A148):
> Will try my best.
> The problem of this proposal is that it is have too many options spread around Blender, and it is dedicated only to facedots (it is not solving select through problem).
> There will be a lot of issues - for example, it will allow to display facedots in Xray mode, but with no selection by facedots, which will be inconsistent, because of no ability to select backface geometry with picking types of selection, which will lead to uncertainty of the mode from its visual appearance.
> If to add possible select through solution to this proposal, the complexity of the resulting system will be too high for comfortable work, because it will assume lots of tweaking of lots of options stored in different places.
This is a wrong assumption, how often does one change these settings? You either change the shading mode altogether without affecting selection, or you change selection display, which is more of a preference that remains most likely untouched. Similarly, facedot selection (those who use this probably won't touch area selection all that much and vice versa), circumstantial Window/Crossing (again, no issue in Max, just tick a button) and select trough are all single toggles. Since there are four interrelated topics contained in one request, it does not mean that all of these have one consistent logical placing in the menus as they have different functionality. From this follows it would be illogical to everyone — apart from those who have read through this design task and other forum threads. Selection options should be in a selection grouping, display overlays in display overlays, etc. This makes for a clear mental map of the interface. And again, you probably won't tweak multiple of these settings if at all.
**Offtopic
What I like about agile development is it gives users the option to preview and use new functionality even though it has not yet fully chrystalised in terms of its interface. The interface may change eventually, that's okay, we atleast we have the functionality. Blender's development seems to be the reverse on many very, very simple and basic things. Instead of rolling out a simple toggle for enabling backface selection — even though the selection isn't snown in the viewport, industry proven, etc.... and an entirely different discussion — it seems as though every tiny thing should be conceived first, yet, you won't know how everything ends up if you don't try it out first as well. Is focussing on a clean interface first and foremost hampering development of missing functionality, definitely?
It is analogous to having to travel from A to B by bus and you have to be on B at a certain time, but then the busdriver is not showing, because he couldn't decide on whether to take the yellow or the blue bus.
Lots of users need this really basic functionality, yet all that happens is "Look at the interface", well, that certainly doesn't solve any modeling issues!
The adiditon of these small things is actually what would make Blender more industry ready imo.//
Here is a workflow issue - if facedots selection is controlled separately from shading mode, there is need to constantly switch both shading mode and facedot display/selection mode every single time, which lead to serious slowdown.
Shading-sensitive facedots behaviour based workflow is faster, this is critical for messy meshes editing and fixing.
This is balanced Blender mechanics which is commonly used to outperform Max and Maya workflow speed limitations.
4A. By active shading/ display mode, selection does not affect the display mode
4B X-ray display
4C Transparent selection highlight, which unlike 4A and 4B is applied after selection
I am not sure what is the goal of this type of behaviour. Selection doesn't affect any display mode, modes are affecting selection.
Is it about displaying the selected geometry, when unselected geometry covers selected?
I think my proposal satisfies all of these now.
It doesn't work like that. There is not only goal to satisfy some conditions, but, actually, exclude all unnecessary.
You can try to make the complete map of your proposal with all possible proposed options states (permutations) to be sure that your design is clean at the same level, and all modes are easy to reach at the same rate.
The X-ray button toggles select through: Yes/No, if the button is blue, select through is on. The icon itself could change to reflect the selection mode with facedots,etc. (but this is a fairly minor thing).
The dropdown should show: Facedot selection and "4. Selection shading/ active display mode".
X-ray button toggles Xray mode, it is different from select through.
Mode certainty - the ability to read current mode from visual appearance - is a major thing in terms of usability. This cancels dropdowns and hidden settings for the most relevant functions.
The fact that LSTV is a paradigm in Blender, yet a proven method elsewhere, sounds to me like it's time for a paradigm change.
Workflow demands is the only reason for any kind of paradigm change.
a distinct button to set the Window/ Crossing mode, such a button could live alongside the other selection buttons, to the right of "intersect existing selection"
This button cannot be placed here, because it is common behaviour setting, it can be placed in Preferences.
X.1) Ability to select visible with backface culling in shaded mode to satisfy selecting visible condition. An example of use is interior basemesh modeling.
Am I correct to state that this requires a "do not display backfaces" button?
It is about the ability to select visible geometry which is visible through backface culling (when is turned on) and all faces normals are flipped inside (interior modeling case).
> In #73479#996771, @Hologram wrote:
> 1) **Facedot display overlay**
> # On
> # Off
>
> 2) **Selection modes**
> # Facedot selection (*requires 1A*)
> # Area selection
Here is a workflow issue - if facedots selection is controlled separately from shading mode, there is need to constantly switch both shading mode and facedot display/selection mode every single time, which lead to serious slowdown.
Shading-sensitive facedots behaviour based workflow is faster, this is critical for messy meshes editing and fixing.
This is balanced Blender mechanics which is commonly used to outperform Max and Maya workflow speed limitations.
> 4A. By active shading/ display mode, selection does not affect the display mode
> 4B X-ray display
> 4C Transparent selection highlight, which unlike 4A and 4B is applied after selection
I am not sure what is the goal of this type of behaviour. Selection doesn't affect any display mode, modes are affecting selection.
Is it about displaying the selected geometry, when unselected geometry covers selected?
> I think my proposal satisfies all of these now.
It doesn't work like that. There is not only goal to satisfy some conditions, but, actually, exclude all unnecessary.
You can try to make the complete map of your proposal with **all possible proposed options states** (permutations) to be sure that your design is clean at the same level, and all modes are easy to reach at the same rate.
> The X-ray button toggles select through: Yes/No, if the button is blue, select through is on. The icon itself could change to reflect the selection mode with facedots,etc. (but this is a fairly minor thing).
> The dropdown should show: Facedot selection and "4. Selection shading/ active display mode".
X-ray button toggles Xray mode, it is different from select through.
Mode certainty - the ability to read current mode from visual appearance - is a major thing in terms of usability. This cancels dropdowns and hidden settings for the most relevant functions.
> The fact that LSTV is a paradigm in Blender, yet a proven method elsewhere, sounds to me like it's time for a paradigm change.
Workflow demands is the only reason for any kind of paradigm change.
> a distinct button to set the Window/ Crossing mode, such a button could live alongside the other selection buttons, to the right of "intersect existing selection"
This button cannot be placed here, because it is common behaviour setting, it can be placed in Preferences.
>> X.1) Ability to select visible with backface culling in shaded mode to satisfy selecting visible condition. An example of use is interior basemesh modeling.
> Am I correct to state that this requires a "do not display backfaces" button?
It is about the ability to select visible geometry which is visible through backface culling (when is turned on) and all faces normals are flipped inside (interior modeling case).
Here is a workflow issue - if facedots selection is controlled separately from shading mode, there is need to constantly switch both shading mode and facedot display/selection mode every single time, which lead to serious slowdown.
I guess I forget to mention that toggling the facedot selection mode would additionally enable the facedot display mode. So it is a single button to control, whereas the facedot display overlay CAN be toggled seperately.
4A. By active shading/ display mode, selection does not affect the display mode
4B X-ray display
4C Transparent selection highlight, which unlike 4A and 4B is applied after selection
I am not sure what is the goal of this type of behaviour. Selection doesn't affect any display mode, modes are affecting selection.
Sure, in principle selection shouldn't affect display mode, unless you want to select through. In that case, (regardless of how select through was enabled) to satisfy LSTV, the selection command would automatically display the active object(s) in edit mode either in X-ray (4B, like Cirno's Box select https://blenderartists.org/t/box-select-x-ray/1212316/23?u=justo) or by highlighting the occluced selection through the mesh (4C). However, if LSTV is dropped, then no changes to the display mode would have to occur (4A).
Is it about displaying the selected geometry, when unselected geometry covers selected?
That is indeed the case for 4C.
I think my proposal satisfies all of these now.
It doesn't work like that. There is not only goal to satisfy some conditions, but, actually, exclude all unnecessary.
You can try to make the complete map of your proposal with all possible proposed options states (permutations) to be sure that your design is clean at the same level, and all modes are easy to reach at the same rate.
The X-ray button toggles select through: Yes/No, if the button is blue, select through is on. The icon itself could change to reflect the selection mode with facedots,etc. (but this is a fairly minor thing).
The dropdown should show: Facedot selection and "4. Selection shading/ active display mode".
X-ray button toggles Xray mode, it is different from select through.
Excuse me, when I referred to the X-ray button, I meant the select through button.... That's confusing indeed.
Mode certainty - the ability to read current mode from visual appearance - is a major thing in terms of usability. This cancels dropdowns and hidden settings for the most relevant functions.
That's the idea behind using the Select through button with a blue indication of it being on and icon changes upon facedot selection.
The fact that LSTV is a paradigm in Blender, yet a proven method elsewhere, sounds to me like it's time for a paradigm change.
Workflow demands is the only reason for any kind of paradigm change.
a distinct button to set the Window/ Crossing mode, such a button could live alongside the other selection buttons, to the right of "intersect existing selection"
This button cannot be placed here, because it is common behaviour setting, it can be placed in Preferences.
Wouldn't it make more sense to (also) include it in the "selection bar"? I find myself changing the mode every now and then in other programs, having to do so in the preferences is a bit of a hassle imo.
You could put the default behavior in the preferences and override it with the button in the selection bar, for instance.
You can try to make the complete map of your proposal with all possible proposed options states (permutations) to be sure that your design is clean at the same level, and all modes are easy to reach at the same rate.
I can have a look at this later, in case anyone has any objections with my proposal please let me know so I can incorporate that in advance.
> In #73479#997115, @1D_Inc wrote:
>> In #73479#996771, @Hologram wrote:
>
>> 1) **Facedot display overlay**
>> # On
>> # Off
>>
>> 2) **Selection modes**
>> # Facedot selection (*requires 1A*)
>> # Area selection
>
> Here is a workflow issue - if facedots selection is controlled separately from shading mode, there is need to constantly switch both shading mode and facedot display/selection mode every single time, which lead to serious slowdown.
I guess I forget to mention that toggling the facedot selection mode would additionally enable the facedot display mode. So it is a single button to control, whereas the facedot display overlay CAN be toggled seperately.
>> 4A. By active shading/ display mode, selection does not affect the display mode
>> 4B X-ray display
>> 4C Transparent selection highlight, which unlike 4A and 4B is applied after selection
>
> I am not sure what is the goal of this type of behaviour. Selection doesn't affect any display mode, modes are affecting selection.
Sure, in principle selection shouldn't affect display mode, unless you want to select through. In that case, (regardless of how select through was enabled) to satisfy LSTV, the selection command would automatically display the active object(s) in edit mode either in X-ray (4B, like Cirno's Box select https://blenderartists.org/t/box-select-x-ray/1212316/23?u=justo) or by highlighting the occluced selection through the mesh (4C). However, if LSTV is dropped, then no changes to the display mode would have to occur (4A).
> Is it about displaying the selected geometry, when unselected geometry covers selected?
That is indeed the case for 4C.
>> I think my proposal satisfies all of these now.
> It doesn't work like that. There is not only goal to satisfy some conditions, but, actually, exclude all unnecessary.
> You can try to make the complete map of your proposal with **all possible proposed options states** (permutations) to be sure that your design is clean at the same level, and all modes are easy to reach at the same rate.
>
>> The X-ray button toggles select through: Yes/No, if the button is blue, select through is on. The icon itself could change to reflect the selection mode with facedots,etc. (but this is a fairly minor thing).
>> The dropdown should show: Facedot selection and "4. Selection shading/ active display mode".
> X-ray button toggles Xray mode, it is different from select through.
Excuse me, when I referred to the X-ray button, I meant the select through button.... That's confusing indeed.
> Mode certainty - the ability to read current mode from visual appearance - is a major thing in terms of usability. This cancels dropdowns and hidden settings for the most relevant functions.
That's the idea behind using the Select through button with a blue indication of it being on and icon changes upon facedot selection.
>> The fact that LSTV is a paradigm in Blender, yet a proven method elsewhere, sounds to me like it's time for a paradigm change.
> Workflow demands is the only reason for any kind of paradigm change.
>
>> a distinct button to set the Window/ Crossing mode, such a button could live alongside the other selection buttons, to the right of "intersect existing selection"
> This button cannot be placed here, because it is common behaviour setting, it can be placed in Preferences.
Wouldn't it make more sense to (also) include it in the "selection bar"? I find myself changing the mode every now and then in other programs, having to do so in the preferences is a bit of a hassle imo.
You could put the default behavior in the preferences and override it with the button in the selection bar, for instance.
> You can try to make the complete map of your proposal with all possible proposed options states (permutations) to be sure that your design is clean at the same level, and all modes are easy to reach at the same rate.
I can have a look at this later, in case anyone has any objections with my proposal please let me know so I can incorporate that in advance.
Mode certainty - the ability to read current mode from visual appearance - is a major thing in terms of usability. This cancels dropdowns and hidden settings for the most relevant functions.
That's the idea behind using the Select through button with a blue indication of it being on and icon changes upon facedot selection.
So it is a single button to control, whereas the facedot display overlay CAN be toggled seperately.
Trying to analyze a propozal.
So, there will be a
toogle to control facedots display/selection between automatic (current) and manual split to
display facedots toggle, including
separate display facedots control in xray and
selection by facedots in xray toggle with
limiting selection to facedots
At least 5 interconnected toggles for facedots? Object mode facedots display? That looks like very over complicated system, close to inconsistent feature set..
We perform a fairly wide range of workflows and it's hard to imagine a workflow that would require so many possible combinations.
Is it about displaying the selected geometry, when unselected geometry covers selected?
That is indeed the case for 4C.
That was design flaw, it was reported and confirmed (https://developer.blender.org/T78482)
I think fixing this would remove the need for the entire Selection shading/ display mode in viewport option.
a distinct button to set the Window/ Crossing mode.
This button cannot be placed here, because it is common behaviour setting, it can be placed in Preferences.
Wouldn't it make more sense to (also) include it in the "selection bar"?
Placing in selection bar was discussed some time ago, it is not available for quick types of selection (B hotkey).
Also, directional selection type (left - CP, right - WP) solves the need for such kind of button for many apps, eliminating the need for frequent switching.
In 3ds Max I find myself changing the mode every now and then, having to do so in the preferences is a bit of a hassle imo.
You could put the default behavior in the preferences and override it with the button in the selection bar, for instance.
Excuse me, when I referred to the X-ray button, I meant the select through button.... That's confusing indeed.
I can have a look at this later, in case anyone has any objections with my proposal please let me know so I can incorporate that in advance.
The complete UI mockup (including both facedots and select through solutions) is nice point to start from. At the moment it is hard to imagine how this proposal should look and work.
> In #73479#996633, @pixtur wrote:
> Just to clarify: The title for this icon would be something like...
> - "Select faces only at dots"
> To be honest I personally would disable this option and can't see any use case to switch it on again.
Can you, please, clarify what it refers to from all this tread?
_______________________________
> In #73479#997179, @Hologram wrote:
>> Mode certainty - the ability to read current mode from visual appearance - is a major thing in terms of usability. This cancels dropdowns and hidden settings for the most relevant functions.
> That's the idea behind using the Select through button with a blue indication of it being on and icon changes upon facedot selection.
Yes, but I didn't found any of them in the figma document (https://www.figma.com/file/bseq6jLsv7njvo0mNGvYP2/X-Ray-Designs?node-id=6%3A148).
Is this document related to you?
> So it is a single button to control, whereas the facedot display overlay CAN be toggled seperately.
Trying to analyze a propozal.
So, there will be a
1) toogle to control facedots display/selection between automatic (current) and manual split to
2) display facedots toggle, including
3) separate display facedots control in xray and
4) selection by facedots in xray toggle with
5) limiting selection to facedots
At least 5 interconnected toggles for facedots? Object mode facedots display? That looks like very over complicated system, close to inconsistent feature set..
We perform a fairly wide range of workflows and it's hard to imagine a workflow that would require so many possible combinations.
>> Is it about displaying the selected geometry, when unselected geometry covers selected?
> That is indeed the case for 4C.
That was design flaw, it was reported and confirmed (https://developer.blender.org/T78482)
I think fixing this would remove the need for the entire Selection shading/ display mode in viewport option.
>>> a distinct button to set the Window/ Crossing mode.
>> This button cannot be placed here, because it is common behaviour setting, it can be placed in Preferences.
> Wouldn't it make more sense to (also) include it in the "selection bar"?
Placing in selection bar was discussed some time ago, it is not available for quick types of selection (B hotkey).
Also, directional selection type (left - CP, right - WP) solves the need for such kind of button for many apps, eliminating the need for frequent switching.
> In 3ds Max I find myself changing the mode every now and then, having to do so in the preferences is a bit of a hassle imo.
> You could put the default behavior in the preferences and override it with the button in the selection bar, for instance.
Please keep in mind avoiding mentioning proprietary software.
https://lists.blender.org/pipermail/bf-committers/2020-July/050616.html
> Excuse me, when I referred to the X-ray button, I meant the select through button.... That's confusing indeed.
> I can have a look at this later, in case anyone has any objections with my proposal please let me know so I can incorporate that in advance.
The complete UI mockup (including both facedots and select through solutions) is nice point to start from. At the moment it is hard to imagine how this proposal should look and work.
Mode certainty - the ability to read current mode from visual appearance - is a major thing in terms of usability. This cancels dropdowns and hidden settings for the most relevant functions.
That's the idea behind using the Select through button with a blue indication of it being on and icon changes upon facedot selection.
It is another user's interpretation of my proposal, but does not cover it entirely.
So it is a single button to control, whereas the facedot display overlay CAN be toggled seperately.
Trying to analyze a propozal.
So, there will be a
toggle to control facedots display/selection between automatic (current) and manual split to
display facedots toggle, including
separate display facedots in xray and
selection by facedots in xray toggle
limiting selection to facedots
At least 5 interconnected toggles for facedots? Object mode facedots display? That looks like very over complicated system or or inconsistent feature set.
There will be:
Facedot overlay
Facedot selection/ area selection
These buttons will be at the same location regardless of shading mode.
Is it about displaying the selected geometry, when unselected geometry covers selected?
That is indeed the case for 4C.
That was design flaw, it was reported and confirmed (https://developer.blender.org/T78482)
I think fixing this would remove the need for the entire Selection shading/ display mode in viewport option.
Indeed, this would solve the display proposals of my end, great!
Also, side-dependent selection (left - CP, right - WP) solves the need for such kind of button for many apps.
In case this mode is set in the preferences, there is no need for a select Window/ Crossing button, however, when set to either Window or Crossing, there is. In that case it has to be readily available with a single click, rather than an option in the preferences.
a distinct button to set the Window/ Crossing mode.
This button cannot be placed here, because it is common behaviour setting, it can be placed in Preferences.
Wouldn't it make more sense to (also) include it in the "selection bar"?
Placing in selection bar was discussed some time ago, it is not available for quick types of selection (B hotkey).
Anyways, if Box select itself is the exception in being a transparent command with no options of its own, would showing the selection options either in the toolbar like any other selection mode be an issue? A counter argument is that it may be considered as "flashing", because the UI changes a bit during selection (from command UI to selection UI and back to command UI), in that case, the there could be a box select options button in the selection bar, which is only a single button change. I would rather change the exception to the rule (boxselection) than the rule (most efficient button placement for quick access in the selection bar instead of preferences) to the exception.
Actually, while you cannot click on the toolbar with box selection active, if you could, there already is a place in the interface that would allow for consistent select window/crossing option:
Here's the option tree:
I'll make a sketch UI mock-up when I've got some more time, should be done by tomorrow.
PS. removed names of proprietary software in my posts.
> In #73479#998663, @1D_Inc wrote:
>>> Mode certainty - the ability to read current mode from visual appearance - is a major thing in terms of usability. This cancels dropdowns and hidden settings for the most relevant functions.
>> That's the idea behind using the Select through button with a blue indication of it being on and icon changes upon facedot selection.
> Yes, but I didn't found any of them in the figma document (https://www.figma.com/file/bseq6jLsv7njvo0mNGvYP2/X-Ray-Designs?node-id=6%3A148).
> Is this document related to you?
It is another user's interpretation of my proposal, but does not cover it entirely.
>
>> So it is a single button to control, whereas the facedot display overlay CAN be toggled seperately.
> Trying to analyze a propozal.
> So, there will be a
> 1) toggle to control facedots display/selection between automatic (current) and manual split to
> 2) display facedots toggle, including
> 3) separate display facedots in xray and
> 4) selection by facedots in xray toggle
> 5) limiting selection to facedots
>
> At least 5 interconnected toggles for facedots? Object mode facedots display? That looks like very over complicated system or or inconsistent feature set.
There will be:
1) Facedot overlay
2) Facedot selection/ area selection
These buttons will be at the same location regardless of shading mode.
>>> Is it about displaying the selected geometry, when unselected geometry covers selected?
>> That is indeed the case for 4C.
>
> That was design flaw, it was reported and confirmed (https://developer.blender.org/T78482)
> I think fixing this would remove the need for the entire Selection shading/ display mode in viewport option.
Indeed, this would solve the display proposals of my end, great!
> Also, side-dependent selection (left - CP, right - WP) solves the need for such kind of button for many apps.
In case this mode is set in the preferences, there is no need for a select Window/ Crossing button, however, when set to either Window or Crossing, there is. In that case it has to be readily available with a single click, rather than an option in the preferences.
>>>> a distinct button to set the Window/ Crossing mode.
>>> This button cannot be placed here, because it is common behaviour setting, it can be placed in Preferences.
>> Wouldn't it make more sense to (also) include it in the "selection bar"?
> Placing in selection bar was discussed some time ago, it is not available for quick types of selection (B hotkey).
Anyways, if Box select itself is the exception in being a transparent command with no options of its own, would showing the selection options either in the toolbar like any other selection mode be an issue? A counter argument is that it may be considered as "flashing", because the UI changes a bit during selection (from command UI to selection UI and back to command UI), in that case, the there could be a box select options button in the selection bar, which is only a single button change. I would rather change the exception to the rule (boxselection) than the rule (most efficient button placement for quick access in the selection bar instead of preferences) to the exception.
Actually, while you cannot click on the toolbar with box selection active, if you could, there already is a place in the interface that would allow for consistent select window/crossing option:
Here's the option tree:
I'll make a sketch UI mock-up when I've got some more time, should be done by tomorrow.
PS. removed names of proprietary software in my posts.
In #73479#998832, @Hologram wrote:
I'll make a sketch UI mock-up when I've got some more time, should be done by tomorrow.
Okay. There is no hurry, take your time.
> In #73479#998832, @Hologram wrote:
> I'll make a sketch UI mock-up when I've got some more time, should be done by tomorrow.
Okay. There is no hurry, take your time.
Here are the mockups, the only setting that should be in preferences is whether someone wants to have Window/Crossing based on direction or based on the toggle in the selection bar.
The issue for box mode selection would be solved by allowing to click on the settings bar, in which there is already a button in the current UI to change selection for commands that make use of selection:
A button for facedot display overlay:
I added an optional slider for selection highlight strength, I don't really know how useful this would be. It may help with large selections perhaps.
For the rest, refer to the option tree to see the modes:
Here are the mockups, the only setting that should be in preferences is whether someone wants to have Window/Crossing based on direction or based on the toggle in the selection bar.
The issue for box mode selection would be solved by allowing to click on the settings bar, in which there is already a button in the current UI to change selection for commands that make use of selection:
A button for facedot display overlay:
I added an optional slider for selection highlight strength, I don't really know how useful this would be. It may help with large selections perhaps.
For the rest, refer to the option tree to see the modes:
> 
First of all, I think you should change "select backfacing/frontfacing" to "select visible/select through" in your proposal to avoid confusion. Backfacing/frontfacing refers to the normal direction of a face in relation to the camera and this terminology is already used for specific things like "Backface Culling". This task is about selecting occluded geometry in solid shading, irrespective of its normal direction. There is also a separate issue with backface selection that needs to be fixed, so it's important not to mix up these terms.
I like the idea to change the appearance of the button to show that facedot selection is enabled, it helps to save a bit of space.
But facedot display controls in the Overlays menu should look like in @lcas build:
There needs to be an ability to control facedot overlay separately for solid shading and xray/wireframe to replicate current behaviour. Same for 'Select Facedots' toggle in your proposal.
But overall I think it's a solid design that covers pretty much all of the useful features.
First of all, I think you should change "select backfacing/frontfacing" to "select visible/select through" in your proposal to avoid confusion. Backfacing/frontfacing refers to the normal direction of a face in relation to the camera and this terminology is already used for specific things like "Backface Culling". This task is about selecting occluded geometry in solid shading, irrespective of its normal direction. There is also a separate issue with backface selection that needs to be fixed, so it's important not to mix up these terms.
I like the idea to change the appearance of the button to show that facedot selection is enabled, it helps to save a bit of space.
But facedot display controls in the Overlays menu should look like in @lcas build:
There needs to be an ability to control facedot overlay separately for solid shading and xray/wireframe to replicate current behaviour. Same for 'Select Facedots' toggle in your proposal.
But overall I think it's a solid design that covers pretty much all of the useful features.
In #73479#999726, @slowburn wrote:
First of all, I think you should change "select backfacing/frontfacing" to "select visible/select through" in your proposal to avoid confusion. Backfacing/frontfacing refers to the normal direction of a face in relation to the camera and this terminology is already used for specific things like "Backface Culling". This task is about selecting occluded geometry in solid shading, irrespective of its normal direction. There is also a separate issue with backface selection that needs to be fixed, so it's important not to mix up these terms.
Sure thing, I fully agree with you on this, I have used the terms interchangeably, because of habit (ignore backfacing is what this is called in the software I use), but Select visible/ Select through makes more sense.
There needs to be an ability to control facedot overlay separately for solid shading and xray/wireframe to replicate current behaviour. Same for 'Select Facedots' toggle in your proposal.
So the button for select facedots would then be:
Select Facedots (header)
X-ray | Solid (two buttons)
E: This means changing display mode switches selection mode (as well as the icon and facedot display overlay) depending on the settings. Fair enough.
> In #73479#999726, @slowburn wrote:
> First of all, I think you should change "select backfacing/frontfacing" to "select visible/select through" in your proposal to avoid confusion. Backfacing/frontfacing refers to the normal direction of a face in relation to the camera and this terminology is already used for specific things like "Backface Culling". This task is about selecting occluded geometry in solid shading, irrespective of its normal direction. There is also a separate issue with backface selection that needs to be fixed, so it's important not to mix up these terms.
Sure thing, I fully agree with you on this, I have used the terms interchangeably, because of habit (ignore backfacing is what this is called in the software I use), but Select visible/ Select through makes more sense.
> There needs to be an ability to control facedot overlay separately for solid shading and xray/wireframe to replicate current behaviour. Same for 'Select Facedots' toggle in your proposal.
So the button for select facedots would then be:
Select Facedots (header)
X-ray | Solid (two buttons)
E: This means changing display mode switches selection mode (as well as the icon and facedot display overlay) depending on the settings. Fair enough.
Interesting double-binary solution.
The proposal is much more clear now.
I think replicating current behavior can be achieved by making this option dependent from xray (like xray is dependent from wireframe - when wireframe turns on it turns on xray, remembering its setting)
This way system will turn to triple-binary but replicating current behavior can be achieved with proper defaults, because I have a feeling that adding special option instead of it will cancel out the entire system, making its behavior unclear.
I need to build relevancy map from this proposal to figure it out and form a question list.
Interesting double-binary solution.
The proposal is much more clear now.
I think replicating current behavior can be achieved by making this option dependent from xray (like xray is dependent from wireframe - when wireframe turns on it turns on xray, remembering its setting)
This way system will turn to triple-binary but replicating current behavior can be achieved with proper defaults, because I have a feeling that adding special option instead of it will cancel out the entire system, making its behavior unclear.
I need to build relevancy map from this proposal to figure it out and form a question list.
I don't want to make the proposal any more complicated than it already is — and it may be partially off-topic — but a though passed my mind about also adding a button with "Enumerate" next to the proposed select through button in the header ("selection bar").
The idea here is that in CAD programs, there is always an option to turn on select from a list in case multiple objects reside under the cursor upon clicking. It is also a form of selecting through (albeit in object mode) and I think that it makes sense to add this functionality to all the selection tools when used to click, rather than dragging a window/lasso/circle. That's what the enumerate button toggles for the tweak tool out of the box.
The "enumerate" button should initiate this functionality upon single click selection in case there are multiple objects behind the cursor:
The button itself should look like a list icon, pretty self explanatory imo.
I don't want to make the proposal any more complicated than it already is — and it may be partially off-topic — but a though passed my mind about also adding a button with "Enumerate" next to the proposed select through button in the header ("selection bar").
The idea here is that in CAD programs, there is always an option to turn on select from a list in case multiple objects reside under the cursor upon clicking. It is also a form of selecting through (albeit in object mode) and I think that it makes sense to add this functionality to all the selection tools when used to click, rather than dragging a window/lasso/circle. That's what the enumerate button toggles for the tweak tool out of the box.
The "enumerate" button should initiate this functionality upon single click selection in case there are multiple objects behind the cursor:
The button itself should look like a list icon, pretty self explanatory imo.
In #73479#1002667, @Hologram wrote:
I don't want to make the proposal any more complicated than it already is
Sorry, but I am in the middle of the deadline, can't even start to work with it.
The "enumerate" button should initiate this functionality upon single click selection in case there are multiple objects behind the cursor:
Even automerge button, that indicates if your mesh be collapsed on the next move, was removed, so you have to guess this all the time.
This button is not used widely enough to fit there.
> In #73479#1002667, @Hologram wrote:
> I don't want to make the proposal any more complicated than it already is
Sorry, but I am in the middle of the deadline, can't even start to work with it.
> The "enumerate" button should initiate this functionality upon single click selection in case there are multiple objects behind the cursor:
> 
Even automerge button, that indicates if your mesh be collapsed on the next move, was removed, so you have to guess this all the time.
This button is not used widely enough to fit there.
The "enumerate" button should initiate this functionality upon single click selection in case there are multiple objects behind the cursor
You can call up the enumerate menu by alt-clicking on overlapping objects, so what's the point to have a button for that in the UI?
>The "enumerate" button should initiate this functionality upon single click selection in case there are multiple objects behind the cursor
You can call up the enumerate menu by alt-clicking on overlapping objects, so what's the point to have a button for that in the UI?
In #73479#1003693, @slowburn wrote:
You can call up the enumerate menu by alt-clicking on overlapping objects, so what's the point to have a button for that in the UI?
I am aware of that, it is just a matter of exposing obscured functionality in a way that may be consistent in the UI. However, currently the enumerate menu only shows in the tweak tool and not with a brief click in any other selection tool. Blender should default to the tweak tool in any brief click, or emulate that behavior with the enumerate menu whether hotkeyed or in the UI, but that's a different topic perhaps. I thought I might bring it up since it is sort of related, atleast for people with a CAD background.
> In #73479#1003693, @slowburn wrote:
> You can call up the enumerate menu by alt-clicking on overlapping objects, so what's the point to have a button for that in the UI?
I am aware of that, it is just a matter of exposing obscured functionality in a way that may be consistent in the UI. However, currently the enumerate menu only shows in the tweak tool and not with a brief click in any other selection tool. Blender should default to the tweak tool in any brief click, or emulate that behavior with the enumerate menu whether hotkeyed or in the UI, but that's a different topic perhaps. I thought I might bring it up since it is sort of related, atleast for people with a CAD background.
Well, I am an architect with deep CAD background (AuroCAD user and AutoLISP developer with more than 1000 lisps written), and I am familiar with this functionality, but it is way more suitable for 2D rather than 3D, because 3D usually is more complex to navigate.
In practice we work with too much overloaded models to use that kind of selection, because it makes too long lists for comfortable work.
We use QCD slots system for navigating complex 3D structures (demo in the end) https://youtu.be/yiti0xWO7Wg
Abscence of alt+clicks for non-tweak tools looks like an issue though.
Maybe, they was not mapped yet?
Well, I am an architect with deep CAD background (AuroCAD user and AutoLISP developer with more than 1000 lisps written), and I am familiar with this functionality, but it is way more suitable for 2D rather than 3D, because 3D usually is more complex to navigate.
In practice we work with too much overloaded models to use that kind of selection, because it makes too long lists for comfortable work.
We use QCD slots system for navigating complex 3D structures (demo in the end)
https://youtu.be/yiti0xWO7Wg
Abscence of alt+clicks for non-tweak tools looks like an issue though.
Maybe, they was not mapped yet?
Trying to analyze propozal. What is the difference between those two options?
The issue for box mode selection would be solved by allowing to click on the settings bar, in which there is already a button in the current UI to change selection for commands that make use of selection:
What is that issue? It would be nice to be described or mentioned.
> In #73479#999322, @Hologram wrote:
> A button for facedot display overlay:
> 
Trying to analyze propozal. What is the difference between those two options?
> The issue for box mode selection would be solved by allowing to click on the settings bar, in which there is already a button in the current UI to change selection for commands that make use of selection:
> 
What is that issue? It would be nice to be described or mentioned.
Trying to analyze propozal. What is the difference between those two options?
They are the same, I didn't know this was there by default, scrap mine. I'm still fairly new to blender, so that's just a silly mistake on my part.
The issue for box mode selection would be solved by allowing to click on the settings bar, in which there is already a button in the current UI to change selection for commands that make use of selection:
What is that issue? It would be nice to be described or mentioned.
The issue is, when you are in box select mode (the temporary one with the large cursor) you are unable to change selection settings. This is because it is a transparent command that is executed while another command is active. With other selection commands, this selection menu is already under the exact same dropdown. So in order for the temporary selection tools to edit selection settings, allowing to use the option bar in the header would fix this. You can see for yourself, with box select active, you can only click in the viewport, but not on the header. And this option dropdown is in the interface and it would therefore make sense to also use it for box select.
> In #73479#1004992, @1D_Inc wrote:
>> In #73479#999322, @Hologram wrote:
>
>> A button for facedot display overlay:
>> 
>
> Trying to analyze propozal. What is the difference between those two options?
>
> 
They are the same, I didn't know this was there by default, scrap mine. I'm still fairly new to blender, so that's just a silly mistake on my part.
>> The issue for box mode selection would be solved by allowing to click on the settings bar, in which there is already a button in the current UI to change selection for commands that make use of selection:
>> 
> What is that issue? It would be nice to be described or mentioned.
The issue is, when you are in box select mode (the temporary one with the large cursor) you are unable to change selection settings. This is because it is a transparent command that is executed while another command is active. With other selection commands, this selection menu is already under the exact same dropdown. So in order for the temporary selection tools to edit selection settings, allowing to use the option bar in the header would fix this. You can see for yourself, with box select active, you can only click in the viewport, but not on the header. And this option dropdown is in the interface and it would therefore make sense to also use it for box select.
I saw the discussion about this and people seems to disagree where it should be.
this feature can either be exclusive to mesh editing only like it used to be in 2.7x or include the other modes.
It's position is in the shading Piemenu just like "only Locations" for the pivot and also somewhere in the viewport, maybe next to the options in the topbar.
I saw the discussion about this and people seems to disagree where it should be.
this feature can either be exclusive to mesh editing only like it used to be in 2.7x or include the other modes.
It's position is in the shading Piemenu just like "only Locations" for the pivot and also somewhere in the viewport, maybe next to the options in the topbar.
but Backface Calling and Select Through it's a must have feature for selecting, at least faces.
Example:
Try to select Spheres faces...
You say: Turn on X-Ray... Ok
Better? Try to select now =)
Yes, you can hide 100500 overlapping and finally reach exact face/s.
But what if you need to see whole scene? In this case you need to hide all unwanted, select needed face/s, then invert selection, then unhide all and invert again to keep that selected face/s.
Inconvinient? Live with it...
Added:
Sorry if I wrong with topic theme...
but Backface Calling and Select Through it's a must have feature for selecting, at least faces.
Example:
Try to select Spheres faces...
You say: Turn on X-Ray... Ok
Better? Try to select now =)
Yes, you can hide 100500 overlapping and finally reach exact face/s.
But what if you need to see whole scene? In this case you need to hide all unwanted, select needed face/s, then invert selection, then unhide all and invert again to keep that selected face/s.
Inconvinient? Live with it...
Added:
From Maya to blender, I spent a day to find a way to separate the Xray display from the back selection, and the Xray mode selection can be directly selected without selecting the center point. Then I found the thread and was surprised to find that such an important modeling function has not yet appeared in the latest version. As a character art, I usually use Xray ray to check Whether the equipment matches the character's body or not, Maya attributes wireframe display, entity display, entity + wireframe display and Xray display as one category. Whether to start back selection and put it under the selection tool
From Maya to blender, I spent a day to find a way to separate the Xray display from the back selection, and the Xray mode selection can be directly selected without selecting the center point. Then I found the thread and was surprised to find that such an important modeling function has not yet appeared in the latest version. As a character art, I usually use Xray ray to check Whether the equipment matches the character's body or not, Maya attributes wireframe display, entity display, entity + wireframe display and Xray display as one category. Whether to start back selection and put it under the selection tool
Creating this design task as there are unresolved issues with D6322: Mesh: Select through which are more design issues.
This is a place holder, some topics to address:
Related Topics
Note that there are topics being raised which relate to select-through, but might be best treated as separate topics since we could change behavior here with or without select-through.
Changed status from 'Needs Triage' to: 'Needs User Info'
Added subscriber: @ideasman42
#91121 was marked as duplicate of this issue
Added subscriber: @ckohl_art
Added subscriber: @1D_Inc
Nice move) Indeed, this task require a lot of workflow design for different cases.
There is no proper solution for this. The problem is that such mode is far from self-explanatory by definition.
It can be some tiny gui element that you constantly will look on to check if it is enabled or not, or draw something around cursor/change it's shape , like in other programs.
It also does not allow you to see what was selected or will be selected, so it will always be necessary to rotate the model or go wireframe/X-ray to check the selection.
If to add an overlay of vertices / edges ontop of shadng to make this mode both obvious and allowing us to control what will be selected, we will get Limit Selection to Visible realization.
I know many cases when people assigned LSTV to a hotkey to obtain quick visual through selections instead of wireframe in gamedev (personally, I'm working moslty with deadly hard mess from CAD software, so I have to stick on wireframe).
That's why Select Through it is an excellent example of a failed industry standard solution. It was invented too long ago, so it is pretty much obsolete concept, that creates more problems than it solves.
All this time already works in the object mode. Do you mean - vice versa - provide the ability to limit selection with visible for object mode? That's actually interesting.
Added subscriber: @Debuk
Added subscriber: @kioku
Added subscriber: @DuarteRamos
Added subscriber: @WilliamReynish
The main issue, is that this option conflicts with Blender's current paradigm, which is 'you select what you can see'.
With the linked patch, this conflict is there. If you disable Select Through, and then enable X-Ray, it does select through. Same with Wireframe view and other examples.
I don't see a great solution to this without removing Blender's core selection paradigm, or offering some sort of preference, or making the option feel broken, since if often won't work as expected.
Added subscriber: @serhatErgen
So blender's current paradigm already fails on loop and ring selection. While selecting a loop you don't really see what's being selected until you rotate your view to other side. Also same for select all and select linked selects everything on active context even you don't see any of them. And in many situation (like topological problems), loop selection may fail.
But even though there is no topological problem, how 'you select what you can see` paradigm applies to loop, ring, select all, select linked selection commands? If they are counted as an exception, why wouldn't be another one as long as it's toggle-able?
This is not true.
This select through behaviour is sort of a defacto standard and that has proven in many other tools to be faster than it's possible right now in blender. Blender is evolving at a great pace, and evolving means changes. This is a central element in nearly every workflow scenario. It should be implemented in the fastest way possible. Having multistep setups needed for activating this is wrong. And the visual clutter introduced by wireframe view is slowing you down. And adding central face dots adds to that clutter even more. And even with selections in wireframe mode you have to rotate the view to check if the selection is right.
This is really a feature many of us are hoping for.
The selection-color for vertices, edges and faces could change if select-trough is turned on.
The cursor get a small rendition of what selection mode is chosen and the color of that could change accordingly to the current mode.
Distinguishing between "select trough" and"select visible" with additional symbols next to the cursor would be possible too, but this way it's cleaner and I don't think it's needed. People who activated it and forgot about the what was active mode get a feedback by the selection color, that's all what is needed I think.
Added subscriber: @Oskar3d
@Debuk already pointed out the importance of this feature. In the Devtal thread you can see there are at least 10 people who registered on the platform just to ask for it.
And tens of thousands use "Select Through" by default (Maya, 3ds Max, Cinema 4D, Softimage maybe others too)
There is a reason for that and I'm glad you're not ignoring us.
From my point of view (Maya old-timer) a simple checkbox in the preferences (maybe in the Editing section) to turn it globally on/off is enough.
I think you either use it all the time or you don't use it at all.
In Maya there is a checkbox in the preferences called "Camera-based selection", select only what's visible like currently in Blender. I haven't see anyone use it though :)
"Select Through" is only for Box select and Lasso select.
Circle select and Click select are not affected. In Maya paint select (circle select) selects only what is on the front surface even if you are in wireframe mode.
I think if its a preferences option no other changes are needed.
Added subscriber: @z01ks
I think this should just be in the User Preferences. I don't think it's something that people would want to turn on and off often, but more of a... well, user preference.
Added subscriber: @TheRedWaxPolice
Tool Settings (checkbox).
Box/Circle/Lasso. Personally I don't think the Tweak tool needs it.
All the modes where Box/Circle/Lasso selection tools exist? Makes sense to me.
Sure.
Indeed..
No, preferences is not ideal for this setting. This is a tool setting that is enabled/disabled several times in a section, therefore it makes sense to be located in the tool settings. In most dcc apps that's where it's located because of that.
Exactly.
Consistency - this is all Blender's mesh selecting paradigm about.
Added subscriber: @CobraA
This "feature" is only useful in Edit mode and it conflicts with xray which already does the job, but the problem with xray is that you have to fiddle with the slider. for example in Object mode you want it 0.5 but in edit mode u need it at 1.0.
So the obvious solution is xray needs preset values or a way to set it per mode, no need to add more extra options and subsequently a hoykey if it can be solved by an existent one.
True, xray = 1.0 is equal to LSTV off for edit mode.
Nice solution)
It's not so much that it's popular or not - I know that other apps work a different way.
The issue is that there is an inherent conflict. If you check the patch, you can disable Select Through, which means it should only select front faces. But if you switch to Wireframe or X-ray modes, it will still select through, even though the user turned off Select Through. The way it works in the patch, is that it's essentially 'select through even if something is not visible', and it only works one way - having Select Through set to Off doesn't ensure that you won't select through.
Added subscriber: @ThinkingPolygons
@Oskar3d @z01ks @CobraA @1D_Inc
Guys look, this is a tool setting and needs to be implemented like -> this
Nothing more, nothing less. No need for endless debate. It's that simple.
You always try to copy other Software then you should use that software instead, Blender already have xray that does the job just need to be set per mode which also be needed in paint modes for mask selection.
@WilliamReynish Maybe we can just call it with a different name like "View-based selection" or "Only select visible elements" as @ThinkingPolygons showed, and show the option only in edit mode.
This way it won't conflict with Wireframe or X-ray modes, because the elements are always visible there. "Only select visible elements" on or off, ether way they will be selected, because they are visible (as is the current behavior) so nothing changes for Wireframe or X-ray.
@CobraA nope, x-ray doesn't do the job. With xray = 1.0 you still see the wireframe/vertex/edges/face dots behind.
We are use to selecting elements we don't see, in most cases we know where they are. It's difficult to explain to users who haven't tried it, but I believe such an option won't hurt and a lot of users could benefit from it.
I remember this in 3dsmax 4.
It is also hard to explain to users who have been accustomed to this for decades, that it is not actually needed to guess what you will get after making a selection anymore.
There are no cases to show when it is needed except a cylinder.
There are a lot of such things in industry standards software, because there were nothing except 3dsmax for reference.
When you say "We" you mean users who used to the other Softwares way like Max,Maya & C4D which i used few of them too.
Blender has always set elements visible with that option and it works exactly as xray = 1.0 and it's arguably better choice from my view, don't forget Blender is not just a modeling software it has other modes with selection tools like i have said.
Added subscriber: @Stan_Pancakes
To whomever saying that this is exactly what current x-ray does in Blender: it's not, due to one key difference which is face dots. Blender's current x-ray and wireframe modes are ill-suited for the problem they're trying to solve. They're supposed to let you see through the geometry and select occluded geometry. What they do instead is replace shading with horrendous face dots that clutter the view and make it difficult to discern the faces. What's worse, bulk selection tools (box, lasso) in these modes require user to be overly precise with selection, having to actually encompass those dots. So while they do let you select occluded geometry, they make it a way more difficult task than it needs to be. One doesn't need to go far to see it:
The dots are not only useless here, they're outright detrimental: you have to spend more time figuring out which dots belong where and targeting them carefully with your mouse than actually making a selection.
Suggesting to "just use" the x-ray value of 1.0 doesn't help, since the dots don't go anywhere even then, and the problem of having to surround them with box/lasso remains.
In more practical examples, however, select-through is very useful. Every time you start a model from simple shapes, you almost always want to be selecting in bulk, including occluded faces. There's no practical reason to clutter the view just for that. User can easily tell where the geometry is, whether their selection tool would pick it up. At least, so long as the software does not make the job more difficult (dots again).
How do you select half a cylinder in Blender currently?
How is it done with "select through" enabled?
Two fewer steps, and much less precision and stress required. The comparison is valid, as in current Blender X-ray/wireframe is normally disabled, while if "select through" option existed, it would be normally enabled. Later, when the model becomes more complex, one may turn the setting off.
"Select through" having no effect in wireframe mode is a non-issue. Implementation could gray out the setting, or even not show it in wireframe view.
You are definitely using them wrong. They are needed for precise selection and depth picking (like Pick shortest path)
Vertex mode - Z - select. It is simple.
Maybe that there are shortcomings with the existing patch itself. But that conflict you are referring to is solvable. Lets add a preference "Auto-Select-Through" that switches to select through in Xray and Wireframe mode if checked. Activate the chosen indicator ( eg the proposed cursor icons and selection colors) for Select through in xray and wireframe and we're done. People who love it the old way can continue to and the new feature is nicely interwoven with the rest of blender.
If it's not activated change the wireframe and xray to select frontfaces only. And if that's not possible for some reason make the "AutoSelectThrough" mandatory for these two viewtypes.
I agree. Not needed for the Tweak Tool
+1. No good idea to have it just in the prefs. A checkbox / toggle and a shortcut assignable would be enough.
With that sort of argumentation, we wouldn't even have a save dialog, or a menuentry for it in the file menu, we would also have no filemenu nor would we have Ctrl+S as a shortcut for triggering it. This all existed in other apps before and these things are also defacto standards just like the proposed select through implementation. This is being asked for so often because it's more efficient. Not because someone wants blender to be a copy of another tool. How does this sort of thinking fit to open source. Is eg. using OpenVDB about copying Dreamworks tools or any other software utilizing it?
I think @Stan_Pancakes describes the problems with the current solution pretty well.
I fully agree with it.
I wouldn't say guessing, its more like knowing. If that's not the case there are x-ray and wireframe modes in the other software products as well.
You've tried it, you don't like it and that's fine. In Max,Maya & C4D you can choose to use it or not, its an option. What's the danger of Blender offering to its users that option too? As developers mentioned, its a trivial thing to code it.
@CobraA By "We" I meant the people who like this feature (I guess this includes native Blender users too).
I think what the main problem for people who want this feature is edit mesh mode. (correct me if I'm wrong) So this option could appear for Box and Lasso tools when you edit meshes.
This thread is turning into a mess, if you want that kind of conversation take it to the forums not here, undestood.
you should first know the context of my comment .
For you information it's not allowed to reference other Softwares here on the bug tracker, and any comment who do that should be deleted by the Admins.
If you try to bring any idea to Blender then see how it could fit with what paradigms Blender already have and not a blant copy like Thinking polygon has done over and over.
Pick shortest path and other precision strategic selections are used way less often than bulk selection. Furthermore, why did you stop there? Four faces further and the problem I'm describing is immediately apparent - the dots get in the way of one another. Furthermore, that particular "shortest path" selection requires quite a few clicks, whereas the same selection can be done by tilting view once and dragging a box.
And then you're suggesting to add even more steps to selection, like switching modes, so select through becomes even more efficient.
Selection is the most performed task while modeling, it needs to be as efficient as it can get. That includes reducing amount of work required for any particular selection. Having to constantly switch to wireframe/x-ray and back, switch modes or hunt for dots increases that amount.
@CobraA No this thread is not turning into a mess. From what I get the description this is about discussing advantages and drawbacks for designing and improving a specific tool. And just saying something has been in there somehow, just to wipe away different approaces is not helpful in any sense. Your argumentation is just about conservation. And I think your agresssive tone was and still is damaging here. I gave you some examples why your argumentation makes no sense, that's all I will say to that sort of comments.
Ok, a real work sample.
But I respect your desire to speed up work with primitives.
Now you want to turn it personal, what agressive tone? I said you should know the context first, is that agressive to you? huh
My argument is valid because rules are rules and if you and the other knew them better then we wouldn't be debating about this., you're twist my words as if they are against making any improvements and yes I am for conservation because i don't like features creep ,sure Devs agree on that too..
That sample has nothing to do with "select through" though, the whole point of which is to not have to rely on wireframe and dots when it's possible. Currently in Blender there's no other way. Yes, for that particular selection you need wireframe and dots. For this you wouldn't need either if "select through" existed:
But with wireframe/x-ray the necessity to encompass the dots does get in the way here (a few faces weren't selected, even though the box selection did intersect them; just not enough to capture their dot).
It is solved with vertices mode.
What about workflow design though?
Do you propose something like
enable through selection mode - make through selection - disable through selection mode - add visible faces to selection, to avoid using wireframe mode
or
disable facedots - make through boх selection - enable facedots - add a couple internal faces to a selection?
Through selection selects everything through with box selection in any mode, no facedots method blocks through selection for single click even in wireframe and through mode.
And all this is necessary for editing primitives?
Like I said before, typical scenario is that select through is normally enabled (meaning, you infrequently disable it when needed). So for my example above, all that would've been needed is to switch to side view and drag a box selection. No switching to vertex mode. No entering wireframe or x-ray. Literally just two actions: view and select. If your workflow is different, you'll keep it normally disabled. That's all there is to it.
Again like I said before, my point is that x-ray and wireframe as they are in Blender are in no way a substitute or a replacement for select through. That said, they can be left as is (while graying out or hiding the "select through" option).
Necessary? No. Convenient and faster? Yes. For primitives? No, for everything that has a surface. Model from my example is certainly not a primitive.
Removed subscriber: @CobraA
Added subscriber: @CobraA
I personally think a debate should be open to discuss differing approaches and generally look for the solution with the most advantages and I think the devs agree on that too.
For your information I didn't name any other software so I don't get why you write things like this. And it's ridiculous to think these mentioned rules are there to hinder users to bring in their expertise from other software generally and include thoughts about the market as a whole or present standards. But I am not really interested in discussing this any further. To get this to an end I will leave it with this, if hope you feel better now that you said this, can we get back to the topic discussed in here please.
This is what makes no sense. The current solution has quite some drawbacks, the select through method is bound to wireframes views. I understand why it once was developed like that. But typical mesh densities for all common use cases tend into the same direction. Meshes get more and more polys. And this solution suffers from that. Especially in complex scenes. And using it needs more steps. And any sort of of depth visualization is gone in pure wireframe and the xray is also too cluttered by the wireframes to leave it on. And the face dots increase that problem. That all are benefits from the alternative proposed and discussed here.
@Debuk Don't tag me again, I have already unsubbed from this thread, I don't want to be added into this conversation, thank you.
Removed subscriber: @CobraA
Sure, sorry for that.
Everything that requires single box strike to select is primitive.
I would like to have such problems, but we rarely edit simple models.
Literally, we even made scripts to select object's vertices with another object's volume or surface for special cases we faced with
So, do you propose a checkbox somewhere? What it will do - just enable through selection or also turn off a facedots as well?
Our proposal stays the same - separate Xray setup for object and edit modes.
But it will cover only our demands.
Please leave the snark out of this, there's no need to trivialize the issue. Keypresses do add up as hours go by. "I don't need it, therefore no one needs it" is not an argument.
Sadly, that "primitive" in Blender right now does not require single box "strike". It requires enabling wireframe and paying close attention to what your box encompasses, and usually having to make additional selections after you're done with wireframe. I thought I expressed that quite clear already. In practice, sometimes it gets to a point where it's faster to select a loop, mark a seam, and then use it as a temporary delimiter for "select linked". For the last time - select through is not for peeking inside an object, it's exactly the way to not have to do that when doing so serves no purpose other than allowing selection tools to select occluded geometry. Therefore Blender's existing wireframe/x-ray views are in no way, shape, or form, a replacement for it. They're a poor alternative.
Yes, I do propose a checkbox, in tool options. As to what will it do - IMHO either way is fine (i.e. leave the wireframe/x-ray views untouched and only gray out the "select through" setting while you're in those views), or do what Benjamin's implementation already does and disable the dots.
That separate x-ray views for object and edit modes would be a welcome addition is not in question - they certainly would. But those have nothing to do with this design task. At all.
To the task at hand:
Tool Settings; Under Options, add a new "Select" panel, and store this setting there. That new panel will come useful for future design tasks, as there are other selection-related globals that Blender would benefit from down the line (e.g. selecting by angle, to which existing Select Linked Flat faces is highly inadequate; but that's for another task).
All bulk selection operators, that is box, lasso, circle. Click selection/tweak tool should stick to non-occluded geometry unless wireframe/x-ray modes are enabled.
Except object mode, all other modes where occluded/non-occluded selection is applicable.
Option 1: gray out or hide the setting, meaning the setting has no effect in wireframe.
Option 2: allow the setting to have an effect, disabling face dots (and face dot selection requirement) if it's enabled, reverting to regular wireframe if it's disabled.
No need. This setting would be adjusted rarely.
As proposed by @Debuk above, additional mouse pointer icons. Alternative selection color scheme (themed) could be an option as well.
No. Object mode should be solved separately.
Added subscriber: @CobraA
Agree there isn't an obvious one-right-way, perhaps changing the color of the border or lasso help, cursor etc. Just suggestions - so users have a hint the behavior is modified if the option isn't in front of them.
Right, updated the main task.
Also...
While technically true, I don't think this is a reasonable argument, The same could be said for select-linked, select-all, select-more... Border and lasso select are projecting selected elements in screen-space, which is different to topology based selection functions.
Changing selection color is fraught with a surprising number of problems, we ran into this when tweaking the theme color early in 2.80, Since we already have color for edge crease, sharpness, selected .. selected-active. I would leave the selection color alone.
Seems a reasonable option.
This means you cant quickly change it, as part of your work-flow, basically whatever the default is - is all most users will ever know.
This seems like you're just suggesting Blender copy other software, without justifying why - besides other software having many users.
I assume you would have this enabled by default too, this is quite a big change.
You need to be more spesific tool settings are displayed in multiple places.
Your other points seem reasonable.
This seems more like a usability issue with X-ray, agree different values are preferable in object/edit mode.
However adding options because current features have poor usability is something I'd rather avoid.
It's not so simple. How would this be accessed for selection via key bindings?
While somewhat related, this complicates discussion significantly.
We could change selection behavior regarding face-dots with/without select-through.
For that reason I rather keep this out of the discussion.
You could make the same argument for how difficult it is to move a vertex.
... In practice you almost never do that, similar with view options. You can tap Alt-Z to enable X-ray... make the selection, and keep working. While it's possible you need to immediately disable it, this is the case for most options which toggle behavior.
We should be conscious of the burden of adding options for users too, that there are settings which control selection which users need to carry round in there head (as we can't have all settings visible at all times).
Blender developers have to review bug reports from users who change settings and manage to end up in confusing situations. Or load files from someone else who left the settings in a non-standard configuration - and think it's a bug in Blender. I can only assume not every user that runs into these problems reports bugs. So keep in mind there is a 'cost' to adding options which tends not to be taken into account when users propose adding additional features.
I believe we're experiencing this with some of the 2.8x features - X-ray geometry fading slider for example. Something already raised in replies to this task,
How does it complicate the discussion, exactly? Let me try expressing this once more: existing x-ray and wireframe modes, as they are in Blender right now, are not a substitute for select-through. Select-through is needed for cases when you do not even need to see the occluded geometry, and to select faces without having to hunt for dots: simple intersection with the box/lasso is all that's needed for both occluded and unoccluded geometry. The arguments such as "just use x-ray for this" or that "you can't see what you select" are inapplicable here: the whole point is to not even have to see it. When you already know what you're selecting, you don't need a special shading mode. While accidental selections with this setting are indeed possible, they're no more frequent than accidental selections with, say, existing click-selection in Blender (e.g. when clicking close to two edges, either one might be selected). They are not an issue so long as user understands what they're doing. And when they don't - they can "accidentally" toggle all sorts of things and start reporting not-a-bugs.
No, this is not at all equivalent. I've said this probably four times already: select-through, for people that would use it, would be a setting that is normally enabled. For prolonged periods of time. With your analogy that means you're already in edit mode, have been for some time, will not be exiting edit mode any time soon, and all you have to do to move a vertex is select it and move it, or tweak it. That's it.
You will be working in solid mode. You will be selecting non-occluded geometry predominantly with click-selections, ring/loop/path selections, expansion/conversion, and other operators. You will be using box, lasso and circle knowingly, relying on the fact that those would select through the object. You will not have to switch shading modes just to have the ability to box-select occluded geometry. You will not have to stare at quite messy x-ray or wireframe views sprinkled with face dots just to have the ability to box-select occluded geometry. At some point your model will become sufficiently complex such that you'd be relying more on un-occluded selection, that's when you simply turn the setting off. Or split it into pieces and keep working as is.
Of course.
Of course there is. Which is why it's important to establish what it is that's being proposed, before weighing all the pros and cons. Dismissing it because it's "like x-ray with value of 1.0", like some people suggested, when it clearly isn't, is just counter-productive.
You keep bringing this up and I don't understand the question. Which key bindings do you mean? This is a "global", if you will, that would affect behavior of box, lasso and circle select tools. No access via keybindings required. Similar to Auto-Merge: the setting is there, you adjust it rarely on an as-needed basis.
Because changing this behavior has it's own sets of pros and cons which need to be discussed.
If this is always available in the "Options" popover, as you say, it can work - however this isn't what was proposed, in both the patch submission and video linked from the statement I was replying to - it was an option for an active tool.
@ideasman42 there is no need for a change in behavior. This is new behavior. Like I mentioned, existing wireframe and x-ray could just stay as they are and ignore/gray out/hide the new setting when they're enabled.
3D View Select Through (design task)to 3D View Selection Occlusion (Select Through)I completely agree here and what you have mentioned on the patch thread too, that's why i am more on the conservative side because you raised good points for a user point of view.
@ideasman42 ok this discussion exploded quickly - so I just wanted to add a few thoughts from my perspective while I wrote that patch..
I come from a background of doing 3d game art oursourcing, so we have almost complete control over the meshes we produce here. Most of the stuff we do are meshes ->bevel via a modifier and subd on top. The input meshes are often not all that complex / dense. So this is probably also an explanation why for instance @1D_Inc has so different requirements, as they seem to deal with very dense, and messy geometry.
Actually I'd be happy to just add such a selection behaviour with an addon, but this is such a computing intensive problem that its really not feasable to solve this that way. Maybe if BMesh would support foreach_get/foreach_set methods one could achive workable speeds for this tho - so instead of changing this on the application level, just create some more sophisiticated apis and let the users deal with this.
First off some answers from the other ticket:
Well, true but there are lots of tools which have a high chance of accidents. While its indeed better to not add more of this - it could be mitigiated with somehow draw all the selected elements.
Well we dont have face dots on regular non x-ray mode and its not an issue..
This is a good question, I placed it on the active tools because it felt quite fitting there. I do understand that its not really correct though - it might fit more to the other 'options' panel with mirror/automerge etc. But to me this felt too much like a feature hotpot there as, its already a weird mix of stuff.
I did not care much about this, as Im just used to this behaviour for years.
But sure that is an area which would benefit from icons and/or different selection border drawing. There is also the idea to just draw the occluded selected elements too. But i guess this would need a fair bit of tinkering to come up with a solution which works with all the modes.
Could look something like this:
@WilliamReynish
I agree this feels a bit weak, but this is mostly because I wanted to avoid altering the current selection behaviour. Its actually simple to connect that in whatever way we want..
Anyhow Im curious to see if something will come out of this..
Yes, this is a matter of priorities.
We are not against adding Select Through ability to Blender as an accessible option, but its design should not violate existing capabilities, since it depends on the specific case of the workflow.
Removed subscriber: @serhatErgen
In non x-ray mode this is communicated with wire thickness and changes to highlight intensity of edges/faces.
Removed subscriber: @Oskar3d
The thing is, I simply don't know of a way to resolve that conflict in a reasonable way. There would need to be some sort of toggle or switch to say 'stop selecting the items that are visible - instead use the Select Through toggle and ignore X-ray, Wireframe or other things' - and only show the Select Through toggle in that case. But to me that's very weak and messy.
In principle I am not against adding a Select Through toggle, but am not happy with adding lots of complexity to handle this conflict in behavior. Of course if we can think of a good/reasonable solution then it probably will be fine, so as far as I am concerned that is the main obstacle.
Alternatively we could make a change to X-ray mode so you have a way to make it not show backfiring geometry at all. It could also become easier to toggle via the Z-key.
Making improvements and changes to X-ray can help us avoid the conflicting collision in behavior.
Yes thats not the same technically, but so your argumentation is rather on the technical side and is about categorizing it based on technical approaches. William was speaking of a sort of global philosophy for blender, and that philosophy is already broken. Technical reasons like being based on screenspace calcuations or topological queries may define restricted possibilities but should not define paradigms for what the ux should be. They may correlate per incident though. But after all technical reasons are unimportant from a users perspective. That was my point. But overall this is not the most important thing though.
For some reasons we partially don't get to the how and stick to the why.
Why should we include this in blender if it already can be done?
Because the proposed change is capable to eliminate some of the existing drawbacks.
And that while it is possible to respect the current way of doing it. It does neither replace it nor can't it be combined. And it is already implemented to a large degree, thanks to @kioku. It helps at a very central element of a DCC, the selection behaviour, and aligns it better with other tools out there. And this helps the users with multiple DCCs. And it serves blenders needs. It make switching to blender easier and more attractive by respecting defacto standards out there. And in the long run this should raise funds and the number of volunteers and core developers.
But beside this its mainly about existing drawbacks. So let me rephrase some of these drawbacks once more:
Wireframe and X-Ray are the only modes where Select-Through is possible right now.
In both modes we are not talking of hidden lines we have all backwires of the active object.
The real wireframe mode is the one with the most drawbacks.
And it's also partly true for the X-Ray mode.
During a box and lasso selection the image typically stands still, an the longer you are selecting portions that the knowledge which edge is foreground and which one is background fades from memory.
Working on nonconcave objects makes that even worse.
Obviously there are quite some of your users who are accustomed to work that way. And it also seems the case that there are usescases where all is ok as it is. But that's not true for others.
Don't get me wrong I also can see some cases where I find eg. face dots really good. They are indeed the only possibility to decide if something is an intended backface-selection click. But personally this is far from the most typical case for me, that I really want to make a backface click and that it couldn't get selected differently. I'd wish for this facedots that I could just activate them with a sticky key held down during a selection. And for deactivating facedots, selecting based on overlap with the selection marker is preferred over face centers.
The thing is that while I am selecting something, my main concern is to get a totally different problem solved. I am working on an object, I am concerned about details, shapes, forms or topology. And then I have to switch to one of these Look-Through modes, but for my intended task at that time that's not a good choice. And I really don't want an x-ray view permanently.
I always get the feel that we are all struggling to communicate this problem clearly. I hope this makes clear that it's not about copying. It's about making something better, and as using a defacto standard is not the worst idea from a users perspective if that solves the problem.
For these problems its a good alternative what is proposed here. It's working on different viewportshading types than the current one. They don't interfere. It works in preferable modes where the viewport is not drawing hidden lines, where there are thinner greyish lines during edits. If I want to box select part of mesh I select through, check with a flick if everything seems ok and continue with the intended edit. For creative workflows on models this is a favorable approach. I can respect everyone here who has other topics he works on and there it might not interfere as much. But I also don't want to take away anything for them, nor do i want to copy another app.
I think with some small changes we might have a fitting solution that combines the current way and the proposed one to fit all needs. That's how I see it.
Ok if that is problematic to achieve it makes no sense. The cursor icon change might be enough, but I'd have found it good to have some more prominent visual feedback. Different selection color would have done this.
Is it an option to have these color different colors applied to the lasso line, the box selection marker and the paint select circle itself? If we would color code these for the current modes it might be as good.
The other way around is much more simple: show and use the setting outside of wireframe and/or x-ray. When wireframe and/or x-ray are active, gray it out or hide it, and ignore it. No conflict required. This is not a setting that needs much communication from the UI. While @kioku's implementation does provide special behavior in wireframe/x-ray, it's not at all required, as the whole point of this feature is to not have to switch shading modes just to get the ability to select occluded geometry.
Despite @1D_Inc's self-important "reservations", predictable geometry is not at all that uncommon.
Hi @WilliamReynish : I am not sure if I got you. Is there a problem with this idea?
Let's say we have a Select Through mode and a toggle icon next to the Xray.
If it is techically possible with an reasonable effort to differentiate between front facing elements and hidden ones for these modes, we could add an option to deactivate that in the userprefs.
Ok, summarizing.
The proposal is about
Possible Xray solutions:
A) Split Xray settings for object and edit modes (will also satisfy LSTV demands)
B) Add the ability to fade with slider backfacing wiremesh display in Xray mode down to zero.
C) Add Xray/Wiremesh mode facedot center disabling setting, what will make possible faces boundary selection.
This way this entire Select through mode will be an Xray setup, so it can be used or detected as turned on Xray mode.
It is also possible to use it temporarily (switch it) or work constantly in that mode if it is needed, depending on a workflow type, since users that will make such setup don't need regular Xray as it is messy to them.
Possible non-Xray solutions:
Apply a patch and... It's hard to say without an comprehensible workflow research videos, since workflow is not obvious for everyone and something can be missed.
Is everything right?
It's more about speed and minimizing distraction, thats why its popular.
box/lasso/paint(circle)
Regarding Possible Xray / Non-Xray solutions
While it's possible to add it wherever we want, some solutions make more sense than others.
I am not sure if a select through mode is generally well placed under an Xray label, especially if Xray is able to be set to non Xray. But overall these are related and the basic thought might be a idea worth thinking about.
If these funtions were grouped somehow, it would make sense to have a sort of preset dropdown for typical/common setups.
Sorry, can't reply to that in more detail right now, I am running out of time.
I generally switched to wireframe selection due to support wider range of workflows, that includes both gamedev and messy meshes editing, but as workflow designer I understand distracting and visual overload issues.
Yes, all non-picking selection types.
Well, speaking of terminology, Xray is "view and select through" mode, but I don't see a seruois issue if it will be possible to set it to a "just select through" setup.
It will still be an Xray mode for selection, so it still can be called as an Xray mode in general.
Also I would like to prefer some of that Xray solutions personally, regardless of Select Through semantic overload issue, as they expand the Xray mode in a positive way, which I would like to see in Blender for any kind of a workflow.
So I like it, it would be nice if this generalizes the solution.
@1D_Inc basing this off of X-Ray is really not a good option. As I keep repeating, these are different behaviors. X-Ray allows picking of occluded geometry (its one of is goals), but this is not something you want for Select Through. You want picking to only work on unoccluded geometry for Select Through. Furthermore, both modes are not mutually exclusive. You may still want to use (semi-)transparent geometry view to actually pick some faces inside your model. If you were to unify Select Through with X-Ray like you suggest, we'd have to adjust quite a few settings every time a "true" X-Ray view was needed.
Hi @1D_Inc,
Xray as word is mainly describing that it's a LookTrough Mode to me. The fact that occluded elements can be selected by this is not really communicated by that and is rather "just" known by it's users. And using it for activating cases where you no longer can't look through is an unfortunate choide of words I think. But lets ignore that for a moment. Perhaps there is a better word that could remedy that.
So lets assume these settings were all combined under a single on/off toggle.
It is really important to see that every user would want two or more different setups for that in his workflow and he wants to trigger them fast and not fiddle with settings all the time. @CobraA, @ideasman42 and @Stan_Pancakes, (if it's now Xray opacity or backwire opacity) all stated in this design task that this is the case.
And if we respect all suggested differences and put them all together into a set of checkboxes and sliders there would be roughly these:
But if we leave them separate, and use the fact that different viewport shadings (including Xray) have different properties per default. The setup would naturally be much simpler.
If we'd combine these the only possible solution I could come up with would be a dropdownlist with common defaultcombinations for that.
Then we'd have a single button/shortcut for that and could choose from a handful of different default setups.
But overall I that's the reasons why I personally think that @Stan_Pancakes is right. If we don't combine these many of these settings would be obsolete.
eg. activating a select through by checkbox in solid viewportshading would per default lead to
and Xref could be activated separately.
And as I already stated, add a forced activation of Select-Through in Wireframe and Xray modes keep the current modes intact and embedded into the new controlmethods. I must say it still Sounds like the easiest way to me.
But perhaps there is another way that can be controlled as fast or the preset idea is liked by everyone here.
Would be nice to get a little feedback here from @ideasman42 , what of these directions is more favored.
( Edit: The DarkenedLineOverdraw Checkbox and FaceDots Checkbox could be combined, no need to have them separate)
Sort of. Like Xray setups preset system.
If you switch to Eevee go to edit mode, Xray then behaves just like 2.7's limit selection to visible. the same for the other engines rendered modes, it's just solid mode that needs some tweaks. Why would u add more complexities to selection tools modes...etc when the solution is so simple.
Because LSTV does not solve semantic overload problem. Also rendering mode is hardware consuming one)
Let me explain a situation to all sides of this dialogue.
>Industry Standard Software users
You are trying to ask for mode that is completely unobvious for developers from the point of use because Blender successfully survives all this time it exists without such mode.
So it took some time to clarify an issue, and we has got short and clear description of a problem in Blender terms both for workflow requirements and possible behavior/appearance.
Workflow requirements + possible appearance make up an understandable image of feature for proper design, and identifying it is special type of work in software development.
>Devs
We were working on a hype around Blender for decades, building features and proper marketing, and we've got it - we've got a lot of people from other software!
So now there will be a lot of such requests (like moving pivot point when there is only origin, ability to select something that is invisible, or killind complex multirefrenced modeling to force complex scene setups),
and you need to take into account an actual workflow behind such requests to satisfy them.
It is impossible to create software that exceeds industry standards, completely following industry standards guidelines, and the only way to make a proper feature design is to take all workflows into account,
placing a feature to a complete workflows map.
WD (workflow designes) are special people who are not just uses, but observes and investigates industry standards software on purpose for its weak places to find/make/test
better solution in opensorce software, which work is to build a competitive advantage for companies, can understand and explain such demands from workflow point of view.
An interesting example of the implementation of such functionality for discussion:
https://gumroad.com/l/viewport_presets
Yes, that's nice, indeed. Btw thanks for the link. And it's quite comparable to what I thought of for the select through presets dropdown.
I would see this rather be a task on its own, there are other places in the gui where such a preset idea fits well to kill unwanted fiddling with too many options too. With a very narrow scope it would fit here aswell, just has the potential to be too much for this design task. If it's an interesting idea for the devs they could make it it's own design task or we could shift that discussion over to devtalk.
Added subscriber: @ThatAsherGuy
What if we came at this from the perspective of creating a sort of selection API? Right now, we use editor state flags (x-ray mode, etc) to drive selection behavior, where we could be using operator properties that, on invoke, are set to match those flags. If we went that route, we'd be able to add an 'override global settings' property, letting users swap between their preferred behavior and the default behavior by toggling a single option. X-ray mode wouldn't change, we wouldn't have to worry about tracking a new editor state, and we'd have a framework for future selection features.
UI-wise, The override option, and an overflow popover with the settings it pertains to, could be added to the tool header. It'd follow a fairly standard progressive disclosure model, so new users wouldn't be overwhelmed with options, and it'd allow for easy state signaling (doubly so if the color of the selection outline changes when overrides are enabled). If we end up finding a set of popular presets, we could throw those into a pie menu for easy access. For modal shortcuts, we could stick common options in the
QWERTrow.We will end with this addon's functionality, but through rewriting entire selection API.
Added subscriber: @pixtur
I'm probably not entitled to contribute to this discussion, because I'm just yet another user coming from Maya and bunch of other 3d authoring systems. And since I'm selecting with Left mouse button, you are of course free to cancel my account now. However I have some experience with user interaction design and usability testing.
Some parts of this thread have excellent arguments that I didn't fully understand before. I can now see, why the Blender team is strongly opposed to selecting something invisible, because that it "might" confuse some people.
I derive two major points from this discussion:
User Testing
I'm not sure if the Blender team defined what the target audience should be. (But I'm certain there are plenty of wiki pages on that topic). "Experienced blender users" would be a terrible answer. To the UX designers of the Blender team I can highly recommend Alan Cooper's "About Face", p. 246ff chapter on "What perpetual intermediates need”.
I believe believe that all user interaction design without user testing is fundamentally flawed and doomed to fail. I am also willing to bet that if you test the current implementation as of 2.8 with 30 people (10 experienced blender users, 10 with some experience in any 3d software, 10 beginners) more than half of the people would rate the experience as unexpected and confusing. (The test should be an intermediate task like selecting some components of a model like the Pixar lamp).
For me cutting out a selection of a 3d-model with a box selection should include hidden objects because...
But as I said, all personal arguments are flawed. Ask 30 non-experts(!) at two day blender training, and you will have your answer.
Using X-Ray mode
I'm probably "holding it wrong", but even after countless hours of mesh modelling I find the face dots in X-Ray utterly cumbersome and error prone. I learned to live and sometimes love a lot of other Blender peculiarities. So maybe I will come around in a couple of years. But are you really sure that these dots are still a good idea? This thread already suggests that a lot of conservative Blender users can't let go but the UX designers are now eager to move on. So why keep it alive for x-ray mode?
A compromise that would be consistent with "don't select invisible stuff" and "selection in X-ray+face dots is annoying" would be a new checkbox like this:
Disabling the checkbox would switch to full face selection mode.
On a side node: Thanks again for finally bringing usability to Blender. The current visual design of 2.8 (especially the vector icon set) is one of the design jobs I have seen in years. It's just incredible that this is coming from an open source project.
Facedots are not about being conservative.
They have two main benefits:
The presence of Facedots makes Blender able to provide several workflows that other programs cannot handle.
For example, Blender is the best tool for Sketchup/CAD/BIM geometry cleanup (Sketchup's geometry is kind of legendary messy at CG industry level).
For sure, facedots are not needed for some types of modeling workflows. This thread is about satisfying such workflows demands without corrupting others.
It seems, your proposal refers to the second point of the summarizing post
Added subscriber: @Senna
If we are going to stick with the "select what you can see" paradigm, I think Object mode should be consistent with Edit mode. The X-ray toggle confuses new users when they are in Object mode because they are already selecting through. Having 2 opposite ways to enable/disable select through isn't good design. Consistency is key here. But yes, I think we should support this in both modes for all selection tools.
To be consistent, I think all selection tools should use this.
I think all modes that have relevant selection tools and hidden objects should be supported, which will make consistency with Object mode more important.
Here is a nice workaround example with some depictive use cases for edit mode.
https://devtalk.blender.org/t/decoupling-x-ray-and-limit-selection-to-visible/3498/92?u=1d_inc
Added subscriber: @KyleYoungblom
Added subscriber: @Rawalanche
I have posted this mockup to death already but I am going to post it here as well because it simply solves all the questions asked above. It's just that someone still keeps artificially making this a problem:
Where this option is stored, accessed?:
Right here. It would be the same button, but it would do different thing based on if its sub-option is active or not.
Which selection tools/operators should use this?
All selection operators in edit mode. Object mode already is, and should always remain select through.
Which modes this should be supported in (edit, pose, grease pencil... etc)
Every single mode which currently does not select all the content inside the selection box if current xray is off. In other words, any mode which currently uses any form of view occlusion for the selection.
How to display this option when in wire-frame display (when the user will always select-through)
The button (with the two overlapping rectangles) will be highlighted to indicate select through is on.
How to access this from both active-tools & key-bindings?
This must NOT be a per tool option, it needs to be a global option like the current xray is. Therefore it would be identical to what happens if you currently assign a hotkey to the xray button. There's no need to bring the tools into this, as current Xray implementation works independent of the tools as well, and works just fine.
How to make it obvious selecting-trough is enabled (draw style, cursor - this might help avoid confusion).
See #4
Should this be supported in object mode too?(the reverse since objects already select-through), IIRC we discussed having this option for box select too.
No, see #2. There has not been any select visible only option in object level mode in any other DCC and no one ever requested it. Please don't add bloat features no one needs just to achieve some unnecessary superficial parity between the modes.
All that really needs to happen here is for Xray button to become select-through button with Xray sub-option. This new select-through button would be what the user actually maps to a hotkey to toggle select through on and off when necessary while the Xray sub-option would be more of a persistent workflow preference, where user chooses if he wants to use the "Select only what you se paradigm" which introduces face dots and transparent drawing, or if the user wants to use "Simple select through" paradigm, where face area is used for selection evaluation and mesh transparency drawing is not required.
This also does not introduce any new paradigm to Blender's UI, since toggle with a set of sub option already exists in form of "Show Gizmo" and "Show Overlays" buttons which are coincidentally next to the Xray (proposed select through) button. These UI elements also work in a way that they toggle the set of sub-options present in their popover on and off.
Not entirely sure how this should work. In short:
When button is pressed, but checkbox is not filled, it will display Xray, but will not perform select through,
and when button is pressed and checkbox is filled, it will display no Xray, but will perform select through,
both for object and edit modes?
No, wrong.
When the button is pressed, but checkbox is not filled, it will perform select through using face area (instead of face center dots) and won't make display transparent.
When the button is pressed and checkbox is filled, then it will be exactly same as when the button is pressed now, in official blender builds. So that occluded faces are drawn transparently and face dots are used to select them.
Above applies to edit mode.
In Object Mode, the button should not exist at all, since select through is always present. If you want to make your scene visually transparent (what Xray should actually be for) in object mode, you would just adjust the Xray value on the display popover:
This would make it extremely clear that you are modifying only visual aspect of the editor, not actual selection.
This Xray amount value in display settings would then also be used in Edit Mode when the Xray checkbox is enabled to define how transparent the occluded face drawing is when Xray checkbox is as you said "filled".
Right now, in official Blender builds, if you click "Xray" button, it's actually hardcoded function to do two separate things. It changes the selection methodology and also drawing of your viewport mesh. You can actually see that Xray button actually toggles the Xray checkbox in the Shading popover. It's two separate features, one concerning selection method and other concerning viewport shading style combined into one feature. This forced conflation of the two is the biggest problem here.
I think what confused you is that I forgot to mention that the button itself would be renamed from Xray to Select Through. So that toggling the top level button would say "I want to select through the mesh" and then the checkbox in the popover would be toggle between "I want to select through using Xray drawing and face dots" vs "I want to select through without Xray drawing and using face area"
Added subscriber: @hadrien
Just chiming in to say as useful as it sounds it would be much appreciated if kept optional - I like selecting what I can see without any side effects, so the sync between xray and selection occlusion suits me fine.
I'm with Ludvik on this one: I transitioned from Maya to Blender about 2 months ago, and by far the biggest pain point for my workflow has been the lack of a discrete backface/occluded selection mode. I don't think xray needs to change, for executing precise selection it's valuable. Maya has an xray mode, but it also has a separate toggle in preferences to globally enable selection of occluded geometry. These are separate controls and don't force the user to use tools that don't fit their needs.
I basically alwayswant backface selection enabled on a fully opaque mesh with no face centers. Having a separate mode (xray) I need to constantly toggle adds unnecessary clicks to my modelling, increases the chance I'll forget and transform only front-facing elements, alters the viewport in a way I don't want/need (transparency), and changes face selection in a way I don't want/need (face centers).
No, wrong.
According to summarizing post , this topic is about solving two problems:View Selection Occlusion/select throughproblem and*Face boundary selection//.
I was confused because you called "Face boundary select"checkbox as"Select through" for some reason.
Well, such inconsistency took it's place because it was assumed that Xray can replace LSTV mode because of... some reason.
So it is one of that pretty much fresh inconsistencies that was brought since 2.8.
For sure, you will need to reproduce Maya behavior since current solution is not good even by Blender standards, and also because Maya approach fits most of workflows that can be performed in Maya.
Attempts have already been made to remove the Facedots concept from Blender by developers about a year ago, for some reason, before even asking what they are actually needed for,
maybe because there are some people which type of work they perform allow them to not to use facedots, like Maya or Max users.
However, they were moved back because face edit mode is for faces editing, and facedots provides the ability of some workflows, difficult to reproduce in Maya or 3dsMax, because of lack of facedots there.
Such problems arise because instead of designing a process with investigating and studying a proper range of workflows behind tools, some assumption is made during development, which is forced until it becomes critical.
Workflow design matter is pretty much fragile - there are a lot of things that possible, but not so much that are versatile, and it is incredibly hard to find the best combination that is almost perfect for every possible use case - a bit wrong assumption, and you've got inconsistency like that, ruining usability experience for some workflows.
@1D_Inc:
This "summarizing post" is made by yourself and it's standpoints and range are at least partially affected by your personal opinion, what is so far absolutely fine. But please don't use that as argument against other opinions.
What this design is all about is dependent on how the implemention of this idea is planned, mainly because the context may differ. So if it takes place within the XRAY mode itself would have other implications on eg what to do with the facedots than if it would be just available in solid shading mode.
Beside that this discussion reached a point long ago where it would have been neccessary to hear which general route this design should rather follow to get the problem solved AND have a chance to be accepted. Otherwise it's just an in length discussed misfit in the end.
You still don't seem to get it. What I propose would basically mean that by default absolutely nothing would change for you. You could use your xray and face dot mode exactly the same way as before, and it would be that way by default. Only change for you would be that next to the button currently named as Xray would be a small popover button with a single sub option. It would take about 16px of horizontal space on the 3D view top bar, and you could completely ignore it. This popover dropdown button would contain a single option which would save many of us hours of wasted work and frustration every week. If this change was introduced quietly without you knowing, I am sure it would take you at least a couple of days before you'd even notice the new little dropdown button, just due to how little impact it'd actually have on your Blender usage.
I don't understand what do you possibly have to gain by arguing against a workflow you personally won't use anyway and against a change which would not impact your personally in pretty much any way, since the current behavior would still remain the default. Like the only motivation to do this I can think of is evil.
I am not arguing against your proposal anywhere.
I just said that the problem it is solving does not completely match the name of the checkbox, which makes such a name a little confusing.
That does not mean, that I don't like the entire concept behind it)
What I think about your solution - I really like such minimalistic approach, a very nice design job!
In my opinion it nicely fits as solution for paragraph C from summarizing post.
Let me remind:
I would like to propose to invert checkbox action (so the current default behavior of X Ray is when the checkbox is empty), and name it "X-ray faces selection" or "Face area selection" to directly indicate its functionality.
So if user need faces area selection ability, he enables that ability by filling checkbox, and if user don't need it at some point, he disables it. That could be more consistent behavior. How do you think?
It is summarizing post, it can't be used as argument against opinions. Sort of a protocol.
Added subscriber: @ludvignygren
I was looking through possible solution realizations for paragraph C, like that one .
It is interesting approach - to create special subset of selecting tools, but they refers to Xray (because it is an addon, and have limitations), that makes through selection result different from regular one.
So I thought about combinations of cases to satisfy, to provide the ability to check possible solutions for compliance.
I applied my proposal of the checkbox state invertion in this table, to make it enabling faces area selection, and got such a table.
Every row represents available selection mode, so there are 5 of them.
This way, a checkbox, proposed by @Rawalanche, will override overlays to perform area faces selection for every type of selection tool.
Is everything complete?
The point of this is to be simple. More does not always mean better. Some of these combinations do not make sense.
Now, the 3 out of 5 options that make sense can be easily mapped to my mockup above.
This is your opinion only (and you are extremely opinionated). 4 is how I do my selecting. It has the speed advantages of shaded selection without having to switch shading modes, and the 'hitbox size' advantage with certain geometry of not accidentally overlapping the corner of a face. But the situational advantages are a moot point because...
...Cirno's addon that Paul linked to should be considered the gold standard for box selection. It's not just some idea or a rough proof of concept, it is working proof that you can have all the features, including dots or face area, or contained or overlapped edges, in x-ray or in shaded, without ruining anyone's workflow. Anyone can use any workflow and it doesn't interfere with someone else's flow. If only it were implemented in C in the standard Box Select tool instead of Python we could have the speed of native selection and the flexibility of options. Just pick sensible defaults and let the tweakers change what they will.
What many (all?) of these ideas, mockups and suggested solutions don't address is that this is much more fundamental than just being about how X-ray works.
The basic paradigm in Blender is that you can select what you see. So, in Wireframe view, you can select any wire you click on, also on backfaces.
Blender could work differently, but most of the suggestions here conflict with the concept of you can select what you see. So the issue is not out of spite or anything like that, but because of this inherent conflict between two incompatible paradigms.
The only solution I can think of to address this conflict is a setting in Preferences called Decouple Selection from Visibility. Once this is set, we could show tool settings to Select Through or not.
This could address the conflict, but it would then be something users would have to enable in Preferences, and tools would have to check for this preference before showing the tool setting.
Maybe so. Just put it as an option, because it is ISS related, to present a full cycle of possible options.
The problem is that facedots are used not only for direct access, but also for analysing topology structure.
Thats why Blender is that good for fixing messy imported meshes at industry level - it allow you to see the topological issues directly. That's one of the points of the facedots concept.
Here is a brief example of topology problems that facedots reveals, but it is a secret, please don't tell anyone.
I know, this is inversion I proposed - to enable checkbox if you need to enable Faces area selection.
It could be more consistent, if you enabling faces area selection by enabling checkbox, instead of disabling it. That's the idea behind such invertion.
Not anymore, we've got a mode to satisfy, and it pretty much fits the conditions)
So I expanded your proposal a bit. However, I will not insist on that one.
We are currently discussing the checkbox that requires such an option.
Or may be such an option.
This is just a byproduct of facedots. It's kind of like turning a bug into a feature. I come from 3ds Max and I myself have learned to utilize many of the design flaws as features in minority of use cases, but that changed nothing about the fact that in majority of cases, it was a flaw. There could easily be a mode or drawing style which would show you overlapping edges even without face dots :) Or if face dots sole purpose was a debug drawing of overlapping edges, that'd also work. But their main purpose is to modify a selection method, not to display overlapping edges. Making overlapping edges visible is really just a side effect.
Yes, you sound like a broken record about that already. What's even more fundamental than "select what you see" is a question if such paradigm is even valid. There were many flawed paradigms in Blender over its history, removal of which led to more productivity and better ease of use. There are quite a few other DCCs out there which don't have "select what you see" paradigm, and I have never seen members of their userbase requesting that to change. Here we have Blender, which does have the aforementioned paradigm, and along with that, a 123 reply long thread of people wanting it to change.
But to expand on your proposed solution, specifically:
If that was the case, then a good way to go about it would be for this user preference to redefine what this button does:
...so that once Decouple Selection from Visibility is enabled, this button would toggle select through instead of Xray, and Xray drawing (not modifying the selection method) would remain as an option here, in shading popover:
But it would be very unfortunate if select through option ended up in the tool settings. Such mistake was already done in case of free origin transform, which was crammed into the tool options, which is inappropriate place for it. I really hope the same mistake won't be repeated here.
So, you are also from 3dsmax. That's nice)
"Facedots? Vertex extrude? Pivot point? 123? Multimaterial?"
Yes, I remember that way of thinking.
Added subscriber: @franMarz
I need to put something related on the table here and now, because I know it would slip through otherwise, namely: Ignore backfacing geometry for selection while in Solid view mode if Backface Culling is enabled.
Select edges in Wireframe Viewport Shading even on backfaces is ok because you are seeing them, but why backfaces are selectable in Solid Viewport Shading mode when Backface Culling is enabled? They also block any selection of the actually visible mesh: vertices, edges or faces. Just consider this scenario: while editing the interior of a high rise building, you'll select the invisible ceiling whenever you try to select the walls of the last floor. There is no way of doing so intuitively now, you have to enable xray and deal with erratic selections on stacked meshes like this, or hide the backfacing geometry beforehand. I see this like the perfect example of why you should only be able to select what you can see, and is really frustating: although being against that philosophy of the program which block certain features like the one being discussed here, is still present.
A few months ago, Backface Culling was added as an option to Snapping in order to avoid a similar issue: the inability to snap to something you are seeing through culled geometry. I hope "Select through culled geometry while in Solid Viewport Shading mode" will be considered to be added as an option for any Select Tool as well, and be located on the Tool Settings, exposed on the Viewport Header, and activated by default.
A very nice point! Indeed, architectural interior design is built on the principle of nesting. That will be very useful to have an access to mesh through walls and ceiling, for example, during modeling a room space .
Fixed №4 row in this table from selecting by facedots to area selection with facedots display (current default behavior).
Thanks, @Rawalanche, I've got the point)
The sentence structure was incorrect.
Added subscriber: @slowburn
Added subscriber: @giuseppebufalo
From personal experience I know how this tool work in 3DsMax, Maya and Cinema4D but I've used it mainly in Modo and they did a really good job in designing the tool.
By default you can box/lasso select with "right mouse button" and drag, this will select only the visible elements. If you use the "middle mouse button" and drag instead then it will select through. This is a tool that need be access quickly when modeling so perhaps it can be activated by holding a key while using the box/lasso selection tool).
The way you know it's selecting through is that you are able to see the selection through the mesh. This will give you a visual indication of what you have selected, without that you are more likely going to make mistakes not knowing exactly what you are selecting.
Hope this helps. Good luck!
I've seen similar realization in 1C game studio, they assigned LSTV toggle to a hotkey to select through.
I would suggest avoiding any kind of key holding because it quickly turns into finger push-ups during intense work.
Thanks)
There's very concerning lack of progress on this. I have again wasted hours and hours of time past two weeks just having to wrangle xray mode on and off again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again...
Added subscriber: @rjg
@Rawalanche Please don't spam post on the bug tracker.
We also feel such discomfort from lots of "again" behavior from things that was added or removed recently.
You also assigned Burninate token to this design task, please, be careful with that.
Why? I did not even know it's named burninate. I don't think those tokens really mean anything. At least for me, the meaning of the fire icon is that it's urgent.
Removed subscriber: @rjg
Well, updating summarizing post?
It is widespread behaviour in industry standards software.
The proposal is about
Possible Xray solutions:
A.1) Split Xray alpha settings for object and edit modes, since alpha = 1 is suitable only for edit mode, and satisfies LSTV - Limit Selection To Visible - demands.
A.2) Add the ability to fade with slider backfacing wiremesh display in Xray mode down to zero.
A.1 and A.2 will make select through with facedots selection mode available.
B.1) Add Xray/Wiremesh mode facedot center disabling option, what will make possible faces area selection for all non-picking selecting tools and methods,
separating the selection mode from the display mode.
Possible design:
or better like this (because takes the same space, but makes option easily accessible, detectable and independent from Xray)
B.2) The option's behavior must satisfy the following conditions:
B.1 and B.2 will make select through mode detectable with no facedots display.
It is also possible to use it temporarily (switch it) or work constantly in that mode if it is needed, depending on a workflow type, because users who will use such option do not need regular Xray, in cases when Xray spoils the viewport.
Additional / Questionable / Offtop:
X.1) Ability to select visible with backface culling in shaded mode to satisfy selecting visible condition. An example of use is interior basemesh modeling.
X.2 ) Split Xray and Wireframe modes, since wireframe without Xray clones Flat shading mode, so it is more about visual style rather than shading mode. (questionable)
X.3) The reasons for separating the selection tools for the edit and object modes are not obvious.
I'd also add that the select through should only modify box/lasso/circle selection, but the single click selection should remain at the behavior of current occluded selection. So that single-clicking things like vertices or edges does not accidentally select elements on the back of the mesh. Select through without Xray should really only affect box/lasso/circle area selection modes.
And one more important thing, when select through is enabled but Xray is off, as requested by many, Wireframe mode should still draw a fully transparent wireframe, not occluded wireframe. Right now, wireframe display is tied to Xray mode, which causes issue because many "select through" users rely on ability to quickly switch to wireframe mode to occasionally have better awareness of what they are selecting. And please don't mention that the current Xray behavior already does that (preemptively anticipating William's reply), because the giant difference here is that in Blender, currently, it's mandatory, not optional.
Both of these things are important details that the original path from Kio did correctly, so they must not be omitted here either.
Agree.
Agree. I think that occluded mesh display just duplicates functionality of Flat Lighting viewport shading mode.
I didn't found other cases when occluded wire mesh display mode could be useful, and would like to know if such cases exist.
Changed Xray positions in table to Xray/Wire.
This is quite a discussion for such a simple and uncontroversial feature :) Anyway, here's my attempt to summarize it and add some suggestions.
Tool settings in properties editor. (Image below)
Box, lasso, circle
Any mode, where it would be useful.
I don't think there's anything to display since this feature only applies to solid shading. Wire and X-Ray function the same way as before.
Putting this in the tool setting means that it's very easy for users to add it to Quick Favourites or assign a shortcut. Additionally there could be a checkbox in the 3D viewport header.
As suggested above selection border could have a different colour. Also temporarily enabling x-ray while dragging a selection like in Cirno's addon would make it really obvious and help to see what you're selecting. 3rd option is to have selection preview: elements (or objects) would light up as you drag the selection marquee to show what will be selected, if you release the mouse at that moment. This setting would highlight even occluded geometry with a pseudo x-ray shading (if that's technically possible).
Yes. An option to prevent occluded objects from getting selected in object mode would be useful.
Related Topics
In addition to giving the users explicit control when to use facedots or area selection, I think it also important to have control how area selection works in general. Basically there are 2 methods: a) selecting everything that at least partially intersects selection area, or b) selecting only the objects/subobjects that are entirely within the selection area. Right now there's no way to do that in Blender, but this functionality can be added without the need for additional shortcuts by checking the direction in which you drag the selection area. In this example dragging left to right selects everything, while dragging right to left selects only a few faces that are fully inside the area.
To indicate which method is used the selection border has a different appearance. Although selection preview would work even better. This feature should also apply to edge selection and object mode.
Another thing is Backface selection. Right now there's no way to disable it, even if Backface Culling is enabled, so there needs to be an option for that.
Here's a mock-up of how these features are presented in the UI. My formatting is probably all wrong and feature names are up for debate, but you get the idea.
Select by Facedots needs a separate checkbox for each shading mode to emulate current behaviour, where it's enabled automatically for Wireframe and X-Ray. I think this covers most of the issues discussed in this thread, but most importantly, it can be configured to make Blender function in a same way it does now by default.
I know these proposals go beyond the scope of this task, and maybe should be split into their own task. But the discussion already expanded into other areas, so I'm just putting them here in case it gives the developers some ideas.
Added subscriber: @finirpar
This proposal does not even support all selection modes, only tools. So this is a controversial solution for a simple and uncontroversal feature.
What do you mean?
Indeed, this proposal does not apply to internal types of mesh selection, like B and C shortcuts, which are used more often because they are faster to invoke.
Also, I don’t think that just putting everything on the checkboxes is the right way to design. Proposal by @Rawalanche seems to be more accurate and complete.
I like the idea of side-dependent selection, which is a fairly common solution, and was proposed many times, but it is a separate design task.
Modal selection can have the same features available as the selection tool, the only difference is that they are controlled with shortcuts, like these:
Default configuration would be synchronised with tool setting so it would work in the same way.
The problem is that right now there is no place in Blender's UI for global selection settings (because there are no setting, just hardcoded stuff like Facedot selection in X-Ray). So tool settings looks like the only area where multiple options could be put in one place. And it could be made to work globally across Blender. Of course a dedicated space would be even better.
Ludvik's proposal to put selection-specific options in the area used for shading and overlays seems like an ad-hoc solution. It works well in this specific case, but cannot be expanded to accommodate additional options. For example, if Backface selection toggle is added in the future, where should the option be located? Next to 'Backface Culling' in Shading menu? I guess it depends on what kind of long term approach devs want take for selection tools - if all setting should be in one place or scattered around the UI.
I did not put it there at all. The Xray button was put on that place by a dev team. What I am against is the way they combined a viewport shading changing feature and selection method changing feature into one feature which can not be toggled separately.
Selection is selection, no matter which tool is used. It does not make sense to split modes per tools, since the same result is expected from any kind or way selection is performed.
There is no problem, because it is just selection, not a rocket science. Selection should be simple, predictable and satisfy some certain conditions to be good. This is the point of concise design.
As Ludvik said, Xray/Wireframe is already affecting the selection mode as well. This is part of the "you can select what you see" paradigm.
It will not be a toggle. It will be a bugfix of a a very ancient problem, that breaks "you can select what you see" paradigm all this time.
Ok, perhaps I didn't explain this properly in my proposal, but options that are placed in the tool settings are synchronized across all tools that share those options. Take a look at Drag option for example: if you set the Drag action to be Select Lasso, all tools will do a Lasso Select. So it's not tool-specific, but a global toggle. Select Through (or any other selection-related option) would work the same way. Here's how it would look like placed in the header:
Since Select Through is something you might want to toggle more often, depending on situation, it gets a separate button (which also works as a visual indicator, solving one of the design goals). Whereas Facedot selection is more of a general workflow preference, so it can be hidden in a drop-down menu. This is a simple and concise solution, that doesn't complicate selection process in any way, but places useful options always within reach in case you need them.
It's not that simple. Even with Backface Culling enabled, only the solid shading of polygons is disabled, but vertices and edges are visible. So you can still select what you see, without braking any paradigm. I think it's better to take the same approach as with this task and clearly decouple selection behaviour from the shading mode.
That looks better, since it is available in fullscreen, that makes mode easily detectable.
But I am not sure what is the reason to see facedots, but not select by facedots in xray/wireframe. It will be rather confusing.
Also, this header will apply to the entire selection as a whole, even if it is assigned to each selection tool separately, that can be confusing as well.
Can you make action table for your proposal, like in that summarizing post to make things clear, and to be sure that there are no doubling options (like same selection behavior when option is turned on and off)?
It looks like combinations of all those options and modes are not mutually exclusive, and checking actual selection state according to this scheme requires a complex mindmap.
Not sure, it will be used quite often (because of why?). It will be used mostly for depicting mode rather than toggling, since its area of use is general workflow-dependent.
This option is actually designed to avoid "again and again" toggling actions.
Basically, it will be turned on constantly while working with mesh with predictable backface geometry, and turned off while working with complex/unpredictable backface geometry,
because only wireframe/Xray/LSTV modes make selection predictable for such kind of models.
No, the scope of use facedots is case-dependent and is related to mesh fixing and topology control cases, and also dependent on model's complexity.
Facedots is topology checking tool, that works similar to checking normals tool, checking non-manifold tool or any other topology checking tools. If there are too many things to check, you just start using them on an ongoing basis.
I can tell the reason Blender has got facedots, it is related to Blender's mesh paradigm.
There is no ability to select visible vertices or edges in backface culling mode, like this, even if we see them:
As for the selection modes - I do not see the need to separate it between the object and the editing mode.
For instance, if I use tweak tool, or box selection, I use it independently of mode, because it is easy to remember what selection mode was used right now.
It’s rather inconvenient to lose the chosen selection mode each time you exit the editi mode to get the selection mode that you used, for example, an hour ago in object mode.
Removed subscriber: @CobraA
This "Select by Facedots" toggle only applies to Box/Lasso/Circle, but you still need to use facedots to pick a specific face, with a single click. Otherwise you would need to click multiple times to select a face that's behind other geometry. That's how it works in 3ds max and it's always frustrating.
What do you mean "separately"? As I said these settings would work as a global toggle, so that selecting is always consistent across all tools, including modal selection that's activated with a keyboard shortcut.
Here are all possible combinations in a table.
In combination 5 and 6 facedots could be enabled as an overlay without affecting selection, the way it works right now.
Occluded selection is still a useful mode, even if hidden geometry is simple and predictable. The point of this option is to eliminate needles switching to x-ray to select-through, when you can do a "blind" selection, but whether you actually need to select trough is a different matter. I guess it all depends on the user preference, model and other factors that are hard to predict. But even if it's used just a couple of times in an hour, I think it's reasonable to put it in a header because it also works as an indicator. Controlling facedot selection also shouldn't be a problem, since it's just one click away in a drop-down menu.
The main takeaway here is that there are as many different opinions and workflows, as there are users. So the goal is to add these options in a way that's easy to configure to fit any workflow.
Yeah, that's a strange problem, but having a Backface Selection toggle would actually fix it in this case.
I agree that drag action should be kept the same when switching modes. Not sure why it was done this way.
Yes, this mode is frustrating in 3dsmax because it is the only mode there.
Unlike in 3dsmax, our solution provides both possible wireframe modes - for face area selection without facedots display and for faces center selection with facedots display, with simple way to control it.
Abscense of facedots in witeframe can clearly visually split face area mode for non-picking selection types, which can be useful while working with predictable geometry.
It is not good idea to place global toggle to some local tools.
If you use move or bevel tool, you still able to make selection with B or C, but can't define if select through mode is currentry in use, because toolbar preferences are occupied with move or bevel tool settings.
The problem is that this table is far from being complete in case of your proposal, since all binary combinations of all proposed checkboxes and options should be listed in it.
Our table is not just listening modes, it contains all possible combinations of options used in our proposal, that is why we can argue that it is minimalistic.
So your table should look like this.
There will be way more than 6 combinations .
This will make it obvious that all these combinations of modes and options are not mutually exclusive.
Also row 3 is highly questionable
For sure occluded selection is useful mode, since this topic exists and we are making proper design. But button that we design will not be "pressed often". That's what i meant by "using often".
Drop down menu makes current selection mode unobvious, that will force to constantly check current options combination in order to understand what you will get with next selection.
This can be more confusing than useful, since it makes it hard to control possible combinations.
From the point of selection there are just two cases to satisfy - predictable backface geometry and unpredictable backface geometry.
All possible use cases and workflows fits that condition.
Providing ability to make backface selection by default also fix that issue.
What is the point of making it as a toggle - to provide ability to not to select what you see as well? What are usecases for keeping it as a toggle?
Yes, it looks like two unrelated things (edit mode and selection tool) are tied together.
Added subscriber: @StanislavOvcharov
agreed, splitting selection mode per editing mode is quite annoying
I think it was mentioned in this thread by a developer, that facedots in Wire/X-Ray are used to indicate face selection mode, so they can't even be disabled. Besides, combining those 2 modes would help to save quite a few clicks: you could use area selection for selecting multiple faces, and then immediately pick a specific face by a facedot, without having to switch to facedot selection mode.
Ok, I see what you mean. Maybe the buttons could be placed in the middle of the header or on the right side, to separate them from tool settings. As I said, there is no obvious place to put selection settings in the UI, but they have to go somewhere.
My table lists all useful ways that these two options (Select Through and Select by Facedots) can affect the selection for each shading mode. Listing all binary combinations wouldn't show anything else that's important.
Facedot positions can also be predictable. For example in this cylinder:
Here you would know exactly what you will select and It's impossible to make such selection by face area. I don't think it makes sense to artificially restrict or remove certain combinations because it won't simplify the UI in any way. And someone might find it useful in some rare corner case.
I don't think people would have much difficulty to remember which checkbox they have clicked. But to make it really clear, the drop-down list can be replaced by a button that is toggled independently for each shading mode. Looking something like this:
So if facedot selection is enabled for x-ray for example, it would light up when x-ray shading is enabled. "ST" is just a placeholder for a proper icon here.
That's one of the use cases. When modelling, I like to keep backfaces enabled to get a better sense for the overall shape of the model, if it's not fully enclosed. But then backfaces can get unintentionally selected and there's no way to prevent that in Blender. It's not that big of a deal, but it would be nice to have an option to toggle backface selection when I need it.
Added subscriber: @Vyach
I have bad experience with separate tweak took per each mode for each type of object.
So I was forced to chand tweak tool to «Tweak» from «Box select» in my startups for all (mesh, curves, bones, uv-editor, node editor, surface, metaball…) Ugh…
And for each separate viewport… It is very annoying.
Also I can
t figure out, why box select is default for tweak tool for all objects. For nodes I move em oftener, And I dont want to press additional G.For curves the same: I move nodes and drag handles.
For Grease pencil I use lasso selection with Ctrl+RMB-drag
So I prefer to have global tweak tool mode at least.
For me it is much more handy than set separate individual modes for each type of object.
Or at least full syncronization per object type and per editor type.
Facedots are already disabled by default in solid mode, so there is no more corellation between facedots display and face mode anymore.
It is also done by developers.
Snaps or proportional editing have nothing to do with selection.
I think placement near Xray button from our proposal is better since shading influences selection as well.
Either you or the developers will have to do this.
This can expose situations like that
Indeed, a very rare case.
All such cases are very specific, are much faster to perform from wireframe shading mode (rather than setup selection back and forth), disallow to read through mode from model appearance and requires separate option.
It looks like LSTV mode but without ability to see backfacing.
Not sure if it's worth it.
For sure, unless they have no other business, rather than keeping it in memory.
That's interesting solution, it will make mode visually clear.
The same way behaves wireframe and Xray buttons (there was an idea to make them independent, since wireframe without xray is more about visual style rather than regular shading mode).
But, as it was told before, such modes are not mutually exclusive.
For example, what is the difference between this possible options combinations? I can see only two unique results.
Not sure I understood that correctly, can you give an example? How you can get unintentionally selected what you can see?
Yes, after selection goes some operation, so you have to switch to anything but box selection immediately after the very first selection anyway.
Tweak also allow to perform picking selection type, and it is the most common operation, that follows selection, so I agree that it could be a nice default.
I am sorry but having all the 4 factors exposed as UI controls is a complete UX nightmare no one should ever do. Blender actually needs removal of options in this case, not addition of new ones. If it was for me, I would not even add the Xray toggle that I did in my proposal, and I would simply kill the whole Xray and face dots thing and have one, proper, consistent selection mode.
The developers are already now in a denial about this feature by claiming it would complicate things, and you are just giving them ammunition to support their unfounded argument.
That's why our proposal consists from a single ui button and several overlay options.
Also added some of the issues discussed in the summarizing post as well.
And what would that one, proper, consistent selection mode, that can satisfy everyone, be?
Regarding X-Ray, maybe it could be merged with Wireframe into a unified see-through mode, that is enabled with the same shortcut/button. And with the X-Ray slider you could set it up to look like a simple wireframe or an x-ray shading that we have now, based on your preference.
But getting rid of facedots is unrealistic, since they are used to reliably select faces that are overlapping each other in wireframe/x-ray.
Single ui button works well for controlling select through/occluded, but tying facedot selection to the overlay is flawed. If I want to use area selection with x-ray do I have to forego the ability to accurately select individual faces? Why can't I do both? These two modes don't interfere with each other.
I mean even if you create Blender's UV sphere primitive and keep the UV segment counts at default, even that is already a case where it's borderline impossible to utilize face dots correctly because you can't reliably tell which face dots belong to front faces and which to the back faces. And even if you could, as soon as you need to select more than 3, you'd probably give up on click selecting and box select instead, where, once again, face dots become just useless annoyance. Face dots are synthetic solution to a problem which never existed in the first place. They are solution to a very small synthetic example, not a real world workflows.
Here's a typical example how brutal failure face dots workflow is in the most common scenario one does many times a day.
Imagine you want to face select a corner of cube. Basically 4 faces touching one edge of cube.
In a normal software, you would just box select a corner of cube from side view, and that would be it.
In Blender, you are faced with two bullshit solutions:
https://www.youtube.com/watch?v=THVtJrsiX0Y
And this is even favoring situation because the front facing geometry is identical to the back one. If the back face was subdivided to 4 faces, it would be even that much more difficult. At the same time, if we had select through without face dots, these issues would never ever exist.
The problem becomes ever more low level if you think about it. Blender is the only 3D DCC where you need to waste your mental energy on something as essential as selection. You don't need to do that in almost any other mainstream DCC. There, the selection always remain consistent, so it gets saved in the intuitive/muscle memory and no longer wastes your mental energy because it's not constantly switched around.
How many times must I correct you before you stop repeating this lie?
https://i.imgur.com/zkARZ5U.png
(That's Maya, in case it wasn't obvious.)
By all means, I encourage you to be an advocate for decoupling face dots from shading modes as much as you wish, I agree that people should not be forced to use face dots, but they also should not be forced to use face area. Face dot selection should be set independently from shading. All 3 things should be set independently from one-another: Select-through, shading, and face dots.
Kindly don't spread lies and advocate for the complete removal of a useful selection feature. You do not speak for everyone and your own personal workflow is not everyone's workflow.
For sure.
As it was told, facedots are needed to detect and work with cursed geometry. It is not the best selection mode for cubes.
Here is GIF with the right way to use facedots selection.
Not sure if it is possible, since Xray with alpha = 1 provides LSTV abilies as well.
Nice example.
Not sure if facedots are needed to be independent from select through, since they can indicate it.
However, A.1 and A.2 paragraphs of the summarizing post make it possible to select through by facedots.
I have genuinely not known there are face dots in Maya despite having it used in production for about 2 years and worked with people using it for at least 8. That goes to show you how useful they actually are. I've never ever seen anyone use it.
Removed subscriber: @Vyach
Added subscriber: @A.Lex_3D
This quote is probably the most important point (not only) in this discussion!
Added subscriber: @Rongix
Let's make things consistent, if user checks on face centers, it should be visible in all modes that draw faces. If user disables face centers - they should be hidden in all selection modes (solid, xray, wireframe). This toggle should change how faces are selected.
We should add new toggle 'Camera based selection'. If disabled - laws of blender 'select what you see' are broken, tools like box selection and lasso can select through. This toggle could have subsetting in pulldown (affected tools: box select, lasso, circle select... ). This way we could make for example circle select always select only visible components.
How will it work? If face center are enabled when camera based selection is off, it will select through all face centers (simple and clear); if face centers are disabled, it will select through all faces touched. I guess we need few simple options that combined create good user experience (the experience that someone wants) and in this way we will limit our personal influence on others workflow.
If we really need distinction between face and edge mode, we could add separate theming options for wireframe (although we have buttons that show what component mode is active so what's the point?).
the same goes for camera based selection mode, if there is a button toggle activated it's hard to miss.
If distinction between camera based selection is really needed, we can change cursor (it would be subtle change like for example crosshair and crosshair in circle).
@down reply
I dont know how to adress this summarize table since I dont understand it.
In quick summary:
Do you mean edges and vertices modes as well? Or do you mean "all face selection modes"?
How will this make possible row 4 form the summarizing post ?
There is such an option, called Edges in Overlays. Turn it off like this to see the difference between edges and no facedot faces. Personally, I keep it enabled since I have to use facedots.
The point is that those buttons are small, and the mode is constantly changing during modeling. So this difference is necessary for visual feedback. This eliminates the need to constantly check small buttons.
I think it is possible to work comfortably with only small button indication in this case, since camera selection mode is not supposed to be changed often during work, so there is no need to check it constantly.
This sounds all good and reasonable for drag selection modes (box/lasso/circle), but how would you pick individual faces in wireframe without facedots? There would be no way to distinguish between overlapping faces. There could be an option to disable facedots in x-ray/wireframe for people who don't want to use them at all, but there also needs to be an option to enable area selection even if facedot overlay is on.
Maybe it's true for your own workflow, but it doesn't apply to everyone. It's much more important to have clear indication when select-through is enabled, because you can mess up your model if you select some occluded geometry without realizing, and then start editing.
True. Usually user goes wire/xray to not only to see inner mesh structures, but also to select them precisely.
Well, let me explain it in a bit offtop manner.
I am a workflow designer, that have to perform widest range of workflows possible - from web/gamedev and CAD to historic resotations and cursed mesh cleanup, that allow to observe the needs and problems of that range.
I am here to be sure that developers doesnot shrink it
(as they usually do, because they don’t even ask users what workflow the features requested by users are compatible with, limiting blender to some kind of "asset/character" modeling, which is the most understandable and obvious to majority).
I don't have "my own workflow", my job is investigate and compare workflows. Companies hires WDs to enhance pipelines.
If you doubt the solution proposed, as a worklow designer I can provide an evidence that this solution works and does not cause any problems for millions people during three decades
So, despite the fact that this solution has already been pretty much tested, our solution allows us to observe and control the mode indication directly, because Blender selection types are more complex because more flexible.
But I understand your concerns, indeed, UI / UX is always subject to mandatory testing, at least because in practice the user needs much less things than it seems even for wide range of workflows.
This is the way Blender got that much condensed UI.
From an outside perspective, it sometimes seems that the people with the longest Blender experience feel entitled to scream the loudest. I'm sure you will find your workflow just perfect. In fact, I believe there are many users who use this workflow. But that does not make it the primary use-case for Blender by default. I'm just following this discussion and somehow I think it looks like the one who screams more often and more aggressively will get his/her right.
As a user who doesn't have much time, I would prefer the Blender Foundation to invest a few hours to build some click-dummy prototypes and just do a usability test (as described by usability experts like Steve Krug). Whatever the result of this test may be, it will be better than any solution you (or I) could come up with. It might not be a solution you like (it's probably not even a solution I would like), but it will be the better solution for Blender.
I sorry for the rant. We all just want the best for Blender.
And yes, I've been using Maya for 15 years. I miss many great features (like Vertex Face selection). Facedots are not among them. :-)
Nobody screams here, just a discussion without emojis and smileys.
This topic is a user request, Blender Foundation has no usability problems with occluded selection to test and fix, otherwise it would have already been fixed.
However, our Maya users don't use that feature, they prefer to select edges with more than 2 faces to detect mesh issues.
That's actually excellent :-)
Eh, that's debatable. 3ds max is not exactly a shining example of a 3d app that is beloved by its users. I've been using it for a long time (too long), and noticed that I have to toggle wireframe mode very often to check what I'm selecting, so I'm hoping that Blender could be an improvement in this regard. The way Cirno's addon works is a great example: switching to x-ray while you drag a selection allows you to see what will be selected, without having to push any extra buttons. Only improvement I would make is to switch only the active object to x-ray, instead of the whole scene, which can be jarring.
I just hope that GSoC project for custom menus is completed successfully, and we don't have to depend on one-size-fits-all approach of the default blender UI.
For sure. This way max is a nice example for testing something that looks important, but is not important in practice, like in this case.
The problem is that Cirno addon's solution have nothing to do with occluded selection paradigm.
The problem of this problem is that we have to exactly define a problem - do we need industry standards occluded selection or do we need in fact just autoxray selection (no industry standards, blender only)
Hard to say. From one side there will be a lot of users from ISS that will require occluded selection. There will be those who are satisfied with Cirno addon's solution. And there are users that have to switch button anyway, because of unpredictable backface topology, that makes both occluded selection and Cirno's addon useless in that cases.
We will still have to make nice defaults. Because it is possible.
As a workflow designer, that works with lots of artists, I can imagine hell of excessively flexible UI. Artists always prefer mess if they have the ability to make it.
I would not be surprised if this was still ignored as a target for 2.90 even despite overwhelming amount of discussion both here and on devtalk thread, as well as significant ease of implementation (it's a minor feature).
I guess that important the result of discussions, not the amount of them)
However, I think our proposal is pretty much solid.
Internally occluded selection should be implemented to work with any shading mode and then autoxray could be added as an additional option, purely for visual feedback.
It's mostly solid, but you should add one more condition and try to find a solution.
It is missed on a purpose, since it is confusing behaviour - you see facedots, you are in wire mode, but your faces selection mode is area.
You can't read mode from visual appearance in this case, so It will be easily confused with the default wire mode.
Can't see common usecases which clearly distinguish this mode as necessary.
Added subscriber: @lichtwerk
Changed status from 'Needs User Info' to: 'Confirmed'
@ideasman42 : From your actions, I assume this can be confirmed then?
Removed subscriber: @Rongix
Added subscriber: @lcas
Hey what's up I saw this, was looking into updating this:
https://developer.blender.org/D6322
But I don't know how, gonna see how this DIFF stuff works tomorrow and give it a go.
In the meantime I'll post a link to the thread.
https://devtalk.blender.org/t/decoupling-x-ray-and-limit-selection-to-visible/3498/150
Got it working as an operator property instead of a tool setting. Can assign it to whatever you want in the keymap. I have both select visible and select through in box, lasso, and circle. Can use either one at any time, by that I mean when in edit mode without changing settings or something like that. Right now I'm using alt-drag, alt-shift-drag, alt-ctrl-drag for select through along with the default select visible mappings you get in 2.8 keymap.
Added an Xray Facedots option in the Overlay options. That way if someone wants to disable facedots entirely they can do so. Or they can have them on all the time. Or just in xray mode. It's a matter of what combination of the two checkboxes you click. I think it would work better as a dropdown sort of thing: both, Xray, none. Would that make it an enum instead of a bool?
Let me know what you think, I have very limited experience so any help or advice is appreciated
This summarizing post was the latest:
https://developer.blender.org/T73479#926945
Keep in mind still that it's just your summarizing post. It's summary of your personal opinion, not of the community consensus. For example for case 4, there's really no reason to ever have occluded selection with face dots ON. The whole point of face dots was to have an ability to select occluded faces. In case of being able to select only visible faces, face dots come only with all of their drawbacks and issues but none of their benefits.
Hi @lcas , nice to see some progress on this task. I've tried your build so here's my feedback:
For facedot controls make one checkbox for solid shading and other for wire/xray. That way they can be controlled independently for each shading mode. Adding a dropdown menu for 2 options is an overkill and would only add additional click to change a setting.
Controlling select-through only with the keymap is too complicated as it would double the amount of selection shortcuts to manage. And modefier keys are most likely already being used for other things by most users. For this feature to be usable it need to be controlled with a single button/shortcut that toggles it for all selection tools and modes in Blender. Also a button somewhere in the UI would work as an indicator to show if select-through is enabled. Maybe keymap option could still be used to override the global toggle, if that's even possible.
There's no way to control when to use facedots for selection. For picking a single polygon, facedot is usually more accurate, but for box and lasso selection it would be good to have an option to choose whether to select by facedots or by area.
It contains your proposal as well.
This is default setup that is used to detect mesh issues. You will just not use this mode, so there is no problem.
Yes.
The design of this option is provided in summarizing post.
It is defined by shading mode.
I am using facedots display with occluded area selection for detecting mesh issues as well.
It is very useful since it clearly shows faces distribution.
I also prefer to use xray with no opacity instead of wireframe or select through because it show mesh.
We are using xray for surface-based kind of models with no inner structures, and wireframe for models with complex inner structures, when faces shading depicts level of inclosure (nesting) of mesh entities.
Alright got a new build for people to check out, once I get what I can do finished I'll throw a diff over on
https://developer.blender.org/D6322
I found these instructions for doing patches. Looks like I'll need to apply this to master, meaning 2.90. So there might be a few other things to do to make it work with that.
https://wiki.blender.org/wiki/Tools/Patches
Here's a link to the build, will update the thread as well
https://www.dropbox.com/s/9vuth1b6ixol4qp/Blender%202.83.3b%20-%20Select%20Through%20Keymap%20Override.7z?dl=0
What's new:
I have a button in the header next to xray for toggling Select Through, using the icon for OBJECT_HIDDEN as a placeholder.
On that Select Through button there's a dropdown with one checkbox called 'Keymap Override'. It gives people like me the convenience of having select through in the keymap, while giving everyone else the button option.
Xray Facedots has been cleaned up. 1 checkbox for solid and 1 for xray. I agree about a dropdown being 1 extra click, not necessary. Slipped my mind because I was thinking about HOW to make it into a dropdown instead of a checkbox, rather than WHY ;)
Select Through can be disabled in Xray now. Pretty sure that wasn't the way it was before. This is a consequence/bonus of having both keymap and a header button to control Select Through. Or at least the way I implemented this behaviour made it happen unintentionally. It seems that Selection and Xray have been even further "Decoupled" to borrow from that thread title. Whether this is something people are wanting is something I'm interested in hearing
Haven't done anything for Area/Facedot selection options yet. Will look into it. No promises of course, not sure where that takes place, but I'm pretty sure that something @kio originally did has an effect because you can select by area in xray. In the official build you can only select by facedots in xray.
Check it out and let me know
Wow, this makes absolutely no sense whatsoever. If this is just about detecting mesh issues, then there's really no reason to have this at all. Instead of going into "mesh detecting mode of displaying face dots but not selecting through", you can just quickly get into the actual xray mode, and see literally the same thing. Furthermore, if you had this hypothetical "mesh issue detection mode" which would show you issues like 0 area faces between the edges of faces, then you'd still not be able to select many of them if you had select through off. You are literally describing just a matter of seeing the face dots. It doesn't matter what the mode which displays them is, if it's just a temporary error detection tool for you. What matters a lot though, is having an option of an additional nonsense mode, which could confuse many average users, whom did not have time to bury through 2 threads of 100+ posts.
My point is that you can have exactly what you want - an ability to see face dots to detect mesh issues - without need to have one additional possible combination of variables to confuse people with.
Yeah, that's probably undesirable. People are asking for select-through mode in solid shading to eliminate needles switching to xray, but I've never seen anyone asking to disable select-through in xray mode. I think it would be best to have it always on in Wireframe/Xray shading and the button could be hidden or disabled in Wire/Xraym mode, if that's possible. Other solution would be to toggle this feature independently for each shading mode, so that you could replicate current behaviour, where it's disabled in solid shading, but gets automatically enabled in Xray.
As for the button itself, I think it would be better to move it out of the area that's used for overlays and shading modes:
Also it is visible in object mode as well, even though it doesn't seem to do anything. Do you think selection occlusion could be enabled in object mode?
Maybe rename first checkbox to "Wire/Xray" since it also affects wireframe mode
But overall the build works well. Global toggle works with all selection modes I tested, keymap override also works without issues.
There is still the issue with facedot selection, I hope you can find out how to control it.
Got all of these except #4, Select Visible by Facedots in Non-xray. Calling it 'solid shading' is a little innaccurate, technically xray is available in solid shading, but we all know what we mean, solid = non-xray. Same goes for wire vs xray, they are basically synonymous, except that you can disable xray in wireframe shading. Going forward I'll do my best to stick with 'xray' and 'non-xray' even though it doesn't REALLY matter and it sounds kinda weird saying non-xray.
Anyways, the way Blender is written, Select by Facedots always does a Select Through.
I tried messing around with it, combining part of the select facedots with part of select visible stuff. Just guessing which specific lines of it actually do the facedot selecting. Then tried doing the opposite, different ways of combining the select occluded with the facedot stuff. Guessing which part actually does the occluded filtering. But no luck so far. Mostly just a slew of errors on build, and then if it DOES build it will crash when testing the desired select mode. Going to get a debug going, but not expecting it to magically tell me how to fix it.
In addition to those conditions above (minus #4) I have:
6. Select Through by Facedots in Non-Xray (the opposite of what I want, probably not useful)
7. Select Visible by Area in Xray (you can see the "occluded" faces or dots, but choose to not select if desired)
Also have these toggle options in header popover/dropdown for quality of life:
Will probably add these options as well:
3. Tool Setting Override - Will give Tool Setting priority unless keymap override is on (I'll add tool setting back, so if someone wants each select mode to have their own select-through or visible independently, they can have it)
4. Select Facedot / Face Center Auto (if facedots are on, it will select by facedot, if they're off it will select by area)
This is assuming I can get your condition #4 working. I think Select Visible by Facedot could be pretty handy, but like I said having trouble getting it to work. I might decide to just set that aside and come back for later, or PLEASE someone else figure that out. In the meantime I would restrict facedot selection to Xray only, and Non-xray facedots would work like they currently do, as mesh checking or whatever else.
I think so, I'm going to work on that once I get Facedot Selection working without Select Through happening.
If it looks like it's a bit much, like a separate topic, or if it's just unlikely to be done right now, I'll turn the button off in Object mode.
And finally, kio said that it was already processor intensive in the other topic. It is definitely heavier now, I imagine anyway. So I'll do some testing with that, I see all these #Debug Time things in the script that probably have something to do with testing that, but who knows. I can always just make a complex enough mesh that it takes a second to complete a selection, and then compare that with normal blender.
Sorry, it is a mistake. Description was right though.
It should represent default Blender behavior , so it should be
Fixed that . Thanks for pointing.
Wow, no kidding? I didn't even read the description just the conditions.
If nobody else really wants it, I'm not going to bother reinventing the wheel so to speak, as far as the way Blender deals with Facedot Selection only working as Select Through. I probably need some real knowledge of scripting to go into that stuff.
If I can't figure out how to do Select Visible by Facedots, by say the end of the weekend, I'm just going to move on and tidy things up.
Then I'll see about Object Mode Select Visible real quick. Probably something for later unless it's really straightforward.
No kidding.
I participating too many development treads (way more than I would like to), and always run several deadlines, so it is easy to make such mistakes for me.
That's why I provided descriptions. Kind a self-check for cases like that.
Indeed, such a mode will be hard to achieve and it is not looking necessary - wireframe/xray modes handles facedots selection type nicely.
It will also add system uncertainty (I can see facedots, it is solid shading mode, but I can't be sure if I am selecting by area or facedots) so let's keep the faces selection by the facedots exclusively for the wireframe/xray.
Can be achived with A.2 of summarizing post. Indeed, probably will be not used often since it requires super predictable geometry.
Sounds pretty much confusing) (I can see inner parts, but can't select them)
Tests are needed for both of them.
Please, be careful with options and overrides, otherwise block-schemes will be needed for getting predictable selection result.
Conciseness is a sign of good design.
Removed subscriber: @Senna
Added subscriber: @KloWorks
Added subscriber: @Hologram
There is no consensus on backface selection and facedots, because the discussion is about scrapping things that are being used by others. Blender shouldn't enforce a workflow upon people for the sake of a few who do not need it. Instead, it should provide the options for all, which includes the option not to use it! Since all combinations are requested, they should all be provided. The difficulty arises in coupling several options of display and selection to which each user has their own preferences, hence why these move to the preferences menu. Again any combination of select through, facedot, area selection and display settings are mentioned! The preferences should accompany setting selection (area/facedot & area type) and how these are activated by default when entering a certain display mode or selection mode. This is where the action scheme is put to use; to couple those modes that require multiple changes. Yet users can individually toggle the buttons and map them to shortcuts like the rest of the interface.
Required UI elements:
Under Overlays
Under Selection
By having the backface selection button in the interface, it shows the user that it's in use. The facedot selection and backface selection mode should be reflected in the icon itself, which changes per mode:
The dropdown with in the mockup by @Rawalanche with a checkbox for X-ray selection should state: facedot selection, this checkbox effectively switches between 1 and 2.
See: https://devtalk.blender.org/t/decoupling-x-ray-and-limit-selection-to-visible/3498/154 for the mockup.
Combined behaviour
Preferences
Under Input? Here you set your prefered behavior (the naming is more of an indication to the use than to what should be exposed in the preference settings UI). It should toggle multiple settings for display/selection. This is were the action scheme comes in.
Seeing as how complex the preferences and possible combinations of functions are, as indicated in the discussion length - and all options have to be available - there isn't really a way to avoid UI clutter. So having this in the preferences under its own collapsable header will suffice as long as the default settings are clear enough for any user and advanced users can have it set their way. Besides, productivity and speed is more important than a minimalist preferences window, with proper grouping it shouldn't even be considered as being cluthering. Having the options there, without redundancy is all that matters.
We all need the functionality, the devs might as well add the individual buttons and functions and do another round of user feedback on the preferences later, that way there is no longer any hold up on this highly demanded workflow fix, because of some minor UI and preference quirrel!
PS. I don't use fadedots, I would already be happy with a like toggle to ignore backface for selection with alt+b, while leaving the default backface selection in X-ray on. I can, however, see the use of facedots in picking faces with fill selection and/ or shortest path with both visible and occluded faces.
Please, take into account summarizing post so as not to repeat the discussions that were already six months ago.
Well, its time to update summarizing post. Previous one .
Left the only design option. Mentioned CP/WP selection types as well.
It is widespread behaviour in industry standards software.
The proposal is about
Possible Xray solutions:
A.1) Split Xray alpha settings for object and edit modes, since alpha = 1 is suitable only for edit mode, and satisfies LSTV - Limit Selection To Visible - demands.
A.2) Add the ability to fade with slider backfacing wiremesh display in Xray mode down to zero.
A.1 and A.2 will make select through with facedots selection mode available.
B.1) Add Xray/Wiremesh mode facedot center disabling option, what will make possible faces area selection for all non-picking selecting tools and methods,
separating the selection mode from the display mode.
Possible design:
better like this (because takes the same space, but makes option easily accessible, detectable and independent from Xray)
B.2) The option's behavior must satisfy the following conditions:
B.1 and B.2 will make select through mode detectable with no facedots display.
It is also possible to use it temporarily (switch it) or work constantly in that mode if it is needed, depending on a workflow type, because users who will use such option do not need regular Xray, in cases when Xray spoils the viewport.
Additional / Questionable / Offtop:
X.1) Ability to select visible with backface culling in shaded mode to satisfy selecting visible condition. An example of use is interior basemesh modeling.
X.2 ) Split Xray and Wireframe modes, since wireframe without Xray clones Flat shading mode, so it is more about visual style rather than shading mode. (questionable)
X.3) The reasons for separating the selection tools for the edit and object modes are not obvious.
X.4) Types of selection (CP - crossing - selecting everything that is crossed with selection border / WP - window - everything that is completely included in the border)
and directional selection (border from right to left is CP, and from left to right is WP)
@1D_Inc To move the discussion forward I would like to visualize the different design proposals. But I have a difficult time to understand the UI-implications of the different options.
Can you help me to roll out these proposals as UI components? I'm using this Figma document:
As far as i understand this statement, it does not require any change on ui-components, right?
To be honest, I don't understand neither the sentence nor the problem it's trying to solve.
I'm not quite sure, if I understand this design proposal. Does it show a toggle icon (with a tooltip) or a drop-down icon (with a misleading icon)?
@1D_Inc Do you already have a set of options/checkboxes etc in mind how B2 could look like?
Offtopic:
How set in stone is the LSTV? It doesn't work in object mode, so I assume it should be a convention/default rather than a guideline. Isn't this like the "right vs left selection" discussion all over again and eventually will become an option?
Will try my best.
The problem of this proposal is that it is have too many options spread around Blender, and it is dedicated only to facedots (it is not solving select through problem).
There will be a lot of issues - for example, it will allow to display facedots in Xray mode, but with no selection by facedots, which will be inconsistent, because of no ability to select backface geometry with picking types of selection, which will lead to uncertainty of the mode from its visual appearance.
If to add possible select through solution to this proposal, the complexity of the resulting system will be too high for comfortable work, because it will assume lots of tweaking of lots of options stored in different places.
The problem of current realization is that setup that satisfying LSTV demands in edit mode (turning Xray on and setting alpha to 1) is useless in object mode, so there is need to constantly tweak Xray alpha slider value between object and edit modes.
There should be two separate Xray alpha sliders - separate for object mode and edit mode to have LSTV in edit mode satisfied and have Xray display in object mode untouched.
In Xray mode + alpha=1 backfacing geometry is drawn on top of the model.
The ability to fade backface geometry display down to zero will bring the ability to select through without drawing backface geometry on top of the shaded model.
This will bring the ability of select through with facedots display, but with no backface geometry display distraction.
It is a single icon with a tooltip temporarily called "Option".
Yes. It is that one single icon that was shown in B.1
"Option" from the table is that one "Option" from B.1
Technically, our proposal is designed to solve select through problem with a single button, including satisfying all critical use cases (table) and avoiding mode uncertainty or system complexity issues.
Just to clarify: The title for this icon would be something like...
(Or if inverted "Allow face selection outside dots")
I'm sure there must be better labels for it.
To be honest I personally would disable this option and can't see any use case to switch it on again.
It sounds like investing a lot of prominent screen space for a user preferences that is unlikely to change frequently.
This comment was removed by @Hologram
@1D_Inc I think this proposal is overcomplicating a quite simple request, allow me to explain: select through is simple, in terms of UI it could be as much as toggling it or have it mapped to a modifier key during selection. The issue at hand is that some people resist, because of the Limit Selection To Visible (LSTV) paradigm which is then used to bring up all sorts of display discussions, which in turn brings up facedot display and this brings up facedot selection vs area selection. So the entire thing is a cascading issue.
The overall proposal is actually about four things: display overlays (facedot), selection modes, select through and selection shading/display mode. Selection display mode is also a form of viewport overlay and is shown upon entering a selection command.
Transparent selection highlight, which unlike 4A and 4B is applied after selection (front and backface selection are both highlighted, this requires any occluded geometry that is selected to display through the geometry in front)
Object and edit mode could be set to behave similarly, so what I have mentioned here applies to both. You could have the same "Selection shading/ display mode in viewport" options for Edit and Object mode to make them behave independently, with the By active shading/ display mode as object mode default (which is the way it is currently and which is what is requested as desired method for select through apart from the facedot and window/crossing selection).
I would opt to put the "Selection shading/ display mode in viewport" options on buttons and hide the X-ray mode slider when the "By active shading/ display mode" is ticked.
The fact that LSTV is a paradigm in Blender, yet a proven method elsewhere, sounds to me like it's time for a paradigm change. With the options I presented above, LSTV can always be enabled anyways (and perhaps could remain so by default?), no big deal.
The X-ray button toggles select through: Yes/No, if the button is blue, select through is on. The icon itself could change to reflect the selection mode with facedots,etc. (but this is a fairly minor thing).
The dropdown should show: Facedot selection and "4. Selection shading/ active display mode".
However, in other packages, selection mode (Window/Crossing) has a distinct button to set the Window/ Crossing mode, such a button could live alongside the other selection buttons, to the right of "intersect existing selection"
Perhaps the facedot selection toggle could also reside there instead, on the 'selection bar'
In principle, facedot selection should toggle the facedot overlay for apparent reasons and would disable the use of the facedot display overlay. However, facedot display could also work independently without the facedots aiding in selection (in mesh inspection mode), this requires toggling the overlay manually from the overlay dropdown.
Optionally
For clarity to differentiate between facedot overlay without facedot selection and facedot overlay with facedot selection, next to displaying an icon for selection mode, the facedot selection mode could affect the facedot overlay.
For instance, the facedots overlay could have opacity in the former and have no opacity in the latter. Other alternatives are: changing the facedot icon in the viewport (solid/hollow dot) and/or resizing the facedot. This fixes select through with area selection in X-ray display mode without overcomplicating (UI) development regarding how this or that mode could be avoided. Display modes should work regardless of selection method and overlays are just overlays, right?
I think my proposal satisfies all of these now.
Am I correct to state that this requires a "do not display backfaces" button?
This one should be in the preferences; here you need to allow for the Hybrid Window/Crossing mode, to avoid confusion. I think that, just like in other packages, it makes more sense to just toggle between Window/Crossing in the interface, unless the Hybrid mode is checked in the preferences, which may remove the button from the interface if checked. The hybrid mode is enabled for a valid user reason in that case.
This is a wrong assumption, how often does one change these settings? You either change the shading mode altogether without affecting selection, or you change selection display, which is more of a preference that remains most likely untouched. Similarly, facedot selection (those who use this probably won't touch area selection all that much and vice versa), circumstantial Window/Crossing (again, no issue in Max, just tick a button) and select trough are all single toggles. Since there are four interrelated topics contained in one request, it does not mean that all of these have one consistent logical placing in the menus as they have different functionality. From this follows it would be illogical to everyone — apart from those who have read through this design task and other forum threads. Selection options should be in a selection grouping, display overlays in display overlays, etc. This makes for a clear mental map of the interface. And again, you probably won't tweak multiple of these settings if at all.
**Offtopic
What I like about agile development is it gives users the option to preview and use new functionality even though it has not yet fully chrystalised in terms of its interface. The interface may change eventually, that's okay, we atleast we have the functionality. Blender's development seems to be the reverse on many very, very simple and basic things. Instead of rolling out a simple toggle for enabling backface selection — even though the selection isn't snown in the viewport, industry proven, etc.... and an entirely different discussion — it seems as though every tiny thing should be conceived first, yet, you won't know how everything ends up if you don't try it out first as well. Is focussing on a clean interface first and foremost hampering development of missing functionality, definitely?
It is analogous to having to travel from A to B by bus and you have to be on B at a certain time, but then the busdriver is not showing, because he couldn't decide on whether to take the yellow or the blue bus.
Lots of users need this really basic functionality, yet all that happens is "Look at the interface", well, that certainly doesn't solve any modeling issues!
The adiditon of these small things is actually what would make Blender more industry ready imo.//
Here is a workflow issue - if facedots selection is controlled separately from shading mode, there is need to constantly switch both shading mode and facedot display/selection mode every single time, which lead to serious slowdown.
Shading-sensitive facedots behaviour based workflow is faster, this is critical for messy meshes editing and fixing.
This is balanced Blender mechanics which is commonly used to outperform Max and Maya workflow speed limitations.
I am not sure what is the goal of this type of behaviour. Selection doesn't affect any display mode, modes are affecting selection.
Is it about displaying the selected geometry, when unselected geometry covers selected?
It doesn't work like that. There is not only goal to satisfy some conditions, but, actually, exclude all unnecessary.
You can try to make the complete map of your proposal with all possible proposed options states (permutations) to be sure that your design is clean at the same level, and all modes are easy to reach at the same rate.
X-ray button toggles Xray mode, it is different from select through.
Mode certainty - the ability to read current mode from visual appearance - is a major thing in terms of usability. This cancels dropdowns and hidden settings for the most relevant functions.
Workflow demands is the only reason for any kind of paradigm change.
This button cannot be placed here, because it is common behaviour setting, it can be placed in Preferences.
It is about the ability to select visible geometry which is visible through backface culling (when is turned on) and all faces normals are flipped inside (interior modeling case).
I guess I forget to mention that toggling the facedot selection mode would additionally enable the facedot display mode. So it is a single button to control, whereas the facedot display overlay CAN be toggled seperately.
Sure, in principle selection shouldn't affect display mode, unless you want to select through. In that case, (regardless of how select through was enabled) to satisfy LSTV, the selection command would automatically display the active object(s) in edit mode either in X-ray (4B, like Cirno's Box select https://blenderartists.org/t/box-select-x-ray/1212316/23?u=justo) or by highlighting the occluced selection through the mesh (4C). However, if LSTV is dropped, then no changes to the display mode would have to occur (4A).
That is indeed the case for 4C.
Excuse me, when I referred to the X-ray button, I meant the select through button.... That's confusing indeed.
That's the idea behind using the Select through button with a blue indication of it being on and icon changes upon facedot selection.
Wouldn't it make more sense to (also) include it in the "selection bar"? I find myself changing the mode every now and then in other programs, having to do so in the preferences is a bit of a hassle imo.
You could put the default behavior in the preferences and override it with the button in the selection bar, for instance.
I can have a look at this later, in case anyone has any objections with my proposal please let me know so I can incorporate that in advance.
Can you, please, clarify what it refers to from all this tread?
Yes, but I didn't found any of them in the figma document (https://www.figma.com/file/bseq6jLsv7njvo0mNGvYP2/X-Ray-Designs?node-id=6%3A148).
Is this document related to you?
Trying to analyze a propozal.
So, there will be a
At least 5 interconnected toggles for facedots? Object mode facedots display? That looks like very over complicated system, close to inconsistent feature set..
We perform a fairly wide range of workflows and it's hard to imagine a workflow that would require so many possible combinations.
That was design flaw, it was reported and confirmed (https://developer.blender.org/T78482)
I think fixing this would remove the need for the entire Selection shading/ display mode in viewport option.
Placing in selection bar was discussed some time ago, it is not available for quick types of selection (B hotkey).
Also, directional selection type (left - CP, right - WP) solves the need for such kind of button for many apps, eliminating the need for frequent switching.
Please keep in mind avoiding mentioning proprietary software.
https://lists.blender.org/pipermail/bf-committers/2020-July/050616.html
The complete UI mockup (including both facedots and select through solutions) is nice point to start from. At the moment it is hard to imagine how this proposal should look and work.
It is another user's interpretation of my proposal, but does not cover it entirely.
There will be:
These buttons will be at the same location regardless of shading mode.
Indeed, this would solve the display proposals of my end, great!
In case this mode is set in the preferences, there is no need for a select Window/ Crossing button, however, when set to either Window or Crossing, there is. In that case it has to be readily available with a single click, rather than an option in the preferences.
Anyways, if Box select itself is the exception in being a transparent command with no options of its own, would showing the selection options either in the toolbar like any other selection mode be an issue? A counter argument is that it may be considered as "flashing", because the UI changes a bit during selection (from command UI to selection UI and back to command UI), in that case, the there could be a box select options button in the selection bar, which is only a single button change. I would rather change the exception to the rule (boxselection) than the rule (most efficient button placement for quick access in the selection bar instead of preferences) to the exception.
Actually, while you cannot click on the toolbar with box selection active, if you could, there already is a place in the interface that would allow for consistent select window/crossing option:
Here's the option tree:
I'll make a sketch UI mock-up when I've got some more time, should be done by tomorrow.
PS. removed names of proprietary software in my posts.
Okay. There is no hurry, take your time.
Here are the mockups, the only setting that should be in preferences is whether someone wants to have Window/Crossing based on direction or based on the toggle in the selection bar.
The issue for box mode selection would be solved by allowing to click on the settings bar, in which there is already a button in the current UI to change selection for commands that make use of selection:
A button for facedot display overlay:
I added an optional slider for selection highlight strength, I don't really know how useful this would be. It may help with large selections perhaps.
For the rest, refer to the option tree to see the modes:
Thank you!
I will try to analyze and will give feedback later.
First of all, I think you should change "select backfacing/frontfacing" to "select visible/select through" in your proposal to avoid confusion. Backfacing/frontfacing refers to the normal direction of a face in relation to the camera and this terminology is already used for specific things like "Backface Culling". This task is about selecting occluded geometry in solid shading, irrespective of its normal direction. There is also a separate issue with backface selection that needs to be fixed, so it's important not to mix up these terms.
I like the idea to change the appearance of the button to show that facedot selection is enabled, it helps to save a bit of space.
But facedot display controls in the Overlays menu should look like in @lcas build:
There needs to be an ability to control facedot overlay separately for solid shading and xray/wireframe to replicate current behaviour. Same for 'Select Facedots' toggle in your proposal.
But overall I think it's a solid design that covers pretty much all of the useful features.
Sure thing, I fully agree with you on this, I have used the terms interchangeably, because of habit (ignore backfacing is what this is called in the software I use), but Select visible/ Select through makes more sense.
So the button for select facedots would then be:
Select Facedots (header)
X-ray | Solid (two buttons)
E: This means changing display mode switches selection mode (as well as the icon and facedot display overlay) depending on the settings. Fair enough.
Interesting double-binary solution.
The proposal is much more clear now.
I think replicating current behavior can be achieved by making this option dependent from xray (like xray is dependent from wireframe - when wireframe turns on it turns on xray, remembering its setting)
This way system will turn to triple-binary but replicating current behavior can be achieved with proper defaults, because I have a feeling that adding special option instead of it will cancel out the entire system, making its behavior unclear.
I need to build relevancy map from this proposal to figure it out and form a question list.
I don't want to make the proposal any more complicated than it already is — and it may be partially off-topic — but a though passed my mind about also adding a button with "Enumerate" next to the proposed select through button in the header ("selection bar").
The idea here is that in CAD programs, there is always an option to turn on select from a list in case multiple objects reside under the cursor upon clicking. It is also a form of selecting through (albeit in object mode) and I think that it makes sense to add this functionality to all the selection tools when used to click, rather than dragging a window/lasso/circle. That's what the enumerate button toggles for the tweak tool out of the box.
The "enumerate" button should initiate this functionality upon single click selection in case there are multiple objects behind the cursor:
The button itself should look like a list icon, pretty self explanatory imo.
Sorry, but I am in the middle of the deadline, can't even start to work with it.
Even automerge button, that indicates if your mesh be collapsed on the next move, was removed, so you have to guess this all the time.
This button is not used widely enough to fit there.
You can call up the enumerate menu by alt-clicking on overlapping objects, so what's the point to have a button for that in the UI?
I am aware of that, it is just a matter of exposing obscured functionality in a way that may be consistent in the UI. However, currently the enumerate menu only shows in the tweak tool and not with a brief click in any other selection tool. Blender should default to the tweak tool in any brief click, or emulate that behavior with the enumerate menu whether hotkeyed or in the UI, but that's a different topic perhaps. I thought I might bring it up since it is sort of related, atleast for people with a CAD background.
Well, I am an architect with deep CAD background (AuroCAD user and AutoLISP developer with more than 1000 lisps written), and I am familiar with this functionality, but it is way more suitable for 2D rather than 3D, because 3D usually is more complex to navigate.
In practice we work with too much overloaded models to use that kind of selection, because it makes too long lists for comfortable work.
We use QCD slots system for navigating complex 3D structures (demo in the end)
https://youtu.be/yiti0xWO7Wg
Abscence of alt+clicks for non-tweak tools looks like an issue though.
Maybe, they was not mapped yet?
@1D_Inc
You cannot currently map the alt-clicks in the keymap for non-tweak tools.
But yeah, enumeration is not the best on heavy scenes.
Trying to analyze propozal. What is the difference between those two options?
What is that issue? It would be nice to be described or mentioned.
They are the same, I didn't know this was there by default, scrap mine. I'm still fairly new to blender, so that's just a silly mistake on my part.
The issue is, when you are in box select mode (the temporary one with the large cursor) you are unable to change selection settings. This is because it is a transparent command that is executed while another command is active. With other selection commands, this selection menu is already under the exact same dropdown. So in order for the temporary selection tools to edit selection settings, allowing to use the option bar in the header would fix this. You can see for yourself, with box select active, you can only click in the viewport, but not on the header. And this option dropdown is in the interface and it would therefore make sense to also use it for box select.
Removed subscriber: @KloWorks
Added subscriber: @Adam.S
I saw the discussion about this and people seems to disagree where it should be.
this feature can either be exclusive to mesh editing only like it used to be in 2.7x or include the other modes.
It's position is in the shading Piemenu just like "only Locations" for the pivot and also somewhere in the viewport, maybe next to the options in the topbar.
Added subscriber: @APEC
Sorry if I wrong with topic theme...
but Backface Calling and Select Through it's a must have feature for selecting, at least faces.
Example:
Try to select Spheres faces...
You say: Turn on X-Ray... Ok
Better? Try to select now =)
Yes, you can hide 100500 overlapping and finally reach exact face/s.
But what if you need to see whole scene? In this case you need to hide all unwanted, select needed face/s, then invert selection, then unhide all and invert again to keep that selected face/s.
Inconvinient? Live with it...
Added:
Already listed as X.1
Added subscriber: @fengxc
From Maya to blender, I spent a day to find a way to separate the Xray display from the back selection, and the Xray mode selection can be directly selected without selecting the center point. Then I found the thread and was surprised to find that such an important modeling function has not yet appeared in the latest version. As a character art, I usually use Xray ray to check Whether the equipment matches the character's body or not, Maya attributes wireframe display, entity display, entity + wireframe display and Xray display as one category. Whether to start back selection and put it under the selection tool
You can check summarizing post .