View Transform and Look settings are ignored in LookDev mode #57649

Closed
opened 2018-11-06 11:55:02 +01:00 by Rainer Trummer · 22 comments

System Information
Windows 10, Quadro 4000

Blender Version
Broken: c86b5fa820
Worked: before mentioned commit

Short description of error
Since the aforementioned commit, any change of View Transform or Look is entirely ignored by Workbench and LookDev mode, which to me makes no sense at all. I've created this bug report to check if everyone is fine with this change. Also Exposure and Gamma settings are ignored by LookDev. Knowing the artists on my team, I'm sure they do tweak these settings while creating shaders, to see how materials react on light condition changes. Also, we're using an external OCIO configuration instead of the one shipped with Blender (we use the original Filmic GIT repo and made some own modifications there). With this commit, LookDev becomes rather limited to us.

I appreciate the separation of Eevee and LookDev a lot, since I can easily check what happens if I don't use scene lights, and try out other environments. But if I cannot use the same View Transform as with Eevee Render Mode, I have to do a lot of tweaks either again, or not use LookDev at all to be on the safe side.

Even in Workbench mode I'm not entirely sure if this change is a welcome one, but I guess we could live with it. Haven't checked if this change goes through down to OpenGL renderings too. If so, the colors of my masks (which I generate using Random Color mode with flat shading) become mangled - they really need to be exported as sRGB EOTF.

CManagement.JPG

Exact steps for others to reproduce the error
Start Blender using Factory settings, Go to LookDev mode, and change View Transform, Look, Exposure or Gamma - nothing changes. Only Display Device is considered. Note that at the moment you have to rotate your 3D View to see CM changes updating.

