It is difficult, and sometimes impossible, to accurately select multiple specific items in the 3D viewport when there is significant screen-space overlap.
For example, the following video demonstrates trying to select two bones, one of which is nested inside other bones (this comes up often when rigging). The video demonstrates this in three phases:
When selecting only a single bone, repeatedly clicking will cycle through the overlapping bones, which works great.
But if you want to add to your selection with shift-click, that same approach doesn’t work.
This can be worked around by hiding the bones you don’t want to select, but that has drawbacks (outlined further below).
The animation and rigging module recently received a PR that tries to address this just for bones. However, this issue isn’t specific to bones, and I think it’s better to address this in Blender holistically rather than with a bespoke armature-specific solution.
So I’m opening this thread to raise and discuss the issue outside of just the animation and rigging module.
Current Workarounds
There are currently three ways (I can think of) that users can work around this issue in Blender:
Orbit the 3D view. This works if the items involved are only overlapping from certain perspectives. This is not always the case, as in the nested bones example.
Alt-click, to bring up a menu of items under the cursor. This works when the items under the cursor have meaningful names that the user has memorized. This is often not the case. And this menu-based selection operator doesn’t exist in e.g. mesh edit mode, presumably at least partly because of the lack of names for vertices etc.
Hide the items you don’t want to select (as demonstrated in the video above). In addition to simply being slow/awkward, this doesn’t work well when you already have other items hidden for other reasons: when you un-hide to bring the items back, it brings back all hidden items, not just the ones you temporarily hid for selection purposes.
None of these are really good solutions, and I suspect we can do better.
One idea that occurred to me: we could add an operator similar to the alt-click selection menu operator, but instead of popping up a menu, it’s a modal operator that as you move the mouse left/right cycles through pre-selection highlighting on the overlapping items. When you finally click, it selects the highlighted item.
sets for selecting/hiding would be cool, especially in edit mode where there are no such tools. I feel like armatures are more likely to be intentionally overlapping than in other modes, so an armature-specific solution might not be bad as well.
This is exactly what came to mind when I read your first post, I almost wrote it in reply. If hovering over bone names in the “alt-click” popup could highlight the bones in question, I’d be sold.
This is obvious when bones perfectly overlap -when using the octahedral shape, it’s enough that two bones be the same size. If using the bbone shape however, you can work around the problem by scaling the bones non-uniformly. I suspect that once we get to node-based constraints/rig definition (virtual bones?), the number of “utility” bones needed for any given rig part will reduce drastically. So this may alleviate the issue somewhat.
Or we could tweak the selection heuristic slightly to make it so bones are only selectable with their outline. Bones contained in other bones would still be selectable. I’m not sure if this is desirable but perhaps it could be prototyped and tested.
It has been impossible to select objects when the armature is in the pose mode when the “lock object modes” is disabled in the 4.0 nightlies. Is this somewhat related issue? So far this has been the most frustrating part of using 4.0 for me, not sure if it is a bug or a new “feature” at this point.
I think the popup has a place in this special selection cases. Maybe highlighting as you go down the list? That way you don’t end up with the mouse cursor far away from where you were at the beginning, which I think it’s the main drawback of what you’re proposing (if I understood it right). Would something like this work?
There is a more general problem, but for arbitrary object shapes and shading it’s not well defined what the behavior should be. And so you end up with slower selection cycling, or a complicated heuristic for direct selection that may be unpredictable.
But for bones there may be a relatively simple and predictable heuristic. A solution specific to bones seems reasonable to me for that reason.
If you wanted a more general heuristic for direct selection, I guess it would be something like preferring the “locally smallest connected shape”. That is counting the number of connected pixels of the same object, within some area around the cursor. But an efficient implementation may not be simple, and it remains to be seen how predictable this is.
@txo The issue with also popping up the menu is that it blocks your view of the things behind it. When all the relevant objects/items are large in the viewport, that’s not a problem. But when some of them are small-ish, the menu will completely obscure them, preventing you from seeing the highlights.
That’s why I was thinking a new operator without the menu, but with highlighting, could work well.
Having said that, you’re making me wonder if we should approach this more as “re-thinking the alt-click selection menu”. For example, maybe there’s a good way to provide the list of items without them obscuring the view. Then with the addition of the highlighting you basically have the best of both worlds.
But for bones there may be a relatively simple and predictable heuristic.
Yeah, something like what @Hadriscus suggested could potentially work, where bone selection is changed to be outline based. Or at least outlines could be given priority. I suspect the heuristics for single-click selection elsewhere can probably also be improved, with some testing and iteration.
But I’d nevertheless like to see a more general backup solution. Even with good single-click heuristics, I suspect there will be annoying cases where those heuristics fall down. And it would be good to have a reliable and consistent fallback for users to handle those situations.
I just made a video and a Right-click Select proposal about this yesterday and someone pointed me to this thread.
Great to see that this is being considered on a higher level.
As far as I am concerned, I would be happy to be able to do what was possible in 2.79.
All of these ideas with pre-selection etc. are great but I don’t think we can come up anything that is better than a single click.
I am not sure that Xray mode is specifically good for that - pure wireframe mode does allow to select directly. Are those bones joined together? If yes, then indeed there is a problem.
Speaking of a selection problems, there were not only the selection process problems, but also selection display problems of overlapping items, which disallow to detect the selection properly, especially during working with linear/repetative geometry in ortho view or during working with dense meshes.
Something strange happened with the selection logics in general.
Similar to the bones selection issue occurs, for example, when you draw boxes with box drawing active tool - you cant snap to the vertices beyound faces even in wireframe mode.
In many cases wireframe mode does not support the behaviour which such a mode supposed to (in solid mode it is supposed to check/operate with composition, in wireframe mode it is supposed to check/operate with structure), which makes different working processes sufficiently harder than in 2.79, including switching between wireframe mode and solid mode, which is a highly relevant operation.
@ToshiCG I totally agree with your proposal. Embarrassingly, I actually forgot that Blender used to behave that way. I definitely agree that it’s a usability regression, and I think we should return to the old behavior.
But I would also still like to see a strong fallback solution for more complicated cases where even that doesn’t work well.
I am glad you think so. Of course, additional tools for more complex cases would be great. I think Blender could use some preselection in general. Is there are reason why preselection is not implemented?
Preselections are quite distracting and also expensive at heavyweight scenes, since they has to be calculated in realtime, so they could be nice to have in object mode as an option, but in edit mode they are prohibited as anti-feature, at least for mesh modeling engines (nurbs, for example, has complex internal components, so having preselection solution there has practical reasons)
Also, preselection will not solve wiremesh access problem, just will make it more obvious.
