X-Ray selection experiments build

I just did a quick test of two things. 1st was just saving a file from the debugbuild directly from visualstudio, with all default settings. And then another file with everything I could think of being different, even the other stuff like the cursor or header highlights. Don’t see any non-default behaviour when opening this file in the official 3.2 release.

Either way I’ll go through this later and take everything out of toolsettings just to be sure. But unless somebody finds it acting weird in this particular way with sharing blend files, I’ll wait until 3.3 or whatever else to do it.

I did notice a problem while making the weirder blend file, where hiding the x-ray button also hides the auto x-ray button, so I’ll have to see why that’s happening.

Doesn’t it depend on the default file settings? And whether or not you have enabled the Load UI?

There’s a selection menu in your build atm (not sure if it’s in vanilla too):

I would also think this should be a preference setting.

1 Like

No, I guess this is expected since 3.2 doesn’t have these options that you added, so there’s no way that would confuse it. But if this goes into master, then Blender will load the settings along with the scene, making it a potential issue. Unless I’m missing something ? always possible

1 Like

If any of it ever makes it to master, it wouldn’t be in the custom build any more because it wouldn’t be necessary. If some version of any feature made it to master, and was “insufficient” enough to consider keeping it in the custom build, I would just modify it (in the typical opt-in fashion) so that everything plays nice with each other.

Knowing about this does make it easier though, I’d rather leave things as-is unless it has a problem.

I think one problem here is that this build tries to cater to all people dissatisfied with blender’s current select-through options. But not all people are dissatisfied for the same reasons!

I agree that this panel of buttons looks way too baroque. Designing a good UI means making choices for the user so (s)he doesn’t have to bother with them. Which is I think the main reason no options for select through have been added to blender master yet. Being too strict in this design philosophy can hurt as well, though.

I think it would be useful to try to find 1 toggle that most people on this thread can agree makes thing better (even if not perfect). And keep the rest of the settings out of the UI, but accessible via python so an add-on can add the UI for people that really want it.

Finding that 1 toggle is probably very hard though … :smiley:

And I have to add: lcas congratulated on your tenacity! Complaining is easy, actually trying to do something about it is better.

3 Likes

It was already proposed - a switch between 3dsmax (classic ST) and Blender Default approaches.
It was also an initial goal of a KIO’s patch.

It was also proposed to provide the backend API functionality for the ability to construct any frontend UI via python.

But I like that we think the same way.

This is what blender does, without telling you. I’ll change the edge “enclose” to “adaptive” for clarity.

With faces, you have to box/lasso/circle in both solid and xray shading to figure things out. Because despite being able to turn on facedots in solid, it will not use them. And despite solid shading working with face area selection, x-ray will not allow this. Neither solid or xray has any indication of this, or a way to change it. You could infer from facedot visibility being forced on you in xray that you need to select by them, but it is not consistent with solid shading’s ability to turn on facedots and forcing face area selection.

With edges, circle only has 1 way and that is by touch. If you touch an edge with the circle it will be selected. With box and lasso you have to drag over one or more edges, but not fully enclose any of them, to realize it will do different things. None of this is ever explained, at least not that I’ve seen, and now it is laid out for you.

Beyond that, you now have the ability to further customize this behaviour to your liking. If you do not want to do that, you never have to open this popover. If you never want to see the popover itself, I could make another checkbox to make it disappear from your header.

This is what select through does. It’s been a while since I used maya, which is probably the same as max, so let me know.

If you want to switch between the two things, you click the button, or assign it to a shortcut however you want.

@1D_Inc

I will try to explain the issue without making it even more confusing.
In short, there is no way to

make ST mode always use area selection in both Xray and Solid modes, according to classic ST behaviour
and make noST mode use facedots selection in Xray, and area selection in Solid, according to Blender defaults behaviour

This has never been the way these select through builds are. Both of these things were always available. I think you are just unfamiliar with how this works. Click button, switch between the two. You could do this before this latest build that lays it all out for you. You just had to read the tooltip for “xray facedot” checkbox if you happened to be fullfilling the requirements for confusion (in x-ray shading, x-ray facedots visible, both “xray facedots” and “enclosed face” on). That would result in the potential for intending to select by enclosed face, but you are getting facedot selection in x-ray. That’s because I gave x-ray facedots priority over enclosed faces. Why? To preserve default behaviour. I actually like it being laid out though, and now that they are all enums instead of bools, there is nothing unclear or unspoken.

