FIXED: PBR Environment Light Seam?

I’m posting what I think to be a bug from win10 / x64 / 2019.20140

If I create an environment map, assign a pbr material to a sphere, and set the metallic to 1(shows seam more clearly), and roughness to 0.8, I get something like this screenshot here.
The seam goes away as roughness approaches 1, and it also goes away at lower roughness values below 0.6.
The HDR image does tile properly, so there’s no seam there between left and right edge.

Below is a simple project folder with TOE that recreates the effect in the screenshot below.
Hdr_Seam_Bug_Download

Hi I have a bit more info on this, I built a small patch that outputs the mip levels of the environment map to buffers, then offsets them by 50%, you can see very clearly the issue at hand.

The left and right edge of the mip levels as they get “blurrier” get more noticeably out of sync with each other. this I’m sure is exacerbated by the fact that the values are 32 bit HDR etc.

I’m not sure if this is helpful, depending on how the specular mips are generated, but this page has some info about cubemap seams, and a way to fix them:
https://learnopengl.com/PBR/IBL/Specular-IBL


Also, there’s a nifty piece of software called CMFT Studio for creating these two maps.
Their method also creates a seam, but they have a checkbox that fixes it, mostly.
https://github.com/dariomanesku/cmftStudio

Here’s a screen shot of their specular IBL mip, somewhere in the middle. You can see the faint edges of the cube map sampling algorithm.
image
This is a lot better than the current seam in TD, but still not quite to the level that Marmoset, Substance and other game engines have.


Another issue with Touch’s IBL generation (might be technically separate , but visually related issue) - are the speckles that are present in the specular reflection IBL’s produce.

Here is a couple examples where it’s very exaggerated, some maps are worse than others, I’ll attach the map that has them very bad.


What’s odd though, is that I don’t directly see these artifacts in the mip levels, though perhaps they are “hidden” in the upper values past 1:


Third question - in CMFT I notice that the diffuse IBL map that is generated looks totally different than in Touch. It has the same format and layout that the specular IBL map has:

In touch though, when I output the IBL diffuse map via a prefilter top, I get a small texture, 9x1 pixels. Nothing at all like the above format.
image

I realize this is intentional, but I am curious why this is so different than the other format? The naive question I have of this difference is, are we losing quality with such a small / low res representation of the diffuse map?


One last thing… this may also be a bug, but I’m not sure - when I drag the pre-filter top containing the diffuse map into the environment light COMP, no dotted grey line appears, and when I insert a level TOP and adjust the values, the diffuse term of the render does not change at all.

I think the diffuse IBL slot is currently broken? or maybe in the backend is still retrieving the diffuse term from the automatic IBL method anyways?


Anyways thank you for your time :slight_smile: didn’t mean for this to turn into an essay, but hope it’s helpful!

Output_MipMaps.3.toe (8.3 KB)
HDRI image featured above in all the screen shots.

1 Like

Thanks for all those details! I’ll try to go through all of this.
The seams are now fixed, I was incorrectly using Hold extend modes for the U direction for equirectangular maps. For cubemaps I’m already using the seamless cubemap feature, but that doens’t come into play with this example.

If you use a TOP to CHOP you can see your source image has a few random pixels that are 20000 or so in value, while most of that bright spot is ~20. The spots you see are when the random algorithm to create the specular mipmap levels are hitting those hot spots. So I think the issue for that is the source material since something that bright is going to cause a bright spot.

For diffuse I use something called spherical harmonics. This is a 27 variable polynomial that is able to represent a sphere of color really well. Those 27 variable values are what are baked into that texture. Most other tools also do this, but some may re-bake this out to a texture by evaluating this equation for every pixels in the target texture. Since calculating the color from the 27 variables is relatively fast, there is no need to actually re-make a texture, we just do it on the fly in the shader.

You are correct, the prefiltered diffuse map isn’t being used at all right now. I’ll fix that.

Hope this helps and thanks again!

2 Likes

Awesome thanks for the detailed info Malcolm! Excited to test out the latest experimental.