Decoupling x-ray and limit selection to visible

[1D_Inc]

@slowburn

@1D_Inc

I’d say directional selection is not a problem but a solution to the other 2 problems . It doesn’t matter in which direction you draw a rectangle, in the end it’s gonna look the same, so there’s no situation where you couldn’t make a desired selection with directional approach.

People mostly trends to start the selection from empty space, to have a better control of an opposite box selection side since it is the most flexible. In directional selection type you often have to start a selection from a model, or control less flexible corners. Something like that:

The Adaptive/Manual has some advantage if you have to work with complex contours, and directional have some advantage when you have to work with overlapping geometry - for example, it is popular in architecture where are lots of windows in walls, but, for sure, none of those advantages can be considered as critical, and everything is case-dependent.

I guess the Adaptive one was originally selected as the default one because it provides the most flexibility for the least amount of options (it doesn’t require any options at all, so it’s minimalistic).

Power select addon

An interesting concept, but it seems to be suitable mainly for exterior modeling, because when modeling an interior, the model takes up the entire screen.

@lcas

The “endless” disucussion

In general, I think that any UI solution can be solved with an addon, as long as the API provides technical support for the functionality. This will provide any desired user interface flexibility while avoiding custom builds of the entire program or controversial hardcoded UI solutions.
Thus, as soon as the API provides functionality, even without being stated in the interface, the reason for having an “endless discussion” will be exhausted.

[lcas]

Not making a custom build is the goal, but I do one for myself because I can. I share parts of it here because kio’s patch made it possible for me to get this feature, and this is where I found it. The alternative is waiting around hoping someone solves my problems for me. I wouldn’t want to be in that position, and I’ve tried to encourage others to do the same for themselves.

The “endless” was in quotes as a response to a rhetorical question that amounted to “No need for talk, guys, this addon answers all our prayers” but unfortunately the addon is lacking. I don’t have an issue with the discussion, I try to keep it going if anything. I don’t care for arguing or complaining all the time since I don’t need to, there’s no reason for it when blender is open source, but will speak up when I feel the need.

[1D_Inc]

So, the original goal is to define which functionality API lacks then, and patch it, that will allow to achieve any desired UI realization via custom addon, exposing and combining patched functionality?

Such an approach differs from trying to build a full stack (UI+API) versatile manifold solution that fits everyone everywhere at once and include all possible cases and workflows, as it looked from the outside.

For example, in the second case, the core developers must provide a complete UI-wise solution that will satisfy everyone, and in the first case, just additional API functional blocks for the ability to satisfy everyone.

[Hologram]

@lcas do you then plan to submit a second patch for the facedots and perhaps the select by area/ included?

[lcas]

You’ll have to dumb it down for me, I don’t know what “full stack ui+api versatile manifold solution” means. I kinda get what you are trying to say, but for the most part, it’s just buzz words.

I will try to explain what I am doing here. Maybe you aren’t even asking that and I’m misinterpretting you, but I’ll answer anyways. Short answer is I am trying to help a community that has done the same for me. It is also fun to figure things out. Sometimes it is annoying when it doesn’t go anywhere and (in my own mind at least) I’m really close to figuring it out. But that is part of what makes it rewarding I guess. I also get new ideas to improve my own build or workflow, and bug fixes, by sharing it. Select through is the only complicated thing I add to my custom build, the rest is just convenience or visual stuff like frame selected distance, zoom speed, different mouse cursor, etc.

That is the main thing I am doing here. But not the only thing. I’ve been asked enough times to submit something and I finally did, knowing there’s not a lot of likelyhood of it happening, and saying as much a few times. What I mean when I say that not needing a custom build is the goal, it’s for the handful of people in the thread not needing one from me. Little time or effort to compile and upload a build, and I get some fixes and ideas in return, but it would be better if it wasn’t needed. So, if some form of select through does get added to blender, that might be good enough that a custom build isn’t needed anymore.

@Hologram from what I understand this isn’t a submitting a patch situation as much as a discussion about what might be considered in the future, with some test builds on the side because why not. I’m open to whatever though.

