Decoupling x-ray and limit selection to visible

[1D_Inc]

Indeed, it is very controversial topic which already started several massive holywars.
Many words have already been said, many proposals discussed.
However, here is our proposal of a single button solution to this problem in the summarizing post, as a result of all those negotiations.
It is pretty simple, safe and can satisfy both sides.

[blented]

Is there an update on when this checkbox will be added back in? Removing ‘Limit selection to visible’ it in 2.8 has clearly upset a lot of people, is there a place we can vote to add it back?

The thread posted by MetinSeven doesn’t seem to have any sort of ‘accepted’ or ‘pending’ status.
https://developer.blender.org/T73479

[snakedogman]

Another sign-up from me to voice my wish for this option. Sometimes it seems like Blender devs get a bit too stuck in adhering to some “paradigm” instead of looking for the best solution to a problem. Adherence to paradigms should not trump usability. Adding one checkbox does not suddenly make Blender too complicated. Surely more checkboxes and controls will be added in the future as more features get added.

[Justo]

So depressing how the devs completely ignore this long-standing issue. My team refused to adopt Blender at work because of this, and I need to rely on modded releases to be able to select comfortably. Despite the mega-long thread here and in developer.blender.org, for years there has only been radio-silence from the devs, unless people become “sour”.

@lcas Have you perhaps kept releasing modded releases using the original patch made by thomas in newer releases? Any 2.92 stuff llaying somewhere? Still using your previous 2.83 mod.

[LudvikKoutny]

Every time there’s new stable blender release, I make myself a version with Kio’s original patch. Luckily so far it has mostly worked, but I am worrying every version that something will change and I won’t know how to fix the patch. Then I will have to use outdated Blender version because I simply can not imagine using Blender with the unusable, face dot based, broken selection in official builds The modeling productivity becomes incomparably worse.

Here’s 2.92 with the Select Through patch. It has just that patch, otherwise it’s completely same as vanilla 2.92:

Blender 2.92.zip

I will try to make 2.93 as soon as it’s out, holding fingers crossed that the patch will still work.

[lcas]

Thanks Ludvik, I’m pretty optimistic that there’s nothing too crazy that would make a select through patch prohibitively difficult. I base that optimism on the approach the devs have taken so far. For example with the BKE_mesh_wrapper_ensure_mdata that was given, it’s what makes the 2.83 (or 2.82?) patch work. It’s not what anybody really wants for efficiency’s sake, but it works fine.

I’d started working my way through a couple C books, hoping to get a clue what I’m doing so I can rewrite Kio’s work for the newer way Blender handles meshes. But you know how reading text books “for fun” usually goes, always something more important that needs doing, right?

If the current workaround stops, it would hopefully be something really easy like it’s been so far like changing a variable name. I’m also pretty sure that if that happens, the newer and improved workaround would already be written (and probably implemented for select through functionality) by the devs.

I just started going through from scratch, building Blender for the 2.93 release, you know refamiliarize myself with a few things. I’ll throw up a diff patch and/or full build as well, thanks again for any help and feedback, it’s good to know when somethings messed up so I’m not using a bad build myself

[lcas]

BUILD 2.93.0 Select Through Facedot

DIFF 2.93.0 Select Through Facedot
This separates Facedot display from the Select Through tool setting. Before, facedots in xray showed up depending on whether Select Through was on or off. Now they will show up based solely on the usual “Center” checkbox in Viewport Overlay dropdown. This Center checkbox will no longer be greyed out in xray mode. Selection by facedot vs face area will act according to facedot visiblity. Can select through by facedot in solid shading mode, I don’t personally like this but it could have it’s uses. I would like to figure out how to select by facedot without selecting through, but haven’t seen anything illuminating enough to hit me over the head with a solution for that.

BUILD 2.93.0 Select Through Kio

DIFF 2.93.0 Select Through Kio