@Baardaap
Yeah it would be nice, but is it really that bad? Everything can be hidden away, even the selection filter popup once I finish 3.21 update. Nothing has to be changed unless you want something other than default blender, or default select through, to happen.

Nothing in this build is something I expect to get a second thought from devs for addition to blender. These are all things that they could add if they wanted them, they do not need anybody to point it out to them. That is what I’ve tried to say a handful of times about select through. It would take an afternoon, or 15 minutes, depending how bad something could mess up other stuff. They do not want these things, it is good enough as is. But since I can do this, I am. Why keep it to myself? I get plenty back anyways from feedback, making it a little different, adding a couple things here and there.

1 Like

I just thought of something, I’ll throw all this mesh filter stuff into the keymap. No more popover that doesn’t attach itself to the vert/edge/face selector thing no matter what I do. It would be the same thing with minimal script editing, just have to split box and lasso from each other and tell the keymaps for box/lasso/circle to expose these enums. I think that will be a little more pallateable until something more consolidated is figured out.

Also if you want to see the extra cost of selection by face area vs facedots:
Go into xray of a higher poly mesh
Set filter for xray face to center
Enable the select through filter
Set filter for select through face to touch
Either disable both of the circle filters, or set them appropriately like they are above
Use circle select with and without select through, if the mesh is high poly enough, you’ll see the lag difference between the two. Face area will be slower of course, but it isn’t too bad on my system anyways. This lines up pretty close with the speed tests I did a while ago, where it was <.025 seconds on a high poly cube.

I am under the impression that it is really difficult to get to a consensus, we’ve been trying for years now. So each and every time someone suggests that we should reach an agreement and have Select Through be a single button toggle, it also comes across as rather dismissive IMO. Usually, it’s people complaining who haven’t participated in the entire discussion who don’t seem to be understanding the complexity of this all and why there are different opinions across the board. I understand this and was guilty of it when I joined, but please then also keep contributing to this thread, instead of throwing a boulder in front of the driving car…

Also, Lcas build is more than just Select Through, it’s a selection method revamp. Theoretically, you may get, let’s say 60% functionality with a single button. And that’ll still leave people wanting more. Moving things to an addon sounds nice, but then the addon should be one that’s bundled with Blender by default. And it needs to be maintained, otherwise, the functionality is made for naught. And do people really think that addonifying such a core functionality makes it easier on the user? I think that’s a terrible design philosophy that is hurting Blender all over the place as much as it also contributes…

It sounds nice in theory, but it seems to be advocated by those who don’t want the additional functionality and who prefer a clean UI. Something that is already catered for by hiding options. But then people complain that the options are too much, but they are hidden! And they said they won’t use them (for the non-Xray features)! So then, why should this very vocal group ‘dictate’ the build if they Lcas tried to address their concerns as best he could?

And why is there so little constructive feedback on how to actually improve stuff? Removing buttons is a chant, it does not tell any of us how, nor what functionality is or is not desired. If you want these features then help discuss them in detail please.

1 Like

That’ll be pretty difficult to set-up then won’t it? You have 3 x 3 selection keymap items (by default) and 3 modal ones, shouldn’t it reside under the preferences instead? It could be under the selection tab I mentioned previously and then under a subheader for “Advanced selection settings” that people will have to expand twice (first for the Selection and once more for Advanced selection settings) to get to this whole list of settings. Then it’s also hidden from view/ the interface. At least, it won’t be a keymap hunt to get everything right straight away then.

Or will there be an addon that toggles all these buttons for you, which is nested within the preferences? :zipper_mouth_face:

1 Like

I’ll be able to say for sure once I get it going, but it should be about the same as it is in popover form. You’d have the box select keymap with some enums added to it somwhere, that are all set to what you’d expect as default:
Near face = Touch
Xray face = Center
Edge = Adaptive
Select Through Face = Touch
Select Through Edge = Touch