[1D_Inc]

@lcas

You’ll have to dumb it down for me, I don’t know what “full stack ui+api versatile manifold solution” means. I kinda get what you are trying to say, but for the most part, it’s just buzz words.

Development is usually split to frontend and backend parts.

Frontend development stands for user interaction (UI) - it is about checkboxes, preferences, visual design, logics of use and other stuff that forms user experience, since is visible to a user.
Backend development stands for Application programming interfaces (API) - technical capabilities of a program, its building blocks under the hood that are indifferent to shaping the user experience since is invisible to a user.

Fullstack development is a development of a feature that include both UI and API - from technical capabilities to a user interface that interconnects these technical capabilities with some kind of logic.

To avoid the necessity in custom builds sometimes is enough to patch backend API parts, providing necessary capabilities under the hood, and solve UI part with custom addons that utilize provided capabilities.

[lcas]

Thanks for speaking plainly. And yeah, I suppose it goes without saying that if blender did select through already I wouldn’t need anything other than the keymap, an addon, or some python scripts I make for myself. But here we are.

I tried to ask before sending the diff, both of the guys in the thread, and afterwards of a dev because the results of the poll I made were more than anybody could expect to be accepted. I made my plans known throughout that proccess. I asked a dev if they even wanted to read a select through diff, and what they wanted it to be, but didn’t get an answer. I come back here, and say I am willing to act as if and move forward, but only if you guys want to play along with me. Some other things get added and I throw the latest custom build into a diff. For the most part, no response, but Julien subscribed and since he is a dev I asked him what he was interested in. Now we are at the point where I wanted to be before sending the diff, we have some idea what the devs might want to see, but I am having to explain what I’m doing again. Maybe in explaining what I’m doing, I can get a clearer idea what to do? It’s pretty simple though, just 3 checkboxes, pending further developments in the thread.

Anyways, explaining again what I did: Since I got nothing from the dev I asked questions of, I made a choice between three things. Either take the obvious hint that a non-response gave and leave it alone, split it up into 3-6 different diffs, or just send it all at once. I went with all of it. Easier to just it send as-is to save time, get a response, and go from there. As long as I send all of what seems to be wanted from different people, I don’t keep getting asked to send a diff for review. If I had gotten a response beforehand I would have acted differently, but I didn’t get one. I expected the dev to tell me something along the lines of “Thanks, but no thanks” based on what I saw them say about kio’s patch.

And that’s what happened, auto-xray is about the only thing that might have some chance. It wasn’t added until after the poll, and I don’t even use it personally, but I am happy to help.

You were here for all that, concerns from both you and ludvik, going back a couple years at this point, are the reason I even asked the question in that poll months ago “Do you want me to send a diff?” Got yes answers only. Not about to justify what I do to anybody, but I am submitting this on behalf of the guys in the thread, and would like to at least put stuff stuff like “killing the patch” to rest. Didn’t matter that I am the only one keeping the patch alive, while telling people to lend a hand however they feel like, and that I try to be really accomodating to people who have nothing coming their way otherwise. I got accused of killing the patch anyway. You have to consider the merit of the person who said that though, they’ve been called out over and over, it carries no weight.

[lcas]

[TEST BUILD]32 RC Lite Select Through
This is a lite build of 3.2 RC, it is cut down to 3 features located in toolsettings, aimed at fullfilling what might be considered for real blender.

Object Mode will only show auto xray if using box, lasso, & circle (or as fallback option of another tool)

Edit Mode will also show Select Through & X-Ray Facedots

If Select Through is on, X-Ray Facedots is greyed out

1. Auto X-Ray turns on X-ray for you while drag selecting in box, lasso, & circle

2. Select Through will act like X-ray is on without changing anything visually during box, lasso, & circle. If selecting edges, it will select any edge intersected by the selection area.

3. X-Ray Facedots is on by default, it selects faces by their center, but only in x-ray mode. If turned off, you select any faces hit by the selection area of box, lasso, & circle select. Select Through does not use X-Ray Facedots. Intersect Select Mode doesn’t work quite right, but there is a workaround that will at least select any faces that are fully enclosed by the selection area. This is because the workaround swaps in and out of edges, and any faces without all their edges selected will not be part of the end result.