This is the same Select Through as Kio made it with one difference. When I’m working on different things, I modify the timing print to be done at runtime because I rarely if ever do a debug build. This is just a thing that shows up in the console window to tell you how long it takes for each select operation to complete. Useful for curiosity’s sake if nothing else, but you probably don’t want it printing every time you select in a release build. Kio’s build doesn’t do that of course, but the way I modify his work for my own convenience it would, so I remove it after I’m done with testing. I don’t even know if you actually need to make a debug build for this time printing to happen, maybe there’s some setting or command that makes it come up in a normal build. Anyways, if you want to check out the time printing to see how fast (or slow) it is doing different selections, grab this other diff and make a build.

DIFF 2.93.0 Select Through Kio Timings

As far as what else is different from Kio’s original work for compatability, there’s a couple variable name changes and the BKE_mesh_wrapper_ensure_mdata workaround:

view3d_select.c
Change mcords to mcoords

Change moves to mcoords_len

view3d_iterators.c
Add up in the include section
#include "BKE_mesh_wrapper.h"

After Mesh *mesh = editbmesh_get_eval_cage_from_orig( vc->depsgraph, vc->scene, vc->obedit, &CD_MASK_BAREMESH);

Add
BKE_mesh_wrapper_ensure_mdata(mesh);

Change modifiers_getCageIndex to BKE_modifiers_get_cage_index

Change vc->ar to vc->region

For now BKE_mesh_wrapper_ensure_mdata is the main sticking point, because it’s slower to do things this way. If you’re curious about any progress in this area, you might want to keep an eye on the affected area of the scripts over here.
https://developer.blender.org/D7169

No promises, and the math or whatever else to get these operations done is probably totally different from select through, but they do need the same thing to work. So if one of them is re-written to be better, everything else might be close behind. I’m pretty sure I saw that one of them has been rewritten to not use BKE_mesh_wrapper_ensure_mdata but I haven’t looked in a week or two, and again, no promises for how relevant those changes are to my limited ability to essentially copy-paste my way to a faster select through.

I’ve added some more stuff to Kio’s work that I’ll upload later, as well as a full build of whatever versions I decide are different enough to bother. Haven’t done a full build on this new install, but I should have all the Optix and Cuda stuff. If there’s a noticable delay that’s probalby why. Either that or this ~100 KB/s upload, good thing Blender is small.

Just saw a warning about needing an older version of Cuda to be sure there’s no errors, and it keeps not finding optix directory, probably going to do the builds tomorrow.

Ok finally got the first build done, add Optix to your PATH or you’ll waste like 3 hours futzing around to no avail

[LudvikKoutny]

I still can’t manage to build it, even after having optix in my PATH.

How did you do it?

[lcas]

Well if what you mean is that it builds but there’s no Optix, I had to add this to Path C:\ProgramData\NVIDIA Corporation\OptiX SDK 7.1.0 because no amount of manually entering it to CMakeCache.txt was working for me. One idea I had was that I was always changing the slashes because that is how everything else in CMakeCache.txt is, who knows maybe it wants it to be different.

If what you mean is that it won’t build at all, you have to tell me more probably. In any case here’s how I do it, going off the top of my head anyways:

1. Follow along here for Windows: https://wiki.blender.org/wiki/Building_Blender/Windows

2. Use only the highest version listed for Cuda and Optix here: https://wiki.blender.org/wiki/Building_Blender/CUDA

3. Yesterday the 2.93 branch was still showing “2.93.1 Release Candidate” in the splash screen, so I specifically checkout out the 2.93.0 tagged version, not sure where it’s at today haven’t looked. Here’s how to do that, shouldn’t matter though: git checkout tags/<tag> -b <branch> you can find tags here: https://developer.blender.org/diffusion/B/tags/master/ But like I said in the earlier post, there’s really no change from even way back with Kio’s original work for ~2.80. So if the DIFF will apply, it should build, it just wouldn’t have Cuda and/or Optix showing in your Cycles Render Devices in System

4. Apply the DIFF git apply and then just drag the file into your command line window it will fill in the rest. If you have something going on with changes in it already, make a DIFF of your own or stash it somewhere and then do a git reset --hard to get things back to default

