X-Ray selection experiments build

[lcas]

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.

[lcas]

[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.

[slowburn]

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.

[lcas]

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.

[Xorrito]

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

[lcas]

[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

[Xorrito]

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!

[lcas]

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

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.

[lcas]

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.

[slowburn]

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
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.

[lcas]

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)

[slowburn]

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.

[lcas]

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.

[Hologram]

For the directional aspect, I’d say add two options for left-right or right-left directions should do the trick. Probably the easiest to implement and you won’t have to fiddle or break the things that are apoarently already there.

[Hologram]

@lcas do you remember that I told you I had an error message popping up continuously? It seems that it is caused by not having a tool selected: ⚓ T98837 Tool 'builtin_brush.Draw' not found for space 'VIEW_3D' warning. So it’s a Blender thing and, as you expected, not part of your build.

E: By the way, why are all the options in the N-panel for me? It looks different on my end from the images you’ve shown: For instance, I also don’t have the buttons up top.

It is the latest link, the 3.3.1 build.

[lcas]

I don’t know why the N-panel has all that, but I see the same thing. I guess I never opened it the whole time while doing that. Going to go back and see later on. It’s been like a month of not doing any blender except messing with 3.4 beta and now 3.5 alpha builds.

Update on what I’ve done -
Object mode able to do a near select instead of forcing a select through every time
Select by both object origin or just touching some part of the object
Make the directional select work with just left vs right and in the way you would expect rather than the relatively strict way it does right now where it will do a tweak if it thinks your drag select is outside of what you’ve assigned the direction to

This works with box, lasso, and circle. Circle by object touch (as opposed to origin like it is right now) isn’t perfect but it is close enough and worth having as an alternative.

Issue I’m having is with the simplified directional keymap. I can’t change the options inside the direction dropdown or add a second one with just ‘any’ ‘left’ and ‘right’. It’s way more convoluted than I expected, and when I finally got close to making a second Click-Drag, calling it ‘Click-Drag Simple’ there’s no direction dropdown. When I try to add a second direction type, I run out of memory buffer and everything crashes when trying to make that keymap entry. Really annoyed with it right now, probably going to try asking in the dev chat for help. I also can’t just hard-code the unwanted directions out (north, south, northeast, soutwest, etc) because something is actually using a couple of them somewhere. Doing that would also go against what I’m trying to do which is not disrupt any current functionality.

I will likely wind up just having a userpref option for ‘simple direction’ or similar and it would just be up to user to ignore all of the directions in the keymap dropdown besides ‘any’ ‘east’ and ‘west’. It doesn’t hurt anything to assign them, but that keymap direction won’t be detected if the simple direction userpref is enabled.

If I knew this was going to be this big of a deal I would have just done the auto xray design doc. But when I was thinking about how to do that I decided I was just going to put all of the selection behaviour in 1 design doc, with links to various diffs if there was any further interest. I don’t get the point of making a design doc when there’s a diff(s) where things could be discussed already, but it’s what was suggested.

[lcas]

Also this new user avatar looks like a mushroom cloud, I know it’s supposed to be that monky head primitive, but it took a bit to figure that out

[Hologram]

You can change your avatar back to the letter icon in the prefs. Everyone without a custom image got the same monkeyhead (haha everyone with monkeyhead is dumb lol, primitives… pff ).

So then, what about this select through build? Will you update it so I can test drive it again in a state in which you meant it to be (i.e. not in the N-panel)?

[lcas]

Yeah I had no idea about that npanel thing so its going to be done, or at least worked on, this weekend

[lcas]

Hey so good news is this is just a python thing so no re-download needed.

edit:
Ok just saw something, because obviously viewport overlays isn’t in the npanel. Just edit space_view3d.py

path_to_custom_build\3.3\scripts\startup\bl_ui\space_view3d.py

There’s 4 panels to change:

class VIEW3D_PT_view3d_auto_xray(Panel):
class VIEW3D_PT_view3d_select_through(Panel):
class VIEW3D_PT_view3d_mesh_filter(Panel):
class VIEW3D_PT_view3d_backface(Panel):

If you want everything out of the npanel, you have to remove (or comment out with a #) the ‘category’ and change the region to ‘HEADER’. If you change the region without removing the category, all of the header button popovers/dropdowns will disappear.

Example:

class VIEW3D_PT_view3d_auto_xray(Panel):
    bl_space_type = 'VIEW_3D'
    bl_region_type = 'HEADER'
    bl_label = "Auto X-Ray Settings"
    bl_ui_units_x = 13

Otherwise, anything I put up in the header will go in the npanel, because the region was ‘UI’ insead of ‘HEADER’. I just set it up wrong by nature of copy-pasting the panel code above it. That’s why it shows up in the view tab of the npanel.

If you want it in the npanel but in a different area, remove or comment out the ‘category’ (with a #) it will throw it into a tab called “Misc” in the npanel. Or you can send it into its own tab by giving it a name.

Example of Auto X-Ray in its own tab:

class VIEW3D_PT_view3d_auto_xray(Panel):
    bl_space_type = 'VIEW_3D'
    bl_region_type = 'UI'
    bl_category = "Auto-X"
    bl_label = "Auto X-Ray Settings"
    bl_ui_units_x = 13

Example of Select Through in a Misc tab

class VIEW3D_PT_view3d_select_through(Panel):
    bl_space_type = 'VIEW_3D'
    bl_region_type = 'UI'
    #bl_category = "View"
    bl_label = "Select Through Settings"
    bl_ui_units_x = 13