…found some more info about what i referenced…
Oh my… making something based on some copyrighted material… and then sue the copyright holder… 
So wild. Situation was already a catch22. Either nobody buys his unlicensed LOTR sequel, and he doesn’t make money while also risking a fairly high possibility of getting shut down and sued anyway, or a lot of people buy his book and he guarantees even more legal problems. To go out there and beg for it by suing them? It’s like showing up to the Universal Studios theme park, stealing some shots on the Jurassic Park ride with your phone, selling the footage as a “sequel” movie, and then suing Universal for releasing their next Jurassic Park movie / tv show.
Got a request in the youtube comments for directional selection stuff similar to another DCC. It should already be working for edges and faces, but as I was starting to make a video showing how to use my build to get the same functionality, I realized I should add “enclose” selection to object mode. At least for box select. Circle and lasso are not within my understanding how to deal with in object mode. Not sure if the guy making the request needs it for object mode, but I added it to my build thanks to this patch made by @erik85
All I needed to do was change a few things so C++ likes it. Either that patch, or this other one adapted from it, is where I figured out how to fix a few problems I was having with collecting mesh data for enclosed face selection outside of x-ray. I was getting bad vertex data before I saw how I needed to do uint index_verts = DRW_select_buffer_context_offset_for_object_elem(depsgraph, ob, SCE_SELECT_VERTEX);
edit - I am dumb. There’s never been a problem with move/scale/rotate using the keymap options I add in my build. They’re just accessed from the “fallback” version of the box/circle/lasso tool. Wish I had remembered that before changing things around and adding stuff I didn’t need to do:
As I am testing enclosed object selection, I am seeing how the selection tools don’t change from the default selection behaviour if you are accessing them indirectly from the Move Scale and Rotate tools. I like these options in the keymap for their versatility, but that’s because I just use the selection tools and access the transform tools from either shortcuts or gizmos. I am going to add more stuff to the keymap for the Transform tools for people who work the other way around than I do. Never realized this was going on. The transform tool keymaps are already a bit huge, but oh well.
1 Like
Lukas, I will rebuy your build on the 3rd or 4th when I get paid. I won’t have the money till then. Have you made any changes yet and will there be a new video on those changes? Thanks
1 Like
Thanks, that is very generous of you! There will be an update and a few videos about it. Only one additions for the build:
- Box Selection in Object Mode can do Enclose select.
I think I will re-use most of what I have in the long video you commented on, and just split it into different topics, put it in a playlist. I was going over what I wanted to put in the youtube video for you, to show you how it can be set for directional selection, and I realized that rhino is showing how it selects objects to demonstrate Enclosed vs Crossing select. Fortunately this was already done in a patch that I had seen before. I got a bit stuck when trying to mess with Lasso Select in Object Mode and just shelved further Object Mode Selection changes until I figured that out. But since you requested some help with using my build, and it made me realize I should add it in, I added Enclose Object to Box Select.
I might just do what I had done in the past as well, where you could decide whether you want to control these things via keymap or toolsetting / userpref. I’ll be done within a few days.
edit: I forgot the transform tools have access to the selection tools via the “fallback” version of their keymaps.
Thanks Lucas. I look forward to the update and videos but no hurry. All the best in the New Year.
Updated the build, box select will do enclosed objects. Didn’t need to do anything for the transform tools to work, I just forgot about the “fallback” keymaps for the selection tools. Those are what you’d need to change for things to work from the move/scale/rotate tools instead of using the selection tools directly.
Will update video/screenshots over the next few days
The 4.0.2 Build needs to be updated one last time, again the problem I had was with enclosed object box select.
Reason I need to re-upload again is that everything is working in a debug build, but not in lite and release builds. Going forward I need to do a thorough test inside of a Release build before I can be sure everything is functional.
The reason for all my confusion is that “uint[4]” works in debug with multiple objects, and it will enclosed select a default cube in release and lite builds, but with multiple objects it will select things that are un-enclosed in release or lite builds. So, I’d see everything doing fine in a fairly thourough test in debug, compile a release, and then see it do enclosed object select with the default cube. Seems good, but it isn’t.
It’s a good thing it doesn’t work with multiple objects in lite builds as well, because otherwise I’d need to do a release compile every time I want to test what the problem is. Release builds can be shortened, but it is a very convenient time-saver if I can just say “make lite” instead of manually configuring cmake.
Here’s the culprit:
qsort(vbuffer_outside[0], hits_outside[0], sizeof(uint[4]), opengl_bone_select_buffer_cmp);
Solution is to change sizeof(uint[4]) to sizeof(GPUSelectResult)
qsort(vbuffer_outside[0], hits_outside[0], sizeof(GPUSelectResult), opengl_bone_select_buffer_cmp);
I’ll recompile, check things over, and reupload the build. Then finally do screens and a video, then source. Then a Mac Silicon build hopefully. If anybody needs Intel Mac or Linux let me know and I’ll ask for a buildbot.
Ok, finally got some time to check the different features, enclosed object select is good now. Build is back up again.
Source, I’ll add it to the main website soon:
Here’s how you can set my build to work similar to rhino, at least from my understanding of how it works with Enclosed selection when dragging to the Right, and Touch aka Crossing selection when dragging to the Left.
Blender’s Keymap is very flexible, but it also looks a lot more complicated than it should, so it is a lot more confusing than it could be. One of those things that works, so it is unlikely to be touched anytime soon by anybody.
The following is based on the standard Blender Keymap. It assumes you want to drag to the Right to Enclose Select, and drag to the Left to Touch Select(aka Crossing). Feel free to adapt this to any way you like to work, just change the mouse click buttons, modifier keys, and drag directions. Don’t even bother using drag directions, and use the keyboard. That is the power of the keymap, unfortunately it is also somewhat of a burden to set up. Do it one time, and you likely won’t have to think about it ever again. Just export the keymap for use/recovery later on.
This guide is better suited for a video, but it’s late at night (technically early in the morning) and I can’t talk on a mic right now. Maybe tomorrow there will be a quick video, but I wanted to show how to do it through screenshots at least for now. Strap in, there’s a lot of screenshots. Modifying Blender’s keymap isn’t hard to do, just a little unusual, and I will try to walk you through it as easy as possible:
- First you’ll need to change a preference my build adds. It makes left vs right direction work a lot better. It is in Edit → Preferences → Input → Mouse → Keymap Drag Direction. Set it to “Left Right”. This will limit what directions Blender looks for to just left and right, instead of the usual 8 directions that really get annoying to deal with if all you need are left and right. Up Down is another option should you want to try it like that instead.
-
Edit → Preferences → Keymap → 3D View → Mesh. Why Mesh and not Object? Well, it doesn’t actually matter, because Blender, and especially its keymap, are weird. If you change something about Box Select in the Mesh area, it will also be changed in the Object Area. This goes both ways, “Don’t worry about it” is all I can say about that. Maybe someday a brave developer or three will try to take on the keymap. But I’d rather they leave it alone and working as-is than “fix” something the wrong way.
-
Anyways, this part depends which way you like to use Blender. You can always set both keymaps up so it doesn’t matter which one you use if you feel like you’ll need it. There are two main ways of using the Selection and Transform tools. You can either use the selection tools (box, circle, lasso) directly, and then access the Transform tools (move scale rotate) from shortcuts and/or gizmo show/hide. If that is how you work, you need to set the keymap for the regular Box Select tool, I’ve highlighted which one I mean in this first picture.
-
If not, you are like the picture below and you set the keymap for the alternate Box Select keymap aka “fallback”. What do I mean by this? You like to do things the other way around, where you swap between the 3 Transform tools and access the selection tools indirectly from them. Be sure to set your Drag toolsettings to Box select in this case, I’ve highlighted this on the right side of the picture. Whichever style you use, the keymaps will look the same, just be sure to change the correct one, or just do both, it will be fine and probably useful.
-
Expand the first “3D View Tool: Select Box” and Copy the name for later, we’ll be pasting it a couple times for the other direction keymaps. For reference, this first keymap should be set to Left Click Drag in “Any” direction with no modifier keys, Mode is on “Set” and the Object, Face, and Edge select modes on the default settings of “Touch” and “Default”.
-
We want to drag left and right. So set the direction to “Left” by clicking it
-
We want to do a “Crossing” select by dragging in this direction. I call this “Touch”. Click the dropdown next to Object and set it to Touch, do the same for Face and Edge.
-
Alright, that’s basically it. We’re just going to be doing the same thing a few more times. All we need to do is change various dropdowns to the appropriate settings. First we’ll complete the rest of the Left Drag keymaps by using the ones that already exist. If you don’t need Ctrl drag to subtract, or Shift drag to extend, or Ctrl Shift to do the relatively obscure “intersect” selection, feel free to skip those, or modify them to whatever you want them to be.
-
Expand the remaining Box select keymaps. There should be 3 of them. Shift Drag for “Extend”, Ctrl Drag for “Subtract”, and Shift Ctrl Drag for “Intersect”. Change their directions to “Left” and their Object, Face, and Edge to “Touch”
-
Now we will finish our keymap by adding the Right direction, it is annoying to have to do it this way instead of some kind of “duplicate keymap” button that could then be subtly modified, but oh well.
-
Go to the end of Box Select and click “Add New”
-
It will add an empty keymap called “none”. Expand it.
-
Click “none” and paste the name you copied from before. If you need to, just click one of the keymaps from before and recopy the name.
-
Click “Keyboard” and change it to “Mouse”
-
Click “Press” and change it to “Click Drag”
-
We want to setup the Right-drag keymaps, so change direction to “Right”
-
When dragging in the Right direction we want to Enclose Select things. Set the Object, Face, and Edge dropdowns to “Enclose”
-
That’s it for the standard Right-drag, let’s do the Shift Right-drag. Click “Add New”, expand “none”, and paste the name from before.
-
Set the Mode to “Extend”
-
Add a modifier key to this keymap, we want to use the Shift key, so click “Shift”
-
Now just set the rest of it like the previous keymap. Keyboard → Mouse. Press → Click-Drag. Direction → Right. Object / Face / Edge → Enclose.
-
Almost done, click “Add New”, expand “none”, paste the name. For the next one, we want to press Ctrl to subtract from our selection. So, set the mode to “Subtract” and click “Ctrl” to set the modifier key. The rest is the same: Keyboard → Mouse. Press → Click-Drag. Direction → Right. Object / Face / Edge → Enclose.
-
Finally, we might want to do intersect selection with a Shift Ctrl drag. Add new, expand “none”, paste the name. Set the mode to “Intersect” and the modifier keys to “Shift” and “Ctrl”. The rest is the same: Keyboard → Mouse. Press → Click-Drag. Direction → Right. Object / Face / Edge → Enclose.
1 Like
Video for setting up the keymap for Left → Touch and Right → Enclose
I just saw that I got 2 more donations, 1 for the Mac build and another for the Linux one. I’ll take that as confirmed interest in those builds and update them soon.
1 Like
Thanks for the new video Lukas.
1 Like
Source on the website now:
I’m going to try it on my Mac tomorrow and see how it compiles. If it works right I’ll ask for a buildbot in chat because making a portable Linux build was a little touch and go and, from what I thought I was told anyway, isn’t quite as portable as I thought.
Regardless, I don’t have an Intel Mac that is new enough to compile Blender and I don’t think Silicon Macs are able / allowed to make Intel Mac builds for whatever reason. It would be great if I’m wrong about that, because it would mean that I can do everything on my own, with only portable Linux builds being a headache / question mark.
Figured out how to make a cleaner source on the website. Whenever I do a make icons it creates a ton of .dat or binary files because it goes through every single icon in the sheet and acts like those files have been changed, and auto includes them in the pull request. At least when I do a git commit -a which is almost necessary because of how many different files I change in the build. 54 different source files, and counting, would be a little annoying to triple-check that I got all of them manually entered into the commit.
The way I did it without all the redundant icon .dat files in the PR was to make a diff of my build pre-make icons and then do the make icons thing. Save a copy of the altered icon sheet, the 2 new icon dat files, and my new cursors. Then just git reset --hard back to normal blender 4.0.2, apply the diff, put the new icons and cursors back, and then commit everything without the extra junk I don’t need. At least I hope the entire icon set of .dat files isn’t necessary for the buildbot to play nice with my build. I’ll find out later when I try to compile on Mac from scratch, should be a good indicator whether the buildbot does the icons right. Can always just use a placeholder for the new auto xray and select through icons if this continues to be an issue.
Anyways, should be good to go soon. Then I’ll go through and update the screenshots, gumroad pages, and the youtube where necessary.
1 Like
Ok got some links for everything thanks to the devs in chat and the buildbots. I read that 4.0.3 isn’t happening, so the next update should be with Blender 4.1 in late March / early April
4.0.2 Windows (gumroad.com)
4.0.2 Linux (gumroad.com)
4.0.2 Apple Silicon (gumroad.com)
4.0.2 Intel Mac (dropbox.com)
File size limit for free stuff on gumroad is 250MB, and the Intel Mac is a little too big for that so I have it on my dropbox. One less page to maintain anyways 
Need to update some screens and youtube, will happen soon.
Couple things I’d like to add / improve:
-
Viewport Facing Select has issues with not selecting everything it should. I still prefer it for what I want, accurate near select. Because at least this way I can see what isn’t being selected as opposed to just guessing what rear-facing mesh has been selected on the unseen side of my scene. I wish I could just refer to backface culling, and tell Blender to remove anything from whatever makes that happen from selection eligibility. It’s like the rendering and selection are completely different logic, and maybe that’s how it has to be, but so crazy that the same thing has to be calculated twice in two different ways. My hope is that Vulkan solves this issue, but who knows how long that takes.
-
Guy in chat was asking for help with some vr selection stuff. Seems kinda cool and within my ability, but not sure. Basically, want to enable selection during walk/fly navigation. What is actually wanted isn’t clear, but I have some ideas what could be done and added to my build at the very least. Might not be as easy as I hope, and low priority besides, so it could be a while or never happen.
Hoping to have a build very near to the release of 4.1.
Finally figured out how to get mesh data in object mode, so lasso and cursor are able to do Touch, Enclose, and Origin select of Objects. It’s accurate, fast, and has an extra toolsetting you may like.
I also added a new toolsetting for Circle Select called “Square Select”. It basically passes the radius into Box select and will do a rapid-fire box select that is the same size as the circle. Why? Because doing touch select is the slowest of the 3 possible options for Object mode, and Box select is exceptionally fast at doing them thanks to taking advantage of view3d_opengl_select as opposed to calculating and projecting bounding boxes, verts, edges, and faces over and over.
If there’s time I will make Square select for Edit Mode and any others I can. Outside of Object mode it would be simply because you want/like the shape of a square more than a circle though.
I thought I had until the end of March to finish up, but after looking earlier today I see that 4.1 is supposed to come out in like a week. Was going to build all of it myself because I saw that Apple Silicon can cross-compile for Intel Mac. Making a portable Linux Build can best be described as “pain” but I wanted to try it again if there was time. Just thinking about it makes me want to reconsider, but at least it is an option if buildbots aren’t possible.
So, I will likely ask chat for a buildbot like last time, and host it on gumroad / dropbox.
Targets for 4.2 are:
-
DONE FOR 4.1 Figure out why Intersect doesn’t work right with Touch X-Ray Faces. This is going back like 2 years now, and looking at it earlier today has revealed nothing. Super niche, and does Center Face as a fallback.
-
Figure out how to get VFS fully functional. It doesn’t select everything it should, not sure why. I don’t understand Linear Algebra, and therefore I kinda hate it. Kinda a lot.
-
Make all of the custom mouse cursor options work in Mac and Linux. Not a big deal, and I don’t have a need for either platform personally. But it is an incomplete thing that needs to be figured out.
-
Add some functionality to walk/fly navigation regarding selection. Seemed cool but didn’t have time to get into it since I finally got Object selection figured out for Lasso and Circle.
5 Likes
I fixed Box and Lasso doing the relatively obscure “Intersect” select mode with Touch and Enclose in Xray / Select Through.
edit 2: issue was not memory allocation
Re-wrote kio’s original work in my own way. I went into it thinking that the problem with intersect was allocating memory for storing vert positions. So I did that using a float[2] array the size of bm->totvert and it seemed to work fine without allocating any memory and using std::vector to get around using a variable-length array. BUT after messing around during testing, just doing whatever ridiculous random things to see if anything breaks, I ran into an out of range error for the array that would actually crash Blender.
Could not reliably reproduce this. Not even once. But at least the description was easy enough to look up and understand. Blender is asking for something in my vector array that isn’t there, because for some reason the size of bm->totvert increased during selection while my script loops over the faces of a mesh and requests a specific index of the array that holds their 2d position.
So since I couldn’t really test for an error I couldn’t make happen again, I went back to see if there was anything else to do. Decided to just use a standard array and double-check for increased size of bm->totvert the same way kio did, and then re-allocate memory for a new size of bm->totvert when necessary. Turns out that wasn’t even the issue with intersect.
The reason kio’s original patch didn’t work with intersect is because of the way it skips faces with invalid screen coordinates. If ED_view3d_project_float_object can’t see some verts because they are behind the camera, it will skip any faces connected to them. This avoids a situation where you move the camera inside your mesh, select some stuff in front of you, but when you turn around or zoom out enough, you will find that you also selected some unwanted faces that were offscreen behind where you had been.
Skipping those faces is necessary, but the original script was also skipping an important part of the selection process for intersect, where you have to do:
const int sel_op_result = ED_select_op_action_deselected(
sel_op, is_select, inside);
if (sel_op_result != -1) {
BM_face_select_set(vc->em->bm, efa, sel_op_result);
data->is_changed = true;
Regardless of everything else to fulfill what Intersect needs to see to do its thing.
Anyways, should be good to go now. Going to clean things up and test everything. If there’s time I’ll try a portable Linux build while I wait for 4.1 to come out. Don’t know how much anybody wants to see these sort of updates, but it helps me figure things out by explaining it a little bit. Plus it helps if I forget something in a few months to see wtf I was doing, and why.
edit 1: made it faster
Based on the speed tests and what I could see, you won’t notice much difference between Center and Touch, even when it starts taking longer to select things. The times I got yesterday were acceptable, but slower than I thought they should be so I looked again. Forgot to do BLI_rctf_isect & BLI_rctf_isect_circle they are a really fast way to filter faces that aren’t near the selection box/lasso/circle. By their name, and what they do, you’d think that was all you need, but it isn’t quite right, it grabs a few extras. An imperfect filter but way better than nothing. I was ok with just Intersect using my method and being slightly slower than it seemed it should be, but now I can just use mine by itself it looks like.
Speed tests in Debug of 4.1 RC. These are single threaded cpu from what I’ve read in the past. The explanation makes sense as well, the overhead of multi-threading doesn’t make sense for something that is expected to be instantaneous. These times are rough but give an idea of what a 7900 non-x cpu with some other things open like firefox does on Windows 11, solid shading of a subdivided default cube. Skipped half select for the smallest one, triple-zero speed all the way down so who cares. Release build should be a little better performance, times are in seconds.
didn’t bother retesting lower poly, it was already fast anyway
1.5 MILLION VERT CUBE
select all
1.513504 - center
1.569179 - touch
1.742419 - enclose
select half
0.951690 - center
1.133776 - touch
1.236356 - enclose
select minimal
0.521249 - center
0.703514 - touch
0.718004 - enclose
Slower times below for reference:
1.5 MILLION VERT CUBE
select all
1.739227 - center
1.722917 - touch
1.933399 - enclose
select half
1.154589 - center
1.590228 - touch
1.444759 - enclose
select minimal
0.518418 - center
1.489186 - touch
0.947548 - enclose
100K VERT CUBE
select all
0.088553 - center
0.085451 - touch
0.093926 - enclose
select half
0.057347 - center
0.073070 - touch
0.068557 - enclose
select minimal
0.033688 - center
0.067273 - touch
0.040694 - enclose
400 VERT CUBE
select all
0.000535 - center
0.000508 - touch
0.000456 - enclose
select minimal
0.000380 - center
0.000424 - touch
0.000426 - enclose
4 Likes
Windows is done, same link as before on gumraod in the first post. I’ll put them here as well as I finish compiling them. Going to try them all without having to ask for buildbots, wish me luck.
Changes:
-
Object mode is done, Lasso and Circle can do Touch and Enclose.
-
Box and Lasso in Edit mode can do Intersect Faces in X-Ray / Select Through with Touch rather than using a fallback of Center in that context.
-
Circle has a toolsetting called “Square Select” it will change shape to a square of the same size. Made it for Object mode because Box is faster at doing Touch select of objects. Works with everything else Circle does (Edit, Particle, Paint, Curve, Node). But other than a different shape there’s no benefit outside of Object doing Touch select.
-
Mouse Cursor option for Paint and 2D called “Blank”. Someone necroed an ancient thread of mine a couple weeks ago, asking if they could make the paint cursor go away. So I did that. Windows only. Will see how Linux and Mac deal with mouse cursors for next version maybe.
-
Box Enclose Object has been improved. Although the solution I used from before was actually a pretty brilliant idea from erik85, it had a problem that I noticed while working on square select. It de-selects non-enclosed objects by drawing 4 small boxes at the perimeter of your selection box, and re-tags anything inside them. Partially enclosed objects would be hit twice, and therefore be ineligible for selection. The problem with that, is if you have a non-contiguous object, or if you are in wireframe + xray, it won’t work as intended. You will select things that aren’t actually enclosed, either because you have one contiguous piece selected, but not all of them. Or because you are in wireframe+xray where the faces aren’t being rendered, so it has nothing to tag and thinks something is enclosed, when you only grabbed the origin which would be disconnected from any wires and treat the whole object as enclosed.
-
Related to #5 is a toolsetting called “Wireless Touch Object”. If you are in wireframe + xray, and you use Box to select an object, you actually need to touch one of the wires / edges or the object origin if it’s visibile. If you make a selection box that is entirely inside one of the faces, they aren’t being drawn in wireframe if xray is on, so it doesn’t select anything. If you want it to just select stuff in that situation, you can use this toolsetting to get the desired behaviour. Otherwise, Box, Lasso, and Circle will act the way Blender does with Box select.
I’ll be making new videos and screenshots of everything after I either successfully compile Linux and Intel Mac (Apple Silicon isn’t a problem) or I ask for a buildbot.
edit: got a bit of playing around to do with CUDA in Linux tomorrow, hopefully goes well.
edit2: Alright, so I’m just going to assume nobody needs GPU-accelerated Cycles rendering for KEPLER in the year 2024. If somebody is actually out there who can run the latest Blender 4.1, but also can’t find something as recent as MAXWELL? I don’t know what to tell you other than you need to thank the devs who keep those buildbots running. The lengths they are going to allow those archaic jumbles of silicon to render Cycles about as fast as a modern CPU, without making multiple versions of Blender to accommodate…
4 Likes
Trying to select the outside seabeds of continents in Edit Mode is pure pain, especially when cutting out the seabeds from a heightmap. I’d love to see a “Select by Heightmap” type of selection operator which will automatically select the white (highest) point of your map once you have fed your texture into the operator, and you can then specify the contraction or expansion of the selection, whether the selection is inverted, or whether to select the grey parts of the map only. This would help with heightmaps immensely.
You would also be able to feed textures from shaders inside it too, as I feel this should be expanded to textures used inside shaders as an option. This will require the addon to treat the textures as greyscale for selection.
Simply put, selecting the flat parts (no elevation) of the outer areas of a continent where the seabed lies is painful when it comes to large amounts of vertices. There has to be a built-in addon to help ease the pain of selecting all of this, as many continents have thousands or millions of verts inside them, so having this kind of suggested builtin addon would work wonders.
1 Like
Free products on gumroad have a filesize limit, and the non-Windows builds are just a little too big to fit. So I can either charge a $1 minimum, or host them elsewhere.
edit2:
Going to update these again in the next day or two because VFS is improved, if not finished, thanks to the image and description from the post below made by @ChameleonScales.
I don’t have ortho yet, but also don’t have a need for it personally. Will poke around and see what I can about adding it, but if nothing happens by the end of the weekend I’ll redo 4.1.0 without it. So happy to get these 3 things all the way done finally (Object select, X-ray Touch & Enclose Intersect, and VFS). A month ago I had 3 things that were sortof good enough, but lacking. Never expected I would figure all 3 of them out, one after the other like this.
Apple Silicon 4.1.0
Intel Mac 4.1.0
Linux 4.1.0
Direct links for now, I’ll put them in a textfile on the main gumroad page later. Plan is to make the Windows page the only one, as long as it is small enough it will be hosted on gumroad, with a textfile that has links to the other builds.
I’ll update the screens and videos and all that stuff after one more thing. Going to try to make VFS better, will be great if I can manage to translate what @Cirno did with his addon into C / C++. If I can’t get there by the end of the weekend, I’ll shelve it until after I update the screens etc for the latest build.
Anybody want to help me play “spot the difference”? Like I know what’s different, but yeah. Not much experience with Einstein Summation 
This was based on an image that I think says:
-
Object position minus Camera position
-
Normalize that
-
Dot product with face normal
Cannot wait to be done with this. Selection will finally be finished, or close enough.
I’d like to understand this code just enough, just a little teeny tiny bit, so I can make it do its thing in C / C++
eye = Vector(rv3d.view_matrix[2][:3])
eye.length = rv3d.view_distance
eye_co_world = rv3d.view_location + eye
eye_co_local = ob.matrix_world.inverted() @ eye_co_world
faces = me.polygons
face_count = len(faces)
face_center_co_local = np.empty(face_count * 3, "f")
face_normal = np.empty(face_count * 3, "f")
faces.foreach_get("normal", face_normal)
face_normal.shape = (face_count, 3)
faces.foreach_get("center", face_center_co_local)
face_center_co_local.shape = (face_count, 3)
new_vec = face_center_co_local - eye_co_local
new_vec /= np.linalg.norm(new_vec, axis=1, keepdims=True)
faces_mask_facing = np.einsum('ij,ij->i',face_normal, new_vec) < 0
What it used to be. Basically what I was already doing from what I can tell:
vec_z = Vector((0.0, 0.0, 1.0))
facing_vec_world = rv3d.view_matrix.inverted().to_3x3() @ vec_z
facing_vec_world.normalize()
facing_vec_world = np.array(facing_vec_world)
face_normal = np.empty(face_count * 3, "f")
faces.foreach_get("normal", face_normal)
face_normal.shape = (face_count, 3)
ob_mat_world = np.array(ob.matrix_world)
mat = ob_mat_world[:3, :3].T
face_normal_world = face_normal @ mat
faces_mask_facing = face_normal_world @ facing_vec_world >= .15
Its a funny feeling. I can’t wait to be done scrambling my brains over Blender selection problems, but I can already tell I will miss it a little once it’s over.
edit1:
Ok, so I called a little bit of an audible here, and good thing too because like I said, I have no idea about Einstain Sumations and all that stuff.
Instead of continuing down that rabbit hole, I went back to the image, and used my own reasoning with it. Just get view3d position, subtract it from the face’s center position, normalize it, and then do the dot product of that normalized result with the faces normal. It works so far, but with all things, some cautious optimism is in order here. Need to go test it fully, and then make it work with verts and edges.
So, instead of getting the viewport angle, and comparing with the mesh’s normal angle, I get the positions of both. A lot less complicated so far than it used to be, and I honestly don’t quite understand how it used to work, I just took what Blender’s align view does and stripped it down to only what I needed.
New code, only works with faces, edges would probably get the position of their center point which I think I’ve seen somewhere in the source before:
BMIter iter;
BMVert* eve;
BMFace* efa;
float centerv3[3], viewcol4[3];
int vcount = 0;
viewcol4[0] = vc->rv3d->viewinv[3][0];
viewcol4[1] = vc->rv3d->viewinv[3][1];
viewcol4[2] = vc->rv3d->viewinv[3][2];
if (efa->len == 3) {
float tri[3][3];
BM_ITER_ELEM(eve, &iter, efa, BM_VERTS_OF_FACE) {
tri[vcount][0] = eve->co[0];
tri[vcount][1] = eve->co[1];
tri[vcount][2] = eve->co[2];
vcount++;
}
mid_v3_v3v3v3(centerv3, tri[0], tri[1], tri[2]);
}
else if (efa->len == 4) {
float quad[4][3];
BM_ITER_ELEM(eve, &iter, efa, BM_VERTS_OF_FACE) {
quad[vcount][0] = eve->co[0];
quad[vcount][1] = eve->co[1];
quad[vcount][2] = eve->co[2];
vcount++;
}
mid_v3_v3v3v3v3(centerv3, quad[0], quad[1], quad[2], quad[3]);
}
else {
float(*ngon)[3] = static_cast<float(*)[3]>(
MEM_mallocN(sizeof(float) * 3 * efa->len, __func__));
BM_ITER_ELEM(eve, &iter, efa, BM_VERTS_OF_FACE) {
ngon[vcount][0] = eve->co[0];
ngon[vcount][1] = eve->co[1];
ngon[vcount][2] = eve->co[2];
vcount++;
}
mid_v3_v3_array(centerv3, ngon, efa->len);
MEM_freeN(ngon);
}
centerv3[0] -= viewcol4[0];
centerv3[1] -= viewcol4[1];
centerv3[2] -= viewcol4[2];
normalize_v3(centerv3);
bool mesh_facing = false;
if (backface) {
mesh_facing = dot_v3v3(efa->no, centerv3) > ts->viewport_facing_select_threshold;
}
else {
mesh_facing = dot_v3v3(efa->no, centerv3) < -ts->viewport_facing_select_threshold;
}
The backface stuff is actually flipped from before when it checked the facing direction of the viewport and mesh normals, instead of the positions of the viewport and mesh.
@WhiteRoses54 thanks for the feature request, I got some stuff to finish for 4.1.0, recompile the builds, and then take a few weeks to do some non-Blender stuff. After that I’ll look closer at what you are talking about. Height maps are unfamiliar territory for me as far as Blender source is concerned, so could be quite a while before any progress.
I do hope this feature request I made can work its way into Blender, since heightmaps can be very complex when it comes to verts. I thought of that feature while doing a continent and trying to cut the seafloor out that because it often involves so many vertices, a “select all by heightmap” kind of operator or modifier would be a great addition to Blender. UPBGE is also based on Blender, so it would also have that too if the feature made its way in.
is there any feature similar to the X-ray selection tool addon to do
- LMB drag left: auto X-ray
- LMB drag right: regular selection
I look at your keymap example but that’s only for different modes or selections.
Thx!
I used to have 2 ways of doing everything in my build. There was a userpref where you would choose whether auto xray and selection style was controlled by the keymap, or in toolsettings. In order to fit in a little better with the way Blender does things, I made it where there was only 1 way. Selection style (Touch, Enclose, Origin / Center) was done in the keymap, and Auto X-ray / Select Through was done in toolsettings (via the viewport header dropdown and optional buttons). I’ve been thinking about putting that 2 way option back in anyways, so I guess I’ll start doing that.
I want to re-release 4.1.0 with a couple improvements sometime tomorrow hopefully. Have one more thing to do, get ortho working with VFS. I will also add directional control to Auto X-ray. I probably won’t have time to make it as robust as it will be for the 4.1.1 release, but if all you want is drag direction without any modifier keys and all the other benefits the keymap provides, you wouldn’t know the difference.
Unless things go very fast, all I will do for 4.1.0 is put some directional controls in the xray viewport header. There’s a dropdown next to the xray button in my build, and in there you would decide what dragging left and right would do. I’ll add a checkbox to choose directional control, where the existing options would be replaced with some dropdowns. One for left and the other for right. You would then just decide to use Auto X-ray and /or Select Through for Object Mode, Edit Mode, Both, or Neither for each drag direction.
4.1.1 would add this directional control ability to the selection styles of Objects, Edges, and Faces as toolsettings rather than just in the keymap. Select Through and Auto X-Ray would be added to the keymap, instead of just in toolsettings / viewport header. Finally, there would be a userpref to choose whether you want to use the keymap or toolsettings. I could add VFS as well, but that’s probably getting a little too crowded for the keymap at that point. VFS has many options for it, so it would either lose some flexibility or add like 5 different things to the keymap all by itself.
Keymap vs Toolsetting control isn’t much different, but there are 2 things I can think of that set them apart, and in my opinion it is worth having both options because people have different ways they like to work.
Keymap is more flexible with what can be assigned as a shortcut. There’s all kinds of input types (press, release, click-drag) that can trigger them.
Toolsettings can be toggled, and are easier to modify as a user. If you wanted to change something, you don’t have to modify every entry for one of the tools.
At least, that’s the way it seemed the last time I looked at it.
1 Like