5. Assuming there’s no error messages, I do a make release nobuild This is where it’ll tell you whether it can see Cuda and Optix

6. Open the output folder for your nobuild, open the Blender.sln file in Visual Studio, change configuration from Debug to Release, show the Solution Explorer if it isn’t there, expand CMakePredefinedTargets, right-click INSTALL and say Build. Then wait for a long time because I’m compiling not just Cuda 7.5 for myself, but all of the different versions that it can. You can change this by editing CMakeCache.txt and looking for CYCLES_CUDA_BINARIES_ARCH:STRING and filtering out any versions you don’t need, what versions you need depends on GPU: https://en.wikipedia.org/wiki/CUDA#GPUs_supported

7. After it’s done, go into that nobuild location, it’s all inside of the bin folder

[LudvikKoutny]

Yes, I made the usual mistake. Accidentally installed Optix 7.3 instead of 7.1

[karmakun]

It’s been a year since I stop using Blender for this very reason, Today I downloaded blender 2.93 thinking in a very naive mode oh well it should be fixed by now, what a shock!

I will be using the kio build, thank you guys.

[michalpe]

Karmakun, what is the kio build?

[LudvikKoutny]

Here’s a cool thing.

This is user response to the select though patch(https://developer.blender.org/D6322):

Result: Ignored now for over 2 and a half years.

This is user response to some semi-random changes to the default keymap (https://developer.blender.org/T88071):

Result: They are going forward with it regardless.

It’s hard to keep the hope up. Anyway, here’s 2.93.1 with the Kio’s patch:
https://drive.google.com/file/d/1SmSa0CAdZNbPX_khaJqMp0WBLFuwxsgk/view?usp=sharing

[lcas]

[BUILD]2931 Select Through Extra
[DIFF] 2931 Select Through Extra

Here’s a new one. It’s all the different ideas I thought about for select through in one build. It’s not too ridiculous, and might be useful to figure out what it is you prefer. Your workflow might change depending on context or project, so you might want the ability to change these options around anyways.

How useful these options are? I don’t know, but there’s somebody or something that might make use of them. What would stay in a polished, official build? Anybody’s guess. Even now it still doesn’t have all the features I’d like, namely select near by facedot. Plus there’s the inefficiency as noted before.

It’s slightly different so here’s a pic with some text afterward

1. Header button for select through, use this to assign keyboard shortcut
2. If you want separate controls for facedots in xray and solid
3. What it looks like with two controls
4. If you don’t want to see the header button
5. If you want to control select through independently for each selection tool
6. If you want to see facedots, but not have to select by them
7. If you want to see in xray, but not select through

Why a header button instead of a checkbox in tool settings? It allows for one shortcut for both independent select through and the usual one checkbox for all three tools. It’s just a custom python operator that toggles unexposed tool settings based on what tool your using or whether independent control is on.

The header button lights up in blue when select through is on. This is tricky, because as far as I can tell, the only way to get it to behave correctly is to alter the draw code. Normally the header won’t update itself when you change tools or tool settings unless you click in viewport or move the mouse cursor in/out of the viewport or the header itself. This results in the button actually showing you the opposite of what reality is, in regards to select through being on/off. If you want to see this oddness in action, just use the tool setting to hide/show the button. It basically looks like a dead checkbox, but it works. It just won’t show/hide the header button until you move the mouse back into the viewport again.

To at least get the button to light up correctly, I changed wm_draw a bit so that the viewport header will redraw itself while the mouse cursor is in the 3d viewport, but only when the select through button is on. If you don’t want to see the button, just right click it and assign a shortcut, then hide it with the tool setting, no extra redraws will happen. Doesn’t seem to have much of a performance hit, I’ll test out the timers later to see for sure. But really, its just that tiny strip of buttons at the top of viewport, shouldn’t be a big deal to redraw them and the viewport simultaneously.

Why two facedot controls? If you only want to toggle them in either xray or solid, or you always want them on in one and off in the other, now you don’t need to do any extra shortcut pressing.

Why independent select through control? If you want to change between selection tools and have them in different select through states, or you never/always want one or more of the tools in select through, you won’t need to do any extra shortcut pressing.

Why an option for “No facedot select”? If you need to see facedots but don’t want to select all the way into their center.

Why select near xray? I don’t know, honestly. It was a happy accident that I made a long time ago when I was trying to figure out Kio’s work, and I figured why not.

Couldn’t dynamically change the label for the viewport overlays so that it would say “Facedots” over the dual facedot textboxes when appropriate, so I had to cheat it a little by making the label blank and adding a line of text. Tried to remove the label entirely but it would error. This means there’s an extra blank line between Motion Tracking and Mesh Edit Mode inside the Viewport Overlays dropdown.

[slowburn]

This build works great and I didn’t notice any significant slowdown when using select-through, even on a heavy object. Definitely works much faster than X-Ray selection addon.
I like that with No facedot select you can still pick individual faces by clicking on a facedot, because it allows to accurately select one of the overlapping faces. Although when facedots are disabled, faces are still selected by facedots (for a single-click action), which are now invisible. So that should probably be fixed.
Right now probably the biggest issue is with the UI. All the new options in the tool settings are also shown in the header and they take up way too much space. Maybe it’s possible to hide them in the header? Also when using transform tools, those options are not visible at all, even though they still apply. Maybe they should be moved to the options section?

[lcas]

Gimme 2 weeks and I’ll come back to this to clean it up a bit.

Single click should be unaffected because it’s in a different area. Let me know what is different about it compared to vanilla Blender 2931. Other than being able to hide facedots in xray, I don’t know what is different.

I do know that single click has a large radius and will just select the nearest center when in face mode, sometimes cycling between multiple faces on a subsequent click. When I say nearest center, I mean in 2d projection based on the camera’s perspective. For example, you could have a face that is waaaaaay far away in depth from the camera, that is on the far side of another face relatively close in depth to the camera, but a single-click will select the super far away face when it’s center (in x,y screen coordinates) is closer to the mouse cursor, even though in 3d space it is miles away compared to the other face. And depending how you position the camera, it wouldn’t even cycle between the two faces like it sometimes does. Very interesting behaviour, hadn’t really thought about it before.

UI, I don’t even like having the toolbar header visible. I’d like to keep most of that stuff related to select through in the tool options so that it is available for asigning a shortcut. I wanted to put select through in a collapsable section the way Options and Workspace are. But those things act a little different, they’re all pre-configured and assigned to a group of similar tools rather than on a tool by tool basis. At least that’s what I gathered when I tried to do it real quick just before uploading this. I’d have to figure out how to create one of those, and then make it assigned to the applicable tools, while also duplicating what collapsable dropodown things are supposed to be in there.

Failing that, I can hopefully put a checkbox to show/hide them from the toolbar header, and then throw them in the transform tool area as well so theyre accessible for people who want to use them that way instead of just turning the gizmos on/off for GRS in the select tools. I use a different thing for doing that where you can toggle the different transform gizmos while also having modal transform accessed from the selecton tools, rather than the transform tools set to drag select actions.

[Alberto]

This still out of master?

[Znio.G]

In a way the Devs are right on their concerns which is probably holding it up, and on the other hand Blender does suffer from inconsistency since in object mode you can also select through objects.
Maybe a better solution is to make it as a preset shading type but without the face dots in edit mode and make it available in other modes/object types. So it’s X-Ray but not X-Ray since the two serve different purposes.
I personally would love to see it in the extra shading piemenu for quick switching between what’s visible and what’s not .

[slowburn]

@lcas

Single click should be unaffected because it’s in a different area. Let me know what is different about it

There’s nothing different about single-click per se. But if facedots are disabled for xray mode, it becomes quite difficult to select a single face, because Blender still expects you to click on a dot. So in this mode it should be possible to select a face by clicking anywhere on it (like in solid shading).
If facedots are enabled then everything is fine.

[lcas]

@Znio.G

In a way the Devs are right on their concerns which is probably holding it up, and on the other hand Blender does suffer from inconsistency since in object mode you can also select through objects.
Maybe a better solution is to make it as a preset shading type but without the face dots in edit mode and make it available in other modes/object types. So it’s X-Ray but not X-Ray since the two serve different purposes.
I personally would love to see it in the extra shading piemenu for quick switching between what’s visible and what’s not .

I’m not sure what you mean. If you mean that select through functionality should be hidden behind a shading mode, then it’s already like that. If you want to select mesh elements that are unseen, you have to make them visible by going into xray.

But the whole idea of select through is to get the selection functionality of xray without having to change shading modes. I’m only dealing with xray and facedots because they are some of the baggage that has to be addressed when implementing select through. In the latest build I made, I’ve tried to offer a reasonable amount of modularity so that different types of people and situations are covered.

Or, if what you mean is that you want an xray without facedots, and also the possibility of solid shading seleciton behaviour (where it won’t always select through) you can try out the build I posted. What you’d do is turn on Near Xray in tool settings and turn off facedots. It will show xray without facedots, and only select through when you drag select while select through is enabled.

If you basically want some shading mode presets that are accessible through the pie menu it might not even be needed. It becomes an issue of whether you’d rather go into a pie menu and switch between different xray shading modes, or just have the ability to turn off facedots in xray. A conventient way of getting all that with one click/shortcut is making yourself a python operator that toggles some combination of facedots, xray, and the Near Xray tool setting.

I’d be interested in what you need to do to add things into the pie menu, I don’t know because I personally don’t use them much. If you do a bit of looking around how to do that, and then also how to make a redundant xray shading mode, that’d be cool.

@slowburn

@lcas

Single click should be unaffected because it’s in a different area. Let me know what is different about it

There’s nothing different about single-click per se. But if facedots are disabled for xray mode, it becomes quite difficult to select a single face, because Blender still expects you to click on a dot. So in this mode it should be possible to select a face by clicking anywhere on it (like in solid shading).
If facedots are enabled then everything is fine.

That’s just how it works though, unfortunately. I’ve merely allowed you to (at least temporarily) remove the facedot training wheels. As much ire as facedots can get, they are still essential, but I enjoy having the ability to turn them off in xray rather than being handcuffed to them. This comes with some compromise with single click, but it’s prefferable to either not being able to single-click farside faces in xray, or constantly toggling select through for single click select when it’s really only useful for drag select tools. That degree of what is intended to be consitent, is crossing a line where it’s really just adding more confusion.

Why is that the way it is? When you’re in xray doing a single click on a face is different than drag-select. With a drag select in xray using either box, lasso, or circle, it will do a select operation (new, add, subtract, etc) on anything it touches. No issues whether you want to go by either facedot or face area.

But with a single click in xray, a decision has to be made, “Which singular element (or none if you’re too far away in empty space) do I perform a select operation on for the user?” The answer is the nearest one, regardless of xray or not, but again we are in xray so it gets tricky. Like I said in the other post, for xray it’s essentially flattening that 3rd dimension of depth and selecting the nearest element in x,y screen coordinates. For verts this is easy, the nearest vert. Edges behave kinda weird with single click distance thresholds, but there’s nothing like facedots for edges so who cares.

With a face, especially when single-clicking in xray mode to select it, you have to ask yourself a question, “What is a face, and where is it located?” Well, it’s a collection of verts, but you can’t choose a singular face based on the nearest vert or edge, because those will be shared by at least one other face most of the time. You have to average the x,y,z coords of the verts for each face. That is it’s center. That’s “where it is” more or less, and flattening those centers for xray select means that drawing a facedot there certainly helps for selection. But as long as you are somewhat close to one center more than another, you’ll be ok depending how comlex the mesh is.

Considering all of that, I don’t know of another way, let alone a better way, to represent a face than a facedot. And, for the purposes of xray, you kinda have to use them for single clicking, otherwise you’d only ever select the nearside faces of a mesh. Not selecting through in xray, for single-click actions, seems like a bad idea to me. But my ears are open as always, so let me know.