Blender with Better Selection and More

[Lcas]

Quick update:
Wanted to re-release 4.1.0 yesterday but I found a few things I wanted to change. Was going to ask chat if there was any idea when 4.1.1 was coming but someone already did that. No release date for it yet, so I’m going to take my time with updating 4.1.0. Couple more days probably, end of week for sure.

Other than some general performance things I wanted to try, here are some things I’m changing:

Viewport Facing Select
VFS is fully functional now, so I am going to streamline it before updating the build. A single dropdown with some presets. No need for a threshold anymore. Don’t see a reason to select by vertex or edge normals, just if they are part of a front face. I don’t use the rear-facing option. Just going to call it “Backface” and add it to a “Drag Select” section of toolsettings with everything else. Will also put it in the keymap, and have a userpref to choose between keymap and toolsetting control.

Backface Presets:

1. Default - Does nothing

2. Fix Near - Leaves X-Ray / Select Through alone. Front Faces and Front Edges of Face only, doesn’t check near verts, because they have no problems and it would just waste performance

3. Front X-Ray - Does the same as Fix Near except it leaves near select alone and also checks verts

4. Zero - Front Facing mesh only. Both modes, checks near verts

Might add a checkbox / bool to turn it on and off and remove “Default” for the toolsettings version, because if you add a dropdown / enum as a shortcut, you have to choose which option rather than a simple toggle.

Userpref for Keymap vs Toolsetting
Used to have this, was thinking about adding it back. Will probably add directional control to toolsettings as well as keymap. It worked before, but it is simplistic. Will probably do each section / feature as an option rather than all or nothing. Like you can have some stuff in the keymap, and other things as a toolsetting / header button. So anything that isn’t in the keymap will be added to it, and anything that isn’t a toolsetting will be added to it.

The main thing I want to try again, is being able to hide things from the keymap that are set as a toolsetting. If I can’t hide stuff, I might rethink this idea. So before I go all the way with adding stuff as toolsettings or keymap options, I’m going to make sure I can hide them when applicable. Hiding Toolsettings is easy, but for whatever reason I can’t add an if statement to the keymap source. I am going to try and modify the python stuff the same way I did for Drag Direction and see if that goes anywhere.

[Lcas]

Luke's Custom Build (Win, Mac, Linux)

Build is done for all platforms. One page on gumroad, links to non-windows in a textfile.

Updates:

1. VFS is fully functional, renamed to “backface filter” and simplified.
2. Keymap vs Toolsetting control of:
   Auto Xray, Select Through, Object / Face / Edge select, and Backface Filter
3. New header buttons for Object, Face, and Edge that will cycle through the different modes. You can limit the modes it cycles through to only the ones you want. Backface filter is just a toggle on/off, the popover has 3 modes to choose from.
4. The header control is for straightforward access to Object, Face, Edge, and Backface selection options. All tools the same. If you want directional control or need to differentiate it per tool, use the keymap.
5. Did not change how the header for select through and auto xray work. Just added the ability to use the keymap for that if desired.

Lots of descriptions, screenshots, and videos to make / update.

[Brick]

Thanks for the new build. I appreciate that you are trying to improve Blender in this area.

First thing I noticed is that the ‘Keymap’ button in ‘Drag Select Settings’ dropdown is misleading. I expected it to enable Keymap, not disable. So it would be better to have 2 buttons - ‘Keymap’ and ‘Header’ to indicate which mode is enabled currently.

Do you plan to simplify directional selection as well?. I wanted to set it up using keymaps, but gave up when I realized just how many different keymaps I would have to create and manage . Also it somehow messed up the selection functionality for my vanilla Blender 4.1, since they share the config file, so I had to reset everything.

Maybe you could add some options in Input preferences to make it work globally? Like a drop-down list where you can choose Blender default or directional left-to-right or right-to-left, etc. It’s a general workflow preference that you want to set up once, and then always use it, so header buttons are not very suitable for that, because they reset with each new blend file. What do you think?

[Lcas]

Yeah I can do that for 4.1.1.

I know how it can be confusing. It is one of those questions that will probably never be answered, “Is this button telling me what it does, or what it is going to do?”

What I did was say "Selection Control : " or “X-Ray Control” and then a toggle button. The button is unlit and says “Keymap” because that is what it does by default, use the keymap. When you click that button, it lights up, changes its name to “Header” and reveals the relevant parts of the header. Why? Because Blender is a little weird, but for now I am not changing it. Would probably be a big deal to even figure out how.

