UI: Improve Mesh Edge Highlighting #111431
No reviewers
Pablo Vazquez
Julien Kaspar
Campbell Barton
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
11 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#111431
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "Gilberto.R/blender:temp-edgehighlight"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Changes to edit mode mesh overlays, use hue shift instead of color fading/darkening for selection mode visual differentiation, and some theme changes to improve the display of mesh edges and faces with good selection visibility. Also:
The visibility of mesh edges were more distinct in Blender 2.79 than in 2.80+ versions. The "edge highlight" option in the edit mode viewport overlay panel being 'off' by default is one of the reasons why. The edges are faded, making selection harder to see. Turning edge highlight ON helps selection visibility and reduced eye fatigue when modeling for many hours.
In the following poll, the vast majority of respondents support edge highlighting being 'ON' by default: https://devtalk.blender.org/t/blender-4-0-default-change-edge-highlighting-feedback/30203
But turning it 'on', without other changes, removes some visual distinction between selection modes. This PR removes this toggle and removes the edge/face color fading, and instead adds secondary hue shifted selection theme colors that are used depending on the active selection mode (for select edge/select face).
Following shows some comparisons. For each monkey the current behavior is to the left, this PR on the right. The top-left monkey is in Vertex select mode, the top-right is Edge select, bottom-left is Face select, bottom right has all selection modes selected:
The down side of this is it makes it harder to tell (at a glance) the difference between vertex & edge-select mode.
This is worst when the entire mesh is selected.
There is also no visual difference between "Vertex" and "Vertex+Edge" selection modes.
During 2.8 design some effort was made to have the different modes visually distinctive.
An alternative to this patch could be to:
Although the benefits of tweaking the current colors may be marginal.
Overall if others prefer this behavior, I think it's OK but it does undermine our attempt to make the selection modes visually distinct which is a shame.
Adding @JulienKaspar as reviewer.
@ideasman42 what you said is true, but I still think that the change is worth it. It boils down to a trade off between seeing well what is selected and knowing quickly what selection mode you're in.
When could someone not know what selection mode they're in? When they first open some file, or when they misstype the selection mode hotkey number, or when they just forget. They'll notice it as soon as they select something or look at the icons. But when does someone needs to see well what's selected? Much more often: after every selection to confirm visually that it was selected correctly and before doing any operation.
I have felt the eye strain after long modelling sessions in 2.80+, and that has been a huge painpoint for multiple users in the 2.8 wireframe discussion: https://devtalk.blender.org/t/blender-2-8-wireframes-discussion
It took me a while to discover that there was a toggle to resolve that eye health issue. And I think many people still don't know that this toggle exists because I see youtubers make their vertex very big to compensate for the bad visibility.
Everything that you have mentioned already also applies to the wireframe shading mode and the x-ray mode, since you reported and fixed the poor edge visibility in those modes by turning the edge highlight always 'on' in them. #67637
And after your patch there was no one concerned or bothered by not knowing the selection mode they're in, in those shading modes.
Just like there wasn't anyone concerned by that in 2.79 or earlier versions.
This picture shows how the selection visibility is compared to 2.79(the one on the right). Even with a smaller vertex it's easier to see the 2.79 selection.
I think this is going in the right direction. Dimming the values of wires depending on the selection mode is hurting readability.
I'd propose to take this further. Remove this overlay option. Instead shift the Hue to indicate the active selection modes.
Display inactive selection mode components slightly more red-orange with full value intensity.
Active selection components are bright yellow-orange to stand out.
Faces can still be slightly dimmed outside of face selection mode to keep verts/edges more readable.
This way we still keep visual feedback of what selection mode is active.
Here's are the current colors for comparison:
I didn't have time to read through the forum threads. But I'd be happy to once I have more time.
@JulienKaspar Your idea for differentiating the selection modes is good, but I'm generally against having different color in the viewport from the selection colors set in the theme. Also, 10% of the users voted against the change, so I don't know if the 10% will be happy if I completely remove the toggle. Because they didn't provide any reasoning why they don't like it 'on', I'm not sure if they'll be satisfied with your solution.
Personally, I have never felt any need for differentiating more the selection modes. But if you want this, we could do something simpler and more impactful: change the selected vertex color a bit and turn on the facedot.
Still, I think any change besides turning Edge Highlight on is unecessary.
In this idea the colors used are the similar to object mode for selections and active selection.
So it's still within the theme.
I would discourage from enabling face dots by default. They signify a change in selection behavior. Like when Xray is enabled, faces are selected via the face dots.
I can share this on the forum threads. Would be good to get some more opinions on this.
Hmm ok seems like the Hue shift idea wouldn't solve the issue of selection mode differentiation for unselected wires ...
I think then I'd be fine with either solution. Enabling edge highlights by default, or that + the hue shift.
Both will increase the wire visibility.
The latter would keep selection mode differentiation a little bit (but only in the edge case of using both vert and wire selection at the same time), so it's negligeable.
Not my area (at all), but this thread reads like there could be some kind of compromise - Edge highlight on and a lessened hue change? My gut feeling is that something that both @JulienKaspar and @Gilberto.R agree on would be a great improvement.
I'm just not wanting this thread and PR to stall.
@JulienKaspar the hue shift would work for unselected edges if they were changed to light blue (I don't like this idea, just mentioning it)
Either way, the edge highlight will be turned on, so we don't have to wait for the additional changes if we decide to do them. Most people already prefer edge highlight ON, as seen on the poll, and having it off is a health issue. Can we just approve and commit this?
@pablovazquez @ideasman42 What do you think? Would you be fine with having the Edge highlight enabled by default?
And what about a subtle hue shift for selected verts/edges/faces depending on the enabled selection modes?
If there will be no difference between Vertex and Edge select modes, why having this setting at all then?
Another option is for edges to be drawn thicker when in Edge select mode, or selected . This has been discussed back in 2.8x but the theme setting didn't exist back then.
Only selected:
This could be interesting to test. Perhaps now with this highlight we can revisit the idea of using the object data color for edit mode. But it can be done as a separate patch.
Thickening wireframes display have been discussed, such a solution doesnot fit dense wireframes readability conditions.
In blender the selection is transferrable (vertices selection forms edges and faces selection and vice versa), this way the selection is supposed to be the same in every mode, and the difference between selection modes is the difference between operations you can apply to it (expand, form, apply tools, filter non-faces selection by switching to faces mode, etc).
The distinction solution has two main flaws - the selection looks different between modes, and dimming contrast solution injures readability, since human's perception of a color is not linear and distinguishable color dimming also results in huge contrast perception dropdown, making the selection not recognisable fast enough.
@pablovazquez If it was up to me I would totally remove that toggle, but 10% of people are against the change. that's why I didn't remove it. I think it's because they are used to other software, and want no selection color on unselected edges around selected vertex in vertex select mode, which could be a theme option. but until they say why, I'm just guessing.
I think it would be good to do something here. We have a bunch of options to move forward and testing them out and tweaking would help.
If a perfect solution can't be reached I think it would be fine having the edge highlight enabled by default for now.
Better edge readability definitely trumps distinguishing vertex & edge selection mode combinations. Especially because Blender is not strict with what operations can be used between selection modes.
In the other software mesh selection submodes has indeed very different mechanics - it is not (directly) transferrable, there are separate independent vertices, edges, faces and entities selection modes, each of them stores its own selection (vertices selection doesnot form edges and faces selection by default there) and each submode has its own subset of operations to apply.
Such a system assumes different mechanics to operate, and has its own flaws and tradeoffs, including selection displaying/analysis area.
Since its mesh selection submodes are not transferrable and stores independent selections, visual selection submodes distinguishing is quite natural for such kind of a systems.
@Gilberto.R
Hey, we talked about this in the UI Module meeting yesterday and it took an interesting turn...
We started off by just agreeing that it is better with that option on. But then reasoning that that if it was on by default there isn't a reason to turn it off. So why not just remove the option?
If the option is removed we could just, under the hood, act like it is on when in vertex or edge mode, but off if face selection (only). On if you have edge+face, etc. If I am misunderstanding the conversation, best if @pablovazquez weighed in.
The discussed solution would be something like the following. Do you see any problems with the idea?
@Harley I personally have no issue with removing it.
Do you mind applying and testing my code changes above to ensure it works as you expect it? I could have made some mistake that turns it off all the time or something else dumb. But if works as advertised you could then update your PR with that.
I can't really take over this PR or submit a superseding version in my name. I just don't do modelling enough and a proposed change like this needs to have proper advocate, like you.
If you would rather not, or if there are any other issues, just let me know and we'll figure something else out.
Otherwise the UI module can then take another look at it on Tuesday. Maybe even give it a go/no-go then
Change Edit Mode Edge Highlight default to 'on'to Remove 'Edge Highlight' overlay toggleI have removed the toggle. Most of the code is by @Harley , with a few changes. It needs to be on for all selection modes, not only 'edge select' and 'vertex select', because it helps to see better the topology on groups of selected faces, and helps to see what edges from selected faces are selected and will be affected by operators like bevel. Visually differentiating the selection modes isn't that important. The selection modes already have no difference in wireframe shading mode and in x-ray mode. Let's just have the selection mode look mostly the same in all shading modes like in 2.79.
I agree. Even with edges highlighting turned on I can barely recognize the selection even on primitives.
If shader has a bit of a glossiness it immediately destroys the readability of the selected topology
@1D_Inc So what do you think, would it be better to not use different face alpha depending on selection mode? To me it could also improve selection visibility at the cost of less differentiation of selection modes.
The problem is that edge and face modes became completely similar in that case.
Faces selection brightness in faces, edges and vertices could be safely equalized only if those modes are clearly distinguishable.
Facedots makes face mode clearly distinguishable from the other modes, so if facedots are turned on, faces selection brightness could be safely equalized. When facedots are off, faces selection brightness could be confusing because this will make faces and edges modes equal visually, but I would prefer to have such kind of a possibility as an option anyway.
Previously such an option was presented as
Texture Solidcheckbox in Shading (N-panel) , which visually equalized faces and edges modes, and it was pretty much okay.@JulienKaspar i think that turning on the facedot doesn't change the selection behavior in solid mode.
I've added the edge color hue shift when edge select mode is activated, so now it is better to know the selection mode, and on wireframe mode and xray too, so it is better than the edge highlight toggle in this aspect. I think you will like the result.
I haven't added the hue shift to unselected edges because they are black, but if you want to change unselected edge to light blue I will add it.
I'm thinking of adding a control to the hue shift as a the theme option, depending on the selected wire color the user may want the hue to shift the other direction(Minimal Dark theme), a stronger hue shift (Print Friendly theme), in the 'White' theme the hue shift is looking like the active edge color. The user should also be able to have no hue shift at all because it's not so useful if the person uses facedot or if the user just wants pure wire color/ does not want the color to change depending on selection mode.
Part of the old Edge highlight toggle should be added as a theme option too if the user wants no edge color at all when edge selection is off (specially for the Maya theme) . By the way there are some people using addons that change what the operators affect depending on selection mode, like other software does, so this theme option could be nice for them. Even 2.79 had this option.
It's starting to come together!
Could you please update it to
main? I've just compiled this patch and the Fresnel option is missing.Having the edges in edge mode mode tinted in a different hue would be a fantastic change! Currently, I sometimes forget which mode I am in between edge and face mode since they look so similar, especially since 2.8 when the face dot was removed by default.
I usually end up clicking the 2 or 3 key multiple times just to make sure I am in the right mode before doing an operation, as it's not always obvious which mode you are currently in, very annoying. It's funny since I was just about to make an add-on that implemented just this kind of change, this patch even has the same color I had in mind! So it's great that it might be implemented as an official change!
This looks great! I also think it's almost there 👍
IMO it's necessary to still find a way to differentiate edge and face selection modes when unselected. At least subtle enough that a bit of visual feedback is noticable when switching the selection modes.
Using face dots is not ideal. It creates a lot of visual noise and it's nice to only use them when Xray is enabled to indicate where to select faces.
Maybe increase the alpha of the "Face" color from the theme preferences when face selection mode is used. Just slightly so that a change is noticable?
From the default on 0.008 to 0.016 or 0.020.
@JulienKaspar The purpose of the "Face" color is to show us filled faces in wireframe shading mode, to make it visually distinct from a mesh with deleted faces, but in solid shading it was not so useful, since the mesh faces are already shaded. I had in mind doing other PR to disable the "Face" theme color when not in wireframe shading, as it can flatten a bit the look of the studiolights, matcaps, etc. But based on your suggestion, it can be useful in solid shading, but be shown only with face selection mode, to better differentiate from the other selection modes. Besides flattening the shading, it could also decrease contrast with the Active Face, so instead of increasing it's Alpha on face select mode, I have decreased the alpha to zero on vertex and edge seletion modes. But in wireframe shading mode it's unchanged, since there is already the facedot to make the visual distinction.
@Gilberto.R Nice move.
According to types of contrast scale, human eye is more sensible to hue shift, so tiny hue shift will be enough for proper modes distinguishing.
For example, human eye is much less sensitive to saturation shift, so the saturation difference which is minimally required for proper distinguishing has to be strong enough so it ruins readability.
I think that faces alpha equalizing could be safely reached with that solution to make face selection equally bright and perceptable.
@JulienKaspar Technically, true, they are cluttering.
However, there is an important difference between different systems I want to try to describe.
In non-transferrable systems faces mode is the only mode you can operate with faces, so every mode has its own tools to operate, and therefore, each mode has equal importance.
For example, in the other software you have to be in faces mode in order to be able to extrude faces.
In transferrable systems, operators are accessible in every mode, so you can extrude, delete, inset or do any other faces operations in vertices or edges modes.
Therefore, in transferrable selection system modes has no equal importance - vertices mode is the most commonly used mode, and faces mode is secondary, which is used mostly for making faces selections or checking issues.
For example, unlike in the other software, in Blender it is technically possible to finish pretty complex model without even entering faces mode (for sure it will be less convenient and slower, but in the other systems it is physically impossible).
Different systems assumes different behaviour.
So, for sure, facedots are cluttering, but from our experience in transferrable systems this has much less practical impact.
It is an important system design difference I would like to mention here, at the time it took some time to me to figure it out before I started appreciate Blender's system design solution when I originally switched to Blender from the other software.
@1D_Inc , I have also removed the selected face alpha difference between modes, before it was half the alpha in vertex and edge select mode, with the edge hue shift I think that this is no longer necessary.
@Gilberto.R I've tried to imagine a nice reason for keeping it, like it was previously with Fresnel, but didn't succeed.
Probably, the selected face alpha difference between modes indeed worth removing, since hue shift is expected to work better.
The edge highlight toggle 'off' used to make the edge gradient on vertex select mode drastically weaker, which could be one of the reasons a few people used to other software may have preferred it, so I have added a user preference in viewport display, to toggle the edge gradient.
@Gilberto.R Looks pretty good 👍
Would be good to get @pablovazquez and @ideasman42 opinion on this too.
The only reason I can think of to not set the face color to 0.0 alpha in solid shading, is for cases where object/material color is set to 0.0 alpha as well. In that case they are essentially the same as wireframe shading.
But that's a corner case that I think can be accepted.
I do miss the stronger selected face color in face selection mode a bit, but only because it made that selection mode even more distinct. Now it's the only one of the three modes that doesn't have an visual element to make it stand out. But that's only an issue when mixing edge & face selection modes.
The preference to remove the edge gradient is not the right way to go. It has an important use. If it's too strong now I'd rather propose to weaken or shorten the gradient so that the edge doesn't look selected.
@JulienKaspar the option for edge gradient off isn't the default, just a nice to have for people that are used to other software. I still have to do the versioning to turn the gradient on when loading settings from older blender version. I personally will keep it on as the default and never toggle it off, but I've added it because I've seen a big artist ask about it on blender chat #support channel a long time ago, and also seen some artists request this on twitter: https://twitter.com/delaneykingrox/status/1646304370986999809/photo/1 . And recently there was also a RCS feature request https://blender.community/c/rightclickselect/yXY6
@JulienKaspar I can try to add hue shift to the face selection color to make it more distinct.
@Gilberto.R Just a general advice is that keeping patches focused in smaller changes improves the chances of it getting them in faster. Adding more and more features makes it hard to review.
Regarding the edge gradient, I don't think it's the way to go. It has a purpose. If you still want to propose it I'd recommend making a separate patch, but I personally don't think it's a good idea to introduce even more settings for something so useful.
This is true, mesh selection in Blender is very analytical in many aspects, it allow you to see things that you mostly have to guess during work in the other software. Such kind of a visual clarity is especially helpful during working with dense/heavy/confusing meshes.
Also agree about separate patch.
4acc283b86to87caeaf4fcOk, I have removed the option to turn off the edge gradient toggle, which increases the chance of people that prefferred the edge highlight toggle 'off' be mad with the removal of the edge highlight overlay toggle.
Come to think of it, the hue shift may not be as helpful for colorblind ppl.
In that case we can expose the colors in the theme preferences so the hue shift can be made more extreme. Offering a color blind theme would be a nice long term goal witha separate task maybe?
Depends on the hue shift. This is the list of combinations we are usually concerned with: https://en.wikipedia.org/wiki/Color_blindness#Confusion_colors
@JulienKaspar I've added hue shift to face select too.
Can I add the option to turn off hue shift, please? It's not so useful for who use facedot.
The selected face alpha in some themes is way too high IMO and will have to be tweaked, because it's no longer using half the face alpha.
This is true, facedots distinguish face mode very well, so in case when facedots are used additional hue shift solution will be excessive.
In that case it's ideal to add theme preferences for the colors of active & inactive selection modes. Then the color can be differentiated more or made the same.
@Gilberto.R @pablovazquez @JulienKaspar
I think it is necessary to determine the use cases of a facedot in solid mode at this point, because the cases when they are used are determined by cases when they are needed, which has certain conditions to satisfy.
Facedots is a mesh issues detecting tool, they are used depending on working conditions - how much you can trust mesh structure you work with.
Facedots in solid mode using can be avoided in cases when you can trust mesh structure a lot, it is about creating model from scratch with topologically stable methods, for example, by box modeling (aka vanilla data, creative workflows)
Facedots in solid mode using is beneficial in cases when you can't trust any aspect of a mesh structure you work with (imported data, editing workflows - finishing or supervising models made by someone farther the pipeline, mesh debugging, optimizations, stock models cleanup or extensive using topologically aggressive tools and methods like knife project, self-intersect, autoweld or booleans during vanilla modeling)
Since facedots using assumes pretty tough topology conditions, hue shift solution could be distracting for that cases while being unnecessary, so indeed it better be optional and customizable.
@JulienKaspar great idea, so each theme can have it's custom hue shift, facedot users can set the colors to look equal(no hue shift), colorblind ppl can set a stronger hue shift if needed or change it to look like before(darker edge selection color in non edge mode), and users can even make the the edge color totally black when not in edge select mode(for people used to other software). Also It's no longer needed to calculate the hue shift because it's just getting the hue shifted color from the theme.
I think that this is mostly done. The edge toggle is removed, visibility is good, there is mode differentiation, I just need to update the non default theme presets... which I don't know how to do because git ignores the theme presets .xml files. How should I proceed?
@blender-bot package
Package build started. Download here when ready.
Remove 'Edge Highlight' overlay toggleto UI: Improve Mesh Edge HighlightingI am curious how it is designed)
Is it a two edges colors in theme setup with a checkbox that forces using the second edges color in edge mode?
Hi @1D_Inc , you can download to test it from the Blender Bot comment right above your. There is no need for a checkbox because if the user wants there to be only one color like in 2.79, the user can just set both edge theme colors to the same color value.
@Gilberto.R technically, true, but only if facedots are not supposed to be switched often. A nice step anyway.
Sorry, can't download the build, it is not available for any OS (I use win and lin)
@blender-bot package
Package build started. Download here when ready.
@Gilberto.R
Yes, it is compiled for mac and linux, so I tested the linux version.
And it looks very promising!
I need to test it for a while, in order to avoid a placebo effect.
I like the flexibility of a customization, now it is clear that it was definitely incomplete.
However, I found the reason to keep edge checkbox, and yes - alongside with fresnel effect it is also about dense meshes.
I made a comparison, so you can see how dense parts became more readable with Edge checkbox turned off:
I assume that the main design mistake was made by enabling by default and even locking/hardcoding options that are beneficial exclusively for dense meshes (fresnel effect, faces alpha submodes differentiation, thin edges checkbox, even facedots), which are incompatible with the editing of low and medium polygonal meshes, which represents the majority of usecases, because such an options provide worse readability conditions in that cases.
For example, we face ultradense meshes editing mostly at historical reconstruction projects, because of a photoscans and satellite photogrammetery, and even in our studio the number of a ultradense mesh editing usecases doesnot exceed 10%, most of the time we live in low and midpoly production area.
So I would recommend to keep the removed edges option, but turn it on by default to satisfy the majority of a usecases.
IMO the patch is almost there! Just a couple of notes:
1. When building and using this PR, existing themes break. Edges have no selection color. This should be fixed.
2. The yellow color for selected edges is too far removed from the established color palette.
We need to check with the existing themes which color fits best for each. For most default themes I recommend to match these Hue values for edge/face selection theme colors:
Then the hue difference is subtle enough to be noticable but not breaking the look of the themes.
If this should be improved further (espeically for color blindness) I highly suggest to do this after this PR is merged.
3. Instead of calling the new theme color items "Variant", let's make the naming more explicit.
I'd suggest this naming for edge/face selection theme colors:
@1D_Inc I don't think there's much benefit of keeping the Edge option around for even thinner edge drawing. But if yes, then I'd suggest to keep this in the preferences. Ideally by offering an even thinner px value for "Edge Width" slider.
The Fresnel and edge width isn't something users would switch often. I think this depends on each persons prefered workflows. If someone would like to prioritise optimal low,high or mixed density visualization, it's can be tweaked in the preferences.
@JulienKaspar
I actually asked for thinner edges since probably 2012.
But only as an option, I didnt thought that it would be set by default for everyone at some point.
Also not sure why it should go to the preferences - it was pretty fine to have it in overlays, the only problem was that it was turned off by default, which stands for compatibility with ultradense meshes display, instead of being turned on for compatibility with low/midpoly.
For example, while working with dense meshes selection you are not interested in the distinguishing of its exact topology since you work mostly with the "selection spot", while in low/midpoly the ability to detect the exact topology of a selection is pretty much essential, so different overlay solutions satisfy different working condition demands.
The same is true for facedots - they are much more beneficial for low/mid rather than ultradense, and they are also located in the overlays.
Preferences is a nice place for storing things you will not touch in a year.
And we switch between editing low/medium and ultradense meshes a lot more often than that.
@1D_Inc What you perceive as thiner edge in practice is just a lower opacity, because the pixel can only be so small. The old edge highlight toggle halfed the edge transparency depending on selection mode, which gave that impression of thinner edge. It really makes seeing dense geometry much better, so for working with dense meshes I thought of adding an edit mode vertex+edge opacity slider in the overlays panel, which would not be selection mode dependant, and could give the user more control of this effect to be weaker or stronger, as it's ideal value depends on the mesh density and zoom level, and it would also work with wireframe and xray shading. Even the UV editor has a similar slider. but that would probably be only accepted after the splitting of the edit mode overlay panel from the overlay panel, as right now that panel is way too cluttered.
@Gilberto.R that sounds reasonable!
Object mode already has wireframe opacity slider, having editmode slider could be beneficial as well.
@Gilberto.R @1D_Inc The edge opacity could be an overlay slider or part of the theme preferences. Either way this should be discussed again later. Not really important for this PR anymore then.
@JulienKaspar I'm not sure on the naming. 'Selected Direct' to me sounds like it was selected directly but then you change the mode and it apparently wasn't? What does it mean? Also changing the name of the previously existing theme color would make it a new entry on the theme files, and existing users themes would have a "reset" on that color, so it's better to just keep it as it was, but if needed it could be changed only in the UI.
It turns out that the theme presets are in the addons repository so I can't update them from this pull request, I will have to make separate PR on the addon repository.
This idea is coming from indirect vs direct linking. If you link a collection/asset from another file it will be directly linked. But that linked collection/asset might also have their own links to other files. Those indirect links are added automatically and will also disappear if the direct link is removed.
Same with the selection. You are directly selecting vertices if in vertex select mode and any fully enclosed edges/faces are indirectly selected as a result.
Instead of changing the existing theme colors, the "Selected Variant" could just be renamed to "Selected Direct".
Do you have another suggestion?
Otherwise I think the PR is good to go imo. I'll check it out again asap to leave a review.
Indeed "direct" term has too many meanings, which makes it vague, while the semantics is closer to "coincident" or "matching".
How about "edge selected" for indirect and "edge select mode" for direct, to depict that this color is related to edges selecting in their own mode?
Also nice to know linked collections going to be differentiated, there are indeed too many different linkings that share the same term.
I would also like to see active face setup separate from active vertex and edge.
The problem is that vertex and edge has tiny geometry, which require contrast white color to be distinguished, but for the active face, which covers area, the color is too bright, so it covers the shading and makes lots of distraction while being unnecessary most of the time.
@1D_Inc , I agree that "Direct" is vague, but "edge select mode" is incomplete, because it doesn't mean that it's the color of the selection, only of the mode. What about "Edge Selection" and "Edge Mode Selection", "Face Selection" and "Face Mode Selection" ? I think that would convey the full meaning. I preffer the noun form instead of the verb "Selected", the noun also means "the state of being selected" or "a collection of selected things" https://www.merriam-webster.com/dictionary/selection
I can make the Active Face color separate from the vertex/edge Active color but that will be in another PR.
Yes, I meant something like that, language barrier sometimes disallow me to suggest precise definitions =)
Your wording looks better than mine, it is interesting what developers think of it.
Sure. Sorry for making proposals in PR.
(I don't know how to avoid scattering - it is always difficult to split discussions of a problems of readability/contrast kind into small separated fractions precisely, since most of them are somehow interconnected and form a workflow-dependent balance)
That sounds good 👍
Let's update the naming and get this approved before Bcon3 on the 27th so it can get into 4.0.
@Gilberto.R
Since this looks to be close, can you update the main description area to include a comparison image or two? Mostly something that shows off what this does in general. Imagine giving Pablo something to point at during "Blender Today".
I think it's done,. the rest of the theme presets are on a PR submited to the addons repository, blender/blender-addons#104912
@blender-bot package
Package build started. Download here when ready.
234b001eb3to163705010fI tested the latest build (win version has been updated) and found it pretty solid.
I am not sure about brown-reddish tones in vertices mode by default, since I find them hard to detect (on my screen it looks more terrakotta rather than sepia), but the provided customization level is flexible enough to allow to achieve the desired edges contrast result.
I like the resulted solution.
@1D_Inc , it looks orange on my screen.
Glad you liked it!
Checking the patch, I can't tell the difference between edge & face select, the difference seems far too subtle and less obvious than the current change in opacity.
Even with the hue shift, there may be materials impacting color too so I don't think a small hue shift is enough to make this clear.
Perhaps we can make faces less opaque in edge select mode, as the hue shift isn't so obvious at a glance.
Theme colors need to be versioned (loading existing preferences causes edge-selection to be black), and this patch conflicts with
main.@ideasman42 the hue shift was stronger but Julien asked me to make it weaker. I agreed with him. I think it's not so subtle. Edit: Actually, I don't want to hardcode the lower edge mode face alpha, because it will make materials impact selection color even more, and also because the user may want the same face color/alpha in both edge and face mode, as we can see in @1D_Inc example, it's not a problem because he uses facedot. But the facedot by default idea was rejected, so I what I can do is make is the edge hue shift stronger again.
@ideasman42 , I think the merge conflict and versioning are fixed. I have now changed the colors slightly for the edge mode to be a bit more different from face mode, also changed the face selection color to be less red as asked by @1D_Inc . I could make the two modes look even more different, but there is always a tradeoff, and we have to balance selection visibility, theme cohesion and selection mode distinction. To me, visually telling apart the selection mode is the least important of these factors. With the new theme options the user is free to make it more different if he needs. It will depend on the person's eyesight, monitor and preference.
@ -287,3 +287,3 @@unsigned char vertex[4], vertex_select[4], vertex_active[4], vertex_bevel[4],vertex_unreferenced[4];unsigned char edge[4], edge_select[4];unsigned char edge[4], edge_selection[4], edge_mode_selection[4];Renaming looses the theme color from existing preferences, prefer keeping
edge_select,edge_mode_select... etc.@ideasman42 at first I was keeping it as 'edge_select' and 'face_select', but then when bringing the settings from 3.6 to 4.0 it would not get the updated 'edge_select' and "face_select" colors, only the new 'edge_mode_selection' and 'face_mode_selection' colors. So if the users had the blender dark or blender light themes in 3.6, they would get a theme very different from the new default when loading those settings to 4.0. And if the user had a very different theme he would get mismatching colors, for example, if he had the "Minimal Dark" theme preset on 3.6, when loading settings to 4.0 he would get blue "edge_select" and orange "edge_mode_selection", blue "face_select" and orange "face_mode_selection". So how it is now it is better for who has the dark/light themes and less disrupting for who has a very different theme, and they can be invited to edit their theme again with the new settings.
Red (grapefruit) orange color has less energy than orange orange, for example, I've been struggling with detecting the selection in that color for a long time. Lemon orange has more brightness energy, but it starts conflicts with white face/backround color.
However, I can agree that red makes hue shift effect stronger.
When I tried that build I also felt that hue shift is too strong and style conflicting, but didnt succeed to provide an exact default value for it, since the change was supposed to be subtle. Then I tried the next build and liked both the style and hue shift value readability even without facedots.
I think it better be left as is - at lower value - to maintain style integrity, or not be pushed too hard.
The goal is to depict the idea of a provided customization abilities, so if someone will face the necessity to make the submodes difference harder they can do it manually, according to their monitor calibration/settings and color perception abilities.
I think that hue shift works better than faces alpha at the concept level - in faces alpha you can tell the difference only when you switch the mode, without switching you cant really tell if you see faces better or is it just shading of your model from a different angle makes them brighter or weaker (aw, I cant detect the face selection to operate with it properly, or to define if the selection is complete so probably I am in edge mode), so you have to constantly switch between submodes in order to figure that out.
Hue shift tells the difference directly without such kind of switching.
Here is the comparison I made to make sure we discuss the same thing.
@ideasman42 how should we proceed?
If this is good to go on a technical implementation maybe we should merge it.
@pablovazquez wanted to have a look at the selection theme colors again for 4.1 anyway, so we can have the discussion on changing/tweaking the colors afterwards?
@ -318,3 +318,3 @@.vertex_bevel = RGBA(0x00a5ffff),.edge = RGBA(0x000000ff),.edge_select = RGBA(0xffa000ff),.edge_selection = RGBA(0xff9900ff),Please don't rename these struct members, there doesn't seem any benefit in doing this and adds noise to the diff.
Other renames remaining,
TH_FACE_SELECTION... colorEdgeSelectThere are still some inconsistencies and renaming that doesn't seem to serve any purpose.
@ -326,2 +327,3 @@.face = RGBA(0xffffff02),.face_select = RGBA(0xffa5522e),.face_select = RGBA(0xffa30033),.face_mode_selection = RGBA(0xffb70033),Please use term
select, matching other names, e.g. (face_mode_select), same with other uses in this patch.@ -192,3 +185,3 @@DRW_shgroup_uniform_float_copy(grp, "alpha", backwire_opacity);DRW_shgroup_uniform_texture_ref(grp, "depthTex", depth_tex);DRW_shgroup_uniform_bool_copy(grp, "selectEdges", pd->edit_mesh.do_edges || select_edge);DRW_shgroup_uniform_bool_copy(grp, "selectEdge", select_edge);Is this rename intentional?
yes, I renamed 'selectEdges' to 'selectEdge', to match 'select_edge' there on the same line, and renamed 'selectFaces' to 'selectFace' to match 'select_face'.
@ideasman42 poke
I like this update. Makes edit mode more crisp, and bring back full contrast!
What happened with it? Looks frozen.
Poke!
Yes, there is indeed a huge problem. Thank you for solving this huge problem.