In T73479#951298, @Pawel Franitza (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?

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.

In T73479#952163, @slowburn (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

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

In T73479#952915, @Thomas Mann (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)

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.

In T73479#953030, @slowburn (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).

In T73479#953125, @Ludvik Koutny (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.

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.

In T73479#953553, @slowburn (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.

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 T73479#977218, @Lukas Sneyd (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

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

In T73479#977218, @Lukas Sneyd (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 @Lukas Sneyd (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 T73479#977445, @Ludvik Koutny (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 T73479#977466, @slowburn (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.

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

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

In T73479#977445, @Ludvik Koutny (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 T73479#977897, @Lukas Sneyd (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:

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 T73479#926945, @Paul Kotelevets (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 T73479#978376, @slowburn (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 T73479#981138, @Lukas Sneyd (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

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.

In T73479#981152, @Lukas Sneyd (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.

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 @Ludvik Koutny (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 T73479#995849, @Hologram (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.

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

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:

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)

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

@Paul Kotelevets (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 T73479#996345, @Thomas Mann (pixtur) wrote:

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

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

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

@Paul Kotelevets (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 T73479#996005, @Paul Kotelevets (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
   1. On
   2. Off

2. Selection modes
   1. Facedot selection (requires 1A)
   2. Window selection (everything fully within the selection window is selected = Area selection)
   3. Crossing selection (everything touched by the selection window is selected = Area selection)
   4. Hybrid selection (combination of Window selection and crossing selection, which is dependent on the mouse gesture direction = Area selection)

3. Select backfacing/ Select occluded
   1. Yes
   2. No

4. Selection shading/ display mode in viewport
   1. By active shading/ display mode, selection does not affect the display mode (i.e. no X-ray display when in solid shading)
   2. X-ray display
   3. 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"

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 T73479#996441, @Paul Kotelevets (1D_Inc) wrote:

In T73479#996345, @Thomas Mann (pixtur) wrote:

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

In T73479#996771, @Hologram (Hologram) wrote:

1. Facedot display overlay
   1. On
   2. Off

2. Selection modes
   1. Facedot selection (requires 1A)
   2. 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).

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

In T73479#996771, @Hologram (Hologram) wrote:

1. Facedot display overlay
   1. On
   2. Off

2. Selection modes
   1. Facedot selection (requires 1A)
   2. 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.

In T73479#996633, @Thomas Mann (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 T73479#997179, @Hologram (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.

In T73479#998663, @Paul Kotelevets (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 T73479#998832, @Hologram (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:

In T73479#999322, @Hologram (Hologram) wrote:

Here are the mockups

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 @Lukas Sneyd (lcas) build:

In T73479#999726, @slowburn (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.

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:

In T73479#1002667, @Hologram (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?

In T73479#1003693, @slowburn (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?

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

In T73479#999322, @Hologram (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.

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

In T73479#999322, @Hologram (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.

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

In T73479#1050405, @Eugene Du (APEC) wrote:

Sorry if I wrong with topic theme...

Already listed as X.1

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

In T73479#1074302, @fengxc (fengxc) wrote:

From Maya to blender,

You can check summarizing post.

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

In T73479#1074302, @fengxc (fengxc) wrote:

From Maya to blender,

You can check summarizing post.

Thank you for your work and hope blender will pay attention to this thread

Hi all-- first time Blender developer here. I had an artist friend complain about the lack of select-through behavior (something he claimed existed in 2.7 and prior), so I figured I'd take a stab at implementing this as a way to expose myself to the Blender codebase. I was pleasantly surprised when I found a task for this already existed, though it seems like the requirements are quite complicated :)

I agree with earlier statements (particularly @Hologram (Hologram)'s) that this should be a fairly simple toggle. While I think being able to see what obscured elements you've selected is useful, I personally wouldn't consider it a minimum requirement for this feature. Providing an option to enable display of selected obscured elements might be a useful addition at a later date, though.

My current implementation adds an additional button (and hotkey) to the Mesh Edit Tool, next to the component type selection toggles:

I figure having the toggle as a top-level button rather than burying it in a menu reduces or eliminates the need for modal mouse icons to indicate which mode the user is in for every selection method (box, lasso, etc.). Certainly happy to move it into the Select menu if that's preferred.

The interaction with X-ray/Wireframe is simple: If you've enabled Select-Through, OR you're in Wireframe/X-ray, you'll be able to select obscured components.

I know I may be jumping the gun by providing an implementation before the design is hashed out, but as before--this seems like a simple feature and I've seen enough people on the internet requesting it that I couldn't help myself :P

In T73479#1104662, @Stephen Coan (Scoan) wrote:

Hi all-- first time Blender developer here. I had an artist friend complain about the lack of select-through behavior (something he claimed existed in 2.7 and prior), so I figured I'd take a stab at implementing this as a way to expose myself to the Blender codebase. I was pleasantly surprised when I found a task for this already existed, though it seems like the requirements are quite complicated :)

I agree with earlier statements (particularly @Hologram (Hologram)'s) that this should be a fairly simple toggle. While I think being able to see what obscured elements you've selected is useful, I personally wouldn't consider it a minimum requirement for this feature. Providing an option to enable display of selected obscured elements might be a useful addition at a later date, though.

My current implementation adds an additional button (and hotkey) to the Mesh Edit Tool, next to the component type selection toggles:

I figure having the toggle as a top-level button rather than burying it in a menu reduces or eliminates the need for modal mouse icons to indicate which mode the user is in for every selection method (box, lasso, etc.). Certainly happy to move it into the Select menu if that's preferred.

The interaction with X-ray/Wireframe is simple: If you've enabled Select-Through, OR you're in Wireframe/X-ray, you'll be able to select obscured components.

I know I may be jumping the gun by providing an implementation before the design is hashed out, but as before--this seems like a simple feature and I've seen enough people on the internet requesting it that I couldn't help myself :P

It does not belong there, that's where the mesh elements modes are. If it's going to be an additional button, it belongs somewhere next to the current Xray button. You've also not considered all the possible combinations of the modes. I'd suggest you quickly read through the posts above to see what others suggested, as it shows how many combinations and details are there to consider.

Also, just a warning: Sooner or later, a guy of the name "Paul Kotelevets" will show up here, forcing you some sort of "summarizing post". Just beware that it's not in any way a summary of the community opinions in here. It's just a subjective opinion of his, and has a same value as any other individual opinion in here. It does not, in any way, represent any community consensus.

In T73479#1104662, @Stephen Coan (Scoan) wrote:

My current implementation adds an additional button (and hotkey) to the Mesh Edit Tool, next to the component type selection toggles:

Hi,
Have you a custom build or addon to test this feature?
I'm afraid it's the same as "Box Select X-Ray" or "Border Occlude". They are good but not handle this exaption

In T73479#1050405, @Eugene Du (APEC) wrote:

Try to select Spheres faces...

You say: Turn on X-Ray... Ok

In T73479#1104662, @Stephen Coan (Scoan) wrote:

Hi all-- first time Blender developer here. I had an artist friend complain about the lack of select-through behavior (something he claimed existed in 2.7 and prior), so I figured I'd take a stab at implementing this as a way to expose myself to the Blender codebase. I was pleasantly surprised when I found a task for this already existed, though it seems like the requirements are quite complicated :)

HI. Nice to meet you here =)
Indeed, this task seems to have pretty much simple single button solution. However this topic is very controversial and already created several holywars, so better be careful with that.
The main design problem was reconciling behavior between combinations of different display options (wireframe, Xray, overlays, facedots, etc) to satisfy all the necessary modes and avoid strange modes, so we tried to design a easy-to-read table that could possibly solve an issue in a minimalistic and safe way.

In T73479#1104719, @Ludvik Koutny (rawalanche) wrote:

In T73479#1104662, @Stephen Coan (Scoan) wrote:

My current implementation adds an additional button (and hotkey) to the Mesh Edit Tool, next to the component type selection toggles:

It does not belong there...

I agree. The selection is related to Blender's display mode, so we suggested placing it next to the shading modes.

In T73479#1104778, @Eugene Du (APEC) wrote:

Have you a custom build or addon to test this feature?

Yes, there have already been many design implementations, it is important to have a build to test the behaviour design, since it is core development.

In T73479#1104778, @Eugene Du (APEC) wrote:

In T73479#1104662, @Stephen Coan (Scoan) wrote:

My current implementation adds an additional button (and hotkey) to the Mesh Edit Tool, next to the component type selection toggles:

Hi,
Have you a custom build or addon to test this feature?
I'm afraid it's the same as "Box Select X-Ray" or "Border Occlude". They are good but not handle this exaption

In T73479#1050405, @Eugene Du (APEC) wrote:

Try to select Spheres faces...

You say: Turn on X-Ray... Ok

Is that one object with two mesh pieces/islands or is that two separate objects?

Genuine curiosity: Is there any other program that can actually do a select-through box select that only grabs the sphere's faces? (A simple yes/no will suffice since it's verboten to mention other software by name here.)

To be honest I wouldn't even waste my time trying to box select that sphere. This feels like overcomplication. Select one face of the sphere and then select linked to get only the sphere; that will work regardless of if it's one object with two mesh pieces or two different objects that are both in edit mode. The only way it won't work is if the sphere is physically connected to the cube as one mesh piece. If you only want some of the sphere faces then select link won't do the job, of course, but at that point you should be working with your camera inside the cube and manually selecting the parts you need to work with if it's one mesh, and if it's two objects then just work on the sphere without having other objects in edit mode so the selection will only affect the sphere.

In T73479#1105417, @Chris Kohl (ckohl_art) wrote:

Is that one object with two mesh pieces/islands or is that two separate objects?

Genuine curiosity: Is there any other program that can actually do a select-through box select that only grabs the sphere's faces? (A simple yes/no will suffice since it's verboten to mention other software by name here.)