Also, I don’t think there’s a way of hiding anything in the keymap at runtime. So if you use the header, the keymap stuff will still be visible, but not do anything.

Tried my best to deal with the annoying way that Blender deals with this sort of thing. Where it saves all of the viewport header stuff you do in the blender file itself. I do not care what toolsettings other people were using when they made a blender file to share with me, don’t mess with my settings when I open it, just give me the scene! But it is what it is for now. The alternative is to have only the keymap available which like you say, is not fun to set up.

If you don’t often share blender files with people who have different header settings than you, the only thing that should be different about my build is if you already have a startup file for 4.1. In that case it is very minor, just the header highlights, where the active header gets brighter. Everything else should be opt-in, and unchanged unless you enable something.

In object mode of vanilla Blender, circle and lasso work different than box. I tried to make it simpler for the header vs keymap since in my build they are capable of acting the same. But I also kept the default for selection and xray control in the keymap, that way it isn’t alterted unless you want it to be.

Was going to wait and see if anybody wanted directional stuff to be simplified, or if the people who want directional control use the keymap and don’t care either way. Didn’t take long, so I’ll be doing that.

Regardless though, it will probably have the issues I’ve talked about where if you share a file to work on, your toolsettings will magically change to the same toolsettings as the person who made / saved the file. I’ll look around for anything about this as well, I can’t be the only person who wonders why this happens. I really hope it’s just some userpreference you can set, where it leaves your stuff alone instead of importing everything via .blend

edit 2-
I don’t need to look into changing anything for .blend file loading because you can avoid the whole toolsettings change by doing File->Append in that situation, grab only the stuff you want, and keep the toolsettings of whichever file (probably the startup file) you want to use with it. What a relief, that might have been quite the task to figure out how to alter .blend file loading.

edit 1 -
@Brick I made this video for the previous version. If that is all you need, then let me know. If you don’t need it to be simpler than it is in the video, I won’t make the header button more complicated than it currently is.

Custom Blender Build with Directional Selection

[Brick]

@Lcas

I know how it can be confusing. It is one of those questions that will probably never be answered, “Is this button telling me what it does, or what it is going to do?”

At least in Blender a button always does what is written on it. Otherwise how would you know what a button does, if the label changes after you click on it (sounds like a great way to troll the user )? If there are multiple mutually exclusive choices like Keymap/Header, then there should be 2 buttons.

@Lcas

Tried my best to deal with the annoying way that Blender deals with this sort of thing. Where it saves all of the viewport header stuff you do in the blender file itself.

I don’t think there’s a point to fight this, that’s just how Blender works. It’s better to sidestep the issue by putting the settings that you want to “stick” inside user preferences. Like choosing which header buttons should be visible for quicker access or configuring how directional selection works. And you could add as many options as you need without worrying about screen space.

@Lcas

If you don’t need it to be simpler than it is in the video

It could be a lot simpler. Instead of editing 50 keymaps it could be just 2-3 options in input preferences where you chose direction (left/right or up/down) and maybe what to do when facedots are visible.
Unless for some reason you can’t add options to user preferences. I have no idea, I’m just throwing out ideas how to make it more usable for an average user like me

[Lcas]

I’ll put a simpler drag direction control in the header then. The sooner I do that, the sooner I can be done making this new walkthrough video without having to redo too much of it. I’ll add new things to the build over time, but I’m planning on leaving what is already there as-is from this point. The drag direction keymap improvements I’ve made will still be there, but won’t be the only way.

Everything else I was talking about is fine, but I didn’t realize that before I looked into it a bit. I’ll explain how things work, and why, regarding userprefs vs toolsettings. Long story short, I am working with what Blender gives me. I’ve avoided any changes to how it behaves while giving it a lot more flexibility.

I think you misunderstood me about the header vs keymap toggle. Sometimes a button has to describe what is currently being done, and change its appearance with different words and graphics depending on its state, rather than just being lit up or not. That’s what I was trying say before about a button showing “what am I doing” vs “what will I do”. There’s also the tooltip that explains things further, but I’m not sure how useful those are. It’s like proving a negative.

