I get you, I guess it circles back to how to present it simply as possible. I don’t think it gets any simpler than the original one Kio did, but for whatever reason there’s controversy about it. Personally don’t care how it works, I can mess with it to my liking.
1 Like
Yeah. UX design is always a battle for a balance between functional compactness and completeness, which is always painful to reach.
Its cost is high but worth it though.
I try it today , man Iam in tears, I can select without thinking of xray mode.
Big thanks man 
I wish the developers take a look and implement it.
people who want to use xray or not up to them its an option.
such great work 
1 Like
Iam really happy 
, with the result, it will save me tons of hours and clicks : D
Iam 100% sure hundreds of people gonna like it
12 Likes
Thank you! I’m learning blender having come from another application(s) and back face selections without xray mode was frustrating me. I often work with CAD files for work too, so I was dreading running into the issues of point and line soup people have outlined here and in other posts.
Hopefully this solution or something similar finds its way into a 3.x build. Thanks again for your work!
5 Likes
I tried to get an idea what, if anything, the devs have in mind for select through but I didn’t get a reply from the guy I asked. One thing I know is that they’re overly busy with a million different things, but what I don’t know is where their interest level is in putting select through back into blender. Another thing I wanted to know is what they’d like to see if this really is a situation where they want a user submitted diff. I am pretty sure none of these things are true: that they aren’t particularly fond of the feature, since they removed it, and that they would just add it back themselves rather than have someone else do it.
But I’m willing to act as if, and submit something on your guys’ behalf if you want to play along with me. If there’s any objection to submitting a diff let me know.
edit: someone told me how to make a poll, you just click the gear button
Vote for whether you feel like we should submit a diff, or if you feel like we should just leave them to it. When I first started messing with this I was just going to send a diff once I was done and see what happens, but I’ve gotten the impression there are some concerns about wasting an opportunity or something to that affect.
I’ve said before that I don’t particularly care if or how it happens, I’ll be doing my own thing either way so it doesn’t matter. I doubt that many people will be voting on this, but I’m fine moving forward based on the results. I’ll wait a couple weeks and go from there. If you guys decide we are going to submit something, we’ll come to some agreement what form it will be. Go ahead and vote for the options you want, if you feel the need maybe give your opinion on that. It’s up to you, but this is what I’m feeling:
From what I’ve seen, these diffs should change as little as possible, so facedots being split into solid and xray is technically a separate patch, and hiding the button would act different from all the other buttons. On the other hand, resubmitting kio’s patch would probably have the same result as last time.
That’s the nice thing about making your own build, you can do whatever you want. I encourage you all to just have a go at it, nothing near as difficult or time consuming as I thought it would be. One afternoon of free time, and you’re done. Every once in a while you might check out something new to play around with. Couple times a year a new build comes out, there might be a slight change you need to make for it to compile, another afternoon at most.
Send a Diff for review?
- Yes
- No
0 voters
How should Select Through Work?
- Toolsetting
- Header Button
- Keymap
- All of the above
- Toolsetting + Header Button
- Toolsetting + Keymap
- Header Button + Keymap
0 voters
Choose any optional features you want to include, if applicapble.
None of these affect your ability to use Blender as it is right now, or exclude the use of each other. It’s a thing where if you want some, or all of these options, while also only using them some, or all, of the time, it is all good.
- Always select by face area
- Hide header button
- Independent control
- Select near xray
- Hide xray facedots
- Dual facedot
0 voters
Always select by face area:
If you are in face mode and have facedots on, you can select faces by touching any part of them rather than needing to hit the facedot. When off it acts as normal, facedots on = select by them, facedots off = select by area of the face. This only affects xray mode because I never figured out how to select near by facedot.
Hide header button:
Hides the header button if you don’t want to see it. You would right click the header button and assign to a keyboard shortcut, and then you would hide it. Don’t worry, it can come back if you need it again. The most uncluttered way to use select through if that’s what you are into.
Independent control:
Only used if you want the header button. You can have different select through states for box, lasso, and circle. If you want to have select through on/off in one or two of those tools, but not mess with the other(s)
Select near xray:
By default, xray shading always selects through. This allows you to select near in xray mode when you aren’t selecting through. I already got rid of this but it’s easy to put back
Hide xray facedots:
This isn’t an explicit option you’ll find in userprefs of my build, it’s just allowed to be done in the viewport overlay dropdown. Normally you can’t turn off facedots when you are in xray because, I dunno. This might be a consistency or training wheels sort of thing. Wielding this immense power might be a problem if you forget or just don’t know what facedots are and then need them for single click or whatever else. Technically a separate feature, so keep this in mind if that’s a concern of yours
Dual facedot:
Xray and solid shading have separate facedot controls. If you never want facedots in solid shading, but might want them in xray without being forced to keep them on all the time, then this is for you. Like the previous option, this is technically a separate feature.
3 Likes
This post was being used as one of two options of a poll (yes, send a diff for review) before someone told me how to make one
2 Likes
At 10 votes so far, it looks like a diff is happening, and the optional features will be hide xray facedots + always select by face area. But how do you want it to work? Nothing has more than 2 votes on it. 6 votes have some form of header button, 5 have tool settings, and 4 have keymap control.
I included “All of the above” and “Toolsetting + Header Button” just because they are technically possible 
without expecting votes for them. My interpretation of TS + Button is that its the same as header button but more specific, saying that the optional feature (always select face by area) should be in the tool settings as opposed to userprefs. “All of the above” would mean the same, with the addition of optional keymap control. But that’s just my assumption. AOTA could also be interpretted as a bit of a PITA, where I make a version that can be either a tool setting checkbox, a header button, or keymap all in one build. I’m a man of my word, if you guys vote for what is essentially a meme diff, I’ll send her off for review.
I think we have 1 choice to make.
On the one hand you have tool setting, it works fine, and all I can think of against it is that maybe it’s not obvious enough where it is and when it’s on. Then there’s the header button. While it’s a little more obvious where select through is, and when it’s on, another button comes with a bit of baggage:
- Is it compelling enough to use up that limited screen real esate?
- What sort of icon is it going to use, and who is going to draw it?
I’ll be using the header button with my own personal build, and hide it whenever I want it out of the way. I also hide/condense a bunch of other buttons because that works fine for me. But that’s only because I don’t have to worry about select through being a special hidable button, or that it’s using the same icon as whatever uses the OBJECT_HIDDEN icon, which could be confusing to some poor unsuspecting blender user.
I’ll wait a couple days to see if anybody else votes, wants to clarify what they want, or has any alternatives before I just pick something.
I don’t think it will matter too much whichever way it winds up. If the devs don’t want facedots to be hidable in xray, or just don’t want two changes as part of one patch, or if we send a header button and the devs say that they would rather it was a toolsetting only (or vice versa) they’ll hopefully just accept a revision if they want select through. Either way you guys will probably get some kind of idea where they’re at with this feature. Even if it gets no response, that’s a pretty clear implied answer (not interested)
edit: tried to reply but it says you cant make 4 posts in a row
This post was being used as one of two options of a poll (no, do not send a diff for review) before someone told me how to make one
I can help out with it. Send me a direct message and we can talk over the details.
1 Like
@kio As someone who was actively involved in the discussion on the design task, I was under the impression that if the ‘only select that which is visible’ criteria was met, there was a consensus.
Basically, the Select X-ray addon also automatically toggles X-ray mode upon window dragging for selection. This toggle is hotkeyable. Furthermore, there could be options not to select faces from facedots and to select all that is contained or all that is touched by the selection window.
@lcas I think your patch would have more success if it were to also toggle X-ray upon selecting by default and make it an option to disable this so you can get it to work the way @KloWorks showed. That way, you can work with X-ray off and select with X-ray on. Thanks for working on this and bringing it to everyone’s attention. Hope it gets picked up and shipped if you manage to flesh it out!
- Yes, I like to see a button flash that I can check to see that its enabled.
Even if you were to enable X-ray during selection, I would want this visual clue, that is because, I would always glance at it first, otherwise I would have to redo the selection > ctrl+d > enable select through > reselect. This piles up over time.
Also note that with the header revision, the devs made space for icons such as these for active tools.
If you make it a tool setting, would it still be hotkeyable (e.g. alt+b > enable/ disable select through)? Or will it be like the Select X-ray addon, wherein you create new selection tools which, if enabled, may show the header and have the Select Through hotkey?
That would be a big F*** you + middle finger to the community. It would put to shambles the whole idea behind Blender as open source, community driven software.
I had an idea for the button, ignore that I hid the xray button I won’t be doing anything that controversial for the real thing. Idea was that with a header button and keymap, the button would reflect which mode its in and act at least sortof normal. Originally I had it autohide the button when in keymap, but hiding is off the table as per the vote. I actually kinda like it better this way, all the options are in one spot now. I didn’t like the prospect of it being in keymap and you have a dead button up there, where it can be clicked and nothing happens. So now it switches button styles where it just opens the options when clicked, and then goes to a button with popover when not in keymap. The three things that need to be checked (select through, keymap toggle, face area toggle) are all userdef properties. These properties need to be an operator in order to be assignable to a shortcut. You can see in the video that the select face by area can be assigned to shortcut, but the keymap toggle itself cannot because I left it as just a property.
I think your patch would have more success if it were to also toggle X-ray upon selecting by default and make it an option to disable this so you can get it to work the way @KloWorks showed.
If you are talking about that video from his latest post, I think he’s just showing my patch in action. I don’t know what you mean by toggling xray upon selection. You mean like, flash xray on while selecting, and then turning off again when done?
@lcas
Exactly, so if I do a box selection (or window drag selection with the selection tool ) selection with select through enabled, ‘Toggle X-ray for selection’ enables X-ray for the duration of the selection. When the selection is done, x-ray is disabled.
You can only select visible criticism averted. 
And for people who do not like the X-ray flashing, you can turn it off.
I like the flyout menu for the options, but I would, as mentioned, place it where it is in the video I showed (although I personally don’t have anything against the button being where it is now). But. I say this because earlier, the criticism on @kio’s patch was that this button adds to UI bloat. However, thanks to Blender’s recent toolbar switch, there now is space for a button on the toolbar for the particular purpose of supporting active tool settings 
Sorry, I didn’t really understand the operator + properties + keymap part. 
1 Like
The operator / properties thing is just explaining stuff that I’m figuring out as I go through making different versions of this patch. It just helps me remember, or solidify what I am learning when I do that, like taking notes that I can check back on later if I forget something too.
I’m not sure how to do the xray while selecting. It’s basically a macro, but who knows. I’ve assumed things were simple before and never figured them out. I think the xray while selecting was born out of necessity because that was the only way to make it work without needing to recompile.
Yes, that is because what I showed is from the Box select Xray addon (X-Ray Selection Tools - Released Scripts and Themes - Blender Artists Community), so not even a custom Blender build. If you know python, you could perhaps check back to version 1.2.X on gumroad to see how it achieved this…?
I am assuming this to be a necessity for the patch to make it into master and it is actually quite a nice workflow, because you always know when you selected through or not. So no nasty mistakes a couple commands further down the road caused by wrong selections.
1 Like
I use this addon and love it. Right click and drag to select with Xray mode and left click and drag for regular selection. Problem with getting this into master is that you have to modify some keymaps and we know how sensitive this subject is, specially since the keymaps are prone to breaking. I also like the placement of the button as you propose.
Do you really need to change them? I mean, the build could even propose no keymap changes and have them all up to the user, right? Long term Blender users will use X-ray mode, those who like the Select Through behaviour, add one or more shortcuts to the new flyout operators.
But, it could also be an option in the Blender Keymap, for instance, to replace the X-ray button with the Select Trough toggle.
Disclaimer: I have customised my own keymap to such an extent that I cannot meaningfully suggest any hotkeys for the default. I would alter them anyways. But I don’t see why using obscure keys and avoiding conflicts/ replacing hotkeys through the keymap preference toggle, wouldn’t result in a key decision. There are so many more keys than Blender uses by default, that it shouldn’t be a problem. BTW Alt+X is free, the key next to X-ray (Alt+Z).
@lcas
Just a thought that hit my mind just now, would it be viable to create a design task (once you are ready) in which you decouple the various elements that make up the patch?
Allow me to explain:
Splitting up the design task in various sub-tasks will allow you to merge at least some parts of the design into master in case certain elements lead to lots of discussion (i.e. a button or keymap), but hopefully all would be accepted. It would make the review process easier for the Blender Devs, since the scope of each subtask is focussed. I’m just hoping to get it in ASAP and not be stuck on an argument on a minor detail for something like a keymap item.
The elements that make up the ‘Decouple x-ray and limit selection to visible’ are:
-
Select through mode
1a. The Select through button in the header (incl. flyout)
1b. The keymap control option
1c. Optionally, the keymap editor preference button (‘Use Select Through’)
1d. Optionally, the keymap item to invoke select through (Alt+X?). -
Toggle X-ray upon selection
2a. For the selection tools (in the T-panel).
2b. For the Box/ Circle/ Lasso select commands (under the select button in the header). -
Alternative selection modes for facedot selection
3a. Select face area (fully contained within the selection window and/ or only touched modes)
3b. Select edge (fully contained within the selection window and/ or only touched modes)
Please let me know if I missed something or the patch is different from what I think it is 
P.S. Correction, the Select X-ray addon does also have a mode without ‘toggle X-ray upon selection’
2 Likes
Sounds like a plan. I had some thoughts about how to approach the, lets say modular, nature of this patch when submitting it. I like the idea of splitting it into different elements so it’s easier to go over and maybe get some momentum with at least part of it.
I had another look at the xray addon, and it seems like it is fairly complicated. I was hoping I could just make some kind of macro of xray->drag select->xray. I’ll spend a little time trying to figure something out but I don’t know. I also like the different edge selection where it will do everything it touches, haven’t looked into it yet but I will soon.
Apart from it’s UI (which is open to debate), the way it handles keymaps in the addon preferences and performance hits from using python. The Select X-ray addon is really feature complete, which is why I keep referencing it.
You know, you could always poke around for help, there must be at least a few more developers who would love to get a native Select Through in Blender.
Figured out a way to get auto xray going. Look at call hierarchy for box_select, pick a script (WM_gesture_box_invoke is working for now but might not be the best place for it) and tell it to look for autoxray bool. Have it call toggle_xray, then have select_box do the same thing to turn it back off again. Need to decide how / what to check for so it only does it when its supposed to, like if it’s already in xray don’t turn xray off then back on.
Seem about right?
6 Likes