Perhaps one alternative option could be to show Xray mode in the shading button? Like dashing the icon for when it is in Xray mode and have a 50% opacity fill as opposed to pure white.
Or, better yet, Auto Xray could be shown like Xray, but whereas Xray gets a fully blue fill of the square button icon in the header (default theme), Auto Xray would only have a blue outline of the square (so the button is only partially filled).
Some good ideas, got me thinking about condensing the header. Probably for my own stuff but I’ll share it here for anybody interested. With the icons changing appearance I’m going to just do what is currently available until I get something I like. Then afterwards maybe get some different icons, or figure out how they do the different draw styles for them to get some new icon effects.
I have select enclosed faces halfway working, xray / select through only. Getting it to work in xray is really easy for me, need to change like 3 lines in do_mesh_box_select__doSelectFace
but getting anything to play nice with bitmap / zbuffer stuff for near selection is too… mysterious to get it done anytime soon. I tried to look at how edges work with both xray and near select, but can’t get index to pass anything but junk and either crash or select nothing.
I’ll leave it out of the diff I will submit, but will include it with the 3.1 build I make sometime in the next week. Going to be busy for a few days, finally got a new gpu supposed to be here tomorrow 
Please also post the link to the patch once submitted so we can drop you some juicy tokens 
Hopefully, once the devs get around to reviewing the patch they will actually help with the issues you are still experiencing.
I just remembered this post, that patch you linked has the solution to my problem I’ve been trying to figure out for like 2 weeks now.
I’ve been trying to do a select enclosed faces and not getting anywhere with the near select version of it. Was about to post a thread asking for help, showing my dysfunctional code modification:
static bool edbm_backbuf_check_and_select_faces(ViewContext *vc,
struct EditSelectBuf_Cache *esel,
Depsgraph *depsgraph,
Object *ob,
BMEditMesh *em,
const eSelectOp sel_op)
{
BMIter iter, viter;
BMFace *efa;
BMVert *eve;
bool changed = false;
ToolSettings *ts = vc->scene->toolsettings;
const BLI_bitmap *select_bitmap = esel->select_bitmap;
uint index = DRW_select_buffer_context_offset_for_object_elem(depsgraph, ob, SCE_SELECT_FACE);
if (index == 0) {
return false;
}
index -= 1;
BM_ITER_MESH (efa, &iter, em->bm, BM_FACES_OF_MESH) {
if (!BM_elem_flag_test(efa, BM_ELEM_HIDDEN)) {
const bool is_select = BM_elem_flag_test(efa, BM_ELEM_SELECT);
const bool is_inside = BLI_BITMAP_TEST_BOOL(select_bitmap, index);
bool is_vinside = true;
if (is_inside && ts->fully_enclosed_faces) {
BM_ITER_ELEM (eve, &viter, efa, BM_VERTS_OF_FACE) {
int i = BM_elem_index_get(eve);
if (!BLI_BITMAP_TEST_BOOL(select_bitmap, i)) {
printf("OUTSIDE = vert %i of face %i\n", i, index);
is_vinside = false;
break;
}
else {
printf("........vert number %i of face number %i is INSIDE\n", i, index);
}
}
}
const int sel_op_result = ED_select_op_action_deselected(
sel_op, is_select, is_inside & is_vinside);
if (sel_op_result != -1) {
BM_face_select_set(em->bm, efa, sel_op_result);
changed = true;
}
}
index++;
}
return changed;
}
And a video of it not working quite right. I remember looking at that patch when you posted it before and bookmarking it for later because I had seen some useful stuff in there. Still didn’t stop me from forgetting about it and messing around with this a dozen different ways that all don’t work in the same way.
Anyways, sorry about the delay I know I said I’d do the build a week or two ago. Shouldn’t be long now, and fully enclosed faces should be functional thanks to that patch made by @Harleya who is actually the reason I got into this whole thing in the first place. A couple years ago he pointed me in the right direction as far as building blender, when I was looking for some information on another forum, trying to figure out how to modify the cursor.
[BUILD] Blender 312 Select Through
[DIFF] Sthru312
[OPTIONAL] Alternate Header
Ok here’s a release build for 3.12, should be good as far as bugs (edit - Intersect selection doesn’t work with faces in xray/select through unless it’s by facedot, see posts below), optix should be working. I don’t think the HIP sdk is out yet, so you’ll need to compile the DIFF later if you need that. I couldn’t check it anyways since the latest AMD I have is a 7870.
Current behaviour of Blender is intact and should be unchanged if you reset to default. List of what it does, some pictures where applicable:
Facedots
Facedots are split into xray and solid shading. Just means you can toggle them independently. Facedots can be turned off in xray.
This is accessed from the viewport overlay popover. If anybody has a keymap for the facedot toggle in vanilla blender it will still work as usual (it toggles facedots in solid shading only). But if you assign the operator I put in its place it will toggle facedots for whatever mode you are currently in, solid or xray. Similar to the default xray button, it will toggle xray for either wireframe or shaded depending if you are in wireframe or not.
X-ray and Select Through
You can select occluded elements without turning on xray manually. This is available in 3 flavors, auto xray, select through header button, and select through keymap. Xray has it’s own popover and the settings for it are in there instead of Viewport Shading. These alternate xray modes are also available whenever you have box, lasso, or circle as your fallback tool for things like the transform tools.
Auto-Xray will turn on xray for you while drag selecting in box, lasso, or circle. When selection is finished, or cancelled out of, it will turn xray back off for you. Can be turned on and off, header button will reflect this.
The on/off status for auto xray and select through header button can be synchronized amongst any combination of the 3 selection tools.
Select through header button lets you select as if xray was on without changing anything visually. Toggles on or off like auto xray.
Select through keymap is the same as the header button version except instead of a toggle, you hold down whatever you assign it to in the keymap during each selection. You’ll need to do this keymap assignment for yourself, tooltip will show you how. It’s in the keymap for each of the 3 select tools, you will find a checkbox called ‘Mesh Select Through’
Drag Select Options
You can select edges and faces differently. Accessed from toolsettings from the two usual spots. Also available whenever you have box, lasso, or circle as your fallback tool for things like the transform tools. You can force select all edges instead of needing to fully enclose them. Circle select does not have fully enclosed edges or faces options, only the ability to disable xray facedot selection.
Faces are slightly more complicated. In short, xray facedots has priority when you are in xray and facedots are visible. This is the default behaviour. If you turn off ‘xray facedots’ it will select by face area aka intersecting faces. If you have enclosed faces on it will only select fully enclosed faces, but again, only if ‘xray facedots’ is off if you’re in xray with facedots visible.
Alternate Header
This is just something I’ve done for myself, and since it’s all python, you don’t need to compile to use it if you’re interested. It saves a little space by moving the shading buttons into the popover. To make more use of the button, it is actually just the xray button with a different icon depending on what mode you’re in. This is so you can have the usual xray state visible in button form when in either auto xray or select through header button, where you’d otherwise have to open the popover to see a button that lights up to show when xray is on.
Let me know if somethings wrong, thanks for helping everybody. I’ll wait a bit to be sure nothing’s messed up, and then go about submitting something. Based on what I read, they don’t want something that combines multiple features in one diff. So it might be split into 3 different diffs (facedot, select through, drag select options)
@lcas FWIW it works really nice with auto X-ray. I’ve been testing a couple of combinations and sofar have not encountered any bugs. It’s simply great! Thank you so much for your work on this!
Small feature suggestion
What might still be a nice addition for Auto-Xray is if it were to work in object mode too, so you can see your selections. This was possible in the X-ray selection tools addon.
Installing the build?
Now, if I want this build to install this build as if it were the .exe downloaded from Blender.org, I need to extract it to the same folder location as where I would redirect the installer, right? Is there anything else to it? Also asking for others who may be looking to install this build.
Awesome work @lcas thanks, going to check out your build asap.
I’ve got a question tho, i’ve been sussing out the various tickets in blender development about this issue and having a hard time following a lot of the disconnected pieces, is this intended to be merged with main and available with full release (after reviews ect)
Or is this an independent diff?
I actually did find a bug, the intersecting selection method does not work with Auto-Xray enabled.
The add, subtract and new selection modes work fine in my keymap, though the intersect method does not (Ctrl+Shift+mouse drag). If I enable this option from the selection tools, it adds to the selection.
With the default keymap, the intersect mode also does not work, neither in X-ray, nor automatic X-ray mode:
I can confirm the bug found by @Hologram. Sometimes intersect just deselects a random face somewhere.
Also a couple points in general:
What’s the point of keymap option in Select Through modes? If I set up a keymap for select through then it should work all the time, having to also switch to keymap mode seems like an extra step that’s unnecessary.
The way Select through options hijack X-Ray shading button is very confusing. Maybe it would be better to move those options to the left side of the header, next to the selection and tool settings? It seems like a more appropriate place and would not interfere with X-Ray button.
Overall the main features are working well, it’s just a matter of finding a good way of controlling them. Maybe core developers from the UI module could give you better guidelines.
Still some significant bugs to check out, thanks to you guys for finding them.
@insideitall I am just doing this for myself and sharing it for anybody to help out or use, I will submit for addition to blender when it is debugged enough, which should hopefully be pretty soon. The real work was done by @kio I’ve just added things to it.
@slowburn please show me a picture / video of the intersect doing the random stuff. I have encountered this before when I was doing select enclosed faces in a different way. It is perfectly reproducable so that you can test for it consistently, but sometimes it takes a little bit to find a specific collection of faces / verts/ edges to get it working weird where it does the random deselect thing. I’ll try to find out for myself of course, but it will be a while so if you could show me that would save me some time.
Question 1
The two modes do the same thing, but are not related at all. Keymap does not care whether the header button is on or not, and vice versa. They have different approaches to engaging select through, and its a workflow preference thing. You don’t have to do anything with the keymap mode to work besides click the checkbox inside the keymap for box/lasso/circle and then do the assigned shortcut while you are using whichever selection tool.
I initially made keymap select through way back when I first found this thread. I did it because I wanted a way to use select through indepently for each tool, and that was the first way I thought of. Since then I’ve figured out how to do that with the toggle version, I had actually removed the keymap from previous builds because I found that I prefer a toggle to an active keymap. I hadn’t really heard anything about the keymap version, it was always in addition to the toolsettings checkbox back when it was around. But it had enough votes on that poll I made so I put it back in.
It’s the sort of thing where it doesn’t hurt to have it in for anybody who prefers it. If you wanted to use a modifier key like ALT, you can’t really do that with a toggle, because you can’t assign to just a modifier by itself. Another reason would be if you wanted to make an active choice to select through each time, rather than a toggle, it makes sense. Lets say its been a little while since you’ve selected something, you never have to wonder if you are going to select through or look at the header button itself being lit up or not, because you’d do it by choice each time. That’s why I like the xray button to change, it lights up when select through is on, or auto xray too, but that one is a bit more obvious when its doing what it does. Speaking of header buttons
Question 2
As far as the header buttons working the way they do, its one of those things that keeps changing as new ideas come in. If the devs take this select through patch on, I imagine they will tinker with it quite a bit. If they need it, I’ll do whatever to assist with or maintain the stuff they want to pick and choose from this patch.
The way I am doing this is just my preference, with a lot of decisions and compromises to accomodate different features, all while not affecting default blender. Always open to changing stuff of course, but here’s my reasoning:
For now I prefer keeping the different methods for turning on xray in the same position of the current xray button, rather than over in the selection type area. That’s all this patch really does in the end, it engages xray in a couple different ways. I dealt with facedots, at least somewhat, because it’s worth doing, and then also the drag select options for edge and faces. Since those already have areas where they are dealth with, viewport overlay for facedots, and toolsettings for box/lasso/circle, I decided they go in there.
I didn’t want to add more buttons to the header, but I was ok with it before because it was worth having the feature more visible. But as I got to thinking more about it I thought of a way to replace what I consider a useless button, without removing it entirely for those who like it.
I’ve never cared for the xray button. I’ve always hidden it since I started messing with blender. If I want to turn it on I’m not clicking that button, I’m just going to assign it to a shortcut and comment it out of space_view3d.py. If I wanted to know if xray was on, all I’d need to do is look at what I’m working on, its either (more) transparent or not. I do however have a lot of gratitude for the xray button at the same time, because the way it works taught me quite a bit about how other things work, and gave me some ideas.
I think I’m ok with the level of confusion from hijacking the xray button. It’s worth the header space. None of the modes stop you from using xray manually, even for header button clickers, you could always open the popover to do that. You can even avoid opening a popover, that is where I eventually made the alternate header, check it out. Like xray, I do not need a button to tell me which shading mode I’m in. Not just one button, but four buttons, just to know what I already know. It’s usually pretty obvious if I’m in wireframe, solid, material, or render shading. All those 4 buttons do is switch between them. I’ll use the pie menu to do that, or just assign a specific mode to a toggle when I want it. So that led to me killing 4 buttons: xray, and 3 of the shader switches. With just one button, I can see which shading mode I’m in and whether xray is on or not. I needed something up there to attach to the viewport shading popover, you can just have it floating there by itself but it’s a bit weird. There is some redundancy in defualt xray and select through keymap, but for now it is an acceptable compromise. If you open the xray popover in those modes you have 3 xray buttons in the header: the xray button, the bottom of the xray popover, and the new viewport shading button that toggles xray.
@Hologram I’ll have a look at why intersect is acting like a new select. I’ve actually never seen where that decision is made, between new, add, subtract, intersect selection. Hopefully easy to track down, which has been the case since I found out that grep tools exist, I am using dnGrep for that. I used to just try to guess what script to check and what something might be called to do a find/replace for that specific script. Super slow.
Once I figure out the bug(s) I should be able to add object mode to auto xray without much trouble.
Installation
I’ve always kept the latest official blender release alongside all my different builds, usually to see if some behaviour is just my build or not (didn’t stop me from missing stuff like how enclosed edge selection works, but it can help). The custom builds work like a portable install as far as I’ve experienced. If you open the addons area it might say something about having redundant stuff in there, I dunno I’ve always just kinda followed what it asks for you to do, something about deleting this or that or picking which area to use to point the addons at. When everything is sorted out, devs will hopefully get at least some of these features added to the real thing, and most people would be covered to the point that they aren’t interested in a custom build enough to bother. I do appreciate you spreading the word though, thanks. I don’t know much about forks, but I do see a ton of them in there when I do a git branch -r so if nothing else I’ll make a fork if that’s a thing I’m allowed to do.
I did not mention any of the below proposals before, because I think it’s best to let the developers shoot at it first. They should indicate their preferences instead of us users dragging the patch out for longer and, possibly @lcas ending up having to do double work. So think of these answers as future references
BTW: Also noticed random faces disappear from selection using the intersect mode.
Header vs selection option
I am not convinced by either method, but I prefer the current approach most. I think moving the select through options to the selection options would be nice for the sake of tool consolidation, but, you cannot have options for Box/Circle/Lasso linking, so then leaving the Select through options were they are sounds more appropriate to me. Then the selection specific and select through options are consolidated in their own respective places.
I think that would simplify the whole from a user perspective.
I had a hunch about intersect not working, so I just applied kios original work, doesnt work there either. Something about this makes intersect do nothing, it basically leaves the selection intact, or deselects a few seemingly random things but not everything that it should:
static void do_mesh_box_select__doSelectFace(
void *userData, BMFace *efa, const float screen_co[][2], int total_count, rctf *screen_rect, bool *face_hit)
{
BoxSelectUserData *data = userData;
if (!BLI_rctf_isect(data->rect_fl, screen_rect, NULL))
return;
bool inside = false;
for (int i = 0; i < total_count; i++) {
int a = i;
int b = (i + 1) % total_count;
inside = edge_inside_rect(data->rect_fl, screen_co[a], screen_co[b]);
if (inside) {
break;
}
}
/* Single point check should be suffienct as we only care if the box rect is inside of the
polygon. */
if (!inside) {
float point[2] = {data->rect_fl->xmax, data->rect_fl->ymax};
inside = isect_point_poly_v2(point, screen_co, total_count, true);
}
*face_hit = inside;
const bool is_select = BM_elem_flag_test(efa, BM_ELEM_SELECT);
const int sel_op_result = ED_select_op_action_deselected(data->sel_op, is_select, inside);
if (sel_op_result != -1) {
BM_face_select_set(data->vc->em->bm, efa, sel_op_result);
data->is_changed = true;
}
}
I’ll see what the oldest sthru build I have is, but I expect it acts the same with intersect selection not working right when selecting through by face area.
As far as the suggestions I’m always interested in improving it.
Keymap
Keymap is called keymap because that is where you would go to access it. Not the best name, but Modifier isn’t quite right either because you don’t have to set it to a modifier key. It could be anything that the keymap will allow, like a letter key.
For example, you attach box select to each of the move/rotate/scale tools, click the checkbox ‘Mesh Select Through’ and assign it to the ‘A’ key. You also do the same thing again, except this time you leave ‘Mesh Select Through’ unchecked and assign it to something else ‘Shift A’ or another letter, whatever you wanted. You then use the move/scale/rotate tools in either ‘Tweak’ or ‘Active Tool’ instead of box select fallback. Then you switch xray mode to ‘Keymap’. While in these tools, you don’t drag to box select, you drag to tweak or whatever else, and when you want to box select, you press ‘A’ once, then drag. It will do a select through. Or you do the ‘Shift A’ or ‘B’ or whichever you like, then drag without it selecting through. With Keymap mode, the selection doing a select through depends whether the keymap for box select has ‘Mesh Select Through’ checkbox on or not. As opposed to the header button version, that only cares if the header button is toggled on or off.
The select through button isn’t enabled in keymap mode, it switches it’s icon, and its functionality, to the standard xray button. I have to leave some kind of button in the header for the xray popover to attach to, otherwise it just floats up there by itself in sthru keymap mode. I just put the standard xray button back in that mode since keymap doesn’t have or need a header button. I could grey it out or something, but I figure why not just leave it like default xray in this mode.
That’s what it is supposed to be doing anyway, I’ll make a video if unclear.
Use things simulatenously
Alright sure why not. Once I’m done figuring out intersect I’ll add two more modes in the dropdown where you can use autoxray with keymap or header button select through, and a second button will show up if necessary.
I went with a dropdown inside the xray popover for switching modes, as opposed to checkboxes, because otherwise there’s no clean way to give priority between select through header button and select through keymap. It’s like with the drag select by xray facedots. Not clean, really wordy just to explain how and when it works, but it is what it is since I didn’t think of a way to detour around it. I had wanted to just have a grid, simlar to the link box/lass/circle that looks like this:
Drag Select Faces
Near | Enclosed | Intersect | Facedot |
X-Ray | Enclosed | Intersect | Facedot |
But I never figured out near by facedot so I didn’t. Maybe I’ll do it anyways without facedot for near.
Once I figure out intersect, maybe we’ll have some kind of approach to the xray options, but like you said it isn’t likely to stick anyways. Either way, I think presenting the devs with something that works more intuitively would be great.
I never really understood the active tool, nor selection fallback modes, so excuse me for those. In that case, keymap is fine. The pop-up descriptions are nicely detailed, shouldn’t be a problem imo.
Yes I agree. Hopefully they are able to provide some constructive feedback or proceed with merging altogether 
I think it’s a well designed all-round package this way.
Recorded a short video with intersect selection bug. The behaviour is quite erratic, so I’m note sure if this will help.
You did great, thats just what I was looking for. I went ahead and ported the original patch, just a checkbox in toolsettings that uses mvert instead of bmvert, to be sure that it wasn’t something else I’ve done afterwards. That eliminates a lot of digging around where I don’t need to.
I can do the same thing and save this as the startup file to test each time I try to find out what is wrong, and then hopefully get it working:
It deselects randomly, but the same mesh with a specific selection will do the same wrong thing everytime which is nice for testing. The oldest build I have around is 293, it doesn’t work either. I think that’s enough for going back in time, it isn’t like a new version of blender did it, it’s something about that script I posted earlier, or the other half of it in view3d_iterators
For now I am going to have to pretend I am still blissfully unaware of this problem with intersect. I got some stuff I need to get going on and was planning on being done with this in a week or two.
It’s been there all this time and I never thought to check since I don’t really do anything beyond the new/add/subtract selection. I definitely see how intersect and also the invert could be useful so it’s pretty dissapointing that it doesn’t work.
Somebody who actually knows why this doesn’t work would have to spend their time looking at it, and since nobody like that has poked their head in here to do that so far, I think we’ll be waiting a while. I’ll ask somewhere tomorrow or something, I’m not expecting anything to happen though.
By all means see if someobdy has a clue. All I can guess is that there’s an issue with
const bool is_select = BM_elem_flag_test(efa, BM_ELEM_SELECT);
Or it’s a problem where, for some reason despite everyting else including invert select working fine, some sort of data loss or memory issue is occuring.
I made a Stackexchange topic about this, maybe some votes would get it the attention of somebody who could help? If select through is going to be part of Blender this definitely needs to get sorted out, thanks guys.
Voted! If anyone could put a bounty on this one it’s even better.
[BUILD]Blender 312 Select Through
[DIFF]312sthru
[OPTIONAL]Alternate Header
Small update that detours around the intersect issue. Details about the build are a couple posts up, will update the links there as well:
I’m having it do what I had initially tried for fully enclosed face selection, which was to select faces by edge while still in face mode and then doing a mode switch from edge to face to get it responsive and mostly functional. I say mostly functional because there was some, let’s say confusion, for subtract selection. Very similar to the current intersect selection issue where random faces are deselected, but not all the time like with intersect where it just does not work in any circumstance.
Anyways, it seems fine with intersect fortunately, so if it sees that you are doing an intersect select it will do this wonky mode switch. It will only do fully enclosed faces though, that is just the nature of how Blender works when you switch from a selection of edges and then go into faces only mode. The only faces you will get are those who had all of their edges selected in edge mode. If you are already in edges+faces mode it wont need to do anything. If you are in verts+faces it won’t select everything quite right sometimes but nothing too bizarre like it was, try it and see if you are curious.
Nothing I am going to do about that right now, I’m a little burnt out to be honest with you guys. Maybe with some time away I’ll think of something that is worth trying. I’ve attempted a lot of different things, from rewriting it entirely, to mimicking the way edges work. The way edges work is amazing by the way, it’s one script for zbuff/near or xray/through in either fully enclosed or intersected edges. With faces it is really frustrating, one thing does zbuff of intersected faces only, another thing does xray and only by facedot. I wish it was a little more straightforward for face select.
Especially considering nobody had any advice, tips, help, something to give me a direction to go in with this problem. I kinda knew that was going to happen but still, you get your hopes up that somebody will say something like, “Hey, I see you are doing this why not try something like that and see if it works”
Going to submit it as-is. Maybe something will come of that, but again, I expect a whole lot of nothing given how this has gone so far. Doing custom build works for me at least, I had been using it without even knowing intersect didn’t work right because I don’t think I’ve ever used that selection mode. I might just go out of my way to try to find ways to use it going forward.