X-Ray selection experiments build

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

Will Ignore backfaces work when selecting vertices? It would make retopology much easier. I’m always selecting occluded geometry

1 Like

[BUILD] Select Through 3.31

Yeah it works with verts, edges, and faces with box, lasso, and circle select. There’s some options for different ways of determining what verts/edges are facing the viewport.

‘Verts of Face’ will select verts that are part of a face that has normals that point toward the viewport. This is what I will be using because I just want selection to act more like I am expecting, instead of grabbing occluded geometry

But if you care about being more technically correct for some reason, you can use ‘Vert’ instead. It will look at the normal of each vert individually rather that the face(s) it is part of. This works faster, but will result in some of the border verts not being selected because their normals are just a little outside of what is wanted

‘Edges of Face’ is the same deal

‘Edge’ doing the same thing as ‘Vert’ where you don’t get some of the border edges

Besides these options, you can decide to keep the box, lasso, and circle select tools the same, or some combination of 2 of them, or have them all different from each other. Any of the tools can be disabled entirely, either by turning them off, or not having any of the vert/edge/face options enabled. Any combination of verts, edges, and faces can be enabled and disabled as well.

You can adjust how close the alignment between the viewport and the vert/edge/face needs to be. Having at 0 should be enough on paper, but it is not, it will catch stray occluded mesh elements. I had thought 0.1 was good, but it still catches the occasional stray, so I have the default backface threshold set to 0.15. Setting it to 1.00 will mean it needs to be perfectly aligned with the viewport. There is an interesting aspect of this regarding quad view. Quad view should show you the exact top, front, and right side of a mesh, but even with a cube it will not think it aligned until you set your backface threshold to 0.99 or lower. But if you just align your viewport using the numpad keys (num1 for front, etc) there is no such limitation, threshold at 1.00 and pressing num1 for front view will select these mesh elements as expected. This is all assuming a cube or similar flat surface aligned with front/top/right.

You can flip which direction it will filter out. I can’t think of a reason for this but it is there if needed. The button tells you what it is currently set to do, “Selecting Forwards” means it will not select occluded mesh elements that are facing backward. This is assuming you don’t have flipped normals and are not inside your mesh. I guess if you were inside your mesh looking outward this could be useful somehow.

A convenience feature, you can see and control which tools will use ignore backface selection from the dropdown, without needing to switch to the tool beforehand.

Another convenience feature. You can decide whether to use ignore backface selection in Near select, X-Ray select, or Both. If you also use ‘Select Through’ or ‘Auto X-Ray’ these are considered X-Ray.

Going to update the top post, and this post, with link to the latest build and some more descriptions

2 Likes

Tested it a bit and looks promising. Backface threshold based on angle works ok but still can catch strays unless is something really high like 0.9, but then has problems selecting front facing verts.(see video)


If only it could detect viewport faces by color, if it sees red unselect, blue keep it…
Also circle select has problems, it doesn’t update viewport selection of verts until it selects an entire face.
Thanks for the hard work!

1 Like

I got an idea why circle is messed up, if I’m right its a quick fix. Maybe its also messing with vert calculation or something, I dunno. Otherwise I have some playing around to do which will hopefully lead somewhere sooner rather than later.

edit:
Ok, so at least I got circle and the rest working right, I had tried to simplify the normal calc I made, I thought it was ok because it was still working for like 1 or 2 things I checked and I had assumed that if what I did broke it at all, nothing would work. Obviously not :grin:

As far as the monkey head, I think this is a demonstration of how this feature breaks down a little bit when dealing with holes in your mesh. Where if you can see the inner side of something that is technically facing the viewport, if there were no other obstructions like the inner side of faces that do NOT face the viewport, you can catch a little bit of an edge or a vert of this face, and magically it thinks that some or all of it should be selected when you really wouldn’t want or expect that.

So for now, if you are dealing with holes and some stuff kinda poking through that is still just facing the viewport enough, you can try switching to the plain ‘vert’ and ‘edge’ version instead of ‘verts of face’ and ‘edges of face’. But I found that also breaks down similarly to varying degrees with this type of situation. It is kinda surprising when you turn on the vert normals and face normals, they will point in a somewhat unexpected direction sometimes.