Lasso woulde be the same, and circle would only have xray face & select through face. Instead of being expanded out, each one would just be a dropdown where you only see the thing it is set to.

It is a little more dynamic and allows you to swap as many as 5 different things at once without needing to make a python macro or something. The tradeoff would be you can’t just toggle something one time, select a few things as normal, then toggle it back again to something else. Other thing is if you wanted to change them from default, you’d have to adjust it more than one time in the keymap (for each of the new, add, subtract, etc you want to assign for each tool) but that would be the end of it for most circumstances.

I am thinking I will have mine setup like this
the standard stuff with most of it set to touch
left mouse = new
shift leftmouse = add
ctrl leftmouse = subtract

then have enclosed it I wanted it for some reason
alt left mouse = new
alt shift leftmouse = add
alt ctrl leftmouse = subtract

It is limiting enough in different circumstances though I think. Will be optional the more I think about it, like select through keymap is optional. It adds some, but takes away some as well.

Yeah, the quick enable disable is probably something that should remain possible. I would rather press a toggle button/ hotkey to change enclosed to touch and vice versa, just as with select through. Some want to use an additional modifier key, others prefer toggles. How do we satisfy both? Adding it to the keymap would be necessary for the modifier key users. What do others think?

What is the link to the latest build?
Is it the same?

Both of these things were always available.

Yes, they were available, but there was no way to switch between them via single button press.
It was button + checkbox way.

No, that was pretty much it, click button, it switches. If you don’t change anything ahead of time, select through is off. You go into xray, it uses facedots. You turn on select through, by clicking the button (or going in 1 time and switching to that mode in the previous build) and it will use face area. If you want to toggle between the 2 things, you turn select through on/off with a single click or keymap shortcut.

The way it is right now, select through has its own mesh filter, separate from xray. This means it has the same thing going on. By default xray will use facedot, and select through will use face area. You have an ability to simplify things by disabling this filter if desired. The shortcut for switching between filter types is different now, where it brings up the enum with all 2/3 options instead of a per-checkbox on/off. But that will probably be a little different now as well, where I’ll add a keymap entry for these things for those who would need to do a lot of switching between filter types instead of just setting them up one time and leaving it alone.

Things could get a little more confusing when it’s unclear when and what a “select through” was. All it ever was is an xray select without going into xray, so for some time it may have worked with face area when not in xray shading, and with facedots if xray was on. But that starts getting into like a semantics thing where it’s like, should select through affect xray, when it isn’t even applicable because xray is on? I don’t know, I think the latest thing I did makes it where the select through filter will apply if select through is on, xray or not.

One more thing I’m remembering. Even in the builds where you are in xray with select through on, and it would select by facedot, you have one or two things that are available. You can turn off “xray facedots” or toggle facedot visibility. Either of which can be assigned to keymap for those who need to do that a lot. I’m starting to wonder what build or situation you are talking about where it isn’t something that is a one-click thing.

Select through never even had an ability to use something different until very recently. When I added enclosed face I always made sure the “default” select through behaviour (face area) was there when switched on, and the default (facedot) was there when it was off. That’s what it should be doing anyway.

I’ll add a 321 build soon, probably a week or so, messing with this right now

1 Like

It seems you are right.
321RCLiteSthruPreview indeed work this way, and the issue I described belongs to 32Sthru version.

Probably, I got too much custom builds with different functionality to test, and launched outdated version or something. It is hard to follow lots of different developments simultaneously - each one has its own custom versioning style)

This should just be built into the default… I don’t get why Blender seems to have such sloths gatekeeping things… no wonder Blender development and improvements in UX and workflow is so awful… still tons of things about Blender that just plain suck compared Maya still… another decade maybe?

Been busy with some other things but also with adding features to this build that have been on my list for a while. First one is ignoring backfaces, spent a while trying to get that working but couldn’t figure out the important part where you get accurate information about face normal vs the viewport. I was trying to just subtract one from the other, but then I got some seriously appreciated help with that from @Chris_Blackbourn. Need to add it to xray which should be easy, then also do edges, and probably verts.

Second feature is near select by facedot, not nearly as useful or exciting, but while I was trying to get ignore backface selection working I saw some things. You know how after a while something that was a bit of a mystery will finally click and you understand it a little bit. Then 20 minutes later I’m done with something that had eluded me for a long time.

