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.

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?

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.

@Debuk (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.

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.

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 T73479#861717, @Debuk (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 T73479#861818, @Oskar (Oskar) wrote:

From my point of view (Maya old-timer) a simple checkbox in the preferences

In T73479#861828, @Peeter Maimik (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 T73479#861687, @William Reynish (billreynish) 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.

In T73479#861995, @CobraA (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.

@Oskar (Oskar) @Peeter Maimik (z01ks) @CobraA (CobraA) @Paul Kotelevets (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.

In T73479#862023, @ThinkingPolygons (ThinkingPolygons) wrote:

@Oskar (Oskar) @Peeter Maimik (z01ks) @CobraA (CobraA) @Paul Kotelevets (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.

@William Reynish (billreynish) Maybe we can just call it with a different name like "View-based selection" or "Only select visible elements" as @ThinkingPolygons (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 (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 T73479#862061, @Oskar (Oskar) 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 T73479#862061, @Oskar (Oskar) wrote:

@CobraA (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.

In T73479#862148, @Stanislav Blinov (radcapricorn) 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 T73479#862002, @William Reynish (billreynish) 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 T73479#861847, @TheRedWaxPolice (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 T73479#861847, @TheRedWaxPolice (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 T73479#862030, @CobraA (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 @Stanislav Blinov (radcapricorn) describes the problems with the current solution pretty well.
I fully agree with it.

In T73479#862062, @Paul Kotelevets (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 (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.

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 (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 T73479#862234, @Stanislav Blinov (radcapricorn) 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 T73479#862244, @Debuk (Debuk) wrote:

@CobraA (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 T73479#862245, @Paul Kotelevets (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).

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.

In T73479#862253, @CobraA (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.

@Debuk (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.

Sure, sorry for that.

In T73479#862301, @Stanislav Blinov (radcapricorn) 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.

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 (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 T64281: 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 T73479#861538, @Paul Kotelevets (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 T73479#861699, @Serhat (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 T73479#861717, @Debuk (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 T73479#861727, @Debuk (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 T73479#861818, @Oskar (Oskar) 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 T73479#861847, @TheRedWaxPolice (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 T73479#861995, @CobraA (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 T73479#862023, @ThinkingPolygons (ThinkingPolygons) wrote:

@Oskar (Oskar) @Peeter Maimik (z01ks) @CobraA (CobraA) @Paul Kotelevets (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 T73479#862148, @Stanislav Blinov (radcapricorn) 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 T73479#862148, @Stanislav Blinov (radcapricorn) 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 T73479#862402, @Campbell Barton (campbellbarton) wrote:

In T73479#862148, @Stanislav Blinov (radcapricorn) 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 T73479#862441, @Stanislav Blinov (radcapricorn) wrote:

In T73479#862402, @Campbell Barton (campbellbarton) wrote:

In T73479#862148, @Stanislav Blinov (radcapricorn) 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.

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

In T73479#862402, @Campbell Barton (campbellbarton) 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.

@Campbell Barton (campbellbarton) 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 @Paul Kotelevets (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:

@William Reynish (billreynish)

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..

In T73479#862583, @Benjamin Sauder (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 @Paul Kotelevets (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 T73479#862583, @Benjamin Sauder (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.

In T73479#862583, @Benjamin Sauder (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.

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 @Benjamin Sauder (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 T73479#862402, @Campbell Barton (campbellbarton) 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 T73479#862641, @William Reynish (billreynish) 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 @Benjamin Sauder (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 @Paul Kotelevets (1D_Inc)'s self-important "reservations", predictable geometry is not at all that uncommon.

In T73479#862641, @William Reynish (billreynish) wrote:

In T73479#862583, @Benjamin Sauder (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 @William Reynish (billreynish) : 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.

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.

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.

In T73479#863009, @Debuk (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.

@Paul Kotelevets (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 @Paul Kotelevets (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 T73479#863017, @Paul Kotelevets (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 (CobraA), @Campbell Barton (campbellbarton) and @Stanislav Blinov (radcapricorn), (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 @Stanislav Blinov (radcapricorn) 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 @Campbell Barton (campbellbarton) , what of these directions is more favored.

( Edit: The DarkenedLineOverdraw Checkbox and FaceDots Checkbox could be combined, no need to have them separate)

In T73479#863407, @Debuk (Debuk) wrote:

Hi @Paul Kotelevets (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.

In T73479#863495, @CobraA (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.

In T73479#863428, @Paul Kotelevets (1D_Inc) wrote:

In T73479#863407, @Debuk (Debuk) wrote:

Hi @Paul Kotelevets (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

In T73479#864447, @Paul Kotelevets (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.

In T73479#865440, @Asher (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.