My build has userprefs for a few things, but they are not convenient to use. It is definitely worth avoiding userprefs for selection options that need to be changed often. Userprefs are an inconvenient, multi-window, multi-step process. Open userprefs, navigate to the correct area, click a dropdown, and then pick the desired option. Not everybody needs to switch selection settings on the fly, but it is easy to make that available without compromising other people. Toolsettings and/or keymap make it possible. Keymap is whatever. I don’t mind it, but I prefer the header for most things.

Toolsettings are great. They can be visible in the header so you can see what is going on, and change it quickly. Not much downside, and only in the situation where you have a vanilla startup file. You just set a few things one time, maybe two minutes of reading and clicking. Then they are fast forever. That is assuming you want to use all of my features differently than what Blender already provides. Most people probably only change one or two things about select through, and how you select faces and edges.

All of the following user types are covered:

1. You want to set up these features once, and use it the same every time.

2. You want all the selection tools (box, circle, lasso) to act the same, and switch between touch and enclose, select through, backface filter, or whatever else. Can do that anytime you feel like in two different ways. With the keymap by holding different modifier keys or mouse buttons for every single selection. Or more likely, you would want to do that with the header operators, because they can toggle things on and off. The other operators I’ve made cycle through the selection modes in whichever set of them you choose. Eliminate one mode you never use, or have it toggle between just two of them. Unlike the box – circle – lasso - tweak operator Blender has at the top of the toolbar, where you’re forced to go through all four of them every time. Most people would probably want to switch between box and lasso only, with a single shortcut.

3. You need each tool to be different, or any two of them to be the same but not the other.

4. You want directional dragging that actually works, while also not taking as long to set it up.

5. You have zero interest in any of these things, but want some other aspect of my build like custom mouse cursors, camera options, or the invoke last operator. There will be no changes to the way Blender acts.

The issue Blender has, is how it opens .blend files. A demonstration you can try:

Open Blender, change a toolsetting, save as .blend, make a new scene, then open the file you made. Toolsettings will be different, rather than the way your startup file has them. You might not even know what is different in a real-world situation, but you would eventually realize that something is wrong. You could probably figure out what was going on back when you made the file, but good luck remembering later. Imagine you are on a team with other people, sharing a .blend file to work on. They probably don’t have everything in their toolsettings exactly the same as you, which would be a chore to deal with.

There is a way around this, besides using a different filetype like fbx. It isn’t perfect, but it works. Use File→Append instead of opening .blend files directly. You have to specify what you want to append, and know which folder to find it from inside of the .blend file structure. But at least it lets you use .blend files without all the baggage they come with like changing your toolsettings. Not that I knew that before yesterday, but it is what it is, for now. I will probably look into changing this later. I’d like to do something similar to the “Load UI” setting for .blend files, where you can tell it not to change your UI when loading them.

[Brick]

@Lcas

It is definitely worth avoiding userprefs for selection options that need to be changed often.

I agree completely and that was my point actually. So things like auto x-ray and select through should be in the header, because that’s something that you going to use often while modeling. Or touch/enclose selection if user wants to toggle between them using keyboard shortcut. But directional selection is something you want to set up once and then use it forever, so it would make sense to put it in the preferences, where it won’t get reset every time.

@Lcas

Use File→Append instead of opening .blend files directly.

I’m pretty sure that trying to open a complex .blend file by appending everything is going to be way more complicated than reconfiguring header buttons again, so that’s not really a solution.
But anyway, I’ll have to wait for the new build to test it on a real scene and see how everything works.

BTW, do you think you could put auto x-ray toggle inside selection modes pie menu (Alt+W)? Kind of like Cirno’s mod does it. That would be a convenient way to toggle it without the need for additional shortcuts.

[Lcas]

Edit:
I just tried something, and it made me realize how much better it can be. I can just put userprefs in the header, instead of toolsettings. Everything up there is toolsettings, so I’ve always just assumed that’s what you had to put there. But you don’t. Userpref properties work just fine, and unlike toolsettings, they persist regardless of workspace changes from startup.blend or any other .blend file you open.

So much better now. This is why feedback is so useful. Makes me try things I wasn’t even thinking about. Still going to look into a setting for .blend files that will allow you to keep your toolsettings, but it will wait until I go through and switch the header stuff from toolsettings into userprefs. After that I will make a few operators and hopefully add a pie menu for switching through the fallback tools as well as change different properties of the things I add.

---

---

---