I am planning on the mesh element filter thing (select by facedot, fully enclosed, or touch) just being one thing for faces and then another for edges (fully enclosed, touch, hybrid). There would be no distinction between xray vs near select, which would be different from default blender. So in this case I am thinking an on/off for a custom mesh element filter makes sense, that way if you wanted some other part of this build, but not the mesh element stuff, you aren’t forced to change anything. The keymap element of it also needs to be done, should be pretty straightforward though. The point of the keymap would be a slightly more customizable way of switching between different things, or just setting them up differently for each tool if needed. With some more consistency with near facedot selection, I have a clearer path forward to a simpler mesh element filter that is easier on the eyes/brain.

Still working with 3.2, will update to 3.3 once I get close to finished. Usually a few things here or there that need to be adjusted between versions to get it to build.

@Koolio thanks for your interest in this build. It isn’t gatekeeping in the way you are trying to frame it, but regardless, how and why the devs decide what to include in blender is necessary. Try to think of this build like some half assed pimp my ride. You wouldn’t go to a Ford dealership and demand they start selling squatted trucks, or lowriders, or hondas with a park bench for a spoiler, or whatever weird modification you are into.

Also keep in mind that one of those devs is the only reason select through works on newer builds or that it works a lot faster once I finally got things rewritten based on his advice. Since you feel strongly enough about at least part of my build, I think some respect toward the devs, perhaps an apology even, makes sense. I normally would like to have some fun at your expense, if for no other reason than to try and set a tone of decency around here, but I wouldn’t want some kind of thread splitting to happen out of sheer ignorance of what is actually going on or something, that would be crazy.

7 Likes

[Test Build]Select Through 331 Lite

Uploading this test build before I go to sleep, its a Lite build so no cuda binaries and stuff like that. I’ll update with some screenshots and videos later. It’s mostly the same, just some new buttons in the header. See if you can find your way around without me telling you how it works, shouldn’t be too complicated but I’d like to know. I could simplify things more, but I like the modularity of it, I’ll explain later. It has default settings that make sense, but you won’t get them if you already have a startup file for 3.3, which you probably have. Don’t know what to do about that one except tell you to set them manually the way you want or start from scratch (temporarily) and see what I think makes sense.

If I send different parts of this for official review I will simplify them, but that will come after we check it for problems for a while. For example, I think that the ‘ignore backfaces’ selection would just be a checkbox next to backface culling. It will do what is most likely to be expected, take it or leave it. I will not do anything that streamlined with my build, because I don’t see the point in limiting that much. There’s enough going on that it makes sense for you to have some control over it. I did include 1 thing that is not very useful at the moment, ‘flip direction’ but who cares. In near select all it will do is select what is normally filtered out. For now it’s one button extra, and it might be useful later. If it looks good enough for submitting something, I’ll try to get it closer to what the devs would probably be looking for, shaped by whatever feedback I get from you guys.

Doing all the different selection styles requires more initialization but it is basically free. There’s enough variance that sometimes my build will show a faster time despite doing a few extra bool and int checks.

I left the timing prints on for box and lasso if you want to check that out. Circle is a rapid fire thing, and rapid fire prints are a huge performance hit. I’d rather you get to see what’s up and report any issues without having to keep in mind that circle will actually be way faster when it doesn’t print every time it runs.

Box select times for a cube of 1.5 million verts, windows 11 5800x cpu. The ‘of face’ versions of vert and edge exist because if you only want to use the normal of the vert/edge itself, rather than seeing if they are part of an elible front facing face, you will not select some of the border verts/edges. Just try the two modes for ignore backface edge and vert, you’ll see what I mean.

official blender:

near verts - 0.270556

near edges - 0.389459

near faces - 0.157972

xray verts - 0.185752

xray edges - 0.256259

xray faces - 0.274512

my build, ignore backface:

near front verts - 0.291056

near front edges - 0.532142

near front faces - 0.233752

near front verts of face - 0.288907

near front edges of face - 0.603311

xray front verts - 0.286604

xray front edges - 0.809353

xray front faces - 0.377577

xray front verts of face - 1.358527

