Yeah, but, double click with programmable mouse buttons or macro keys are just like single click buttons. But they do increase the number of single use keys in any setup. I don’t like double clicking a button either, but when setup correctly, you don’t have to double click 
Technically, yes, but it comes with peripheral dependency.
For example, I can use such a solutions for myself (like g300s I personally use because of additional buttons), but I can’t propose it for the studio I work or to the masses.
I am glad that it is in general possible to avoid doubleclicks by design, and such a design was discovered and implemented in Blender instead of cloning solutions that already exist on a software market.
Pretty brave and useful step.
True, true, but for peripherals, it’s nice to have additional buttons that you can actually input (unlike F13-F24) and which you know won’t lead to conflicts. That allows you to circumvent having to go through loops and change the regular keymap just so you can use your peripherals. But let’s not get side-tracked any further.
1 Like
-removed-
E: Not to pressure you but what are your plans moving forward? Do you have a release target for the patches? Will you do a 3.4 update or do you plan to skip this version and release 3.5 later? I may be working extensively in Blender in the near future, so this would help me plan ahead
1 Like
No pressure on my end, just a little holiday break. Will go through 3.4 and send what I have soon. 3.5 will probably be done within a week of it being released.
None of those icons are things that I am changing, not seeing those errors in console either. What addons you using? I will try a couple and see if it happens or not.
I thought the issue that I had might have been caused by this, but apparently you need Developer extras enabled to see operators in the search bar. So that’s fixed now 
I can wait for the 3.4 update, then I’ll use the occasion to go over all my addons to update those that need to. Could very well be that some of my addons are outdated/ incompatible and thus prompting erros. No worries for now.
Hey there, I am just writing to say a huge thank you as I love to use your branch of Blender 
I was simply wondering if version 3.4 would soon get released or will it be 3.5? Some addons I want to play with only works with 3.4 and higher so I was wondering
THanks again!
1 Like
You’re welcome, wrapping things up. Either today or tomorrow it should be uploaded. 3.5 will be ready when it comes out. I keep either finding something that isn’t moving over to 3.4 smoothly, needs to be changed a little, or a I just lose the time I had set aside to work on this because some non-blender stuff has to get done first.
Wow, that is some great news!
Thanks again for all that hard work!
I have a family and so I too understand what it is not to always get the time you’ve set aside for your personal stuff 
Take your time and have a nice day!
I’m finalizing how I am going to do a couple things for this version, thinking about it for a little while and then just get it done. Biggest thing I’ll probably change is the tool synchronization for controlling the non-keymap way of using different features.
Then for 3.5 either refine things further in that direction or switch it back to something from a previous version. Depends on what I hear, and how it feels like using it.
I like the idea of iteratively improving things till it is ripe for submission.
1 Like
Pre-Release Build Blender 3.41
I started to realize yesterday I was going to need a few more days to do everything I want with 3.4. So I made a full build (meaning CUDA/Optix are in there) out of a few earlier stripped down diffs to tide people over. This is the meat and potatoes version, also they’re leftover from the other night and a little over-microwaved 
It has auto xray, select through, mesh selection options, a new object select option, and a fix for directional select. Pretty barebones, some things don’t have keymap, and other things are forced to use the keymap. The final relase will have both options available for everything. You’ll need to opt-in to some things that would otherwise have a default set to “on”. For example, select through would be on for all tools in object mode. Just turn it on, and select all the tools and modes you want.
No keymap for auto xray or select through, its in a dropdown next to the xray header button.
You can turn select through off in object mode. You can turn object origin selection on for box, and off for circle. Lasso doesnt work right, so it is stuck with object origin select for the forseeable future. I actually use lasso to approximate a circle in order for circle to work like box select does in object mode. Despite this, lasso will cut corners and select things you would be intentionally moving around to avoid selection. To a point it is unusable, like you could make simple roundish shapes with it and get what you’d expect for the most part, but try to manuever around something in an L shapre or anything like that and it will select it. Going to move this to the “options” section of toolsettings so it isn’t in the tool header.
Directional select works like it ought to, just left and right. No tweaking for unassigned directions like North-East, or making a decision about North always being the same as East or South always being like West.
Mesh selection options are only in the keymap.
Anyways, I need to go through and change a bunch of things around both in where everything is at and how it is processed. The main thing I want to fix is how I tell it which selection style to use. Last build I had a thought about making it “simple” by sending 3 ints (vert, edge, and face) to each tools userdata. Like the one’s place of this int would tell it which type of frontface selection to do, and the ten’s place would determine which of the mesh filter things to do (default, touch, enclose, center). It works, but after a few months of not looking at the code, it was as if some other person wrote it. I have to constantly refer back to it and have notes everywhere to tell me what a int edge_style == 23 actually means. Switching this to a bunch of bools, with descriptive names.
Going to put most or all of the userprefs for my stuff in the miscellaneous section so they’re in one place. Also probably moving the auto xray and select through into the “options” section of toolsettings. Can get rid of that xray popover and combine the xray and viewport shading buttons without adding even more stuff to the viewport shading popover.
Switching between keymap or toolsetting control over any of the features will be a userpref, and should be able to hide everything that isn’t applicable depending which one you choose.
5 Likes
Nice news, occluded selection option was added in 3dsmax 2023.
1 Like
Hi,
I like new UI.
So far I’ve found two issue:
-
Lasso selection - missing “Object origin select” option and it did not select objects by touching, only if object origin in selection.
-
And a discussion about selection lights objects (or all extras) only for their origin (if not possible to exclude line).
Possible solution (I know checkboxes is pain in a*):
split “Object origin select” to the three options (or similar):
Select by: Origin, Objects all, Objects meshes.
Or your vision about this.
Why only there?
As in my 2 point, it would be nice to see this as options.
And in opposite way, would be nice to see “Select by” option in keymap.
But I think UI should be discussed at the finish way.
1 Like
No lasso object origin options because it doesn’t work. It cuts corners or something, but not quite that. As it makes the polygon for selecting, based on what is drawn, it does some min/max bounds stuff that just isn’t working for anything that you would actually use lasso for. If you make a shape that is sufficiently “inside” the vertical and horizontal space of an object, without being inside it, but an L shape sort of thing, it will select the object. Just watch it will make more sense probably:
This is a prerelease build since a couple people have been asking about it. I decided to change more about this for 3.4 than I anticipated and I’m not going to be done this weekend like I had said. So I threw this together in case it was useful, and to get some feedback. Lot’s of stuff missing from it, like the ability to use either toolsettings or keymap.
Turning on Object Origin for box seems to apply to extras as well, which is interesting. I like the idea of having Origin, Object Mesh, and Object All. I’ll have a look and see if it goes somewhere as far as filtering non-mesh objects.
Maybe this will be helpful, using addon X-Ray Selection Tools - Released Scripts and Themes - Blender Artists Community
I have no problem with that
Ask the author how he did it?
no hurry, in your spare time
I grabbed the latest version of that to have another look, it’s the same addon I’ve seen before. Great stuff, and from what I can tell, he redoes the selection process inside of python. The autoxray feature is based on what’s in there, but works much simpler in my build because I could get away with not having to rewrite anything.
I’ll probably work on lasso some more for 3.5 once I’m done with 3.4. Not much time left before 3.5 has to be done so not sure, depends how easy it is for me. Anybody is welcome to lend a hand, I’ll put links to all the different features once I have it all split off.
This is pretty interesting:
def get_obs_mask_overlap_lasso(obs, obs_mask_check, depsgraph, region, rv3d, lasso_poly, check_faces=False):
list_of_obs_to_check = compress(obs, obs_mask_check)
bool_list = []
for ob in list_of_obs_to_check:
ob_eval = ob.evaluated_get(depsgraph)
me = ob_eval.to_mesh(preserve_all_data_layers=False, depsgraph=None)
vert_co_2d = get_vert_co_2d(me, ob_eval, region, rv3d)
verts_mask_in_lasso = points_inside_polygon(vert_co_2d, lasso_poly, prefilter=True)
if np.any(verts_mask_in_lasso):
bool_list.append(True)
else:
edge_vert_co_2d = get_edge_vert_co_2d(me, vert_co_2d)
edges_mask_isect_lasso = segments_intersect_polygon(edge_vert_co_2d, lasso_poly, prefilter=True)
if np.any(edges_mask_isect_lasso):
bool_list.append(True)
else:
if check_faces:
face_vert_co_2d, face_cell_starts, face_cell_ends, face_loop_totals = get_face_vert_co_2d(
me, vert_co_2d
)
if face_loop_totals.size > 0:
faces_mask_cursor_in = point_inside_polygons(
lasso_poly[0],
face_vert_co_2d,
face_cell_starts,
face_cell_ends,
face_loop_totals,
prefilter=True,
)
bool_list.append(np.any(faces_mask_cursor_in))
else:
bool_list.append(False)
else:
bool_list.append(False)
ob_eval.to_mesh_clear()
bools = np.fromiter(bool_list, "?")
return bools
Looks like he’s telling an object, “gimme your verts” and then projecting them in 2d. If they’re inside the lasso, good. If not, check the same as edges being intersected. If still nothing, check if the lasso is fully contained inside of one or more faces. This could get really slow if there’s a lot of complex objects I imagine.
Some or all of that stuff might already be in source, which would make it much easier for me to get it working. At the moment I’m just using what box does, which works ok for circle at least, and simple shaped lassos.
5 Likes
Trying to finish up with the directional keymap fix, because it doesn’t work quite right. What little I know of C absolutely dwarfs my understanding of Python, and doing something as simple as setting an enum value has annoyed me enough to ask for help. See this stackexchange link:
2 Likes
Did you try asking in the IRC chat on this?
I thought keymap direction was something that was finished but it has some… cosmetic issues that are a deal breaker. It will be fine for a custom build, people will just have to ignore the irrelevant directions. That’s preferable to copy-paste the operators name and make a new entry every time. So incredibly stupid, and all just to limit the number of choices in the direction enum. Purely visual stuff, nothing for funtionality at all. Unbelievable. I have working enums that do this, but they don’t set to any direction other than ‘Any’ until you make a new keymap item and whatever needs initializing happens.
At least it isn’t me being too dumb to figure it out how to get and set an enum with python, it’s not something that is done from that direction apparently. Best I can do would be run an operator that changes a hidden direction enum on every keymap entry for whichever tool. Or the first entry in the list, or the last entry in the list. None of these are very useful for my intentions. If someone like dodo can’t tell me how to get a specific keymap item that an operator is running from, I’m not going to waste any more time thinking about it.
I thought maybe I could make some goofy boolean for each keymap item. Like a safety switch that says it’s ok to perform an operation on whichever keymap item has it enabled. Not only is that too weird anyway, but it would then need to do some counting trickery and generate the correct amount of bools or ints in an array depending how many keymap items it see’s, just to show the user which direction is happening for the keymap item. And then, it would have to run every time the keymap is opened or something, otherwise you wouldn’t know what direction for any given keymap item until you click one and it updates itself. All terrible.
There might be some potential here for a batch assignment sort of thing for the keymap. Basically, I know how to put an operator in the keymap, and unfortunately, all I can do with it is run it on all keymap items for a specific tool. Or the first/last which honestly isn’t very good for much other than sorting items.
Going to bump everything to 3.5 so it is ready close to release. I do wish the new diff website would allow me to just hit an upload button to send a diff, but I’ve been told it works easier now. Not sure what wasn’t easy about it before but what do I know, not my thing to begin with. Shouldn’t be too much bs to get it set up for me hopefully. If I have time I will put together a more generic / convenient direction thing that just works for box and maybe lasso similar to the way these patches do.
https://archive.blender.org/developer/D10525
https://archive.blender.org/developer/D9180
3 Likes