**System Information** Windows 10, Quadro 4000 **Blender Version** Broken: c86b5fa820d181c2beabdf4147ac17cb6ff8149b Worked: before mentioned commit **Short description of error** Since the aforementioned commit, any change of View Transform or Look is entirely ignored by Workbench and LookDev mode, which to me makes no sense at all. I've created this bug report to check if everyone is fine with this change. Also Exposure and Gamma settings are ignored by LookDev. Knowing the artists on my team, I'm sure they do tweak these settings while creating shaders, to see how materials react on light condition changes. Also, we're using an external OCIO configuration instead of the one shipped with Blender (we use the original Filmic GIT repo and made some own modifications there). With this commit, LookDev becomes rather limited to us. I appreciate the separation of Eevee and LookDev a lot, since I can easily check what happens if I don't use scene lights, and try out other environments. But if I cannot use the same View Transform as with Eevee Render Mode, I have to do a lot of tweaks either again, or not use LookDev at all to be on the safe side. Even in Workbench mode I'm not entirely sure if this change is a welcome one, but I guess we could live with it. Haven't checked if this change goes through down to OpenGL renderings too. If so, the colors of my masks (which I generate using Random Color mode with flat shading) become mangled - they really need to be exported as sRGB EOTF. ![CManagement.JPG](https://archive.blender.org/developer/F5406851/CManagement.JPG) **Exact steps for others to reproduce the error** Start Blender using Factory settings, Go to LookDev mode, and change View Transform, Look, Exposure or Gamma - nothing changes. Only Display Device is considered. Note that at the moment you have to rotate your 3D View to see CM changes updating.
Author

Added subscriber: @RainerTrummer

Added subscriber: @RainerTrummer

#58218 was marked as duplicate of this issue

#58218 was marked as duplicate of this issue

Added subscriber: @moisessalvador

Added subscriber: @moisessalvador

Yeah, I'd like for the HDRs of Lookdev to use the scene's Color Management settings as well, minus the exposure settings, unless you turn scene lights on

As for the Workbench, Matcaps and Studio lights depend a lot on the intention of how they were created. Some matcaps benefit from Filmic, like EXR matcaps of materials with highlights, like porcelain, rubber, sculpt clay, etc. while others should be sRGB, like all the custom PNG matcaps I imported, and even some of the EXR ones, like normal map or horizontal lines. Studio lights are ok for the most part, except some of them have weird darkenings. I propose for Matcaps and Studio lights to switch View transform on an individual basis, controlled maybe by flags written on the filename of each, but not by the scene's color management. Just to throw it out there ^_^

I remember that for a while matcaps would use Filmic, the color pickers would also use filmic as well which was weird and wasn't even affected by the scene color settings. How to improve the color picker to have more transforms than gamma is another different history

Yeah, I'd like for the HDRs of Lookdev to use the scene's Color Management settings as well, minus the exposure settings, unless you turn scene lights on As for the Workbench, Matcaps and Studio lights depend a lot on the intention of how they were created. Some matcaps benefit from Filmic, like EXR matcaps of materials with highlights, like porcelain, rubber, sculpt clay, etc. while others should be sRGB, like all the custom PNG matcaps I imported, and even some of the EXR ones, like normal map or horizontal lines. Studio lights are ok for the most part, except some of them have weird darkenings. I propose for Matcaps and Studio lights to switch View transform on an individual basis, controlled maybe by flags written on the filename of each, but not by the scene's color management. Just to throw it out there ^_^ I remember that for a while matcaps would use Filmic, the color pickers would also use filmic as well which was weird and wasn't even affected by the scene color settings. How to improve the color picker to have more transforms than gamma is another different history
Member

Added subscribers: @fclem, @troy_s, @brecht, @lichtwerk

Added subscribers: @fclem, @troy_s, @brecht, @lichtwerk
Member

Just to get this right: this only kicks in when you dont use Shading > Scene Lights in LookDev, right?
Once you do, you seem to be getting colormanaged output, right?
[So enabeling Scene Lights but hiding all lights plus not using Scene World would be what you are after?]

Whole point sounds reasonable to me, not sure if this was changed by design...
That being said, colormanagement is not my playground, adding the usual suspects here:

@brecht, @fclem, @troy_s : opinions?

Just to get this right: this only kicks in when you **dont** use `Shading` > `Scene Lights` in LookDev, right? Once you do, you seem to be getting colormanaged output, right? [So enabeling `Scene Lights` but hiding all lights plus not using `Scene World` would be what you are after?] Whole point sounds reasonable to me, not sure if this was changed by design... That being said, colormanagement is not my playground, adding the usual suspects here: @brecht, @fclem, @troy_s : opinions?
Author

@lichtwerk Well, when scene lights are enabled from the Shading Popover, Color Management is fully applied to the viewport in LookDev mode. Thanks for pointing this out. The problem is, in my scene I have a lot of area lights illuminating an interior like LED strips. The viewport becomes unusably slow if they are enabled, so that's not really a route for me to take. I fail to understand the benefit of not applying the selected View Transform if scene lights are turned off. Especially because there is zero indication in the UI that the transform is overridden, and neither is indicated by what it is being overridden. Maybe the decision was clever and I just don't see the reason yet, that's why I'm asking the question.

@lichtwerk Well, when scene lights are enabled from the Shading Popover, Color Management is fully applied to the viewport in LookDev mode. Thanks for pointing this out. The problem is, in my scene I have a lot of area lights illuminating an interior like LED strips. The viewport becomes unusably slow if they are enabled, so that's not really a route for me to take. I fail to understand the benefit of not applying the selected View Transform if scene lights are turned off. Especially because there is zero indication in the UI that the transform is overridden, and neither is indicated by what it is being overridden. Maybe the decision was clever and I just don't see the reason yet, that's why I'm asking the question.

Added subscriber: @SteffenD

Added subscriber: @SteffenD

We already agreed to apply the View Transform and Look into LookDev mode, but still ignore the Exposure. That hasn't been implemented yet, and I'm not entirely sure it's the right solution yet.

The problem is that the view transform, look and exposure are all used to tweak what the final render looks like. This might be very dark or have some artistic look, which gets in the way when modeling, sculpting, or texture painting. Further if you don't use Filmic or a similar transform, your viewport will look washed out when using matcaps or lookdev mode, and it's not great to have that when loading existing .blend files created in earlier version. We want working display modes to be always clearly shaded regardless of the artistic choices for the final render.

We already agreed to apply the View Transform and Look into LookDev mode, but still ignore the Exposure. That hasn't been implemented yet, and I'm not entirely sure it's the right solution yet. The problem is that the view transform, look and exposure are all used to tweak what the final render looks like. This might be very dark or have some artistic look, which gets in the way when modeling, sculpting, or texture painting. Further if you don't use Filmic or a similar transform, your viewport will look washed out when using matcaps or lookdev mode, and it's not great to have that when loading existing .blend files created in earlier version. We want working display modes to be always clearly shaded regardless of the artistic choices for the final render.

Removed subscriber: @moisessalvador

Removed subscriber: @moisessalvador
Member

@RainerTrummer: regarding the (temporary) workaround of enabling Shading > Scene Lights: I meant you can hide all lights on top of that setting (easiest to put them all in a collection and hide it) to get you speed back... and have colormanaged HDRI influence...

@RainerTrummer: regarding the (temporary) workaround of enabling `Shading` > `Scene Lights`: I meant you can hide all lights on top of that setting (easiest to put them all in a collection and hide it) to get you speed back... and have colormanaged HDRI influence...

In #57649#550468, @brecht wrote:
We want working display modes to be always clearly shaded regardless of the artistic choices for the final render.

This isn't going to be possible. We also have to remember that the view transform is going to be handling the primaries, as such it is much more than just the transfer function.

Specifically, if the primaries are wide gamut such as REC.2020, the transfer function itself will change accordingly. And this doesn't take into account various things like the many sweeteners in something like ACES.

There won't be a one-size fits all, and even if there seemed to be, it would break fundamental colour management.

> In #57649#550468, @brecht wrote: > We want working display modes to be always clearly shaded regardless of the artistic choices for the final render. This isn't going to be possible. We also have to remember that the view transform is going to be handling the primaries, as such it is much more than just the transfer function. Specifically, if the primaries are wide gamut such as REC.2020, the transfer function itself will change accordingly. And this doesn't take into account various things like the many sweeteners in something like ACES. There won't be a one-size fits all, and even if there seemed to be, it would break fundamental colour management.
Author

@brecht Thanks for your feedback, it's really cool that parts of CM are re-introduced back to LookDev mode. I do understand that the topic is complex, as the Blender Devs are putting a lot of effort into making Blender more accessible and easy to use. As far as I gather the discussion, this is the main reason for the change, so people would find a consistent experience. However, I find it counter-intuitive for LookDev mode.

Yes, you have a valid point that if LookDev and Rendered View share the same Color Management settings, one is going to tweak the other. But from my perspective, that's exactly what I want. If I were to use a certain exposure for rendering, why use a different one for dialing in the shader? Same with gamma. Same with View Transform and Look. I'd like to share some thoughts using images to make the point clearer:

This is an excerpt of a final shot of a rendering I worked on a while ago. A spin-off was presented at BCon17:
Stop0.JPG

This is the same shot at exposure level -2:
Stop-2.JPG

And here at -5:
Stop-5.JPG

What I should have noticed when doing this is that even though the engine is getting close to black very soon, the orange tank still sticks out as if it was kind of self-illuminating. This is a hint that there is a problem with the Albedo Color. It was a false assumption of a certain RGB triplet I made. While it looked fine in the final shot, the Exposure check revealed that I can really only use that material under the lighting conditions I prepared for the final scene. But PBR materials should allow to be used under very different lighting conditions. The problem is not the material, it's my false assumption.

If I had checked that triplet in LookDev mode using exposure checks, I'd have detected this. So to be clear: We use the exposure slider NOT to tweak final render exposures, but to CHECK albedo color consistency! That's why I see it as something important for LookDev mode.

@brecht Thanks for your feedback, it's really cool that parts of CM are re-introduced back to LookDev mode. I do understand that the topic is complex, as the Blender Devs are putting a lot of effort into making Blender more accessible and easy to use. As far as I gather the discussion, this is the main reason for the change, so people would find a consistent experience. However, I find it counter-intuitive for LookDev mode. Yes, you have a valid point that if LookDev and Rendered View share the same Color Management settings, one is going to tweak the other. But from my perspective, that's exactly what I want. If I were to use a certain exposure for rendering, why use a different one for dialing in the shader? Same with gamma. Same with View Transform and Look. I'd like to share some thoughts using images to make the point clearer: This is an excerpt of a final shot of a rendering I worked on a while ago. A spin-off was presented at BCon17: ![Stop0.JPG](https://archive.blender.org/developer/F5426270/Stop0.JPG) This is the same shot at exposure level -2: ![Stop-2.JPG](https://archive.blender.org/developer/F5426286/Stop-2.JPG) And here at -5: ![Stop-5.JPG](https://archive.blender.org/developer/F5426293/Stop-5.JPG) What I should have noticed when doing this is that even though the engine is getting close to black very soon, the orange tank still sticks out as if it was kind of self-illuminating. This is a hint that there is a problem with the Albedo Color. It was a false assumption of a certain RGB triplet I made. While it looked fine in the final shot, the Exposure check revealed that I can really only use that material under the lighting conditions I prepared for the final scene. But PBR materials *should* allow to be used under very different lighting conditions. The problem is not the material, it's my false assumption. If I had checked that triplet in LookDev mode using exposure checks, I'd have detected this. So to be clear: We use the exposure slider NOT to tweak final render exposures, but to CHECK albedo color consistency! That's why I see it as something important for LookDev mode.

I can see how it's useful to have control over exposure in LookDev mode. However there are many users using scene exposure to tweak final render exposures, and I don't think we want to break that. There are a lot of .blend files out there that if you open them look very dark or bright in lookdev mode, because it's not using bright or dark scene lights.

Perhaps the solution would be to fold "LookDev" functionality into the "Render" display mode, always following scene color management there. And then "LookDev" mode could be renamed to something like "Material" or "Preview", ignoring most of the scene color management settings. It could still have a per-viewport exposure setting.

I can see how it's useful to have control over exposure in LookDev mode. However there are many users using scene exposure to tweak final render exposures, and I don't think we want to break that. There are a lot of .blend files out there that if you open them look very dark or bright in lookdev mode, because it's not using bright or dark scene lights. Perhaps the solution would be to fold "LookDev" functionality into the "Render" display mode, always following scene color management there. And then "LookDev" mode could be renamed to something like "Material" or "Preview", ignoring most of the scene color management settings. It could still have a per-viewport exposure setting.
Author

@brecht I see. Well, if the exposure story is seen as an issue, I guess we can live with having exposure and gamma settings ignored. I don't want to complicate things too much, I'm just sharing my thoughts from a user/studio perspective. View Transform and Look however are a must-have, but this I gather was agreed already. If exposure and gamma are ignored, there will be a need to deal with this in the UI. Having the parameters there doing nothing will confuse the hell out of people.

I'm not a fan of tucking LookDev somewhere as a sub-setting to be honest. When it was introduced I thought initially "what's the point?", as it was so close to Eevee. Now after using it for a few months I'm a huge fan of it, because I can quickly preview scenes with my favorite environments without constantly setting them up, and check the material easily without light influence too. Having it very accessible in the UI is very important in IMHO.

@lichtwerk As a side note, the light hiding fails as soon as lights are part of a collection instance coming from another Scene, which is the case for one of my files. I'd rather prefer not to need to work around in this specific case.

@brecht I see. Well, if the exposure story is seen as an issue, I guess we can live with having exposure and gamma settings ignored. I don't want to complicate things too much, I'm just sharing my thoughts from a user/studio perspective. View Transform and Look however are a must-have, but this I gather was agreed already. If exposure and gamma are ignored, there will be a need to deal with this in the UI. Having the parameters there doing nothing will confuse the hell out of people. I'm not a fan of tucking LookDev somewhere as a sub-setting to be honest. When it was introduced I thought initially "what's the point?", as it was so close to Eevee. Now after using it for a few months I'm a huge fan of it, because I can quickly preview scenes with my favorite environments without constantly setting them up, and check the material easily without light influence too. Having it very accessible in the UI is very important in IMHO. @lichtwerk As a side note, the light hiding fails as soon as lights are part of a collection instance coming from another Scene, which is the case for one of my files. I'd rather prefer not to need to work around in this specific case.
Member

@RainerTrummer : Not sure why the light hiding is failing for you (working fine here for collection instances [be it linked from another blend or coming from another scene]), if that is an issue please report a bug for that as well.
I just noticed though that in the "instance" case, there appears to be an issue with shadows (reported separately -- see #57693).
That being said, I dont wont to hijack the original report -- and I am not a big fan of this workaround either...

@RainerTrummer : Not sure why the light hiding is failing for you (working fine here for collection instances [be it linked from another blend or coming from another scene]), if that is an issue please report a bug for that as well. I just noticed though that in the "instance" case, there appears to be an issue with shadows (reported separately -- see #57693). That being said, I dont wont to hijack the original report -- and I am not a big fan of this workaround either...
Author

@lichtwerk Maybe a misunderstanding, it technically works, but it's not very convenient from a user perspective, that's what I'm trying to say. So no bug to report there.

@lichtwerk Maybe a misunderstanding, it *technically* works, but it's not very convenient from a user perspective, that's what I'm trying to say. So no bug to report there.

Added subscriber: @Alaska

Added subscriber: @Alaska
Member

just checking if this is still an issue? (as of 0e5f97a3a1 CM seems to be respected in LookDev? -- havent hunted down the relating commit though...)

note there is another (loosely related) discussion in #58405 [which now adds Solid mode inconsistencies to the mix...]

just checking if this is still an issue? (as of 0e5f97a3a1 CM seems to be respected in LookDev? -- havent hunted down the relating commit though...) note there is another (loosely related) discussion in #58405 [which now adds Solid mode inconsistencies to the mix...]
Brecht Van Lommel self-assigned this 2018-12-06 12:26:00 +01:00

This is still to be fixed.

#58405 (Inconsistent Color management behavior for textures between Solid and Eevee) seems to be a mix of this bug and some refresh issue.

This is still to be fixed. #58405 (Inconsistent Color management behavior for textures between Solid and Eevee) seems to be a mix of this bug and some refresh issue.

This issue was referenced by 9a63fa21eb

This issue was referenced by 9a63fa21eb45038ce747748156da61b14213d6c7

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'
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
No Assignees
7 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#57649
No description provided.