I put these toolsettings inside the collapsable area because otherwise they clutter the toolbar as noted a while back. Any suggestions or bugs? Another way to add visual feedback instead of a header button would be to change the mouse cursor. I remember a couple years ago there was talk of a mouse cursor that would change to reflect the current tool, but never saw anything in action.

[LudvikKoutny]

This has more or less converged to what I imagined originally. The only difference being that I’d change the meaning of the existing Xray button (in the vanilla UI top bar) to be the select through toggle, and I’d give it a popover menu where the Auto Xray and Xray Facedots reside.

Usually, what the user needs to see at glance is whether they are in a mode which selects only the visible faces, or whether they are in a mode which selects the entire volume inside the box/lasso. Knowing if this selection is being performed by select through or select through with xray is secondary, it’s more of a workflow preference.

So having select through being the icon button ON/OFF state of which gives user visual indication of how the selection is going to behave is a bit more useful then not knowing the state of select through, and instead of just knowing which type of select through workflow is active (Xray on or off).

[Schiette]

I agree with @LudvikKoutny but I would also be ok with this landing in master as is and then later refining the behavior.

Given the history of this feature any change that introduces the concept of select through without having to constantly be in xray mode I would receive as a victory. Once that concept has been established and it’s part of blender core, I hope we’ll have an easier time landing smaller patches that refine the concept.

Or in other words: don’t let perfect be the enemy of better.

[Xorrito]

I like it, xray facedots wasn’t activated by default, maybe it could change its naming to “ignore facedots” for clarity and be off by default? Good job, love that I can add auto xray to quick shortcuts. ::

[Hologram]

@lcas

I remember a couple years ago there was talk of a mouse cursor that would change to reflect the current tool, but never saw anything in action.

⚓ T69441 Cursors Design

I also agree with @LudvikKoutny that I should be able to tell that Select through is on by a highlight in the X-ray button. Even if it’s just half a triangle or something like that.

Thanks! I’ll test the build for the final release of 3.2. And with testing I mean, use it as my Blender 3.2, just like I did for 3.1.2

[1D_Inc]

@lcas

I put these toolsettings inside the collapsable area because otherwise they clutter the toolbar as noted a while back.

Looks good.
It was also proposed to use the toggle button with this icon from the outliner to indicate and control Select Through.

But at the moment Select through and AutoXray options will be available, any additional buttons with any interconnecting logics can be achieved with addons and without custom builds.

[Hologram]

In that case, @JulienKaspar what do you think of an additional button in the header to indicate Select Through is on?

[LudvikKoutny]

Why? When lcas finally made a good version with less UI clutter, why is the first instinct of everyone else to start cluttering the UI again?

Having two interdependent ON/OFF toggle buttons on the top bar is a hell. You can’t just glance at one to see if you are selecting only visible faces or not. You now need to evaluate two buttons next to each other with 4 total possible combinations of states, and extrapolate the “mode” you are currently on.

Select Through is what you should toggle frequently on or off. That’s what determines if you are able to select only visible faces or not. Whether you want to use xray and/or facedots to do your select through is more of a workflow preference. There will be almost no people who will want to keep togging the xray on or off as they work. They will just mostly settle on one of the two states. It makes no sense to put workflow preference toggle on the top level of the UI to create visual pollution.

Really… everyone in this thread, all the time… is always like “how can we add more buttons?”. It’s so incredibly frustrating. I should rename the title of this thread from Decoupling x-ray from and limit selection to visible to “Ideas on how to add as many buttons to Blender as possible”.

[Hologram]

Relax, I was asking for replacing the X-ray button with the Select through button on/off or a feasible alternative to show that Select through is on.

@Hologram

I also agree with @LudvikKoutny that I should be able to tell that Select through is on by a highlight in the X-ray button. Even if it’s just half a triangle or something like that.

So to clarify, maybe Select through could show like this:

