<p>The problem is in the diffuse term, which can be seen by making the specular portion of IBL not be added into the result.  The diffuse only render will not have the darkening, and of course, the specular can't make the diffuse darker. (Note, fresnel vs no fresnel is not the issue here).</p>

<p>The core problem is that lambertian diffuse is being used, which is view independent. There are other view independent diffuse terms which give results closer to the ground truth.</p>

<p>Two example diffuse terms are Burley (Disney) and Oren-Nayar.</p>

<p>Burley is talked about here: <a href="https://google.github.io/filament/Filament.md.html#toc4.5" rel="nofollow noreferrer">https://google.github.io/filament/Filament.md.html#toc4.5</a></p>

<p>An approach used in Titanfall is described here:
<a href="https://www.gdcvault.com/play/1024478/PBR-Diffuse-Lighting-for-GGX" rel="nofollow noreferrer">https://www.gdcvault.com/play/1024478/PBR-Diffuse-Lighting-for-GGX</a></p>

CC BY-SA 4.0
2018-09-12T20:36:59.207Z
it's actually unclear if this is the whole story, and some thoughts that the path traced version may actually be incorrect. there is a twitter conversation here: https://twitter.com/Atrix256/status/1039943676552568832 .
Alan Wolfe
CC BY-SA 4.0
2018-09-13T11:33:19.803Z
Burley has an entire paper about the Disney Diffuse Model: https://disney-animation.s3.amazonaws.com/library/s2012_pbs_disney_brdf_notes_v2.pdf However, the Disney Diffuse BRDF is not energy conserving. This might not be a problem in the questioners case but should be mentioned.
The Titanfall approach is good, but I want to add a blog post series by Stephen Hill ( https://blog.selfshadow.com/2018/05/13/multi-faceted-part-1/)  which explains a different way to handle this problem
Tare
CC BY-SA 4.0
2018-09-14T14:06:50.730Z
@Alan Wolfe - Although Oren-Nayar may give a closer look to the ground truth, I think the main problem is in fact the Fresnel Issue. Fresnel issue guarantees that at glancing angles, more light reflects, this would mean at glancing angles we have more specular part and very low diffuse part thus giving the black ring. Atleast that's what makes sense to me.
gallickgunner
CC BY-SA 4.0
2018-09-12T18:44:25.757Z
2018-09-12T18:44:25.757Z
Alan Wolfe
<p>This is not related to the edge but in <a href="https://eheitzresearch.wordpress.com/240-2/" rel="nofollow noreferrer">https://eheitzresearch.wordpress.com/240-2/</a> you can clearly see that energy is lost for the microfacet stuff when roughness is increased. The issue is that the rougher the surface is, the more occlusion you get from the shadowing function.</p>

<p>There are a few "hacks" to boost the energy. One can be found in <a href="http://www.cs.cornell.edu/projects/layered-sg14/" rel="nofollow noreferrer">http://www.cs.cornell.edu/projects/layered-sg14/</a> section 5.3. Maybe the rasterized version uses one of these "hacks" and doesn't have that issue.</p>

<p>Also see 5.1 here <a href="https://blog.selfshadow.com/publications/s2015-shading-course/burley/s2015_pbs_disney_bsdf_notes.pdf" rel="nofollow noreferrer">https://blog.selfshadow.com/publications/s2015-shading-course/burley/s2015_pbs_disney_bsdf_notes.pdf</a>.</p>

CC BY-SA 4.0
2018-09-14T18:33:41.757Z
Filament does use energy compensation yes. Its implementation is explained here: https://google.github.io/filament/Filament.md.html#toc4.7.2
Romain Guy
CC BY-SA 4.0
2018-09-12T21:03:11.910Z
2018-09-12T21:03:11.910Z
anders
<p>If you have a dielectric (non metallic) sphere with a large roughness value (say, 0.95), and put it in a lighting environment that has a constant onmidirectional lighting value (such as 0.5) Cook-Torrance ggx PBR renderers seem to be missing a darkening at glancing angles.</p>

<p>I thought this was a bug in my PBR implementation at first when comparing vs a mitsuba ggx render, but I've found the same issue in google filament (<a href="https://github.com/google/filament" rel="noreferrer">https://github.com/google/filament</a>) as well as in substance.</p>

<p>For instance, below is the iray version from substance compared to the opengl version from substance. 0 metalness, 1 roughness, omnidirectional ibl of 0.5, albedo of (1,1,1).</p>

<p><a href="https://i.sstatic.net/jMt7C.png" rel="noreferrer"><img src="https://i.sstatic.net/jMt7C.png" alt="enter image description here"></a></p>

<p>Is this a known limitation of cook-torrance ggx based PBR? Can anyone explain why this limitation is here, and the reason for the difference?</p>

<p>I've noticed that it's much closer to the path traced "ground truth" at lower roughness values (like up to around 0.5-0.75), and that the most commonly interesting roughness values are near the lower end of roughness. 0.5 even looks almost "completely rough" for instance.  Is the issue that the approximations used don't really try to make these less important higher roughness values look correct?</p>

CC BY-SA 4.0
2018-09-12T18:35:10.703Z
it's odd to see that in substance, the IBL color is interpreted different between the path traced and rasterized version, but that's unrelated :P
Alan Wolfe
CC BY-SA 4.0
2018-09-20T12:45:47.277Z
couldn't that be a result of some tonemapping postprocessing step?
ivokabel
CC BY-SA 4.0
2018-09-20T14:04:59.207Z
Nope, it doesn't have anything to do with tone mapping or any other post processing. Verified by doing other furnace tests, and comparing between different renderers which have explicit controls for those things.
Alan Wolfe
CC BY-SA 4.0
2018-09-21T15:18:39.197Z
That's strange.
ivokabel
<lighting><shading><pbr>
PBR missing rim darkening on non metallic rough surfaces
Alan Wolfe
# PBR missing rim darkening on non metallic rough surfaces

(Asked by: username_0 on 2018-09-12)

If you have a dielectric (non metallic) sphere with a large roughness value (say, 0.95), and put it in a lighting environment that has a constant onmidirectional lighting value (such as 0.5) Cook-Torrance ggx PBR renderers seem to be missing a darkening at glancing angles.

I thought this was a bug in my PBR implementation at first when comparing vs a mitsuba ggx render, but I've found the same issue in google filament (<https://github.com/google/filament>) as well as in substance.

For instance, below is the iray version from substance compared to the opengl version from substance. 0 metalness, 1 roughness, omnidirectional ibl of 0.5, albedo of (1,1,1).

[![enter image description here](https://i.sstatic.net/jMt7C.png)](https://i.sstatic.net/jMt7C.png)

Is this a known limitation of cook-torrance ggx based PBR? Can anyone explain why this limitation is here, and the reason for the difference?

I've noticed that it's much closer to the path traced "ground truth" at lower roughness values (like up to around 0.5-0.75), and that the most commonly interesting roughness values are near the lower end of roughness. 0.5 even looks almost "completely rough" for instance. Is the issue that the approximations used don't really try to make these less important higher roughness values look correct?

**Tags:** lighting, shading, pbr

> **Comments:**
> **username_0**: it's odd to see that in substance, the IBL color is interpreted different between the path traced and rasterized version, but that's unrelated :P  
> **username_1**: couldn't that be a result of some tonemapping postprocessing step?  
> **username_0**: Nope, it doesn't have anything to do with tone mapping or any other post processing. Verified by doing other furnace tests, and comparing between different renderers which have explicit controls for those things.  
> **username_1**: That's strange.  

---

## 2 answers

### Answer by username_0 on 2018-09-12. Score: 3

The problem is in the diffuse term, which can be seen by making the specular portion of IBL not be added into the result. The diffuse only render will not have the darkening, and of course, the specular can't make the diffuse darker. (Note, fresnel vs no fresnel is not the issue here).

The core problem is that lambertian diffuse is being used, which is view independent. There are other view independent diffuse terms which give results closer to the ground truth.

Two example diffuse terms are Burley (Disney) and Oren-Nayar.

Burley is talked about here: <https://google.github.io/filament/Filament.md.html#toc4.5>

An approach used in Titanfall is described here:
<https://www.gdcvault.com/play/1024478/PBR-Diffuse-Lighting-for-GGX>

> **Comments:**
> **username_0**: it's actually unclear if this is the whole story, and some thoughts that the path traced version may actually be incorrect. there is a twitter conversation here: https://twitter.com/Atrix256/status/1039943676552568832 .  
> **username_2**: Burley has an entire paper about the Disney Diffuse Model: https://disney-animation.s3.amazonaws.com/library/s2012_pbs_disney_brdf_notes_v2.pdf However, the Disney Diffuse BRDF is not energy conserving. This might not be a problem in the questioners case but should be mentioned. The Titanfall approach is good, but I want to add a blog post series by Stephen Hill ( https://blog.selfshadow.com/2018/05/13/multi-faceted-part-1/)  which explains a different way to handle this problem  
> **username_3**: @username_0 - Although Oren-Nayar may give a closer look to the ground truth, I think the main problem is in fact the Fresnel Issue. Fresnel issue guarantees that at glancing angles, more light reflects, this would mean at glancing angles we have more specular part and very low diffuse part thus giving the black ring. Atleast that's what makes sense to me.  

---

### Answer by username_4 on 2018-09-12. Score: 2

This is not related to the edge but in <https://eheitzresearch.wordpress.com/240-2/> you can clearly see that energy is lost for the microfacet stuff when roughness is increased. The issue is that the rougher the surface is, the more occlusion you get from the shadowing function.

There are a few "hacks" to boost the energy. One can be found in <http://www.cs.cornell.edu/projects/layered-sg14/> section 5.3. Maybe the rasterized version uses one of these "hacks" and doesn't have that issue.

Also see 5.1 here <https://blog.selfshadow.com/publications/s2015-shading-course/burley/s2015_pbs_disney_bsdf_notes.pdf>.

> **Comments:**
> **username_5**: Filament does use energy compensation yes. Its implementation is explained here: https://google.github.io/filament/Filament.md.html#toc4.7.2  

---

