Object Selection Accuracy

Hi guys,

I posted a question up on stackexchange a while ago but never got an answer. I was hoping someone here might be able to shed some light on what’s going on. Bear with me, it’s code-related

Here’s the question:https://blender.stackexchange.com/questions/78921/increase-object-selection-accuracy

Basically I’m noticing two different selection behaviors. The ‘select (de)select all’ tool will select an object while clicking up to 20 pixels off the actual object. So clicking on empty space <= 20 pixels away from the object will still select the object.

Border select on the other hand will very precisely select what’s surrounded by the marquee. So dragging the marquee up to the edge of an object will not select it until the object is actually inside the border, and it is exactly or very close to exactly pixel accurate.

So I thought maybe I could force more accurate single-click selections by invoking a single pixel border select through python, like this:

bpy.ops.view3d.select_border(gesture_mode=3, xmin=x, xmax=x, ymin=y, ymax=y)

But that gave me the same sloppy results as regular ‘select (de)select all’

A 2x2 pixel border like this, however:

bpy.ops.view3d.select_border(gesture_mode=3, xmin=x, xmax=x+1, ymin=y, ymax=y+1)

Gave me very accurate selections! But since it’s actually border selecting, executing this on overlapping objects would make multiple selections with a single click, which isn’t really what I’m after.

So I checked the source code for VIEW3D_OT_select to see if I could figure out what’s going on and saw this:

prop = RNA_def_int_vector(ot-&gt;srna, "location", 2, NULL, INT_MIN, INT_MAX, "Location", "Mouse location", INT_MIN, INT_MAX);

The location property takes a single pixel coordinate as it’s argument.

So what, if anything, is here that would cause this inaccuracy when a single pixel is given for selection targeting? Does the Integer 2 after “location” have anything to do with it? I couldn’t figure out what that value does. Furthermore, what is the benefit of this behavior? Why does selection work this way instead of only selecting what the user has actually clicked on?

I’m desperately trying to understand this. Thanks for any help!

1 Like

Hey, it’s been about 2 months since I posted the question so I thought I’d give it a bump. It says the thread has over 800 views but not a single reply! :o Is there a better place I could post this question to get some information? I’d still really like to solve this problem. Thanks for any info!

Property Vectors in Blender hold more than one value. That “2” in the prop definition is the size of the vector, so that property holds 2 integers (x and y).
Doesn’t select (de)select all always select all objects (without clicking) ?

A reply!!! First, thank you so much for replying.

From the API docs:
Select element under the mouse, deselect everything is there’s nothing under the mouse

So it’s single select as long as there’s something to click on, otherwise it deselects everything.

Ok, thanks for the info on the vector size. So I guess what I need to find out is how select is “casting it’s net”. There’s INT_MIN, and INT_MAX which I thought would be drawing a hit box or something to test for object intersection, but I can’t figure out where those values are being determined.

If you have any insight on that I’d love to hear it! Thanks again!

Hey, no problem. INT_MIN/MAX are the maximum and minimum values for integers. They are provided by C in limits.h (AFAIK) https://www.tutorialspoint.com/c_standard_library/limits_h.htm

This behavior has also been driving me crazy! Subscribed!

Thanks for that. I’ll start digging around there.
I’m glad I’m not the only one!

I reached out to Aligorith today, too, before I saw Januz’ reply. I’ll post up anything I find out here.

Made some progress!

In view3D_select.c I found a function called:

Which calls:

Inside mixed_bones_object_selectbuffer on line 1237 there’s this:
BLI_rcti_init(&rect, mval[0] - 14, mval[0] + 14, mval[1] - 14, mval[1] + 14)

This looked like it was defining a 28 x 28 rectangle with the mouse coords at the center.
So, I changed all the 14’s to 1’s, built Blender and this is what I got:

It selects solid objects beautifully! But, I think it makes selecting wireframe objects like lights, cameras, lattices, etc more difficult. But you’d think there’d be a way to test if you’re selecting a mesh versus a wireframe, right?

