@thomasaull, I have been looking into the issue today and have not been able to reproduce your results. Would you be willing to share with me your settings in cmftStudio for computing your radiance map so that I know I am debugging the issue you are seeing? Can you also confirm with me that you are using cmftStudio v1.1? Thanks for your help!
And then I save the Radiance map as .dds, Cubemap, RGBA16F
Did you try reproducing with the sandbox and the .dds environment I provided? I gave it a try on a colleagues computer and it looked even more interesting:
@thomasaull, I have been digging into what’s going on with your files and wanted to give you an update. Originally, I was not able to repro your issue because I was tonemapping the skybox, and that was correcting the issue. What is happening is similar to the blog post we just wrote where there are several pixels in the image that are very bright. In this case, there are maybe 9 pixels in the center of the sun that have values that are problematic for spherical harmonics.
If you are able to set a view mode to compressed highlights for HDR tonemapping, and it has to be a view mode so the values of the pixels aren’t changed, you can see where you need to make some edits:
When I pull the extreme pixels down to something more workable for spherical harmonics, in this case changing the exposure by -6.5 just for the pixels over 100,000 the issues are corrected.
There is still something that we need to fix as the baked environment from cmftStudio, when dealing with extreme values, is returning data that is making our harmonics calculations fail. @sebavan is looking into what we can do to gracefully fall back when in these cases. However, I did note that cmftStudio is having some problems when dealing with 22EV HDR files as the calculations are taking maybe 15-20 minutes to bake the radiance while baking the HDR that is clamped manually takes less than two and produces a correct result.
The other thing I am seeing in the way that cmftStudio calculates roughness versus what we have targeted, which is a perceptual roughness model that renderers like Arnold produce is that the falloff of roughness using cmftStudio’s radiance calculations is too slow.
You can see in the top render that when a material is at a roughness of 1.0, the cmftStudio Blinn BRDF has too much definition in the reflection and you can still see a clear horizon line. When a material is this rough, all of the reflections should be very broad and there should be no definition in the reflected environment at all. You will want to experiment more with the lighting models, but none of them are physically based so you may not find the right answer. If you aren’t on a Mac (cmftStudio is the only cross platform environment tool) you may want to try IBLBaker (free from GitHub) or Lys (paid with a free trial). We use Lys for our work as we are able to match the lighting model with what we expect in Babylon.
Let me know if you have more questions and I’ll report back with how we handle an unclamped environment coming from cmftStudio.
Damn, that’s some enterprise level technical support right there. I’m not affected by this issue, and don’t pretend to understand half of it, but it’s a joy to read this thread regardless. If I was in the same hemisphere I’d buy you a beer … or 10.
@PatrickRyan I’m late with my answer, but I just want to say a big thank you to you! I really appreciate your detailed explanations, not only did you resolve/explain the problem and a possible solution, but additionally you provided some hints for a better rendering result. Thank you!
I actually got a Windows Machine a couple of days ago, I’m going to give Lys/IBLBaker a try.
One quick follow up question: Is there any easy way to inspect the spherical harmonics babylonjs uses?
