Decoupling x-ray and limit selection to visible

I am under the assumption that adaptive means the way edges are. Where they either do fully enclosed if you fully enclose at least one of them, or intersected if you don’t fully enclose any of them. I would like to know for sure though.

@LudvikKoutny came with the example a few post above so I went on with that. Never really noticed such a thing myself honestly.

It’s this. The annoying feature where sometimes edges are selected by the lasso shape overlap while other times by the containment, depending on whether the lasso selection fully contains at least one edge:

And it works really poorly with Select Through. Luckily, Kio’s patch smartly disables it whenever Select Through is enabled.

It doesn’t have any official name so I just say adaptive. Or it if it does have a name, I don’t know what it is.

1 Like

I can’t remember any cases when it could be critically useful.

A Toolsetting.
If to provide the ability for selecting faces by facedots in solid mode, toolsetting should provide the ability to view facedots+ area selection case. But here is an issue - it will be not possible to say what turned on facedots mean - selecting by area or selecting by facedot, that could be non-binary confusing.
Since there is no such a toolsetting, facedots display in solid mode clearly means just displaying which is good.

I can see cases when it could be useful, for example during working with variable density topology.
It also fit Select through paradigm, making possible reaching select through task goals by AutoXray mechanics.

I think it should only be available if facedots are off. This also makes facedot display meaning binary.

The need for such a differentiation between solid mode and xray occurs because those modes naturally provide different visual conditions for selecting, so they cannot be unified for consistency.

Fully enclosed aka fully inside aka pass0. If it doesn’t catch anything then intersect aka partially inside aka pass1 happens. I made it where user can elect to skip fully enclosed by toolsetting for Drag Select called “all edges”.

@1D_Inc
It’s an interesting decision to make, if I had near select facedots I think I would just leave it where it works either way. I left it this way for xray as well, if solid can do area select with facedots on, “why not xray?” is what I went with.

Remaining issue I can think of: Do you allow selection by invisible facedots? It’s going to happen for single click if you can turn facedots off in xray. It’s one of those things that I am fine with for myself and anybody who wants to try a custom build, but for a wide audience? Drag select by invisible facedot seems out of the question, but that’s me.

1 Like

It is technically possible, but will make facedots display meaning in Xray mode non-binary - in this case you can see facedots, but can’t say if you select by them. Also, facedots in Xray mode provide depth-picking (the ability to select inner/occluded faces which are covered by visible geometry in solid mode), so if facedots in Xray are turned off the only possible way of selecting faces is by area anyway.

That sounds like making selection without proper aiming, in case if I got the context right.
For example, we are currently switching to wireframe mode manually to get impression about structure first and have the ability to aim. If you don’t have an impression, you have no proper aiming.

Nice question, terminology is important for proper conversation, but it is a bit confusing right now.
Directional/Adaptive terms are about the way frame/contour of a selection forms mesh elements selection.

In short:

The limitation of adaptive selection is edge mode, the limitation of directional selection is that you have to control direction.
The industry also has an “always crossing/always inclusive” solution with manual switching between those modes. The limitation is manual switching.

“Whole element” term is needed to be clarified.

1 Like

I never even noticed that… yes that’s weird now that you point it out

@1D_Inc is this directional selection thing actually workable ? that sounds like a nightmare on paper. I mean, having to think of the direction in which to draw the box select ? maybe it grows on you ? does it become second nature ?

1 Like

I can imagine getting used to it, but it needs to be optional.

It is very helpful in autocad especially for working with complex 2d vector graphics with lots of overlapping elements it was originally designed for.
In 3d it is also pretty much okay.

But it can also be annoying that you have to change the view to use either mode as to not select unwanted things in a certain direction. And sometimes that won’t work and you will be forced to select things bit by bit.

There are a few cases where it could be useful:

  1. Zero area faces can’t be selected in solid shading mode. For example I can see that there is an extra face hiding between the two with the help of facedots, but I can’t select it with with a simple box select.

  2. Selecting very dense meshes can be inconsistent, because the way Blender determines what is visible is pretty inaccurate (for performance reasons, I guess).


    Selecting by facedots should fix these issues, although I have no way to test it.