Select through is sortof in between both modes, which is the reason why I thought this might solve the issue for the icon, since this way, it can be part of the button. Left is default, middle is select through enabled and right is X-ray enabled. If you enable X-ray, it’ll go to the right icon, if you disable X-ray and have select through enabled it’ll be the one in the middle and if both select through and X-ray are off, it’s the left icon. The button itself thus only toggles X-ray on/off like it does now. Select through thus only toggles between the left and middle icon for the header UI wise.

But, at least, it will now be possible to do so with an addon too. So maybe that could be a simple addon that is shipped with Blender to enable the Select Through button if it can’t be in the official build.

I also want this in master ASAP, so I try to reach a consensus here.

[LudvikKoutny]

You are still avoiding the issue. You are mixing something you will be occasionally toggling during you work with something most people will decide once and keep toggled for a long time. You are mixing two features which have extremely different usage frequency. By adding half highlight to a button, you are introducing tons of new issues:

1: Blender’s UI framework does not have any concept of half-highlight like you drawn. No, the developers won’t add whole new UI concept for just this feature. No, they will not allow it to be hacked in there just for this feature. It will also add whole new visual language users need to learn. Which would not make sense to learn just for a single new feature.

2: You still quadruple the complexity. ON/OFF highlight has two possible states: 0 (OFF) and 1 (ON). Two buttons or one toggle button with two sub states has 4 possible states:
0 0
0 1
1 1
1 0

People won’t just glance at the button and think “Oh yeah, the top right triangle portion of the square is blue but the bottom left is gray, this means I am selecting through but not using Xray”. That’s just poor design. People will more likely be like “Oh crap, does top right blue triangle and bottom left gray triangle mean select through off and xray on? or is it the other way around?” So they will just end up having to open the popover menu anyway.

Non the less you keep missing the main point. You don’t want to overload the UI by shoving too much information in user’s face. User just needs to know whether their current selection will result in selecting only visible faces, or all faces within the lasso selection. They will mostly not need to know if the selection is done using Xray or not, becuase they have explicitly enabled or disabled xray themeselves, so they remember the state, and want to rely on that state always behaving the same. As I said, most people won’t be toggling Xray facedots on and off frequently. There are two camps of people, those who like them, and those who hate them. Almost no people seem to be in the camp in between.

It’s like saying we need top bar UI button for toggling between bright and dark UI theme. UI theme is something you set once according to your preference and something you expect to remain consistent. Not something you keep toggling several times a minute.

[Forester64]

There is no half on button state in blender, but there is example of 4 state (on, on connected, on projected, off) button in edit mode made by using different icons:

[Hologram]

There are only 3 states, right?

1. X-ray off, Select through off
2. X-ray off, Select through on
3. X-ray on > select through is on by definition

For mode 2, there could also be an icon change instead then. The button should not be highlighted in blue, since the button is still for X-ray on/off.

I can see when X-ray is on in the viewport. I can’t see when Select Through is on, neither from the header nor the viewport. I can only try to select something in the viewport to see if it’s on. I do occasionally toggle both X-ray and Select through, even in lcas build. And when I was in Sculpt mode for the last hour, I don’t know/ remember what mode it was on.

This visual confirmation for me is the only question that I would like to see solved. For the rest I am fine with the way it is really. So if everyone disagrees with me, then that’s a consensus too. Then no button change.

[LudvikKoutny]

Yes, there are more than two states, but there are only two states which you care about. Whether you are selecting through, or whether you are selecting only visible faces. You will hardly be turning the xray on and off frequently. You will settle on one of the two workflows, since switching the selection method (face dots vs intersection) is usually inefficient and confusing.

I’d compare it to Autokey and keying set. When want to start animating, you set the keying set to whatever set of parameters you want to be keying, and then you turn on autokey. You want to see a visual indicator of whether autokey is on or off, to see whether moving your object will immediately result into keys being added, but you don’t need to see the button displaying which keying set is active, since you have explicitly set it yourself before you started for the exact reason that you expect the keying se to remain consistently the same, so you don’t have to constantly paranoidly keep checking it if it’s set to the right value.