xray front edges of face - 1.342028

My goal was a more accurate near select and this will do that assuming you aren’t inside your mesh or have flipped normals. Near front vert/edge/face are pretty fast. Edges are slower so I think they take longer to calculate normals, I’ll check later.

Xray is mostly the same, but the ‘of face’ versions of vert and edge take much longer. This is because it’s in xray so every single vert/edge is selected, so it checks all of them. Half of them are not eligible but they don’t know it until they look at the normal of every single face they are attached to. You can imagine this is a lot of unnecessary work, but it isn’t likely you are going to be dragging over the entirety of a 1.5m vert mesh very often.

The other stuff like near select face center and enclosed circle edge/face aren’t likely to be of any significance time-wise. I’ll check them later just to be sure.

4 Likes

What is the use case for ‘Ignore Backface’ toggle? I tried the typical problematic example with a cube inside another cube with inverted normals, but it’s still not possible to select inner cube like this:


It seems like faces closest to the camera block any selection behind them.

Also the subdivision modifier doesn’t work in this build for some reason. Maybe because it’s lite? I would like to test auto xray more thoroughly, but I need subd for my work.

2 Likes

I think you’re right about lite not having subd, because the lite build I made of just blender with selection time prints doesnt do it either.

For the backface test to work without going into xray you have to use select through as well. Near select just does what it does, it doesn’t actually care what it can “see” as far as when backface culling disappears something. It just cares what it hits first, and then stops without going further.

Looking at a few things, mostly wanted to see about adding single click select to ignore backface. Probably not going to happen, but I wanted to check it out. It would need to re-run itself until it either found a vert/edge/face that is facing the viewport or ran out of things within the selection radius.

After that I’ll show the reason I made ignore backface, to get an idea you can see this

edit-
Here’s my primary reason for doing the ignore backface, though I’m hopeful that the other benefits of it in xray + select through are useful for other stuff. I’m not familiar with any of that but I’m always looking for new things or new ways of doing them. I’d like to see it in action if anybody feels like demoing it, whether this build (once I upload the full thing in a bit) is capable or if somebody can show something else doing what is intended.

Anyways, the problem I have with near select is how it grabs other stuff you wouldn’t want it to. I will call this ‘overdraw’ because from what I’ve read -

Selecting faces in edit mode uses OpenGL to make a drawing that maps all faces within the rectangle.
Some pixels of faces that should be 100% occluded are still drawn. This is because these faces share a same edge as the face that occluded and the threshold between drawing and not the face is hard to distinguish.
I can’t think of an efficient solution to this problem.

I will be using ignore backface for all of my near selections I think. It isn’t 100% perfect, but I find that a threshold value of .15 is realiable enough without affecting what I call ‘underdraw’ which I’ll cover in the next section after the video. I had set the default for threshold to .10, but I keep catching a stray face here and there so I’m going to set it at .15. Here’s a demo of the occasional stray face with .10 theshold, the likelihood of this happening at .15 should be very low, and you can always tune it to your needs in any given situation.

What I call ‘underdraw’ is the opposite situation that you get with near / bitmap selection. I cannot offer anything to fix this issue, but maybe a rewrite of the viewport with vulkan would fix this, either directly or incidentally. Not happening anytime soon though I think, because last I read nobody is assigned to it. But at least this is not made worse with a reasonable ignore backface threshold. A demonstration, you can see that whether ignore backface is on or not, the same faces are not being drawn aggresively enough for bitmap select to “see” them.


Depending how dense your mesh is, you will have to go looking for overdraw and underdraw to have an issue with them as long as you set a reasonable threshold, again, 0.15 is what I’m liking so far.

The alternative is living with what I consider a very unrealiable near select:

None of what I’ve done would be possible without the help and advice I’ve recieved from developers and contributers when I run into trouble that I can’t figure out. In hindsight some of it is braindead stuff, but other things like quaternions I may never really wrap my head around. It is interesting to me though, so there’s a chance I can take the time to understand them.

Going to upload a full build this weeked I think. I will put off any new stuff until at least 3.4. I do think I could at least fake a single click selection that ignores backfaces by using circle select and telling it to only select one element inside of its radius, and maybe not rapid firing too.

3 Likes