I want to change the ‘edge’ option in the edit mode overlay panel to be ON by default for Blender 4.0, because the selection visibility in 2.8+ versions is much worse than in 2.79 or earlier versions. When modelling for many hours, I’ve felt that 2.8+ can lead to more eye strain or fatigue. When modelling we often do edge operations regardless of selection mode, so it’s important to see well what edges are selected in any selection mode. Turning edge highlight ON also helps differentiating between faces, and seeing the selected vertices. I need user feedback if you agree with this change. Also because when on it uses the theme color instead of a lighter black and a darker orange on edges.
By the way, the selection visibility was so bad in wireframe mode that Campbell already hardcoded this to be on by default in wireframe view years ago.
For the people who are against this default change, can you provide any reasoning why? I could make tweaks to please everyone.
Does this mean you’ll be using the active edge display for all selected edges? How would you differentiate the active edge with edge highlighting enabled?
Don’t get me wrong, I think it’s a great idea to improve visibility of edges. Just wondering about the approach.
Do you plan to address pre-selection highlights too? Though I guess that may be off-topic.
No, the active edge color will remain the same, I will only change the “edge” toggle default to ‘on’ in the edit mode viewport overlay panel. Though this option says “Highlight” in it’s description, it doesn’t make selected edges brighter than the theme color when ‘on’, it actually makes them darker when ‘off’.
I’d like to offer a related question on this; I’ve often wondered when when I am in point select mode, and select some points - I’m also seeing edges highlight.
I realize it’s highlighting the edge between the points, but I’m not selected edges. If I wanted to see highlighted edges, I’d be selecting edges in edge mode. Given that there’s discussion on the user wondering what mode they’re in, it seems changing this might make it more obvious.
It depends. If there is no edge selection color at all in vertex mode, like in other software, it would make the selection modes visually more distinct, but it would hurt vertex selection visibility, requiring a giant pink vertex (just like in other software…). And make selected geometry edges look unselected. We use vextex select mode to edit edges too, therefore the selected edges should look selected.
But If it was to disable only the edge color around selected vertices(the gradient on unselected edges), it would make edge selection and vertex selection mode look even more similar. But I can see this as a theme option for people that are used to other software.
I remember how hard was working with ripped edges in 3dsmax and Maya with no edges highlighting, those software was definitely design for working from scratch, not for editing massively confusing mesh data.
In fact, Blender’s vertex-to-edge highlighting is a deep mesh modeling solution we was looking for a long time, since it is the only visual solution which allow to handle any mesh structure’s selection analysis perfectly. As a result you always know what exactly is selected and which side of a mesh the selection is connected with.
So about this. I was also making a proposal and it would be nice to get some opinions on this.
This is to increase wire visibility but still make each selection mode distinct:
(This is with vertex, edge and face selection mode from left to right)
Currently selection modes are indicated by dimming the brightness of components of inactive selection modes.
We could alter the hue slightly instead of dimming wire values.
This way each selection mode and combination is distinct. Readability is also enhanced.
I think it would be easier to eval the screenshot examples if all the elements were not selected, so that I could see a mix of selected and non-selected elements as they would appear under those color conditions.
Oh that’s a good point… the Hue shift wouldn’t apply on unselected verts, edges & faces. So with that logic the wires would be black. No difference in values … that means the hue shift wouldn’t really solve the issue anyway.
I can see how it can have value; i just wish i could turn it off. I actually looked for such a setting, and finally decided “ok, apparently that can’t be turned off”.
Erm… no, if the edges were not colored, it would make the two modes less similar. Because edges would not be lit up in orange, as they currently are when you select points. (In order words, I’m not suggesting the gradient become a solid line - but that the edges not be lit up at all, in vertex mode.)
I spent some time today in the theme, and highly increased the contrast/color/alpha of the color difference between selected, unselected, and alpha transparency of selections (IE, pure black, pure white, brighter orange, etc). I also made the vertex 1 pixel larger. It’s made the visual differences more obvious to my eyes, so perhaps it can be left as-is.
I really hope so, the result was fascinating when I tested it.
Also, at the moment averall selection contrast is very broken by default, and in verices+edges modes its even worse than in face mode. Previously it was solved by distinguishing face mode with facedots, but even if facedots are turned on, the contrast differentiation between edges and faces in vertices+edges mode and faces mode still exists.
For example, it is assumed that we will have to work tens of hours in a row daily having selection contrast like that, which we don’t consider as possible since the selection is barely distinguishable even for the simple cube, so most of time you search for your selection right on your monitor instead of doing actual work, which is a heavy design mistake.
Since some time I cannot see selection highlighting any more on my celeron-2. On the bigger machine, I can see selections without problems.
On the small Celeron machine there is a message in the Terminal:
libGL error: MESA-LOADER: failed to open iris: /usr/lib/dri/iris_dri.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden (search paths /usr/lib/x86_64-linux-gnu/dri:$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
libGL error: failed to load driver: iris
libGL error: MESA-LOADER: failed to open iris: /usr/lib/dri/iris_dri.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden (search paths /usr/lib/x86_64-linux-gnu/dri:$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
libGL error: failed to load driver: iris
libGL error: MESA-LOADER: failed to open swrast: /usr/lib/dri/swrast_dri.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden (search paths /usr/lib/x86_64-linux-gnu/dri:$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
libGL error: failed to load driver: swrast
nohup: Eingabe wird ignoriert und Ausgabe an ‘nohup.out’ angehängt
However, older Blender 4.0 worked properly for a while, and 3.6 selection works without problems on the little celeron.
May this relate to changes discussed in this thread?
Seems more like a driver issue or that the cpu is no longer supported, 4.0 has increased the minimum requirements. You can make a bug report and they’ll get you sorted.
