At this point it might be easier to implement some non-contextual functions that don’t rely on editor state, tool settings, or user preferences, and then expose those functions through the API such that the actual operator could be implemented in Python.
There’s enough inter-dependent behavior being discussed here to justify demoing parallel implementations, and doing that with an add-on (rather than throwing diffs around) could save everyone a lot of work.
Please be aware that this is an opinion and not a fact. And heavily based on the kind of modeling you do. In low(ish)poly modeling this feels extremely natural to me and I wouldn’t want to miss it. I’m all for adding options for people who want them, just please don’t go the other extreme.
On facedots: afaik the way blender’s frontface selection works (for performance reasons) is that the indices of the faces are rendered to the selection area and then the selection is made in the 2d (pixel) image. This is extremely fast but I don’t think it works for occluded geometry at all (and it also works quote badly for high density meshes by the way). I think facedots are not only added for UI reasons, but also for performance reasons because transforming a single point per face and clipping it with the selection shape is very fast.
Maybe this is a historical artefact and modern computers are fast enough to just transform all vertices but performance matters as well. Just keep this in mind while testing/designing. Blenders selection is way faster than meshlabs (for example).
Here it is:
Facedot Selection and Visibility Options
I think the scope that it covers is ok, the visibility and selection are pretty well connected, but I could cut it down to just “turning off facedots in xray could make a dense mesh easier to look at” and then do the selection of facedots in xray in another one.
@TheOtherZech
That is interesting an interesting idea, I don’t know enough to have any sort of opinion about it though.
@Baardaap
Last time I checked the speed of select through by area it was pretty much the same. A little slower but not really noticible, it was <0.1 seconds difference on 1.5 million verts cube. This is on 5800x cpu though, so it will vary.
I read through the design task and I wasn’t aware that the face dot selection behaviour should ideally be always the same for click selection
I see the reasoning … but this complicates things a lot.
Since the overlay cannot change the single click selection behaviour it therefore should never be hidden.
The overlay is the only clue where faces can be selected when Xray is enabled.
So the proposal of linking the face dot overlay to all selection behaviour falls apart.
This potentially brings this back to being a tool setting as well, unless there’s a solution I don’t see yet?
Pretty much. I don’t have an issue with facedots, but I also see the benefit of hiding them temporarily in x-ray. For my own build, and anybody who’s interested in something similar, I’m fine with giving the user an ability to hide facedots, and potentially forget that the option exists (or that they are in face select at all).
But for real blender, I think we are looking at face area select in xray with facedots visible. It basically lets you select in x-ray the same way as solid. Facedots are there, but you aren’t forced into using them for drag selection if you either can’t, or won’t, at any given moment. A toolsetting gets the job done, and checking for select through and forcing face area is easy enough. This muddy’s the UI or workflow perhaps, but best I got at the moment. Is the benefit worth another toolsetting?
I am interested in directional control. That patch works, but from what I remember the issue was with lasso. The starting left vs right direction is the determining factor, but (anti)clockwise was desired instead. You can start left or right to make a clockwise lasso, and you can double-back after starting clockwise, and then go anticlockwise. Resolving that is way above my understanding, don’t even know where to start.
Yeah, that whole clockwise/counter-clockwise thing is needlessly overcomplicated. Just sampling the initial direction should be enough.
I found a bug in the latest SelThrough build - doing a box selection in Outliner instantly crashes Blender.
[BUILD]312 Select Through
Autoxray wont look for view3d when it doesn’t exist and crash blender, also made it where you cant do a select through fully enclosed edges. Not sure I like that, but it will keep people out of trouble/consusion in the context noted above. I looked into making selected elements get drawn like was requested before. Best I could get going with that is making it look the same as xray with 1.000 alpha, neither unique or the desired effect. Getting just the selected vert/edge/face drawn behind solid shading is not a simple thing from a quick looking around.
Wow thats a bad one 
Its autoxray looking for view3d but its not there because it doesnt exist in that window. Need to check for that and also tell edges to not do fully enclosed for select through. Should have build later today, thanks
From 3.2 onwards I’m going to use the build I make here, with the additions I make for myself, as my personal build. That way hopefully I catch some more of these myself so you guys don’t have deal with it as often
I think as an official feature the best shot is still as tool settings. There are almost none on the selection tools so I don’t think it’s a big deal to add some there.
This would just need a design, probably one to replace the current one for face dots.
It could even just be as simple as a “Select through” and “Auto-Xray” toggle.
Select through in this case would not use face dots, while auto X-ray would. Maybe that’s the most intuitive way of dealing with it.
I’ll keep an eye out on this thread and any future tasks but I have to focus on other things for now.
I personally wouldn’t use Auto-Xray anymore if it forces me to use facedots. That would be a step back from what is currently possible in Lcas’ build.
I am okay with them being tool settings if it means that all Select through and Select whole/ partial elements can be propagated across the various box/ lasso and circle selection tools. But @JulienKaspar, what would be the UI indication that Auto-Xray or Select through is enabled if they are tugged away in the tool settings? Or is that a matter of try and you’ll see it anyways (which I think is fine).
I am okay with them being tool settings if it means that all Select through and Select whole/ partial elements can be propagated across the various box/ lasso and circle selection tools.
I think that should be doable.
For using the Tools from the Toolbar it should be fine as just a toggle in the tool settings. The header is showing those by default and it’s not obvious how to hide it. So if someone is hiding the tool settings I’m sure they know what you’re doing 
For the shortcut operators I’m not sure. That should be a separate patch, maybe to include those options as modal keymap entries? For example:
Press B → Draw a box → Press Z for Select Through-> Release to accept
It would probably just be important that it remembers the toggle for the next box selection operations 
Or the shortcut operators could use the Tool Settings as their default settings. But that’s a bigger change throughout Blender and less likely to happen soon, even with lots of support.
But this is why a design task and prototypes are so important. You don’t want to have those questions flood in with a final patch that is in review.
Speaking of Adaptive/Directional/Manual selection types.
From my long-standing observations on this issue, a picture emerges of a rock-paper-scissors-like system.
None of these solutions are perfect, the only difference is which limitation you will agree to cope with, which mostly depends on the preferred workflow and conditions you belong to.
But why? Just to be clear - auto x-ray is a feature that temporarily enables x-ray shading while you drag a selection, so you could better see what you are selecting. I don’t see why it should use different settings than the regular “blind” Select Through. Basically how @lcas build works right now is good in terms of functionality, it just needs UI clean-up. As you said, tool settings seems like the best option.
I’d say directional selection is not a problem but a solution to the other 2 problems 
. It doesn’t matter in which direction you draw a rectangle, in the end it’s gonna look the same, so there’s no situation where you couldn’t make a desired selection with directional approach.
What’s the deal for the never ending discussion. Why not just get power select addon and all with x-ray is good.
That’s pretty neat, thanks for bringing it to my attention. I skimmed through this video to get an idea what it does. It covers a lot of different things. Some of it I will see if I can figure out how to make it work, because I like to do that for fun if it is something I think is useful.
It does a few things that are available through the keymap alone, like the doubleclick to enter edit mode. But it also has some useful tricks like the “tweak” stuff together by saying if there’s more than 1 vert/edge/face selected to do a move instead of a tweak.
First thing regarding this subject, select through, is that it doesn’t seem to do that at all. It does autoxray, but at a cost of $10 or $15. You can get that, with a little more functionality from what I could gather from the video at least, for free with this:
The “endless” disucussion will likely continue though, since that paid addon doesnt even cover select through. Just autoxray, and a bit strangely where it has issues if you click on the object itself. You gotta do a lasso with multi-modifier shortcut stuff. I get asking for money, but it comes with a bit more expectation than what it’s offering, honestly.
Going to finish up a few things with my personal build, then cut it down to just 3 tool settings like was suggested by @JulienKaspar. I’ll make a test build to see what you guys think, 1 checkbox for autoxray, 1 for select through, and 1 for select by face area. Nothing different from real blender regarding facedots, or selection of faces or edges differently. Select through will always do face area, and all edges to avoid any trouble or confusion. Let me know if there’s anything about that you want changed, I’ll probably get started in a day or two. Will continue adding a more flexible build if needed, which would allow facedots to be hidden etc. Hoping that won’t be necessary but I don’t mind.
Ok,
but it selects through in x-ray mode. Anyways it was just for understanding the difference.
By the way, I tried to install x-ray selection tools 4.1 on blender 3.3 without luck getting it enabled.
I used to use them until they stopped working - that was the reason I looked up for power select to have x-ray select trough. There was another tool also stopped working.
So I hope you’ll get it working next week to all our liking, bringing more options to x-ray and select through etc.
People mostly trends to start the selection from empty space, to have a better control of an opposite box selection side since it is the most flexible. In directional selection type you often have to start a selection from a model, or control less flexible corners. Something like that:
The Adaptive/Manual has some advantage if you have to work with complex contours, and directional have some advantage when you have to work with overlapping geometry - for example, it is popular in architecture where are lots of windows in walls, but, for sure, none of those advantages can be considered as critical, and everything is case-dependent.
I guess the Adaptive one was originally selected as the default one because it provides the most flexibility for the least amount of options (it doesn’t require any options at all, so it’s minimalistic).
Power select addon
An interesting concept, but it seems to be suitable mainly for exterior modeling, because when modeling an interior, the model takes up the entire screen.
In general, I think that any UI solution can be solved with an addon, as long as the API provides technical support for the functionality. This will provide any desired user interface flexibility while avoiding custom builds of the entire program or controversial hardcoded UI solutions.
Thus, as soon as the API provides functionality, even without being stated in the interface, the reason for having an “endless discussion” will be exhausted.
Not making a custom build is the goal, but I do one for myself because I can. I share parts of it here because kio’s patch made it possible for me to get this feature, and this is where I found it. The alternative is waiting around hoping someone solves my problems for me. I wouldn’t want to be in that position, and I’ve tried to encourage others to do the same for themselves.
The “endless” was in quotes as a response to a rhetorical question that amounted to “No need for talk, guys, this addon answers all our prayers” but unfortunately the addon is lacking. I don’t have an issue with the discussion, I try to keep it going if anything. I don’t care for arguing or complaining all the time since I don’t need to, there’s no reason for it when blender is open source, but will speak up when I feel the need.
So, the original goal is to define which functionality API lacks then, and patch it, that will allow to achieve any desired UI realization via custom addon, exposing and combining patched functionality?
Such an approach differs from trying to build a full stack (UI+API) versatile manifold solution that fits everyone everywhere at once and include all possible cases and workflows, as it looked from the outside.
For example, in the second case, the core developers must provide a complete UI-wise solution that will satisfy everyone, and in the first case, just additional API functional blocks for the ability to satisfy everyone.
@lcas do you then plan to submit a second patch for the facedots and perhaps the select by area/ included?