The only time your toolsettings change, is if you are opening a .blend file that was made by somebody who wasn’t using the same toolsettings as you. This applies to startup.blend as well of course. That’s just the way Blender works, like people say, and as usual it’s weird.

It’s nice to have the option to share your workspace, and makes debugging somebody’s problem easier for things that are related to it. Dev can say “Give me .blend file” and everything is there without having to tell them anything else.

But to force it on everybody with the default filetype? Bad. Just make the workspace a different filetype. Hopefully I can make a setting that just looks for the filename, and if it isn’t starup.blend it will give you the ability to tell Blender, “Hold the pickles, hold the lettuce, workspace doesn’t interest us.”

Besides that, I’m just going to make a 3rd way to control the new drag select stuff from inside userprefs. That way the header popovers can be what they are, minus the control switch.

It’s like a baby keymap for the extra options I made for the 3 drag select tools. Technically not a keymap, because there’s no assigning a key to it, you’d do that in the real keymap. This just lets you pick where the new things I made get controlled from.

If you choose the “userpref” control for either one, it will show you the controls for it. The directions for the keymap I already made still have an affect, they are global settings for anything assigned to “click-drag” in the real keymap. So if you need directional select for some normal thing that already exists in Blender, you’d need to set that up as well regardless.

Again, these drag directions I offer in this baby keymap only apply to the settings shown. Each tool operates independently, otherwise the directions would be a little odd. You’d be forced to use directional control for lasso if you wanted it for box, and understand that circle only uses the “Left” or “Down” direction.

All this thing really does, is allow you to avoid the keymap if you needed directional control for one of the new things I’ve added, but nothing else. Very niche, but it’s there.

Pie menu is something I’ve never messed with, so I can’t guarantee anything. Shouldn’t be too hard to figure out. The thing I’m hoping for, is that I can tell it to use the approriate property. There’s 3 properties for everything now. A keymap one, a toolsettings one, and now a userpref as well.

@Brick
Ok so I see what you are doing with the pie menu thing. The addon is just giving you its own version of the box/circle/lasso select tool, and making sure it is part of the list of selection tools in the toolbar, as well as the fallback menu. That Alt-W shortcut is just a way of changing what fallback tool you are using with the Transform Tools.

What you actually want, is a bypass button. By switching between the addon version of Box Select, and the real thing, you are bypassing what the addon does. So I’ll make a boolean property, where if it is enabled, it will just keep everything as Blender Default regarding Object, Face, Edge, Auto X-Ray, Select Through, and Backface Filter. I’ll put it in Userprefs or something, you can add it to the header if you want for easy reference.

This could lead to a “preset” system. Where you could make a handful of different setups for whichever selection tool, and quickly cycle through or toggle between them. That is basically what the keymap already does, but this wouldn’t require a bunch of different keymappings and making a claw-hand to hold some combination of SHIFT-ALT-CTRL for every single selection you make.

[Brick]

@Lcas

I can just put userprefs in the header, instead of toolsettings.

That’s an interesting approach. Probably goes against Blender’s regulations but it’s your build so nobody can stop you

@Lcas

So I’ll make a boolean property, where if it is enabled, it will just keep everything as Blender Default regarding Object, Face, Edge, Auto X-Ray, Select Through, and Backface Filter.

You mean toggling all those things at once? Because I was talking only about auto x-ray, since that’s something I have to toggle often while modeling. I can already control by assigning a shortcut to the header button, but as I said, adding it to the pie menu would be even better.

[Lcas]

Going really good so far, but I wanted to ask a question.

Is anybody in dire need of 4.1.1 right now? If yes, I will finish up what I’ve done so far and compile tomorrow. Otherwise I will keep going for about a week until I am done. If nobody has any objections by this time tomorrow I’m going to do everything before compiling again. Once I’m finished with this, it should be the last major change to how everything works.

4.1.1 has been out for a few days now, but I want to do one more thing: put all of my userprefs in it’s own section. Either above Interface or below Experimental. Having the new things I’ve added in different sections like Interface, Editing, and Input is confusing even for me. The sections Blender uses aren’t exactly free from overlapping concepts. When I test things before final compile I have to ask myself, “Did I put header highlights in Interface or Viewport?”

