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
Well, yeah, that one would be also quite important, but I’d say on an equal level. Holding down Alt key while clicking or pressing enter to apply the modification to all objects is a bit annoying, and also frequent, but I don’t think it happens more often than selection of mesh elements when modeling and also doesn’t slow down one that much
But that being said, it’s really sad that one is taking the ages too, because it would be probably relatively easy fix. I personally would simply invert it so that just interacting with an UI element would always apply the change to all objects (if possible) and holding down Alt key would apply it only to active one. It would literally mean just flipping meaning of a single bool in the code
At least regarding Multi Object Property Editing I know the team decided that a quick solution would be undesired and that a better, more flexible and robust implementation is in order. There is a design task bringing it on par with the way other software handles it: https://developer.blender.org/T54862
It also means that it’s probably going to take a longer time, probably.
I am very much looking forward to it, though.
It’s slower because of the new changes requiring a BKE_mesh_wrapper_ensure_mdata(me); which depending how complex your mesh is, will take 2-3 times as long as a normal xray select does. These times are based on a 2500k @ 3.4ghz so chances are you got something a bit newer and aren’t as bad off.
First 3 are dragging over a uv sphere of 482 verts, followed by 122k, 1.9 million, and finally 7.8 million verts. By the time I’m working with that many verts you can see it’s a bit much at 7.5 seconds vs 3.
@ideasman42 told me before how void mesh_foreachScreenFaceVerts needs to be re-written to use BMEditMesh directly. I was hoping it was straightforward but it isn’t. It’s gonna require some more understanding of what exactly is going on in there. I’ve asked him for some information and resources for this type of work, and while I wait for something in that regard I can at least get started with what I’ve found in some generic C tutorials and a couple books.
I know some of you know about this stuff, so anything to speed along the learning process would be fantastic. Let me know what you did to learn what you know, and maybe you could even lend a hand re-writing @kio 's work.
Any info you can give me would be great, because I’d like to know how to do this myself even if it isn’t necessary because one of you wind up doing it for the rest of us before I am able to do the same.
Once this thing is rewritten I’ll add what I’ve added to it again unless someone needs an inefficient version of Select Through with keymap or header button with some extra facedot options.
I unfortunately don’t believe I have sufficient skill to rewrite Kio’s patch. I do have some C++ experience but only with UE4 C++, which is a walled garden where almost everything is re-made from scratch, and it almost feels like a scripting language. Blender’s C++ on the other hand feels like hardcore C99 with classes
That being said, I’ve asked Kio to update the patch to work in 2.90 and he did. He messaged me the patch directly, so I’ve asked him if I can share it here too. Once he gives me a green light, I’ll post it here
It’s also a bit sad that Campbell knows exactly what to do, and it probably would not even take him a very long time, yet he could not be bothered…
Thanks a lot, looking forward to it. Let @kio know he’s appreciated! I’d really like to hear whatever he has to say about what he’s done, any recommendations for learning about this type of coding, even if it’s just what to call this specific subject.
I get what you’re saying about it, but I’m just going to assume they were waiting for the improvements introduced in 2.90 to put it back in. Or maybe they don’t really want it because it doesn’t fit with whatever design, but they aren’t totally opposed to it, so they’re waiting for some sort of everyone’s happy solution that also looks pretty, is logically consistent, and is intuative (probably doesn’t exist )
And yeah, exactly… They are waiting for some miracle unicorn solution that would address all the artificial problems they’ve invented. So either it’s gonna be on hold for another couple of years, or they will come up with some brutally overcomplicated solution that will add another 5 interdependent buttons, making the learning curve that much steeper
It’s a shame because if done right, it could be just one additional button, and if done perfectly, the face dot selection could simply be removed altogether and replaced with this, so no added buttons at all, and in fact a few of them actually removed.
It’s the same thing unfortunately. It works fine but it is slow because of BKE_mesh_wrapper_ensure_mdata(me); being needed for 2.90 to see the MVert data.
Was going to take a leisurely approach to learning how to rewrite this, but looks like I’ll be dedicating more of my time to it so I can get this done sooner.
Some learning resources that are specific to this problem would be great.
I’ve also created an account to add another voice to this issue. I’m glad to use this custom version for now, but maybe The Blender devs should fix it instead of users. I afraid that new Blender version could be without this custom patch and I will work slower(
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 