The bad news is that right now, other than doing a custom build of Blender, I don’t know how to work around this. I mean, they’ve hard coded a massive 28 x 28 hit box in to the selection test. Maybe someone who understands this better can chime in. I’ll keep playing around, even if I have to try and submit code to Blender, this really should be improved.

Awesome! Is there a mesh equivalent of that object pick somewhere?

ed_mesh_select_pick? Then we can just do a check if we are in edit mode or object and use either or accordingly?

I wish! As far as I can tell the selection stuff is all weaved together. I think all the testing for edit modes and object types is done either within that function or in functions scattered other places but called by the overall operator. And without modifying the source code we can only invoke that main operator and manipulate the few parameters that are exposed to Python.

It does look like there’s work being done on this code as recently as March 8 of this year:

But it looks like they are only messing with how they sort depth while selecting, and not the fact that you can select things that are nowhere near your cursor, haha. I’ll keep trying to either figure this out or bring it to someone’s attention who could actually do something about it. (I’m an animator not a programmer)

I’m just surprised more people haven’t complained about this. Is there some benefit to it that I’m not considering? Why would this be the desired behavior? I must be missing something but it’s not at all the way I’d expect it to work.

I have so many little questions like this. I tried that ed_object_select_pick you posted which is quite magical! I guess this is a good excuse to learn how to code :P.

Congrats on figuring this out ^_^. You should bring it up on bf-committers. It looks like those lines changed recently (by Campbell) but they still use 14, so there’s probably a reason for it.

I’m not 100% sure, but from looking at the code I think the reason for it is that they’re trying to catch non-mesh objects like cameras, lights, etc. that aren’t detected as easily with smaller hit boxes.

But I’m finding no trouble selecting even non-mesh objects with numbers as low as +/-3 so it just seems +/-14 is way too aggressive and leads to accidental selections and not being able to click-deselect in areas you’d expect to be empty space.

In 3dsMax the mouse cursor will change when you’re hovering over something selectable but without that visual feedback in Blender the massive 28px selection window becomes pretty unintuitive and clumsy to use.

Anyway, bringing it up on bf-committers is a good idea. In the meantime I’m actually working on a python-only fix that seems to be working pretty well!

Did you ever have any luck with this. So far there are a few issues with object picking that I’ve run into including the area outside the object selecting the object.

  • I can’t stand the regular view3d.select method that selects-through an object even if I move my mouse. Usually there’s a small distance tolerance from the initial click that you have to stay within to “click-through” an object to select one behind it. Luckily view3d.select_or_deselectall seems to work as I expect.
  • Unfortunately view3d.select_or_deselectall does not honor the ‘toggle’ flag, so you’re forced to use view3d.select for shit+clicks which of course has the issue mentioned above, but is at least used a bit less often.
  • Click-through selection order is broken in all mode. If I have 3 objects in a row, I’m able to make it work from one viewing angle such that it selects the closest, middle, farthest objects in that order. But if I rotate around to the other side and try, then it selects closest, farthest, middle.

All the UI improvements for 2.8 are really cool and all, but I really wish they could improve on basic operations like object selection as I’ve never had these issues in other apps.

All the UI improvements for 2.8 are really cool and all, but I really wish they could improve on basic operations like object selection as I’ve never had these issues in other apps.

I could not agree more with this.

I’ve worked professionally in 3d for almost 15 years and almost everyone I’ve come across has at least tried Blender. And almost none of them stuck with it for more than a day or two because it just doesn’t feel like a good way of working, and I think selection issues like this one play a really big part in that perception.

I think it’d be great if there was an addon that would just override Blender’s workflow and give users a true 3dsMax or Maya interaction mode. That way all the die hard Blender guys don’t freak out, and everyone else could could actually use Blender without getting frustrated and giving up.

I really think like 70% of Blender’s workflow could be made to behave like conventional software just though python scripts alone.