I’ve done a bit more than I was expecting, and the UI formatting is relatively slow since it is always a little wonky. Edit- By slow I mean takes longer for me to code, not that performance is slow, because of the trial and error aspect of how the formatting works. For example, I had to make a redundant enum because I can’t change the row’s heading without it moving to the line above it. This type of thing works fine for booleans, but not enums. Latest commit’s diff file is six thousand lines, and that’s before removing all the obsoleted toolsetting props I don’t use anymore.

Pie menu is a lot easier than I thought. You can just throw any operator you want in there. I made it where object select is only visible in object mode, and face / edge / backface is only visible in edit mode. Because if I put more than what you can see there, they start drawing on top of each other. Box, Circle, and Lasso with “Context” visibility means that if you are using Box, you will only see Circle and Lasso since using the “Box” operator wouldn’t actually do anything in that context.

Lots of useful new things. To the point where I am thinking about removing the keymap controls altogether. If I could guarantee that nobody is going to ask me about them later, I’d just get rid of them.

Last thing I’m going to do before moving everything in its own section is make a few operators I’m calling “Quick Assign” that will set everything for you, to give a starting point.

Quick Assign presets I’m planning on:
Default (Blender defaults)
Better (Touch for everything basically, and the operators that cycle selection modes will toggle between Touch and Enclose)
Directional (I think it was drag Left to do Touch and drag Right to Enclose, whatever it was requested like earlier in the thread or youtube comment)

If you have any preset requests let me know. I’ll be mentioning it in the walkthrough video(s) after I’m done as well. I will probably have 1 operator that sets things based on an enum (a dropdown with a list of options like “Default”, “Better”, “Directional”)

Directional controls are actually more flexible than the keymap. You can have Box on Left-Right and Lasso on Up-Down. You can also opt out of directional controls on a per-feature basis. Like if you want to use drag directions to control stuff, the operators that I made (accessed from the header, pie menu, and/or keyboard shortcut) won’t do anything. So I figured I’d add a second drag control mode where you can choose which features use drag select.

There’s an “Easy” mode where everything acts the same, and a “Split” mode where everything has its own controls. At the moment, I did not put directional control in “Easy” mode but I think I might make it available. I don’t see anybody doing directional with Easy mode though, because I don’t think too many people actually want drag direction control with Lasso. I also found that, at least for my brain, I can do Up vs Down Lasso more consistently than Left vs Right. But I never use directional control for anything, so what do I know?

[Lcas]

Sorry for the delay, been trying to figure out what was wrong with backfacing mesh filter while juggling some non-Blender stuff. I didn’t realize anything was messed up with backface selection until last weekend when I was testing stuff. Problem should be good now, was getting information about mesh location but it was in object space. Need position relative to the viewport, so object space is mostly useless on its own. Gotta add it to obact->object_to_world for that.

Been wracking my feeble brains for a while now. All I had to do was just print my position data and it would have been so obvious. Oh well, at least it looks good now. Going to get some sleep and hope it’s still good when I wake up

[Lcas]

Man, UI stuff sure can be weird. Had to tell bpy.ops.wm.tool_set_by_id to redraw the header when it gets called, otherwise the icon graphics don’t get updated when you switch tools. Not an issue unless you are in split mode where each tool acts different, but it needs to work right. Had to tell my pie menu operators that switch selection tools to do that twice. Otherwise nothing gets updated until you click or move the mouse in and out of the viewport:

class VIEW3D_box_select(bpy.types.Operator):
  bl_idname = "view3d.box_select"
  bl_label = "Box"
  bl_description = "Use Box Select"

  def invoke(self, context, event):
    from bl_ui.space_toolsystem_common import ToolSelectPanelHelper
    tool = ToolSelectPanelHelper.tool_active_from_context(context)
    tool_settings = context.tool_settings

    for i in range(2):
        if tool.idname == "builtin.select_circle" or tool.idname == "builtin.select_lasso" or tool.idname == "builtin.select":
            bpy.ops.wm.tool_set_by_id(name="builtin.select_box", space_type='VIEW_3D')
        elif tool_settings.workspace_tool_type == 'FALLBACK':
            bpy.ops.wm.tool_set_by_id(name="builtin.select_box", as_fallback=True, space_type='VIEW_3D')
        else:
            bpy.ops.wm.tool_set_by_id(name="builtin.select_box", space_type='VIEW_3D')

    return {'FINISHED'}