I’ll rebuild and reupload soon after I clean up an older diff that I had made before rewriting the normal calc and messed it up a bit.

1 Like

New build, description at the top. I think I’ll not duplicate the description and all that down here, just put the links again

[BUILD] Select Through 3.31
[DIFF]sthru311

I scrolled through my diff just now and saw one or two things that don’t need to be in there, like do_lasso_select_objects doesn’t need bContext *C for a while now. It doesn’t do anything but I’ll get rid of that, and have a closer look through it all after the next bug is found.

2 Likes

I tried to set up the keymaps to test if this patch could actually work to implement directional selection, but I don’t think it will do. The problem is that Blender has not 2 but 8 directions, so to fully cover left-to-right movement you need to create 4 keymaps, then 4 more for right-to-left. There are also 4 different selection modes, so 32 different shortcuts and that’s just for box select. 32 more if you want lasso selection to work as well. Having to set up 64 shortcuts just to get directional selection working sound like a form of torture to me :confused:
A multiple-choice setting in the preferences is a much more user-friendly solution. Directional selection has been in use in many other 3d apps for decades, and it always needs just two directions, no need to reinvent the wheel here.
Keymap control makes sense if you want to use keyboard shortcut though.

2 Likes

Yeah I went into it thinking it would be the same as the earlier patch, just in the keymap. At the very least I can slap the rest of that patch on top of what I did and put it in userprefs instead. I want to look at the keymap and see how easy it would be to do 3 things.

  1. Batch assignment. Be able to shift click multiple entries and change them all at once. For example, shift click a handful of box select entries, and then change it to ‘Extend’ or 'Subtract. Or change the direction type. Or change the element style to ‘Enclose’ or ‘Center’. Or change from ‘Shift’ to ‘Ctrl’

  2. Limit the directional behaviour to either 2, 4, or 8 way. Just a second dropdown next to it that would have your choice of EW, NS, NSEW, or the current 8 directional one.

  3. Toggle or Cycle through entry-specific options. Like if you are using the box select tool, have the ability to do a singular key press, and it would toggle things on/off, or cycle through multiple options like the ‘Touch’ ‘Enclose’ ‘Center’. User can throw an icon that changes to represent what is currently being done into the header, depending what you want it to show, with just editing view_3d.py (no need to compile on their own)

1 Like

Blender’s keymap editor could certainly use some improvements, but I don’t think it makes sense to get bogged down with right now. Even if you could implement some batch processing functionality, it’s not going to make managing over 60 entries any less absurd. And you would still have to manually set up everything in the first place. Maybe an addon could be written to automate this task, but it would be yet another flawed solution to a problem that shouldn’t exist in the first place.
Main issue with keymap approach is that it gives too much granular control over every possible direction and selection type, which is unnecessary and only complicates things. Directional selection only needs to recognise 2 directions - left or right, and work consistently across all selection types and modes. So trying to build upon the current patch by Harley Acheson seems like a better idea.

Current plan:

  1. Auto X-Ray design doc
  2. Have a closer look at Ignore Backface, make a diff
  3. Check out the keymap, I’m unfamiliar with how it works other than adding something to it
  4. Look at some object selection options, maybe sneak in a different way of evaluating select through (not going to work but you never know)

The 60 entries itself is crazy. My intention for element selection is more about having a choice in the matter, not necessarily about mapping every single one of them. Reducing the 8 way to just 2 is a thing that is probably not that hard to do, so I’ll look into it. It is possible for some madman to have all of it ready in the keymap (East for default, North for Center, South for Enclose, West for Touch) but not expected. At most I would think you would have to do double the setup, one for left, one for right. I don’t plan on doing any directional mappings for myself, personally.

The other keymap stuff (batch and toggle) are less likely because it is a lot of different things to check for and make sure nothing breaks. I don’t know how they approach things at all, but my assumption is that the directional stuff from the diffs by Harley and Erik85 would, at this point, be adding a redundant feature. I’ll do it regardless, but I don’t expect much to happen since it already exists in the keymap.

1 Like