I mean, look what I was able to do with the timeline just using python:

Unfortunately this took me MONTHS to figure out and I’m sure my code is super inefficient.

I got pretty far along with my selection script, too. I got it behaving almost identically to Max’s selection workflow in object mode, and also in vertex and edge sub-object modes. Including the click-through behavior you’re talking about. But I eventually gave up because I had to then script the same behavior for working with particles, splines, grease pencil, etc etc etc. It just got way too complicated.

I wanted to show some progress on my python selection script.

Here’s the standard broken selection order cycling like you described, selecting in reverse order:

Here’s it working correctly from both angles using a custom depth search:

Mine will only select through an object if the mouse hasn’t moved since the previous click.

And It also works in edit mode on verts and edges.

Here’s the standard selection accuracy, just terrible:

It’s so bad in edit mode it’s impossible to deselect a vertex without either clicking off the object or zooming in. Even clicking off the object results in accidental vert selections! So frustrating!:

Here’s the accuracy improvements with the script in object mode:

And a HUGE improvement in edit mode:

1 Like

Nice! Those changes look great. Were you able to do them all with Python, or did the distance selection require changes to the C code?

It’s still so bizarre to me that some things in Blender are so different. I had to make a small script just to get Ctrl+S to save without prompting because I switch between Blender and Unity a ton and would often miss-click on the popup prompt and then wonder why things didn’t change in Unity. (There’s even a flag on the save operation that sounds like it would prevent it if you checked it on your hotkey setup… but no.)

There are 1 billion options in the User Preferences (including an option to not even prompt if you quit with changes made), but not one to simply let you save without prompting like every other application ever!

To be fair, there’s a lot of great stuff in there, but the UI/UX needs some help if they want to reach more users and get more donations.

Hopefully v2.8 will help some of that, but I noticed that they merged some of the dope-sheet into the TimeLine. But not the timeline into the dope-sheet. So instead of just having the dope-sheet up (with the playback functionality there), you now end up having to have a timeline which includes the dope-sheet as well as the Dope Sheet up if you need to access Actions/etc. !??!

I’m doing it all just with Python! :slight_smile:

Yeah… I’m not crazy about what they’re doing with the timeline so far either. Hopefully whatever changes they make just gives me better access to the timeline so I can script something to bend it to my will.

The save without a prompt thing… I know. I know. I think if they’d lean a little closer toward a conventional UI/workflow on the super basic low level stuff and only break convention where there was an actual advantage to it their adoption rate would skyrocket. And I really want it to. I’d love it if Blender was used by all the top studios.

But we’re evaluating software at my studio right now and no one here will give Blender more than a day because those basic, basic interactions are so clunky and unpolished feeling. Even though the software is obviously super capable and powerful.

Anyway, gonna keep picking away at this selection stuff because I think that’s one of Blender’s biggest failings right now.

I have to agree with OP when you are coming from 3ds max or other 3d package you feel that strangeness when selecting in viewport.

But keep in mind also that 3ds max introduced new highlight over selection and the code for this broke selection in both max 2017 and 2018. Even if it is a bit better in 2018 i still have a lot of funky behaviors like having to zoom in and out to be able to pick an object and dragging a rectangle marquee around a bunch of objects often left a few unselected and the trick to make it work is again zooming out and in until you found the sweet spot where the selection work.

If they can make it better i am all for it but in the current state of 3ds max selection i am currently happier in Blender since when i select something it is at least working the first time i click on the object.

Oh trust me, the Max team that made the UI/workflow intuitive, comfortable and cohesive is long gone and they’ve been hard at work making it worse ever since. It stayed pretty true to Max’s core workflow philosophies up until 2014-2015 maybe? Ever since they keep trying to make it more like Maya, which is a terrible workflow template to follow. They started hiding really useful tools by default, removing helpful icons, making new workflows convoluted and hard to figure out. It’s been really frustrating to watch the direction drift so far away from it’s roots.