One more thing I want to change with the drag direction stuff. Nothing funcationality-wise, its just a thing I overlooked when setting the default Up vs Down direction for that mode. It makes sense to put the Up direction first, but I had set the default to Down. Just means some redundant lines in the formatting. If they were put in the same order, it would be Down before Up which is weird. So I just have to go and set the default direction here differently, and then change the variable names from upright to downright:

int WM_event_drag_direction(bContext *C, const wmEvent *event)
{
  const int delta[2] = {
      event->xy[0] - event->prev_press_xy[0],
      event->xy[1] - event->prev_press_xy[1],
  };

  const bool box_left_right = U.drag_direction_box == 1 && U.drag_control_mode == 1;
  const bool box_up_down = U.drag_direction_box == 2 && U.drag_control_mode == 1;
  const bool lasso_left_right = U.drag_direction_lasso == 1 && U.drag_control_mode == 1;
  const bool lasso_up_down = U.drag_direction_lasso == 2 && U.drag_control_mode == 1;
  const bool left_right = U.keymap_direction == 1;
  const bool up_down = U.keymap_direction == 2;
  int val = up_down ? KM_DIRECTION_S : KM_DIRECTION_W;

  if (left_right || up_down || box_left_right || box_up_down || lasso_left_right || lasso_up_down)
  {
    const float thetaf = 4.0f * atan2f((float)delta[1], (float)delta[0]) / (float)M_PI;

    if (U.direction_upright_box) {
      U.direction_upright_box ^= true;
    }

    if (U.direction_upright_lasso) {
      U.direction_upright_lasso ^= true;
    }

    if (thetaf > -2.0f && thetaf < 2.0f) {
      if (left_right) {
        val = KM_DIRECTION_E;
      }

      if (box_left_right) {
        U.direction_upright_box ^= true;
      }

      if (lasso_left_right) {
        U.direction_upright_lasso ^= true;
      }
    }

    if (thetaf > 0.0f) {
      if (up_down) {
        val = KM_DIRECTION_N;
      }

      if (box_up_down) {
        U.direction_upright_box ^= true;
      }

      if (lasso_up_down) {
        U.direction_upright_lasso ^= true;
      }
    }
  }

  if (!left_right && !up_down) {
    const int theta = round_fl_to_int(4.0f * atan2f((float)delta[1], (float)delta[0]) /
                                      (float)M_PI);
    if (theta == 0) {
      val = KM_DIRECTION_E;
    }
    else if (theta == 1) {
      val = KM_DIRECTION_NE;
    }
    else if (theta == 2) {
      val = KM_DIRECTION_N;
    }
    else if (theta == 3) {
      val = KM_DIRECTION_NW;
    }
    else if (theta == -1) {
      val = KM_DIRECTION_SE;
    }
    else if (theta == -2) {
      val = KM_DIRECTION_S;
    }
    else if (theta == -3) {
      val = KM_DIRECTION_SW;
    }
  }

#if 0
  /* debug */
  if (val == 1) {
    printf("tweak north\n");
  }
  if (val == 2) {
    printf("tweak north-east\n");
  }
  if (val == 3) {
    printf("tweak east\n");
  }
  if (val == 4) {
    printf("tweak south-east\n");
  }
  if (val == 5) {
    printf("tweak south\n");
  }
  if (val == 6) {
    printf("tweak south-west\n");
  }
  if (val == 7) {
    printf("tweak west\n");
  }
  if (val == 8) {
    printf("tweak north-west\n");
  }
#endif
  return val;
}

After that, test everything. Which at this point takes a while. By the weekend assuming nothing weird happens. Then just maintain what’s here, try a few new ideas out for some other features. Way easier from there on out.

[Brick]

These changes you’ve made look great. Should be much easier to customize everything. When do you plan to release a new build?

[Lcas]

Won’t be too long from now, a couple days. Have to test all the possible scenarios out. Looks good at the moment, but I have to go over everything very methodically and thoroughly just to be sure there isn’t one thing somewhere that isn’t quite right. Need to set a few default values, then go through the diff to find anything weird or overlooked. Then do a make format and test it all.

Over time I’ll come up with a method, but until then it’s just going to be slow and steady. Split mode, specifically with Selective direction control (your choice of selection features can use either drag direction or operator/pie menu) and the ability to keep any of the 3 selection tools synchronized with each other. That’s the one that needs the most attention when checking it out. Everything has to work correctly and simultaneously in both Python for the UI, and in C++ to do the real work.