I'll write you PM on blenderartists.org if you don't mind, with short video where I can do this kind of selection in other program.

! In T73479#1105419, @Eugene Du (APEC) wrote:
I'll write you PM on blenderartists.org if you don't mind, with short video where I can do this kind of selection in other program.

Ahhh, now I understand. What APEC is describing is "Ignore Backfaces During Selection" which is similar to--but distinct from--"Select Through". (Which Paul listed as X.1)

This might be tangential to Select Through but for the people who were confused like me here's a video I faked of a simple case for what this would look like in Blender. The cube's normals are pointed inside, X-Ray is off, and Backface Culling is on.

The first part shows how Blender works now ("Select what you see" or "Select Visible") with the selection tools selecting the faces of the cube that are closest to the camera because they are between the camera and the other faces that are internal to the model (the sphere and the cube's opposite sides). Blender counts them as "visible" even though backface culling is enabled and their normals are facing away from the camera.

The second part shows what "Select what you see, but ignore backfaces" would look like (APEC's internal modeling use case). The cube's faces that are closest to the camera are ignored because backface culling is on. The sphere's faces and the opposite faces of the cube still respect "Select what you see" and the sphere occludes selection of the cube faces behind it.

All of the above would also apply to edges and vertices, of course.

Wow, a very nice mockup. How did you made that?
(Yes, it was listed as X.1, that's why I am listing them - otherwise discussion often goes in a circle)

I am thinking of updating the summarizing post mentioning a proposal by Hologram, your mockup to X.1 and a solution for X.4 which is currently being developed in parallel.

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

Wow, a very nice mockup. How did you made that?

I cut the cube in half and then halfway through the video I turned on wireframe viewport display on the front half to make it look like it was in edit mode, then deselected the front half so only the back half was actually in edit mode.

What's the possible solution to X.4?

In T73479#1105525, @Chris Kohl (ckohl_art) wrote:

! In T73479#1105419, @Eugene Du (APEC) wrote:
I'll write you PM on blenderartists.org if you don't mind, with short video where I can do this kind of selection in other program.

Ahhh, now I understand. What APEC is describing is "Ignore Backfaces During Selection" which is similar to--but distinct from--"Select Through". (Which Paul listed as X.1)

This might be tangential to Select Through but for the people who were confused like me here's a video I faked of a simple case for what this would look like in Blender. The cube's normals are pointed inside, X-Ray is off, and Backface Culling is on.

The first part shows how Blender works now ("Select what you see" or "Select Visible") with the selection tools selecting the faces of the cube that are closest to the camera because they are between the camera and the other faces that are internal to the model (the sphere and the cube's opposite sides). Blender counts them as "visible" even though backface culling is enabled and their normals are facing away from the camera.

The second part shows what "Select what you see, but ignore backfaces" would look like (APEC's internal modeling use case). The cube's faces that are closest to the camera are ignored because backface culling is on. The sphere's faces and the opposite faces of the cube still respect "Select what you see" and the sphere occludes selection of the cube faces behind it.

All of the above would also apply to edges and vertices, of course.

Great job finding one more, even more inconsistent and confusing mode of selection useful for less than 1% of cases. It'd really be awesome if we had even more chaos in already very chaotic selection modes :)

Meanwhile there's all the other mainstream 3D software where there's just one or two selection modes, and THEY JUST WORK! And since they work, no people in their communities are requesting any changes to them, or new modes, since no one needs any more modes. Yet here, in Blender land, we still don't have functional selection implemented, and every second they are broken, more and more people spawn their "new solutions" which just add into the ever growing pool of chaos.

In T73479#1105631, @Ludvik Koutny (rawalanche) wrote:

Great job finding one more, even more inconsistent and confusing mode of selection useful for less than 1% of cases. It'd really be awesome if we had even more chaos in already very chaotic selection modes :)

It's not so confusing as you think
just a one checkbox. Or is it?

In T73479#1105710, @Eugene Du (APEC) wrote:

In T73479#1105631, @Ludvik Koutny (rawalanche) wrote:

Great job finding one more, even more inconsistent and confusing mode of selection useful for less than 1% of cases. It'd really be awesome if we had even more chaos in already very chaotic selection modes :)

It's not so confusing as you think
just a one checkbox. Or is it?

The entire popover is dedicated to viewport shading. It's the shading popover, meaning it affects how the scene looks. There's absolutely nothing indicating it should contain any settings that affect how selection should work.

There's already like 5 different selection modes people want, introducing this toggle would multiply all of them by 2, so we'd end up with roughly 10 different selection behaviors based on terribly messy combination of different switches scattered on multiple places across the user interface. That's exactly what a hell looks like.

In T73479#1105727, @Ludvik Koutny (rawalanche) wrote:

The entire popover is dedicated to viewport shading.

It can be anywhere, even hidden in keymap option, like this one (for what is this? any one use it?)

In T73479#1105738, @Eugene Du (APEC) wrote:

In T73479#1105727, @Ludvik Koutny (rawalanche) wrote:

The entire popover is dedicated to viewport shading.

It can be anywhere, even hidden in keymap option, like this one (for what is this? any one use it?)

I do not insist on developing it. I am more than sure that this will have to be done by ordinary users in the form of addons, because the developers are busy with other urgent matters.

It's not possible to do it in a form of addon because it requires changes on C/C++ level and Blender has no C/C++ API whatsoever.

In T73479#1106257, @Ludvik Koutny (rawalanche) wrote:

In T73479#1105738, @Eugene Du (APEC) wrote:

In T73479#1105727, @Ludvik Koutny (rawalanche) wrote:

The entire popover is dedicated to viewport shading.

It can be anywhere, even hidden in keymap option, like this one (for what is this? any one use it?)

I do not insist on developing it. I am more than sure that this will have to be done by ordinary users in the form of addons, because the developers are busy with other urgent matters.

It's not possible to do it in a form of addon because it requires changes on C/C++ level and Blender has no C/C++ API whatsoever.

Besides that, most people seem to overlook that Python is slower than C. In order for Blender to compete with other packages it needs better performance (to be useful for large scenes and heavy meshes at the very least). Now that my PC is in repairs and I'm temporarily using a new €600 laptop I notice lag in all sorts of areas that I wasn't even aware of the performance hits. The Box select Xray shows a delay in object mode while selecting 6 default cubes (without any modifications).
That's just unacceptable, imo missing mesh modeling functionality should be prioritised over geometry nodes...