Baking diffuse lighting on 100% metallic surface produces black #95973

Closed
opened 2022-02-23 00:12:25 +01:00 by Jim Conrad · 12 comments

System Information
Operating system: Windows-10-10.0.19044-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 2080 with Max-Q Design/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 511.79

Blender Version
Broken: version: 3.0.1, branch: master, commit date: 2022-01-25 17:19, hash: dc2d180181
Worked: NONE

Short description of error
When attempting to use the Bake function to render Diffuse on Metallic surfaces, setting the surface to be 100% Metallic causes the render bake to turn out completely black on those surfaces.
It makes some degree of sense that a metallic surface would not absorb any diffuse light, however, this is internally inconsistent as setting the Metallic value to ANYTHING below 1.0 produces diffuse lighting information in the bake.
Metallic surfaces of varying degrees in real life show lighting and shadows on them. Blender appears to work the same way--except for this 1.0 metallic case, which ends up seeming like a bug.
99.99% metallic bakes diffuse lighting but 100.0% bakes NO diffuse lighting. How was that threshold decided? There must be a more scientific, physically-based approach that might make more sense.

NOTE: I understand, from this [other bug report ]], that you cannot bake the Metallic factor into a Diffuse channel, for example. However, this is just diffuse lighting and shadow information, not metallic.I also tried on the latest daily alpha build (3.2.0 Alpha, branch: master, commit date: 2022-02-20 22:15, hash: 36d7adf85c), but baking was somewhat broken in general.[ https:*github.com/mrdoob/three.js/issues/22692 | This issue thread in the Threejs github repo is what sparked this whole exploration, for context.

Exact steps for others to reproduce the error

  • Start with the provided .blend file
  • Select the cube object and make sure the image texture is selected in the Shader Editor
  • Try light baking with the "Diffuse" setting enabled (dropdown). Set to both Direct and Indirect lighting (no color)
  • Try again with the Metallic slider all the way up to 1.0
  • Compare the rendered lightmap-- when at 1.0, the cube doesn't get any baked lighting at all.

LightBakeMetal.blend

**System Information** Operating system: Windows-10-10.0.19044-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 2080 with Max-Q Design/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 511.79 **Blender Version** Broken: version: 3.0.1, branch: master, commit date: 2022-01-25 17:19, hash: `dc2d180181` Worked: NONE **Short description of error** When attempting to use the Bake function to render Diffuse on Metallic surfaces, setting the surface to be 100% Metallic causes the render bake to turn out completely black on those surfaces. It makes some degree of sense that a metallic surface would not absorb any diffuse light, however, this is internally inconsistent as **setting the Metallic value to ANYTHING below 1.0 produces diffuse lighting information in the bake**. Metallic surfaces of varying degrees in real life show lighting and shadows on them. Blender appears to work the same way--except for this 1.0 metallic case, which ends up seeming like a bug. **99.99% metallic bakes diffuse lighting but 100.0% bakes NO diffuse lighting**. How was that threshold decided? There must be a more scientific, physically-based approach that might make more sense. NOTE: I understand, from this [other bug report ]], that you cannot bake the Metallic factor into a Diffuse channel, for example. However, this is just diffuse lighting and shadow information, not metallic.*I also tried on the latest daily alpha build (3.2.0 Alpha, branch: master, commit date: 2022-02-20 22:15, hash: `36d7adf85c`), but baking was somewhat broken in general.*[[ https:*github.com/mrdoob/three.js/issues/22692 | This issue thread in the Threejs github repo ](https:*developer.blender.org/T69826) is what sparked this whole exploration, for context. **Exact steps for others to reproduce the error** - Start with the provided .blend file - Select the cube object and make sure the image texture is selected in the Shader Editor - Try light baking with the "Diffuse" setting enabled (dropdown). Set to both Direct and Indirect lighting (no color) - Try again with the Metallic slider all the way up to 1.0 - Compare the rendered lightmap-- when at 1.0, the cube doesn't get any baked lighting at all. [LightBakeMetal.blend](https://archive.blender.org/developer/F12883503/LightBakeMetal.blend)
Author

Added subscriber: @JCo

Added subscriber: @JCo

#98880 was marked as duplicate of this issue

#98880 was marked as duplicate of this issue

Added subscriber: @ConorW

Added subscriber: @ConorW
Member

Added subscribers: @brecht, @Alaska

Added subscribers: @brecht, @Alaska
Member

I personally don't believe this is a bug, but I would like confirmation from someone more closely related to Cycles development. @brecht would you mind looking at this?


When attempting to use the Bake function to render Diffuse on Metallic surfaces, setting the surface to be 100% Metallic causes the render bake to turn out completely black on those surfaces.
It makes some degree of sense that a metallic surface would not absorb any diffuse light...

This is correct. A 100% metallic surface should not show up in the diffuse render as it doesn't scatter any diffuse light. All the light it scatters is specular in nature and is thus in the Glossy bakes.

...however, this is internally inconsistent as setting the Metallic value to ANYTHING below 1.0 produces diffuse lighting information in the bake.

I don't believe this is wrong. When the Metallic slider in the principled BSDF is set to anything below 1.0, then the material is treated as a metal/non-metal hybrid. And the non-metal part contains diffuse information and the metal part contains specular information. So what you're seeing in the diffuse bake is the "diffuse contribution" of the non-metal part of the hybrid material.

Metallic surfaces of varying degrees in real life show lighting and shadows on them. Blender appears to work the same way--except for this 1.0 metallic case, which ends up seeming like a bug.

100% Metallic surfaces will show shadows when baked. They just don't include shadows in the diffuse bake as the material is entirely specular in nature. And thus only shows up in the Glossy bake.

99.99% metallic bakes diffuse lighting but 100.0% bakes NO diffuse lighting. How was that threshold decided? There must be a more scientific, physically-based approach that might make more sense.

See my comments above about how <100% metallic materials are metal/non-metal hybrids. And metals are entirely specular in nature and non-metals (in this context) are diffuse in nature.


One thing you might be wondering is "Why is it that when I set the metallic slider to 0.99 that the diffuse contribution of the material is so prominent in the bake when it only makes up a very small fraction of the material's appearance?"

This happens due to the bake settings you have chosen. When picking your bake settings for diffuse, you get three options. Direct, Indirect, and Colour.
Each of these passes are combined together like this: Final output = (Direct + Indirect) x Colour
When a material has it's metallic slider set below 1, then the Direct and Indirect passes will always be the same. What changes when you change the metallic slider value is the Colour output. When the Metallic slider is set to 0.99, then the Colour output will be really dim, and thus as a result also make the diffuse bake really dim (making it roughly 1% the brightness of the material as most of the light the material is reflecting is in the specular part). When the Metallic slider is set to 0.0, then the Colour output will be really bright.
In your .blend file, you have the Colour pass disabled. And as such you don't observe this aspect.

Based on this logic, it could be argued that when a Metallic slider is set to 1.0, then the Direct and Indirect passes should continue to render the same way as they did when below 1.0. But the Colour pass should be set to 0. But as far as I can tell this isn't done because there is literally no diffuse component in the material for Cycles to work with when rendering the Direct and Indirect passes as the material is entirely specular in nature. And thus as an optimization(?) a fake diffuse component of a fully specular material isn't rendered by Cycles and thus the material appears black in diffuse bake passes.

I personally don't believe this is a bug, but I would like confirmation from someone more closely related to Cycles development. @brecht would you mind looking at this? --- > When attempting to use the Bake function to render Diffuse on Metallic surfaces, setting the surface to be 100% Metallic causes the render bake to turn out completely black on those surfaces. > It makes some degree of sense that a metallic surface would not absorb any diffuse light... This is correct. A 100% metallic surface should not show up in the diffuse render as it doesn't scatter any diffuse light. All the light it scatters is specular in nature and is thus in the `Glossy` bakes. >...however, this is internally inconsistent as setting the Metallic value to ANYTHING below 1.0 produces diffuse lighting information in the bake. I don't believe this is wrong. When the `Metallic` slider in the principled BSDF is set to anything below 1.0, then the material is treated as a metal/non-metal hybrid. And the non-metal part contains diffuse information and the metal part contains specular information. So what you're seeing in the diffuse bake is the "diffuse contribution" of the non-metal part of the hybrid material. > Metallic surfaces of varying degrees in real life show lighting and shadows on them. Blender appears to work the same way--except for this 1.0 metallic case, which ends up seeming like a bug. 100% Metallic surfaces will show shadows when baked. They just don't include shadows in the diffuse bake as the material is entirely specular in nature. And thus only shows up in the `Glossy` bake. > 99.99% metallic bakes diffuse lighting but 100.0% bakes NO diffuse lighting. How was that threshold decided? There must be a more scientific, physically-based approach that might make more sense. See my comments above about how <100% metallic materials are metal/non-metal hybrids. And metals are entirely specular in nature and non-metals (in this context) are diffuse in nature. --- One thing you might be wondering is "*Why is it that when I set the metallic slider to 0.99 that the diffuse contribution of the material is so prominent in the bake when it only makes up a very small fraction of the material's appearance?*" This happens due to the bake settings you have chosen. When picking your bake settings for diffuse, you get three options. `Direct`, `Indirect`, and `Colour`. Each of these passes are combined together like this: `Final output = (Direct + Indirect) x Colour` When a material has it's metallic slider set below 1, then the `Direct` and `Indirect` passes will always be the same. What changes when you change the metallic slider value is the `Colour` output. When the `Metallic` slider is set to 0.99, then the `Colour` output will be really dim, and thus as a result also make the diffuse bake really dim (making it roughly 1% the brightness of the material as most of the light the material is reflecting is in the specular part). When the `Metallic` slider is set to 0.0, then the `Colour` output will be really bright. In your .blend file, you have the `Colour` pass disabled. And as such you don't observe this aspect. Based on this logic, it could be argued that when a `Metallic` slider is set to 1.0, then the `Direct` and `Indirect` passes should continue to render the same way as they did when below 1.0. But the `Colour` pass should be set to 0. But as far as I can tell this isn't done because there is literally no diffuse component in the material for Cycles to work with when rendering the `Direct` and `Indirect` passes as the material is entirely specular in nature. And thus as an optimization(?) a fake diffuse component of a fully specular material isn't rendered by Cycles and thus the material appears black in diffuse bake passes.
Author

Thank you for explaining how it works under the hood, so to speak. That helps me understand it better.

I think the way it works makes sense from that perspective, but from an artist's point of view, it's somewhat confusing. As you pointed out, there's nothing explicitly telling me that switching to a metallic material will affect the Color output. It also feels arbitrary that 0-0.99 will have discernible shadows whereas 1.0 will produce NO shadows whatsoever.

I think artists tend to think of a light baking operation as something that will produce light and shadow information on a texture, regardless (well, maybe not completely regardless) of what material is chosen. That way, if I decide later to change the metal to concrete, the light/shadow info is still there. Having to settle on a final material before light baking can be quite limiting in terms of workflow since it would require rebaking things just to accommodate a material change. In real life, if there are shadows being cast onto my kitchen floor, those shadows remain regardless of the floor being granite or wood or aluminum. Even a shadow cast onto a fully reflective mirror would show a visible difference between the shaded and non-shaded part. The shadow, while not a 'thing' on its own, is still the absence of light. But in Blender, a solid cube will not cast a shadow onto a 100% metallic surface. It makes it seem as though metal things simply cannot have shadows on them. It may not be an actual bug, but I'm pretty sure people will continue to report it as long as it works that way.

Regardless, I really appreciate your time and attention in explaining it.

Thank you for explaining how it works under the hood, so to speak. That helps me understand it better. I think the way it works makes sense from that perspective, but from an artist's point of view, it's somewhat confusing. As you pointed out, there's nothing explicitly telling me that switching to a metallic material will affect the Color output. It also feels arbitrary that **0-0.99** will have discernible shadows whereas **1.0** will produce NO shadows whatsoever. I think artists tend to think of a light baking operation as something that will produce light and shadow information on a texture, regardless (well, maybe not completely regardless) of what material is chosen. That way, if I decide later to change the metal to concrete, the light/shadow info is still there. Having to settle on a final material before light baking can be quite limiting in terms of workflow since it would require rebaking things just to accommodate a material change. In real life, if there are shadows being cast onto my kitchen floor, those shadows remain regardless of the floor being granite or wood or aluminum. Even a shadow cast onto a fully reflective mirror would show a visible difference between the shaded and non-shaded part. The shadow, while not a 'thing' on its own, is still the absence of light. But in Blender, a solid cube will not cast a shadow onto a 100% metallic surface. It makes it seem as though metal things simply cannot have shadows on them. It may not be an actual bug, but I'm pretty sure people will continue to report it as long as it works that way. Regardless, I really appreciate your time and attention in explaining it.
Member

Added subscriber: @lichtwerk

Added subscriber: @lichtwerk
Member

Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'

Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'
Member

In #95973#1312310, @Alaska wrote:
I personally don't believe this is a bug, but I would like confirmation from someone more closely related to Cycles development. @brecht would you mind looking at this?

If you feel that way, please set status to Needs Information from Developers

> In #95973#1312310, @Alaska wrote: > I personally don't believe this is a bug, but I would like confirmation from someone more closely related to Cycles development. @brecht would you mind looking at this? If you feel that way, please set status to `Needs Information from Developers`

Changed status from 'Needs Developer To Reproduce' to: 'Archived'

Changed status from 'Needs Developer To Reproduce' to: 'Archived'

This is indeed a known limitation for now, not considered a bug.

This is indeed a known limitation for now, not considered a bug.

Added subscribers: @tiles, @mano-wii, @PratikPB2123

Added subscribers: @tiles, @mano-wii, @PratikPB2123
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#95973
No description provided.