[Lcas]

Luke's Custom Build (Win, Mac, Linux)

4.1.1 builds are done, lots of screens and videos I need to make, will take a while. Probably make some screens and text description in this thread before I got to bed. Then make some walkthrough videos and salespitch type of stuff to post around wherever I can think of.

Should be pretty good, but there’s always something, so let me know if anything is acting weird. Custom mouse cursors haven’t changed for Mac and Linux. The only ones that work are the ones that already exist in regular Blender: Sysem, Cross, Cross Dot, Cross Minimal, Dot. The ones I made are .cur files, those either aren’t looked for in the same way, or are the wrong type of file for those OS. Will look into it for a later release as well as any other feature requests from before.

At the bottom of Edit->Preferences there’s Luke’s Custom Build, a new section for the things I added.

Unless you want drag directions, or need box, lasso, and circle to work differently from each other, you should leave it on Easy instead of Split mode.

Quick assign will set things for you. Select a preset from the dropdown, then click Quick Assign to execute it. I’ll add any preset you have, so make a request.

edit: I’m going to change the formatting of this. Didn’t think about it before, but now that I’m looking at it, it’s kinda stupid. Just going to call it “Preset” instead of “Quick Assign”, remove “Quick Assign Mode” text, and the “Quick Assign” button that makes it happen will be called “Apply”.

The Better preset is what I will probably be using. Notice the header icons that show up.

The operator controls allow you to customize some operators that will change settings quickly. Either by clicking the optional icons in the header, assigning those to a keyboard shortcut, or by using the pie menu I created, more on that later.

Object, Face, and Edge operators will cycle through your choice of selection modes. Enable whichever modes by clicking on them (next to Cycle). The icons in the header and pie menu will change to show you which mode is currently active.

Backface, Auto Xray, and Select Through operators allow you to toggle the feature on and off. Backface will toggle it in one of the two modes it works in. Auto Xray and Select Through will toggle either in both Object and Edit mode, or whichever mode you are currently using.

If you are using directional control, any non-applicable operators will be greyed out in the header while that tool is active.

The pie menu controls allow you to show and hide any of the features in my custom pie menu operator. You’ll need to add this operator somewhere in your keymap, the tooltip for each pie menu option has the full name of the operator (view3d.pie_drag_select). Just type “drag” or “pie” in the keymap search and you’ll see it. Context view for the selection tools means that you won’t see the operator for the tool you are currently using. Edit mode stuff isn’t visible outside of edit mode, same with object mode. This custom operator is also in space_view3d.py so you could modify if even further if you feel like.

The icons for object, face, and edge will change, and the backface, auto xray, and select through icons will light up, to reflect their current state. If you are using drag control for box or lasso, any non-applicable operators won’t be visible when you call this pie menu with that tool. If you are using a non-selection tool (with something other than box, circle, or lasso as the fallback tool) the only things that are visible will be the box/circle/lasso tool switchers.

Directional control is only available in split mode. I could add it to Easy mode, but it kinda contradicts the name and intention of that mode. Assigning drag directions is more flexible than the keymap, you can use left right for box and up down with lasso for instance. But you can also use directional control in the keymap and userprefs at the same time. Video will explain this better, but basically, you do directional control in the keymap for things like Extend, Subtract, Difference, Intersect, and then userpref drag control for stuff like Select Through, Touch, Enclose, Backface Filter.

For example, you set the keymap to up/down, and userprefs to left right:
Up + Right = Extend + Touch
Down + Right = Subtract + Touch
Up + Left = Extend + Enclose
Down + Left= Subtract + Enclose

Pretty flexible if you have a reason for it.

Selective drag control lets you decide which features use drag direction, and which features use operator/pie control.

Split control assignments for each tool. Notice how box only has left and right dropdowns for the selected features according to what was chosen in the previous screenshot.

You can synchronize any combination of the 3 tools. This means that when you use an operator to change something, any other tools that are synchronized with it will do the same thing. If you are synchronizing box or lasso and they have some drag control, synchronization won’t do anything, because they are not controlled via operator. UI will reflect this by separating that tool out and greying out the dropdown in opcontrol.

The Object, Face, and Edge opcontrols have box separated and greyed out, but Backface, Auto X-Ray, and Select Through (just off screen) keep them combined since box is not using directional control for those features as defined in the screenshot earlier.

