Update Default Theme Colors for 3D View and Wireframes #37419

Closed
opened 2013-11-13 22:39:11 +01:00 by Jonathan Williamson · 56 comments

Due to the recent additions of separate Edit Mode mesh colors as theme options, and the Hidden Wire display option, it's time to rework the theme colors for the 3D View. In particular, mesh Edit Mode. The reasoning for this is to ensure all tools and features, such as Hidden Wire, are usable as intended without needing to change the default colors. Doing this will also improve usability by making it easier to distinguish the active object from other objects in Edit Mode.

The below proposal is a near match to what I've been using in my custom theme for months now. I find it much more clear and pleasing to work with. It greatly helps distinguish between the edit mesh and other objects and the 3D View gradient gives a better impression of depth.

Proposal

  • Change Grid color to 737373
  • Change Edit Mode wire color to B3B3B3
  • Change Vertex Color to CCCCCC

This leaves us with this theme_3d-view_proposalA_02 theme_3d-view_proposalA_01 theme_3d-view_proposalA_03

Note: ignore the background gradient. I have removed it from the proposal due to inactive wireframes getting lost towards the bottom of the screen.

Due to the recent additions of separate Edit Mode mesh colors as theme options, and the Hidden Wire display option, it's time to rework the theme colors for the 3D View. In particular, mesh Edit Mode. The reasoning for this is to ensure all tools and features, such as Hidden Wire, are usable as intended without needing to change the default colors. Doing this will also improve usability by making it easier to distinguish the active object from other objects in Edit Mode. The below proposal is a near match to what I've been using in my custom theme for months now. I find it much more clear and pleasing to work with. It greatly helps distinguish between the edit mesh and other objects and the 3D View gradient gives a better impression of depth. **Proposal** - Change Grid color to **737373** - Change Edit Mode wire color to **B3B3B3** - Change Vertex Color to **CCCCCC** ``` ``` This leaves us with this ![theme_3d-view_proposalA_02](https://archive.blender.org/developer/F27746/theme_3d-view_proposalA_02) ![theme_3d-view_proposalA_01](https://archive.blender.org/developer/F27747/theme_3d-view_proposalA_01) ![theme_3d-view_proposalA_03](https://archive.blender.org/developer/F27792/theme_3d-view_proposalA_03) **Note:** ignore the background gradient. I have removed it from the proposal due to inactive wireframes getting lost towards the bottom of the screen.
Author
Member

Changed status to: 'Open'

Changed status to: 'Open'
Jonathan Williamson self-assigned this 2013-11-13 22:39:11 +01:00
Author
Member
Added subscribers: @JonathanWilliamson, @brecht, @AndrewPrice

Ooo I love this topic! It's something I've been waiting to discuss.

A great quote on this topic:

"...one well-known disadvantage of modes is that people often make mode-errors: they forget what mode the system is in and do the wrong thing by mistake... [this] is one reason why user-interface design guidelines often say to either avoid designs that have modes or provide adequate mode-feedback."-Johnson, Jeff. Designing with the Mind in Mind

In summary: each mode should look distinctively different than each other. Including object, sculpt, paint modes etc.

A couple of ideas for edit mode:

  • Make the background switch to gradient mode whilst editing
  • Use a distinctly different color for wires (white?)
  • Zoom into the mesh when edit mode is activated? (like pressing Numpad .)
  • Make hidden meshes very transparent but still visible?

On that note, we should probably discuss the default color for wires in object mode.
How do you guys people feel about the white-ish color I suggest earlier? (Wireframe Proposal - Current/New )
A couple of people at the conference said they'd switched and found it a lot more readable. You can try it by going into the theme settings and changing the Wire, Lamp, Camera and Empty color value to 0.660.

Here's the reasoning: Color Text Readibility Tester

Thoughts?

Edit: Sorry if this is a bit off topic.

Ooo I love this topic! It's something I've been waiting to discuss. A great quote on this topic: *"...one well-known disadvantage of modes is that people often make mode-errors: they forget what mode the system is in and do the wrong thing by mistake... [this] is one reason why user-interface design guidelines often say to either avoid designs that have modes or provide adequate mode-feedback."*-Johnson, Jeff. Designing with the Mind in Mind In summary: each mode should look *distinctively* different than each other. Including object, sculpt, paint modes etc. A couple of ideas for edit mode: - Make the background switch to gradient mode whilst editing - Use a distinctly different color for wires (white?) - Zoom into the mesh when edit mode is activated? (like pressing Numpad .) - Make hidden meshes very transparent but still visible? On that note, we should probably discuss the default color for wires in object mode. How do you guys people feel about the white-ish color I suggest earlier? ([Wireframe Proposal - Current/New ](http://www.blenderguru.com/wp-content/uploads/2013/10/Wireframe-Comparison.png)) A couple of people at the conference said they'd switched and found it a lot more readable. You can try it by going into the theme settings and changing the Wire, Lamp, Camera and Empty color value to 0.660. Here's the reasoning: [Color Text Readibility Tester ](http://www.hgrebdes.com/colour/spectrum/colourvisibility.html) Thoughts? Edit: Sorry if this is a bit off topic.

Each mode looking different: I would leave that out of this topic. We can discuss that at some point in the future but let's keep this about wireframe and other mesh element colors. Wireframe colors could be part of a solution if having them in different colors is helpful to working in that particular mode, but I would consider that more as a coincidence then, as we can show the mode well in other ways too.

White wireframe colors: there is a tradeoff here: if unselected objects are white, it makes the selected ones and any other widgets or markings stand out less. My gut feeling is that unselected things should be more muted than white so that there is space to add more colorful things where the user attention needs to be, but I would need to see it in practice. In any case any such color scheme should be tested on a production scene with a bunch of things going on, to see if you can still pick out the import stuff well.

Each mode looking different: I would leave that out of this topic. We can discuss that at some point in the future but let's keep this about wireframe and other mesh element colors. Wireframe colors could be part of a solution if having them in different colors is helpful to working in that particular mode, but I would consider that more as a coincidence then, as we can show the mode well in other ways too. **White wireframe colors**: there is a tradeoff here: if unselected objects are white, it makes the selected ones and any other widgets or markings stand out less. My gut feeling is that unselected things should be more muted than white so that there is space to add more colorful things where the user attention needs to be, but I would need to see it in practice. In any case any such color scheme should be tested on a production scene with a bunch of things going on, to see if you can still pick out the import stuff well.
Author
Member

@AndrewPrice your point about the different modes is a good one, but I agree with @brecht that it's out of the scope for the time being.

In my own workspace I've solved the Edit Mode Colors issue by simply changing the Wire Edit color to a light grey. This is pretty close your initial proposal @AndrewPrice, but more localized to just the edges.

Here are some screenshots to show it.

Object Mode Selected (same as default)
Screen_Shot_2013-11-14_at_10.12.22_AM.png

Edit Mode Wire as Light Grey
Screen_Shot_2013-11-14_at_10.12.28_AM.png

Original Edit Mode Wire Color
Screen_Shot_2013-11-14_at_10.12.36_AM.png

I've been using the light grey color in Edit Mode for a few months now and find it far more usable. This solves all of the problems mentioned in the Design Task, and it just a single default change. It works well in complex or dense scenes. It works with the Hidden Wire option to distinguish the Edit Mesh from the Object Mesh.

@brecht, if we only change the Edit Mode wireframe color, then unselected objects will never by white. This still keeps the black, orange, and muted orange for unselected, active, and selected.

@AndrewPrice your point about the different modes is a good one, but I agree with @brecht that it's out of the scope for the time being. In my own workspace I've solved the Edit Mode Colors issue by simply changing the **Wire Edit** color to a light grey. This is pretty close your initial proposal @AndrewPrice, but more localized to just the edges. Here are some screenshots to show it. **Object Mode Selected (same as default)** ![Screen_Shot_2013-11-14_at_10.12.22_AM.png](https://archive.blender.org/developer/F27260/Screen_Shot_2013-11-14_at_10.12.22_AM.png) **Edit Mode Wire as Light Grey** ![Screen_Shot_2013-11-14_at_10.12.28_AM.png](https://archive.blender.org/developer/F27261/Screen_Shot_2013-11-14_at_10.12.28_AM.png) **Original Edit Mode Wire Color** ![Screen_Shot_2013-11-14_at_10.12.36_AM.png](https://archive.blender.org/developer/F27262/Screen_Shot_2013-11-14_at_10.12.36_AM.png) I've been using the light grey color in Edit Mode for a few months now and find it far more usable. This solves all of the problems mentioned in the Design Task, and it just a single default change. It works well in complex or dense scenes. It works with the Hidden Wire option to distinguish the Edit Mesh from the Object Mesh. @brecht, if we only change the Edit Mode wireframe color, then unselected objects will never by white. This still keeps the black, orange, and muted orange for unselected, active, and selected.

Sorry, wasn't trying to derail it. I just thought that since this relates to the color of one mode, we may want to consider the other color decisions that may lay ahead of us.

For example @brecht you make a good point that unselected objects should be muted. That makes a lot of sense, and I hadn't thought of that. But if we keep it as current, there's still a problem with the lack of contrast in object (wireframe) mode.

So in that case should the background be brighter (like [modo ]] and [ http:*area.autodesk.com/userdata/forum/s/screenhunter_09_aug._24_22.42.jpg | maya for example) to make the black outlines stand out more? And if so, would @JonathanWilliamson's white wireframe not be as effective?

Again, sorry if this sounds like a derail. Just trying to think of the whole scope of the UI and how the colors of edit mode will affect other issues to be addressed later.

But to be on topic, if we're just talking strictly edit mode with everything else staying current, then I like the idea by @JonathanWilliamson to make them white.

Sorry, wasn't trying to derail it. I just thought that since this relates to the color of one mode, we may want to consider the other color decisions that may lay ahead of us. For example @brecht you make a good point that unselected objects should be muted. That makes a lot of sense, and I hadn't thought of that. But if we keep it as current, there's still a problem with the lack of contrast in object (wireframe) mode. So in that case should the background be brighter (like [modo ]] and [[ http:*area.autodesk.com/userdata/forum/s/screenhunter_09_aug._24_22.42.jpg | maya ](http:*osx.iusethis.com/screenshot/osx/modo.png) for example) to make the black outlines stand out more? And if so, would @JonathanWilliamson's white wireframe not be as effective? Again, sorry if this sounds like a derail. Just trying to think of the whole scope of the UI and how the colors of edit mode will affect other issues to be addressed later. But to be on topic, if we're just talking strictly edit mode with everything else staying current, then I like the idea by @JonathanWilliamson to make them white.

No problem, this last comment is pretty much on topic I think. It's difficult to untangle design topics like this, we're also still figuring out exactly how to structure this kind discussion.

No problem, this last comment is pretty much on topic I think. It's difficult to untangle design topics like this, we're also still figuring out exactly how to structure this kind discussion.
Author
Member

@AndrewPrice @brecht, what do you guys think about extending this proposal to include the following: 3D View background color, 3D View grid color, and Edit Mesh wire color? Each of these need to work in tandem and I feel all could be improved.

If you're not opposed I'll make an actual proposal on the colors. These updated colors should work well with the existing default theme, so as to be a more polished update to the current theme rather than an entirely new theme.

@AndrewPrice @brecht, what do you guys think about extending this proposal to include the following: 3D View background color, 3D View grid color, and Edit Mesh wire color? Each of these need to work in tandem and I feel all could be improved. If you're not opposed I'll make an actual proposal on the colors. These updated colors should work well with the existing default theme, so as to be a more polished update to the current theme rather than an entirely new theme.

Fine with me.

Fine with me.
Jonathan Williamson changed title from Tweak Mesh Edit Mode Theme Colors to Update Default Theme Colors for 3D View and Wireframes 2013-11-15 20:59:00 +01:00
Author
Member

Okay I've updated the initial description to include those few things and my actual proposal.

Okay I've updated the initial description to include those few things and my actual proposal.

Added subscriber: @billrey

Added subscriber: @billrey

This is going in a nice direction, though I'm not sure about the heavy gradient. The background gradient in Blender hints as a sense of horizon, making it easier to identify what's up or down. But the gradient doesn't respect the view angle at all - it's just a gradient which doesn't help communicating anything. Instead it gives users a false sense of place.

I see two options for the gradient:

  • Make it so the gradient actually respects the horizon (making it a useful communication tool and orienting users)
  • Remove the gradient :)

I'm in favour of option #1, even though it's more work, I think it would be the right thing to do.

This is going in a nice direction, though I'm not sure about the heavy gradient. The background gradient in Blender hints as a sense of horizon, making it easier to identify what's up or down. But the gradient doesn't respect the view angle at all - it's just a gradient which doesn't help communicating anything. Instead it gives users a false sense of place. I see two options for the gradient: - Make it so the gradient actually respects the horizon (making it a useful communication tool and orienting users) - Remove the gradient :) I'm in favour of option #1, even though it's more work, I think it would be the right thing to do.
Author
Member

@billrey, making the gradient respect the angle would be quite nice and make good sense. @brecht, any idea how involved that is?

@billrey, making the gradient respect the angle would be quite nice and make good sense. @brecht, any idea how involved that is?

Added subscriber: @PawelLyczkowski-1

Added subscriber: @PawelLyczkowski-1

This is mine. Light-blue wireframe on a dark grey model, with light-blue outline on active objects, dimmer on selected objects, on a dark grey background. Selected elements are orange. Selection pre-highlighting, if Gert's patch would be accepted, would be subtle light-blue.

shot_131115_224342.png

The grid is a bit lighter than the background, and the axes are dimmer to be more visually pleasing:

shot_131115_225821.png

This is the edited and not edited wireframe:

shot_131115_230220.png

This is mine. Light-blue wireframe on a dark grey model, with light-blue outline on active objects, dimmer on selected objects, on a dark grey background. Selected elements are orange. Selection pre-highlighting, if Gert's patch would be accepted, would be subtle light-blue. ![shot_131115_224342.png](https://archive.blender.org/developer/F27825/shot_131115_224342.png) The grid is a bit lighter than the background, and the axes are dimmer to be more visually pleasing: ![shot_131115_225821.png](https://archive.blender.org/developer/F27829/shot_131115_225821.png) This is the edited and not edited wireframe: ![shot_131115_230220.png](https://archive.blender.org/developer/F27831/shot_131115_230220.png)

As for the gradient, I don't like it due to the banding it produces. This makes the viewport look cheap and archaic.

As for the gradient, I don't like it due to the banding it produces. This makes the viewport look cheap and archaic.

@PawelLyczkowski-1 Yes the banding is annoying, but surely this is something that could be fixed? By making it slimmer, or by using dithering.

@PawelLyczkowski-1 Yes the banding is annoying, but surely this is something that could be fixed? By making it slimmer, or by using dithering.

Added subscriber: @mr_projects-3

Added subscriber: @mr_projects-3

Added subscriber: @sozap

Added subscriber: @sozap

This comment was removed by @sozap

*This comment was removed by @sozap*

Added subscriber: @BartekMoniewski

Added subscriber: @BartekMoniewski

@sozap You make a good point, but that'd be for another topic. This topic relates strictly to the colors of the 3D view and Wireframes.

@PawelLyczkowski-1 In your screenshots, does the shaded mesh have a dark material or is that the theme?
If it's the theme, I can think the models will be hard to find when navigating the scene. Your examples look great in edit mode editing, but the unedited objects seem to almost fade into the background.

For readability I think we should really aim for a .440 contrast difference, in whatever object state. Shaded objects against background, wireframes against background, and edit and object mode differences. It's a tough challenge but I think it's doable with some thought.

I personally like the screenshots proposed by @JonathanWilliamson in the OP look promising. The only issue is that if the gradient is view dependent, then unselected black wireframes will almost vanish when looking down. You can see this already in the second screenshot, near the bottom right corner of the cube. Perhaps a less dark gradient could fix this? Or maybe make all wireframes light and selected ones a different color?

@sozap You make a good point, but that'd be for another topic. This topic relates strictly to the colors of the 3D view and Wireframes. @PawelLyczkowski-1 In your screenshots, does the shaded mesh have a dark material or is that the theme? If it's the theme, I can think the models will be hard to find when navigating the scene. Your examples look great in edit mode editing, but the unedited objects seem to almost fade into the background. For readability I think we should really aim for a .440 contrast difference, in whatever object state. Shaded objects against background, wireframes against background, and edit and object mode differences. It's a tough challenge but I think it's doable with some thought. I personally like the screenshots proposed by @JonathanWilliamson in the OP look promising. The only issue is that if the gradient is view dependent, then unselected black wireframes will almost vanish when looking down. You can see this already in the second screenshot, near the bottom right corner of the cube. Perhaps a less dark gradient could fix this? Or maybe make all wireframes light and selected ones a different color?

Added subscriber: @ZsoltStefan

Added subscriber: @ZsoltStefan

I see a much larger question here than the exact colours. Maybe it is a separate topic. The question is why do we use a negative representation (dark background with lighter objects/contours) and not a positive representation (light background with darker objects)?
Blender switched from positive to negative from 2.49 to 2.50. I personally cannot work with these very dark themes during the day or in any well-lit environment. Reducing eyestrain requires a switch to the 2.49 theme, which seems to be the only light theme pre-packaged in Blender.

This is a topic often discussed in software ergonomics, and i am sure that there is no one-size-fits-all. My suggestion would be however that we always keep at least two themes up-to-date and modern, one light theme and one dark theme.

I see a much larger question here than the exact colours. Maybe it is a separate topic. The question is why do we use a negative representation (dark background with lighter objects/contours) and not a positive representation (light background with darker objects)? Blender switched from positive to negative from 2.49 to 2.50. I personally cannot work with these very dark themes during the day or in any well-lit environment. Reducing eyestrain requires a switch to the 2.49 theme, which seems to be the only light theme pre-packaged in Blender. This is a topic often discussed in software ergonomics, and i am sure that there is no one-size-fits-all. My suggestion would be however that we always keep at least two themes up-to-date and modern, one light theme and one dark theme.

@AndrewPrice

In your screenshots, does the shaded mesh have a dark material or is that the theme?

It's the theme.

If it's the theme, I can think the models will be hard to find when navigating the scene

That's possible. I usually do character work.Here is a screenshot with a scene:

shot_131122_111248.png

I also usually switch to a custom MatCap:

shot_131122_111635.png

@ZsoltStefan

I see a much larger question here than the exact colours
I personally cannot work with these very dark themes

Dark themes are favoured by artists in general.

always keep at least two themes

You can choose a light theme in Preferences. That said, they are not that good. Create one and post it here.

@AndrewPrice >In your screenshots, does the shaded mesh have a dark material or is that the theme? It's the theme. >If it's the theme, I can think the models will be hard to find when navigating the scene That's possible. I usually do character work.Here is a screenshot with a scene: ![shot_131122_111248.png](https://archive.blender.org/developer/F29939/shot_131122_111248.png) I also usually switch to a custom MatCap: ![shot_131122_111635.png](https://archive.blender.org/developer/F29941/shot_131122_111635.png) @ZsoltStefan >I see a much larger question here than the exact colours > I personally cannot work with these very dark themes Dark themes are favoured by artists in general. >always keep at least two themes You can choose a light theme in Preferences. That said, they are not that good. Create one and post it here.

2.70 release is good time to introduce new updated theme. In my opinion changes have to be visible for new people but not too rampant for old users.

I agree about dark themes in general but @PawelLyczkowski-1's theme is way to dark. Many people are getting tired by to contrast and to dark images, me for example. I thing something in the middle of current theme and this colors will be fine.

I don't like idea of white wires in edit mode. Just see how vertex selection looks with it. Bright color over another bright color. I often enable wire shading mode to see my selections on dense meshes (searching for non-manifolds, holes in sculpts). In this scenario white wires will blend everything to one white flat shape.
@brecht concept for muting unselected objects (or non-active objects to be clear) is way better imho. Not as big change from user point of view and it resolve problem.

Background gradients are bad! As artist we know that background color have influence on how we perceive object silhouette. Gradients or other non-solid backgrounds creates visual mess. They don't give better impression of depth because it's just flat image, no matter how we rotate camera or how far objects are they always are the same. It we dim objects by mist and rotate gradient as skybox like in games it will work that way. But think about performance. ;)
Option to enable gradients have to be clearly visible in view3D theme settings but we have to turn it OFF in default imho.

2.70 release is good time to introduce new updated theme. In my opinion changes have to be visible for new people but not too rampant for old users. I agree about dark themes in general but @PawelLyczkowski-1's theme is way to dark. Many people are getting tired by to contrast and to dark images, me for example. I thing something in the middle of current theme and this colors will be fine. I don't like idea of white wires in edit mode. Just see how vertex selection looks with it. Bright color over another bright color. I often enable wire shading mode to see my selections on dense meshes (searching for non-manifolds, holes in sculpts). In this scenario white wires will blend everything to one white flat shape. @brecht concept for muting unselected objects (or non-active objects to be clear) is way better imho. Not as big change from user point of view and it resolve problem. Background gradients are bad! As artist we know that background color have influence on how we perceive object silhouette. Gradients or other non-solid backgrounds creates visual mess. They don't give better impression of depth because it's just flat image, no matter how we rotate camera or how far objects are they always are the same. It we dim objects by mist and rotate gradient as skybox like in games it will work that way. But think about performance. ;) Option to enable gradients have to be clearly visible in view3D theme settings but we have to turn it OFF in default imho.

Added subscriber: @WeeKwongBong

Added subscriber: @WeeKwongBong

This is Energy Theme V12-refC (work in progress).

ThemeColor.png

From this you can see I made many modification without changing hue (therefore no relearning).
The main issue is valuedifference.
Value difference too high will lead to retina burn (like black BG and white objects).
Value difference too low, object can't be differentiated (0.5 grey on 0.4 grey), a basic guide is to have value difference of 0.2 to 0.5 for colored elements. Text can go way higher.

Viewport background: shouldn't be too dark compared to default material. Retina burn!
Gradient background banding problem: To solve banding for gradient, top and bottom should shift in all channels (RGB), shifting 1 channel (IE value alone) will produce banding, as there are not enough info to interpolate.
Grid color: should introduce hue shift from viewport background, value alone is not enough. Default is too low contrast (without gradient background).
Face: should be named "face mask". I use white, to mute texture and material, can turn on/off with face overlay setting. Default theme is doing it in reverse (black) which is wrong. Active object in edit mode is darker.
@JonathanWilliamson that is the problem you show on your 3rd screen shot .
Active face: the dot dot face, eye sore. My students even asked why it is dotted even when edge selecting. Hue change/shift should be the better behavior.

@PawelLyczkowski-1 your text to background is too low contrast. Really hard to read.

@ZsoltStefan My theme used to be very dark (0.15 value), until I experienced eye strain watching recorded tutorial using the early versions of Blender theme Energy.
Now the viewport has value of 0.25 to 0.4. Menu has a value of 0.2. Default material has a value of 0.6+. (value range less than 0.5)
Compare that to default: Viewport 0.0 to 0.23. Menu 0.45. Default Material 0.6+. In short value range too big (over 0.6).
Text on default theme is black on 0.23 value background, that is dark on dark. Hard to read.

This is Energy Theme V12-refC (work in progress). ![ThemeColor.png](https://archive.blender.org/developer/F29968/ThemeColor.png) From this you can see I made many modification without changing hue (therefore no relearning). The main issue is **value**difference. Value difference too high will lead to retina burn (like black BG and white objects). Value difference too low, object can't be differentiated (0.5 grey on 0.4 grey), a basic guide is to have value difference of 0.2 to 0.5 for colored elements. Text can go way higher. **Viewport background:** shouldn't be too dark compared to default material. Retina burn! **Gradient background banding problem:** To solve banding for gradient, top and bottom should shift in all channels (RGB), shifting 1 channel (IE value alone) will produce banding, as there are not enough info to interpolate. **Grid color:** should introduce hue shift from viewport background, value alone is not enough. Default is too low contrast (without gradient background). **Face:** should be named "face mask". I use white, to mute texture and material, can turn on/off with face overlay setting. Default theme is doing it in reverse (black) which is wrong. Active object in edit mode is darker. @JonathanWilliamson that is the problem you show on your [3rd screen shot ](http://developer.blender.org/file/data/ttjkegub2t67kkb7ixpd/PHID-FILE-zsckyomkkflei2jm4gnr/Screen_Shot_2013-11-14_at_10.12.36_AM.png). **Active face:** the dot dot face, eye sore. My students even asked why it is dotted even when edge selecting. Hue change/shift should be the better behavior. @PawelLyczkowski-1 your text to background is too low contrast. Really hard to read. @ZsoltStefan My theme used to be very dark (0.15 value), until I experienced eye strain watching recorded tutorial using the early versions of Blender theme Energy. Now the viewport has value of 0.25 to 0.4. Menu has a value of 0.2. Default material has a value of 0.6+. (value range less than 0.5) Compare that to default: Viewport 0.0 to 0.23. Menu 0.45. Default Material 0.6+. In short value range too big (over 0.6). Text on default theme is black on 0.23 value background, that is dark on dark. Hard to read.

@WeeKwongBong Can you show a screenshot of just the 3d viewport? Right now it's blocked by the user prefs. Also from a presentation point of view, you may want to hide distracting elements like normals and toolbars and try showing a standard view so we can make a better judgement of it.

@PawelLyczkowski-1
"Dark themes are favoured by artists in general."
We should probably avoid generalized statements like this unless it's backed by some supporting evidence. I don't doubt that you're right, but we should be making design decisions based on principles.

In regards to your later screenshot, I'd have to agree with @BartekMoniewski that it appears too difficult to see the objects. I tested the colors using an eye dropper and in some parts there's only a contrast difference of 3 (out of 254), making it very difficult to tell where the object ends and the background begins.

As a point of reference, recommended contrast difference for text is at least 110. Solid objects in a 3d viewport are usually much wider than text, but that also depends on how close you are to the object. Trying to find a small object in a huge scene can be a nightmare. Having a clear contrast difference will alleviate some of the difficulties.

So for now I'm still in favor of the design proposal by @JonathanWilliamson in the OP. But the problem still remains of the black wireframe being a problem when it meets with the darker side of the gradient.

@WeeKwongBong Can you show a screenshot of just the 3d viewport? Right now it's blocked by the user prefs. Also from a presentation point of view, you may want to hide distracting elements like normals and toolbars and try showing a standard view so we can make a better judgement of it. @PawelLyczkowski-1 *"Dark themes are favoured by artists in general."* We should probably avoid generalized statements like this unless it's backed by some supporting evidence. I don't doubt that you're right, but we should be making design decisions based on principles. In regards to your later screenshot, I'd have to agree with @BartekMoniewski that it appears too difficult to see the objects. I tested the colors using an eye dropper and in some parts there's only a contrast difference of 3 (out of 254), making it very difficult to tell where the object ends and the background begins. As a point of reference, recommended contrast difference for text is at least 110. Solid objects in a 3d viewport are usually much wider than text, but that also depends on how close you are to the object. Trying to find a small object in a huge scene can be a nightmare. Having a clear contrast difference will alleviate some of the difficulties. So for now I'm still in favor of the design proposal by @JonathanWilliamson in the OP. But the problem still remains of the black wireframe being a problem when it meets with the darker side of the gradient.
Author
Member

@AndrewPrice, based on your's and others feedback I think it's best to not do the gradient. That is unless we are to use colors other than black, grey, and white for the inactivate wireframes. I'm not a big fan of this, though, as I think we should use color to draw user's focus to an object. Greyscale colors are generally, by nature, neutral.

I've updated the OP to remove the gradient.

@AndrewPrice, based on your's and others feedback I think it's best to not do the gradient. That is unless we are to use colors other than black, grey, and white for the inactivate wireframes. I'm not a big fan of this, though, as I think we should use color to draw user's focus to an object. Greyscale colors are generally, by nature, neutral. I've updated the OP to remove the gradient.

@AndrewPrice, sorry for covering that part up. I was trying to show the colors in the theme editor. Since you can pick color from it and experiment.

This is default view with my theme, contrast is just right.

a02DefaultView.jpg

Next is edit mode in solid view, default material

a03Selected.jpg

Next is wireframe

a04Wire.jpg

Next is daily modeling situation when objects covering almost 100% of view

a01DailyUse.jpg

And for completeness, you can play with the theme energy_v12-c.xml

There is one compromise, selected activeedge and selectededge are white.
Edges are harder to see if orange. The case is true when you have faces selected.
Everything just becomes a blob of orange, with edges more saturated than faces.

Menu design of orange and white is for fast searching of items.
Top level (panel name) always white > lower level (settings) always orange.
So the process is Scan white then orange.

Also I removed the line between panels, noise!

The theme has been tested in few VFX movie productions (few series jobs too).
Blenderheads love it because it feels close to Nuke and AE.

@AndrewPrice, sorry for covering that part up. I was trying to show the colors in the theme editor. Since you can pick color from it and experiment. This is default view with my theme, contrast is just right. ![a02DefaultView.jpg](https://archive.blender.org/developer/F32471/a02DefaultView.jpg) Next is edit mode in solid view, default material ![a03Selected.jpg](https://archive.blender.org/developer/F32477/a03Selected.jpg) Next is wireframe ![a04Wire.jpg](https://archive.blender.org/developer/F32479/a04Wire.jpg) Next is daily modeling situation when objects covering almost 100% of view ![a01DailyUse.jpg](https://archive.blender.org/developer/F32481/a01DailyUse.jpg) And for completeness, you can play with the theme [energy_v12-c.xml](https://archive.blender.org/developer/F32483/energy_v12-c.xml) There is one compromise, selected **active**edge and **selected**edge are white. Edges are harder to see if orange. The case is true when you have faces selected. Everything just becomes a blob of orange, with edges more saturated than faces. Menu design of orange and white is for fast searching of items. Top level (panel name) always white > lower level (settings) always orange. So the process is **Scan white** then **orange**. Also I removed the line between panels, noise! The theme has been tested in few VFX movie productions (few series jobs too). Blenderheads love it because it feels close to Nuke and AE.

I find this theme too dark and too contrast.
Also I'm pretty sure we need to avoid highly saturated elements, like orange text and sliders in your theme. Saturated interface colors affect visual perception and they are very distracting. Blender has many areas that require clear look of colors - compositor, texture paint, even setting up materials in cycles.
Photoshop, Nuke or After Effects stick to grayish and non-saturated interface items. Only things that need color coding are colored (one exception are numeric values in AE).
Grayish interface is good solution to follow. :)

I find this theme too dark and too contrast. Also I'm pretty sure we need to avoid highly saturated elements, like orange text and sliders in your theme. Saturated interface colors affect visual perception and they are very distracting. Blender has many areas that require clear look of colors - compositor, texture paint, even setting up materials in cycles. Photoshop, Nuke or After Effects stick to grayish and non-saturated interface items. Only things that need color coding are colored (one exception are numeric values in AE). Grayish interface is good solution to follow. :)

Added subscriber: @DataDay

Added subscriber: @DataDay

DataDay here (SaintHaven on BA), still new to phabricator, so forgive me if there is a means of presentation or formatting I am missing at first for this area of contribution.

That said, here is an excerpt from a study done on interface color choices as well as their usage, much of which covers this very are of development:

"The 1997 study (Hill and Scharff 1997) also included a comparison of gray and white backgrounds, which was motivated by the fact that most web browsers at the time had gray
backgrounds as a default. Due to the contrast effect one would expect that a white background would result in better readability. Therefore, they replicated the method of the first experiment with the exception that only black text and three different background colors (light gray, dark gray, and white) were used. Surprisingly, they found better performance with the gray backgrounds than with the white background, a finding, again, inconsistent with the contrast effect. (Ironically, despite these findings, the default background in web browsers these days is, of course, white.)"

The full text can be found here , it covers quite a bit: http:*sighci.org/uploads/published_papers/bit04/BIT_Hall.pdf

@AndrewPrice, I have to agree with plyczkowski here on the Dark Themes. While it may sound a bit like a generalization, whats not a is the objective observation that most applications dealing with visual content have transitioned to the dark greys. I like how one user on stack exchange put it, "Darker color scheme are often used effectively in software that focuses heavily on visual content." Knowing that this convention exists and for a reason can safely tuck away any hesitance over generalization.

The reason behind going with a dark grey is both "scientific" and also technical. The key points being:

  • Readability. Dark themes frame and help the artist focus on the content being made, whether its with calculating light in a scene or the color on an asset. It is easier to find and identify colored objects within a darker interface.
  • The sciences have shown our eyes are able find and focus on visual content if it is the window providing the light and color ranges. The focus of the eye is easier to maintain when the surrounding interface is darker. Another way to illustrate how this works is with game design, rather level design in games. A rule level designers and environment artist use is to have light in a darker surrounding to hint at what the player should focus on or the direction they should go. Its how we can trick players into going in certain directions without making them feel like they are being lead in a linear fashion. In short its a pattern of behavior.
  • The technical side is this... our LCD screens these days are brighter and often emit a blue light associated with eye strain. Those yellow tinted computer glasses you see popping up all over the place for professional gaming and computer usage block such light. The strain becomes worse with brighter themed interfaces as opposed to darker interfaces. Artist, such as ourselves, often spend hours on end in front of these applications, so thus the push towards darker themes is entirely user centric.

There is some sentiment involved with those who just dont like dark themes. And thats fine. Allowing custom themes is important so that some people, even if they chose to live with some of the side effects of a brighter (see whiter) interface, have the ability to do so. Defaults on the other hand probably should best fit the convention that most visual applications are using in response to the user's desires.

What I think is important, and this is just my opinion, is having the most artist friendly set up (which includes theme) that help highlight and identify specific color choices made by you, the developers.

One solution is to even have something like a context sensitive color range for the interface itself. For example, say you have a limited range of gray, mid-dark gray and dark gray. When the user enters say sculpt mode, the theme range would transition into the dark gray. Going into object mode, it might subtly slide into the gray range. In the camera fly mode, a dark gray. Not only will the brain begin to identify this with modes, but help give that valuable feedback tied to user interactivity. Modes become more recognizable in other words. The importance is that the brain will start picking up on these shifts, even if the user does not see it right away. This would certainly be a first as far as I know, and would give the impression of being ahead of the game not behind it.

In regards to gradients in the background itself... they are useful as it conveys depth. When working in 3d, depth is important. A limited range of a lighter gray to a darker gray, from top to bottom is probably the best and most color neutral combination. Additionally, if we were to look at some of the other leading 3d creation software, having a hotkey or toggle between 3d viewport backgrounds would empower the user a bit more. In one application that will not be named, I can hit a hotkey combo which changes the background gradient into a pure 50% grey, and tapping it once more makes it 100% black. I can toggle through this to set up lighting for a scene or re-evaluate contrast before going back to a gradient for the depth (perhaps when modelling or with dynamics).

Anyways, I hope this helps in some way, even the parts that are mere opinion.

DataDay here (SaintHaven on BA), still new to phabricator, so forgive me if there is a means of presentation or formatting I am missing at first for this area of contribution. That said, here is an excerpt from a study done on interface color choices as well as their usage, much of which covers this very are of development: "The 1997 study (Hill and Scharff 1997) also included a comparison of gray and white backgrounds, which was motivated by the fact that most web browsers at the time had gray backgrounds as a default. Due to the contrast effect one would expect that a white background would result in better readability. Therefore, they replicated the method of the first experiment with the exception that only black text and three different background colors (light gray, dark gray, and white) were used. Surprisingly, they found better performance with the gray backgrounds than with the white background, a finding, again, inconsistent with the contrast effect. (Ironically, despite these findings, the default background in web browsers these days is, of course, white.)" The full text can be found [here ](http:*sighci.org/uploads/published_papers/bit04/BIT_Hall.pdf), it covers quite a bit: http:*sighci.org/uploads/published_papers/bit04/BIT_Hall.pdf @AndrewPrice, I have to agree with plyczkowski here on the Dark Themes. While it may sound a bit like a generalization, whats not a is the objective observation that most applications dealing with visual content have transitioned to the dark greys. I like how one user on stack exchange put it, "Darker color scheme are often used effectively in software that focuses heavily on visual content." Knowing that this convention exists and for a reason can safely tuck away any hesitance over generalization. The reason behind going with a dark grey is both "scientific" and also technical. The key points being: - Readability. Dark themes frame and help the artist focus on the content being made, whether its with calculating light in a scene or the color on an asset. It is easier to find and identify colored objects within a darker interface. - The sciences have shown our eyes are able find and focus on visual content if it is the window providing the light and color ranges. The focus of the eye is easier to maintain when the surrounding interface is darker. Another way to illustrate how this works is with game design, rather level design in games. A rule level designers and environment artist use is to have light in a darker surrounding to hint at what the player should focus on or the direction they should go. Its how we can trick players into going in certain directions without making them feel like they are being lead in a linear fashion. In short its a pattern of behavior. - The technical side is this... our LCD screens these days are brighter and often emit a blue light associated with eye strain. Those yellow tinted computer glasses you see popping up all over the place for professional gaming and computer usage block such light. The strain becomes worse with brighter themed interfaces as opposed to darker interfaces. Artist, such as ourselves, often spend hours on end in front of these applications, so thus the push towards darker themes is entirely user centric. There is some sentiment involved with those who just dont like dark themes. And thats fine. Allowing custom themes is important so that some people, even if they chose to live with some of the side effects of a brighter (see whiter) interface, have the ability to do so. Defaults on the other hand probably should best fit the convention that most visual applications are using in response to the user's desires. What I think is important, and this is just my opinion, is having the most artist friendly set up (which includes theme) that help highlight and identify specific color choices made by you, the developers. One solution is to even have something like a context sensitive color range for the interface itself. For example, say you have a limited range of gray, mid-dark gray and dark gray. When the user enters say sculpt mode, the theme range would transition into the dark gray. Going into object mode, it might subtly slide into the gray range. In the camera fly mode, a dark gray. Not only will the brain begin to identify this with modes, but help give that valuable feedback tied to user interactivity. Modes become more recognizable in other words. The importance is that the brain will start picking up on these shifts, even if the user does not see it right away. This would certainly be a first as far as I know, and would give the impression of being ahead of the game not behind it. In regards to gradients in the background itself... they are useful as it conveys depth. When working in 3d, depth is important. A limited range of a lighter gray to a darker gray, from top to bottom is probably the best and most color neutral combination. Additionally, if we were to look at some of the other leading 3d creation software, having a hotkey or toggle between 3d viewport backgrounds would empower the user a bit more. In one application that will not be named, I can hit a hotkey combo which changes the background gradient into a pure 50% grey, and tapping it once more makes it 100% black. I can toggle through this to set up lighting for a scene or re-evaluate contrast before going back to a gradient for the depth (perhaps when modelling or with dynamics). Anyways, I hope this helps in some way, even the parts that are mere opinion.

@DataDay Thanks, my statement about darker themes lacked solid arguments which you provided.

@DataDay Thanks, my statement about darker themes lacked solid arguments which you provided.

@BartekMoniewski I don't advocate to use my theme's orange as default.
It is best to stay with neutral greys as @DataDay argued clearly.
But be extra careful with value, that is the parameter that makes or breaks a theme.
Avoid those retina burn situations, because for some people, retina burn can be a permanent visual injury.

Another factor to consider is color, as it will shift circadian rhythm.
Cornucopia of color to circadian rhythm research papers
I used to be lighting product designer, so I know this topic like the back of my hand.
But I'm too exhausted to type more stuff right now.
So hit the link above (and google) to dig deeper onto the topic of color and circadian rhythm.

@BartekMoniewski I don't advocate to use my theme's orange as default. It is best to stay with neutral greys as @DataDay argued clearly. But be extra careful with value, that is the parameter that makes or breaks a theme. Avoid those retina burn situations, because for some people, retina burn can be a permanent visual injury. Another factor to consider is color, as it will shift circadian rhythm. [Cornucopia of color to circadian rhythm research papers ](http://justgetflux.com/research.html) I used to be lighting product designer, so I know this topic like the back of my hand. But I'm too exhausted to type more stuff right now. So hit the link above (and google) to dig deeper onto the topic of color and circadian rhythm.

Added subscriber: @xrg

Added subscriber: @xrg

Added subscriber: @numarul7

Added subscriber: @numarul7

No gradient by default! +1

No gradient by default! +1

Added subscriber: @TodorImreorov

Added subscriber: @TodorImreorov

There is a specific reason that ADOBE and AUTODESK are starting to move their software to darker interfaces.
Darker themed skins emit less light, which in fact reduces the strain to the eyes. If you think about the profession of 3d artists- we spend a lot of time in front of those screens.

On wireframe colors- my only interest on this topic is the one of readability. When you have a slightly lighter gray wire/vertices on top of a gray mesh- there is not much contrast- you have to strain your eyes to see it.
When you are in wireframe mode- the almost white grey the wireframe has makes more sense. But in shaded mode I'd rather have it a darker color than the default gray mesh.

So if you are changing the wireframe color- change it only for wireframe mode if you will- to improve the contrast. But keep it dark for shaded mode.

There is a specific reason that ADOBE and AUTODESK are starting to move their software to darker interfaces. Darker themed skins emit less light, which in fact reduces the strain to the eyes. If you think about the profession of 3d artists- we spend a lot of time in front of those screens. On wireframe colors- my only interest on this topic is the one of readability. When you have a slightly lighter gray wire/vertices on top of a gray mesh- there is not much contrast- you have to strain your eyes to see it. When you are in wireframe mode- the almost white grey the wireframe has makes more sense. But in shaded mode I'd rather have it a darker color than the default gray mesh. So if you are changing the wireframe color- change it only for wireframe mode if you will- to improve the contrast. But keep it dark for shaded mode.

Added subscriber: @AndyDavies-3

Added subscriber: @AndyDavies-3

I'm not super keen on light wireframe colours tbh. I find it much easier for to read black wireframes on a grey object than light wireframes on a grey object.
I would be up for a darker theme by default though.

I'm not super keen on light wireframe colours tbh. I find it much easier for to read black wireframes on a grey object than light wireframes on a grey object. I would be up for a darker theme by default though.

Added subscriber: @MartinLindelof

Added subscriber: @MartinLindelof

@TodorImreorov I've studied interactive design, HCI for two years. Regarding the dark theme, it might be soothing, but to low contrast between text elements will quickly strain the eyes.

Regarding themes could it be possible to submit an updated versions of Softblend here? to someone. To commit before 2.70

@TodorImreorov I've studied interactive design, HCI for two years. Regarding the dark theme, it might be soothing, but to low contrast between text elements will quickly strain the eyes. Regarding themes could it be possible to submit an updated versions of Softblend here? to someone. To commit before 2.70

Added subscriber: @Januz

Added subscriber: @Januz
Member

Added subscriber: @liquidape

Added subscriber: @liquidape

Added subscriber: @gun4hire

Added subscriber: @gun4hire

wire.PNG
solid.PNG
I love the gradient. Just need some color so it does not blend with background!

I found that cyan worked well for wire visibility. If we are going to go with black and/or white background, the color helps it pop, while still being bright. Also, most meshes are the default gray, so white wire does not stand out well against white or gray.
Wire
009797
vertex
00FFFF

Same idea for grid floor, but red and more muted:
2C0000

Side note:
edge length should be red :)

![wire.PNG](https://archive.blender.org/developer/F62906/wire.PNG) ![solid.PNG](https://archive.blender.org/developer/F62908/solid.PNG) I love the gradient. Just need some color so it does not blend with background! I found that cyan worked well for wire visibility. If we are going to go with black and/or white background, the color helps it pop, while still being bright. Also, most meshes are the default gray, so white wire does not stand out well against white or gray. Wire 009797 vertex 00FFFF Same idea for grid floor, but red and more muted: 2C0000 Side note: edge length should be red :)

Added subscriber: @michaelknubben

Added subscriber: @michaelknubben

I really don't know why everyone loves such light wireframes so much :P

So far I much prefer the theme proposed by @PawelLyczkowski-1 though perhaps not the light wireframes.

As said previously Adobe and Autodesk have spent vast amounts of money on this kind of thing and they all are toward the darker side of the spectrum with slightly lighter values for wires. I personally really don't see the need for such an overhaul of the default theme however. The orange we have now is perfectly contrasted against dark grey and is easy enough on the eyes. Orange is also one of the main aspects of the Blender brand which we would lose if it were changed. As such I feel very strongly about keeping it.

We could however have the option for 4 increasingly lighter themes like Adobe have for their products. At least then there is something for everyone. :)

I really don't know why everyone loves such light wireframes so much :P So far I much prefer the theme proposed by @PawelLyczkowski-1 though perhaps not the light wireframes. As said previously Adobe and Autodesk have spent vast amounts of money on this kind of thing and they all are toward the darker side of the spectrum with slightly lighter values for wires. I personally really don't see the need for such an overhaul of the default theme however. The orange we have now is perfectly contrasted against dark grey and is easy enough on the eyes. Orange is also one of the main aspects of the Blender brand which we would lose if it were changed. As such I feel very strongly about keeping it. We could however have the option for 4 increasingly lighter themes like Adobe have for their products. At least then there is something for everyone. :)

@AndyDavies-3 The problem isn't selected meshes, it's the unselected ones. Black wireframes against a dark grey background presents readability issues. It causes you to squint or select everything in order to see all the meshes properly.

Selected meshes staying as orange is fine, but something needs to be done about the unselected state. Either the background or wireframe color needs changing.

@AndyDavies-3 The problem isn't selected meshes, it's the unselected ones. Black wireframes against a dark grey background presents readability issues. It causes you to squint or select everything in order to see all the meshes properly. Selected meshes staying as orange is fine, but something needs to be done about the unselected state. Either the background or wireframe color needs changing.

@AndrewPrice, Fair enough but I still have to disagree with you there, mate. :P

There is still a 23% difference in brightness with the default theme which is more than adequate IMHO & I would much rather have a dark wireframe than a bright one which would kill my eyes at least. I feel it would be the same as white text on a black background.

But yea, I really can't say that I have ever had this issue to a great extent and if I do have trouble seeing the mesh I can just hit Z to jump into solid mode and then there isn't a problem, but on the other hand if I have lighter coloured wireframes and on the current grey mesh then hitting Z with the values from above I have now reduced the contrast between the mesh and wireframes to 10% or less rather than the 40%+ that is was before which would cause more eyestrain because the values are much closer than before. In reality we are switching one problem for another, which will affect people who work in solid mode to a much greater extent to those who do not.

Idk, I can really see why some people don't mind this but for those people who do it's going to cause some major headaches. This small change has a major effect on how people interact with Blender ,so personally I feel it is better left alone.
Everyone can already change it if they wish and I don't hear any sort of massive outcry of people relative to the size of the userbase asking for this change so it feels that it is fixing something that isn't broken. ofc I would be happy if there were 2 options for this but as it stands I will have to change it back if this because the default setting. :)

