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

New Issue

Jim Conrad · 2022-02-23T00:12:25+01:00

Jim Conrad commented

2022-02-23 00:12:25 +01:00

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)

Jim Conrad commented

2022-02-23 00:12:25 +01:00

Added subscriber: @JCo

blender-admin commented

2022-02-23 00:12:25 +01:00

#98880 was marked as duplicate of this issue

Conor Woodard commented

2022-02-23 00:24:44 +01:00

Added subscriber: @ConorW

Alaska commented

2022-02-23 04:30:31 +01:00

Added subscribers: @brecht, @Alaska

Alaska commented

2022-02-23 04:30:31 +01:00

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.

Jim Conrad commented

2022-02-23 05:12:46 +01:00

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.

Philipp Oeser commented

2022-02-23 10:47:39 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2022-02-23 10:47:39 +01:00

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

Philipp Oeser commented

2022-02-23 10:47:39 +01:00

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`

Brecht Van Lommel commented

2022-02-23 18:17:13 +01:00

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

Brecht Van Lommel closed this issue

2022-02-23 18:17:13 +01:00

Brecht Van Lommel commented

2022-02-23 18:17:13 +01:00

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