I watched your video and I don’t see the new button. You might be trying to use, or just downloaded a different build. Try redownloading maybe I dunno.
Turn off indices if they’re on, let me know if that is what makes the numbers show up.
Slowburn didn’t seem to have any problems and neither do I so I’m curious, if after redownloading / relocating the build, if it is functional for you.
It’s a work in progress. Trying different things, and including as many options as make sense. It doesn’t need any explanation really, pretty straightforward. It just has some quality of life options for people/projects with different needs.
You not needing all of these options doesn’t mean the sky is falling. I don’t need any of them other than keymap. I’m just giving different people what they want (or close enough while I’m figuring it out)
I did completely delete and redownloaded it already two times.
I keep mentioning it because last time there was a big push for this feature, the response from the developers, mainly William Reynish was that the one added button toggle is too much UI clutter and that it will be confusing for people. So replacing one with 3 is certainly not going to bring this feature request any closer to success.
All I want is for this to get into official Blender in any usable way, so that I don’t need to be scouring for patched versions or cooking them myself to get absolutely essential modeling functionality in ever new Blender release, especially given how frequent they are these days.
Well, I don’t have much to go on, but there’s definitley something up if you don’t see the button. All I can do is say try again later once I get a new build up, sorry. Maybe you have a few different standalone builds, and they are getting a little “confused” or something.
Far as the official build adopting this. I’m not here to try to convince the developers of anything, and I feel like a patch definitely isn’t going to. They’re well aware of what select through is, and it used to be a part of blender. If they want it, they know how to put it in better than I do. From what I can tell, they are interested in it, they just have a lot to do, and are figuring out the most efficient way to do it.
Either way though, even after I make a few different custom versions of select through for 2.83.3, and 2.9+ if needed, and the developer’s do their own thing with select through, chances are it won’t be exaclty to everyone’s liking. That’s why I am going to make a short (I hope) tutorial thread with some videos so people can get exactly what they want, not just with select through but anything else.
It isn’t hard, I can do it with next to no experience. And it’s not like you need to update very often. Every major release, and not a whole lot changes once you got it done once.
Basically, if it’s a big enough deal, it’s worth the evening, or weekend’s worth of free time to get it done, and then forget about it.
Haha. Fair enough.
Hope it will be included in some form eventually.
It looks basically like this: Imgur: The magic of the Internet
I imagine this is something that could be easier when the retopo view/shader is finally implemented, maybe?
Alright 2.83.3 is out so I did a quick build of the original work that kio did.
Just the tool setting for box, circle, and lasso
No header buttons or keymap stuff
No disabling facedots in xray
Tool setting for box, circle, and lasso don’t work independently, if one of them is on, all of them are on
If you want to select by face area in xray you need to turn on the tool setting
Going through and making a few versions of the additional stuff I’ve added, will update this post with links to those builds.
AMATEUR HOUR ALERT
Nuking the other builds for a bit, noticed some inconsitencies. Nothing big deal, but I neglected to test vertex and edge select through in xray. Doesn’t work right, when I got it fixed I’ll put links back in here.
Also decided to test how long it takes to do a box select in Make Lite builds of normal blender (with just the time printing added) as well as each of the select through styles I’m planning on uploading. Make Lite seems good enough for this test, Debug takes like half an hour to compile and start. Multiply that by each build, and it’s a couple hours extra for something that’s not that big of a deal, from what I can see anyways.
I did this for box select by dragging over the entire mesh from the same angle. This is ensured by not changing camera or anything like that, and it all uses the same startup file which is convenient. Did this 5 times in Non-Xray followed by 5 more in Xray.
For the select through builds I’m doing 5 select visible Non-Xray, 5 select-through Non-Xray, 5 select through Xray.
Funny thing is it’s faster in Xray for the small mesh, but slower for the bigger ones. My guess is that once there’s enough of them, it is faster to filter out occluded verts than to select them all.
The mesh I used was a uv sphere. Small is 482 verts. Medium is 122k. Big is 1.9 million.
So far the builds are pretty much the same. It takes about this long in seconds for an old 2500k @ 3.4ghz (32gb ram & gtx 1660 if those matter)
small - 0.01
small xray - 0.0001
medium - 0.04
medium xray - 0.05
big - 0.4
big xray - 0.8
I’ll update the test info as I work through each build, planning on adding a keymap only, header button only, and a build that will allow you to switch between keymap, tool setting, and header button. As you can see there’s no difference in execution time between normal blender and kio’s work. Also no difference between select through and xray. I don’t expect much difference in what I’ve added but who knows.
There is no consensus on backface selection and facedots, because the discussion is about scrapping things that are being used by others. Blender shouldn’t enforce a workflow upon people for the sake of a few who do not need it. Instead, it should provide the options for all, which includes the option not to use it! Since all combinations are requested, they should all be provided. The difficulty arises in coupling several options of display and selection to which each user has their own preferences, hence why these move to the preferences menu. Again any combination of select through, facedot, area selection and display settings are mentioned! The preferences should accompany setting selection (area/facedot & area type) and how these are activated by default when entering a certain display mode or selection mode. This is where the action scheme is put to use; to couple those modes that require multiple changes. Yet users can individually toggle the buttons and map them to shortcuts like the rest of the interface.
Area selection/ facedot selection (checkbox in dropdown)
By having the backface selection button in the interface, it shows the user that it’s in use. The facedot selection and backface selection mode should be reflected in the icon itself, which changes per mode:
Xray icon (used in the interface as default) it means backface selection is on/ off)
Grey with backface selection off
Blue with backface selection on
Xray icon and facedot (just add dots to the default icon), it means facedot selection is on and backface selection is on/ off
Grey with backface selection off and facedot selection on
Blue with backface selection on and facedot selection on
The dropdown with in the mockup by @LudvikKoutny with a checkbox for X-ray selection should state: facedot selection, this checkbox effectively switches between 1 and 2.
Combined behaviour
Facedot selection turns on facedots, facedot display is turned off when the selection mode is off
Display modes act independently from selection and overlay, with the exception that X-ray and wireframe enable backface selection automatically thereby greying out/ removing the button
Preferences
Under Input? Here you set your prefered behavior (the naming is more of an indication to the use that to what should be exposed in the preference settings UI). It should toggle multiple settings for display/selection.
Facedot display & facedot selection
Facedot display sets facedot selection
Facedot display does not affect facedot selection
Facedot selection toggles facedot display
Facedot selection turns facedots on, but does not turn it off (I would skip this one).
Default to Facedot selection mode in X-ray/Wireframe
On: sets facedot selection in X-ray/Wireframe mode (and a activates upon entering X-ray/Wireframe)
Off: defaults area selection
Select backface to toggle:
X-ray display
Wireframe display
Solid display with highlighted selection in which the selection highlight acts as an overlay (like in Modo I have come to understand? )
Select backface does not alter display mode (this effectively only sets backface selection)
Display modes that default to facedot display
X-ray
X-ray & Wireframe
Solid, X-ray & Wireframe
Do not display facedots by default
Allow global facedot display override: default facedot display in 4. is overruled by the facedot display toggle.
Enable backface selection with modifier keys: Enabling this shows a drop down from which the preferred override keys can be assigned:
hold alt/shift/control, this option should go through conflicts in the keymap (on the long term) and or add a select through option within each applicable tool).
LMB, RMB & MMB with dropdowns for: LSTV - Limit selection to visible & RMB backface selection
Area selection method:
Crossing: everything touched by the selection window is selected
Window: everything completely within the window is selected
Direction: window or crossing depending on the input direction: left/ right
Seeing as how complex the preferences and possible combinations of functions are, as indicated in the discussion length - and all options have to be available - there isn’t really a way to avoid UI clutter. So having this in the preferences under its own collapsable header will suffice as long as the default settings are clear enough for any user and advanced users can have it their way.
We all need the functionality, the devs might as well add the individual buttons and functions and do another round of user feedback on the preferences later, that way there is no longer any hold up on this highly demanded workflow fix, because of some minor UI and preference quirrel!
PS. I don’t use fadedots, I would already be happy with a 3ds Max’ like toggle to ignore backface for selection with alt+b, while leaving the default backface selection in X-ray on. I can, however, see the use of facedots in picking faces with fill selection and/ or shortest path with both visible and occluded faces.
I’m too opinionated to move this discussion forward, but at least I can help to visualize the various proposals with little click-dummies. IMHO your proposal (although not beautiful) is much better than the current situation (2.90.0 beta) and would at least solve all my pain points.
I freely rephrased the different preference options and I’m happy for any feedback.
I’m happy to visualize all other proposals so we can better discuss the various pros and cons and (with the hell freezes over) give the blender foundation some material for usability-tests.
I’m totally confused by the different forums and threads for this topic: Should I also post these designs in the design task thread?
It’ s unbelievable that this idea is still not merge to the master …I creat this account to support this.
Yes ,the biggest problem while modeling is,we have to chang to x-ray to select the back faces or points ,then switch back.
And the truth of this action is: to select through ,not look through.
Most time ,x-ray is useless,we wont use it to do anything.We make the object display as wireframe or bounding box instead.
We need select through without looking through,which make us focus more on the current model than the x-ray model(most time is hard to read)
Same idea with paint through in weight painting
If I had a penny every time someone signed up for this forum just to post in this thread… This is probably currently the most requested and at the same time most ignored Blender feature.
For box mode selection (default hokey = B), the UI should allow for clicking on the toolbar to be able to change the selection settings (note this button is already there, a select window/crossing toggle is added).
Under preferences, there could be a setting to have direction dependent window/crossing selection based on which direction is used during dragging, as is common in many CAD applications. This would remove the toggles from the interface.
Another design task was labeled, where selection preview should be added, i.e. if a non-selected face is in front of the selection, the selection should be displayed over this unselected face. See here: https://developer.blender.org/T78482
Really disappointing news. 2.90 had some significant API changes so I am no longer able to build a new version with @kio 's patch because I don’t have as advanced understanding what’s going on to adjust for code changes. I really wish this was properly in the master so I would not have to deal with this whole “build it yourself” nonsense. For anyone who’s not a full time developer, just getting something to finally build for the first time is a matter of at least one entire day of work
Nothing changed for 2.90 except ‘mcords’ is now ‘mcoords’ and ‘moves’ is ‘mcoords_len’. Same as before in 2.81 or 2.82 -> 2.83 when ‘ar’ was changed to ‘region’
edit: spoke too soon, select through in face isn’t working right. Going to have a look through
Also, forgot to mention that ‘modifiers_getCageIndex’ is now ‘BKE_modifiers_get_cage_index’
The annoying part right now is that it builds fine and everything else works like it should. If it didn’t build I could just look at what script and line was wrong and fix it. But Select through face by area doesn’t select anything. A skim through things hasn’t shown anything yet. I’ll have a look around for some kind of changelog for the relevant scripts. Hopefully that will speed things along.
Took a break from this for a bit and came back today to see what’s up. Still trying to figure out a minor thing, making select by facedot work without doing a select through. Nothing that useful, but I was thinking it could come in handy if you want to select some faces quickly without selecting through and without having to avoid unwanted faces entirely.
I imagine it could be something to use with a somewhat complex, but not so complex that facedots make it unreadable, mesh with lasso tool and a graphics tablet or something. If you want to have some semi-exclusive face selection where you don’t have to draw your lasso so carefully outside the lines of unwanted faces.
To avoid unwanted faces, you’d just have to avoid their facedot instead of any part of the face. Basically you can draw a sloppier lasso. The tradeoff is that to select something, you have to go all the way inside to the facedot.
Anyways, I’ll update with a 2.90 build of kio’s stuff after a while and throw up what I’ve added to it once I either figure out the last bit I want to do, or just shelve the idea and live with it being a little inconsistent as far as facedot selection only doing a selecting through
Yes, I fixed mcords to mcoords, moves to mcoords_len, and modifiers_getCageIndex to BKE_modifiers_get_cage_index. It all compiled and I got it to build but the selection wasn’t working. So I assumed I’ve missed something I am just not experienced enough to determine.
Nah it’s just a matter of looking through this bs moonlanguage to find what is different from before. Help me look through it if you can I will do some more tomorrow.
Found a much easier way to see what’s different than just skimming through it manually.
Saved a copy of all the scripts from 2.83.5 (untouched, not with the select through patch) in another directory
Right click script from 2.83->Tortoise SVN->Diff later
Right click same script from 2.9->Tortoise SVN->Diff with “nameOfScript”
Click next/previous difference, or go to the relevant line(s)
From what I can tell, there’s nothing going on in view3d_select or view3d_iterators.
It’s probably something that happens in what kio put inside of view3d_iterators under
void mesh_foreachScreenFaceVerts
So far I’ve checked
editbmesh_get_eval_cage_from_orig
which is in DerivedMesh.c and BKE_DerivedMesh.h - both of which seem fine.
Going to check the rest tomorrow, but like I said, if anybody out there has the time help me check it out and let us all know what you find, thanks
Quick update:
went through a few more scripts and wasn’t seeing anything, so I did a debug build for 2.90 with select through. It’s saying there’s something wrong with ‘mvert’ in the place I figured (void mesh_foreachScreenFaceVerts)
if (mvert->flag & ME_HIDE) {
Exception thrown: read access violation.
**mvert** was nullptr.
My guess is it might be named something else now, or something different is being done to it somewhere along the way. Either way it’s late, and it should be pretty easy to figure out now, definitely not jinxing myself by saying that.
Any help with this part?
In the select through patch, view3d_iterators.c, under ‘void mesh_foreachScreenFaceVerts’, around line 414 kio tells it to get the mesh:
In 2.9 this doesn’t work, it acts as if there aren’t any and keeps it NULL. This results in the read access violation I posted earlier, and nothing gets selected.
I tested this by adding some prints:
const MVert *mvert = mesh->mvert;
if (mvert !=NULL) {
printf("something in there \n");
}
else {
printf("NULL \n");
}
Now, in 2.83 it will always see something in there, even if you don’t select anything. It’s just checking if the mesh has stuff to select. If you delete all of the components of the mesh, then try selecting something, it will print ‘NULL’
In 2.9, always NULL.
Comparing ‘dna_meshdata_types.h’ between 2.83 and 2.9 reveals nothing. Almost no changes and nothing that seems relevant. Bit of a head scratcher
Also, it sees a mesh in 2.9, just checked it. So the issue is somewhere in the check for mvert.
Alright so big thanks to @ideasman42 for helping me
At the very least there’s a quick workaround, but like he says, it aint pretty. To avoid all of that and the performance issues that will come with it, I got what I think should work.
Just send the Mesh from ‘view3d_select’ to ‘view3d_iterators’ instead of getting it in there and having some things get lost in translation. In short there’s some useful things coming that are being implemented for 2.90, but in some contexts there’s issues passing mesh data around.
Checked everything and it’s fully functional. I’ll do some performance tests like I did a while back to see what the gains are, because why not.
Don’t mind me, I’m just chiming in to voice my support for this proposal as well.
I can’t believe that Blender, which is famous for its modeling capabilities, still doesn’t have this basic feature that can make our lives so much easier. It’s something most people do on a daily basis in Blender. Imagine the time and frustration saved.
I’m coming from 3ds Max and small, but very important problems like this one, prevent me from making the jump to Blender. The people have spoken. So why is this still not addressed?
Well, in context of highly popular feature requests in any software, 2 years certainly does not qualify as “rather recently” Such time frame would qualify for something like buildings, where you could say “This house was built quite recently” and 2 years would be appropriate for that. But the patch @kio has made took probably couple of weeks to do, and would take probably fraction of that for a fulltime Blender developer.
I am also not sure that there are that much more important things on the table for 2 years straight. This is currently #1 issue in terms of wasting time doing daily bread and butter tasks for most people who use Blender for modeling. And most people who use Blender do use it for modeling