03. Mouse

Click select mesh and there’s a huge radius for it, except faces which have none. This will fix that, and allow you to choose how large the radius is.

75 is the default, can go as high as 150. Select Unbiased is something that is borderline useful. There’s a small bias, I think it’s 5 pixels, that Blender gives to unselected mesh so they are more likely to be selected over mesh that is currently in your selection. If this is messing with something for you, turn this feature on to remove that bias.

You can change the mouse cursors. In Mac and Linux you won’t get the full benefit for now. Unless you are using Windows, any new cursors I’ve made won’t do anything. They will turn whatever cursor into the system cursor rather than the cursor I’ve created.

When you first turn this feature on, you’ll probably want to hit the “reset” button unless you really want to change every single cursor into something else.

These are the default cursors. If you ever need to change one of them back to default without hitting the reset button, the one at the top of the list is the default for that cursor type.

Possible cursor options. 2D and Paint have one additional option called “Blank” that will hide the cursor.

04. Visual

You can turn off facedots in X-Ray now. Operator is inside the overlay header. Two modes, either toggle both Solid and X-Ray and keep them synchronized, or only turn off facedots in whichever of those 2 shading modes you are currently using. Solid means anything besides X-Ray. Default is to toggle the current shading mode’s facedots, because that isn’t going to catch anybody by surprise and is probably what most people would want.

Solid facedots on

X-Ray facedots off

The shading header is a bit excessive. 4 buttons to do 1 thing? Nah.

3 modes to choose from. Default leaves things the way Blender does it. X-Ray mode will combine the 4 shading buttons with the X-Ray button. It’s the X-Ray button with a different icon that changes with shading mode, and is attached to the shading popover. The X-Ray Button setting (next row in userprefs) will be disabled because the X-Ray button is “hidden” in this mode, from a certain point of view.

The 3rd mode is called “Cycle”. It will cycle through your choice of shading modes. Pick them by clicking their icon that shows up next to the mode dropdown in userprefs. When you click the header icon, it switches to the next shading mode in the cycle.

If applicable, you can hide the X-Ray header button.

I don’t like header highlights. They make the active window’s header brighter. It’s that horizontal strip at the top there. Default value is 5.

Highlights off

Highlights twice as bright

[Brick]

Ok, that’s a lot of stuff
I’ll try to test it over the weekend.

[Brick]

Finally had some time to test the new build for a bit.
Directional selection works great, haven’t found any issues yet. Although I think it would be useful to have ‘select by face centers’ toggle somewhere. Basically if facedots are enabled either in solid or x-ray mode, then they take precedence over directional selection and faces always get selected by their centers. Pie menu seems like a good place for that.

Regarding keymap controls - I’d say get rid of it. At least for directional selection. It would make your life easier and also minimize potential keymap conflicts with vanilla blender. For other stuff like auto x-ray, maybe someone would prefer to use modifier keys to enable it. So there might still be some use for keymaps in this case.

Also I would suggest changing the splash screen and adding some info to the lower right corner to indicate that this is a custom build and not just standard Blender release.

[Lcas]

I’ve been thinking about it, and I’m just going to remove the keymap controls. What I mean is these:

If anybody actually prefers them I’ll leave them alone, or add them back later in an update. I mostly just don’t like how they can’t hide themselves when they aren’t in use. I think like they are worse in almost every way. Holding modifier keys all the time is one of those things I avoiding as much as possible now, so I’m a little biased.

At the same time, I don’t necessarily have to remove them. So I’ll wait a week and if anybody wants them to stay, I won’t get rid of them.

Giving facedot visibility priority in selection is a thing I can do. For now I’ll add it as an option under face selection in userprefs.

I might expand the pie menu stuff a little more. Where you can decide how complicated it can be. Default will be the way it is now, but it will have a more complicated mode that gives the pie menu two stages with different sections. It would present you with a set of options like “Drag Select”, “Tools”, “Visual”, etc. You would click one, and then it would open that section and show what you actually wanted. It’s a two click process at that point, but can be left alone as a single click one as well.

[michalpe]

This stuff is mighty dope. Selections are quite annoying in Blender, but no more!

[Lcas]

Hey do me a favor and upvote this question, maybe someone who knows will see it:

Props Dialog Width Issue

Minor thing but ridiculous at the same time. Going to start porting everything to 4.2, should be ready by release.