@AndrewPrice, Fair enough but I still have to disagree with you there, mate. :P There is still a 23% difference in brightness with the default theme which is more than adequate IMHO & I would much rather have a dark wireframe than a bright one which would kill my eyes at least. I feel it would be the same as white text on a black background. But yea, I really can't say that I have ever had this issue to a great extent and if I do have trouble seeing the mesh I can just hit Z to jump into solid mode and then there isn't a problem, but on the other hand if I have lighter coloured wireframes and on the current grey mesh then hitting Z with the values from above I have now reduced the contrast between the mesh and wireframes to 10% or less rather than the 40%+ that is was before which would cause more eyestrain because the values are much closer than before. In reality we are switching one problem for another, which will affect people who work in solid mode to a much greater extent to those who do not. Idk, I can really see why some people don't mind this but for those people who do it's going to cause some major headaches. This small change has a major effect on how people interact with Blender ,so personally I feel it is better left alone. Everyone can already change it if they wish and I don't hear any sort of massive outcry of people relative to the size of the userbase asking for this change so it feels that it is fixing something that isn't broken. ofc I would be happy if there were 2 options for this but as it stands I will have to change it back if this because the default setting. :)

Added subscriber: @ideasman42

Added subscriber: @ideasman42

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'

No conclusion here, while defaults can change based on designs that are agreed on, its been over a year and no conclusion.

Archiving, can re-open if UI team wants to finish this off.

No conclusion here, while defaults can change based on designs that are agreed on, its been over a year and no conclusion. Archiving, can re-open if UI team wants to finish this off.
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
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
EEVEE & Viewport
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
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
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
EEVEE & Viewport
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
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
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
21 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#37419
No description provided.