Absolutely not. Hitting an invisible dot is hard enough on an uniform quad, imagine selecting a distorted n-gon this way. That’s why it’s important to decouple selection behaviour from facedot display, so you could select by face area in xray mode with box select, but still have a reliable way to pick a single face by its facedot. I know your build has this functionality, and I have already argued for this multiple times in this thread, but I need to reiterate, because I see that it’s one critical issue that’s being overlooked right now.
Slightly different color or opacity could be used on facedots to indicate whether you select by facedots or by area.

You don’t have to think, it just happens automatically once it becomes part of your muscle memory. It might take a couple of days to get used to, but after that it’s going to improve selection efficiency by a lot. But you’d have to try it yourself.

2 Likes

Sorry, this is getting quite deep. I’m reading up on the directional box and lasso revisions too.
So I might get some things wrong.

It does seem like directional box/lasso selection can really solve the use cases for adaptive selection of edges and faces.
It’s intuitive enough and doesn’t require toggling settings manually. And it’s optional for those that don’t want to use it.
I’ll look further into those tasks and why :gear: D10525 UI: Directional Box Selection never went any further.


I think the face dot design can be made pretty clear then.
The overlay and selection behaviour should be interlinked.

When enabled = Select faces via face dots
When disabled = Select faces via their area

The face dots overlay should be for Xray then and greyed out for solid mode instead.
For Xray it will then offer an alternative selection method, while it’s never used for solid.
@slowburn I think face dot selection when xray is off is less useful since it only works on faces that would be z-fighting (In the exact same spot). So there are plenty of cases where you might still not see the face dots on broken geometry or other special cases.

It’s also important that the face dots overlay get’s a different spot in the overlays popup.


For the “Select Through” behaviour I’m still unsure. Especially because some want it as a preference, while other’s would like it to essentially replace the Xray toggle.

I can at least add to my proposal from before, that implementing it as a tool setting and a toggle in the keymap entries is the best way of having it as both a preference and a regularly used toggle.
Tool settings can be carried over to other files if you save and reuse workspaces.
That would be good if you want to keep a different default behaviour in every file.

We could even synchronise the tool setting between all three selection tools that would use it.
There are various tool settings that sync between tools.

Adaptive selection is not intuitive. And mainly, adaptive selection is not optional. That’s its biggest issue.

Sorry if I wasn’t clear. With “It’s” I was referring to directional selection from the sentence prior.

Nevermind. Totally my mistake, sorry. I misread the sentence above as “It doesn’t seem” instead of “It does seem”.

1 Like

@lcas Can you create a design task for the Face Dots improvement? You can tag me as a subscriber and then we can look over it in detail.

1 Like

It will be definitely nice to have as an option.

Sorry, can you clarify - do you mean using such behaviour for both solid and xray modes or for xray only?

That would be bad to receive such files from a colleagues especially during deadlines.
The ability to save personal preferences per file instead of storing them in application is always bad for teamwork/collaboration. When you open application to finish some job you always expect it behave in predictable way, not learning what is changed by someone each time.

1 Like

Maybe the setting can belong to the workspace, then the other user has the choice when opening whether or not to load it with the workspace when opening the file.

But then maybe it’s not such a good idea because I don’t think other preferences/settings work like this and it would introduce another layer of complexity in managing preferences and startup file so…

1 Like

In gereral, there are 4 possible levels of datamanagement complexity, depending on number of people and data type. They are:

  1. Individual + vanilla data
  2. Individual + imported data
  3. Collaboration + vanilla data
  4. Collaboration + imported data

For example, Blender studio belongs to the third level, since it is a collaboration, but all used data is mostly made from scratch so is predictable. Any architectural/archviz studio belongs to the fourth level of datamanagement complexity (corporate level).

Solutions that are applicable to the first level are deadly for the fourth level because the fouth one always has the most tough requirements to survive. Solutions that are applicable to the fourth level are automatically applicable to all levels above because of lesser amount of restrictions and requirements.

Collaboration assumes that lots of files will be edited by lots of people. Sharing personal preferences in those files will predictably bring a mess.

1 Like