To whom it may concern:
Hello. I find that the lumen diffuse indirect varies greately between quality level 2 and 3 when having a static skylight cubemap of HDR (values between 0 to 160) with high resolution (512), which has its peak lighting concentrated in a small aera (a sun). After some research I find out it’s the r.Lumen.ScreenProbeGather.RadianceCache.ProbeResolution [16/32] that causes the problem. Eventually the lower resolution of radiance cache has less chances to hit those few but bright pixels (like sun), which brings overall lower lighting values. I think when radiance cache samples skylight there should be a some kind of mip-map mechanism to correspond the cubemap mip into the cone angle, making skylighting vary lessly. But it turns out nothing has been implemented. Any future plans about it? Or any suggestion about how I could implement it myself?
Below are visualizations of Lumen.ScreenProbeGather.DiffuseIndirect when r.Lumen.ScreenProbeGather.RadianceCache.ProbeResolution is 16 and 32, respectively. You may clearly see the color difference. The last picture is the place where the mip-mapping should be, but cone angle is assigned constant.
Best Regards,
Sicong
[Image Removed]
[Attachment Removed]
The skylight cubemap I am using is attached here.
[Attachment Removed]
Hi,
Sky prefiltering was removed in CL 20979993. Issue with it was that you check visibility with a ray, but integrate over a cone, which can cause extra leaking. Still, you can try to restore that.
In general Lumen won’t work well with sun baked into sky. It’s designed to run on consoles with a relatively low overhead and won’t be able to handle well such a demanding scenario. Ideally sun should be separated into an analytical light source.
[Attachment Removed]
I’ve checked the CL and try to restore the sky prefiltering stuff on radiance cache trace only. Unfortunately the results looks over exposed. I am not sure about the reason behind as I’ve checked the mip levels calculated are roughly matching (mip 3.9 for radiance cache probe res 32 and mip 4.5 for probe res 16 while mip 0 cubemap has res 512).
I think it’s expected that prefiltered version is brighter. World Space Radiance Cache probes trace a very small number of rays uniformly (16x16 or 32x32 in this case) across the entire sphere. There’s a very low chance that a particular probe will hit a small bright spot like sun. And even if it hits, then the firefly filter will cap that energy (r.Lumen.ScreenProbeGather.MaxRayIntensity). If you want to make sure that everything is correct then the simplest way is to put a constant value into the sky env and see whether prefiltering changes anything (it shouldn’t).
I also have tried applying sky visiblity on radiance cache sampling of screen probe gather. It looks good, and maybe the best solution for now. Wonder why it’s not applied to screen probe gather by default? Maybe for performance considerations?
Sky visibility was done as a part of trying to use World Space Radiance Cache to speedup reflections. It allows to sample sky directly making outdoor reflections look better. Using World Space Radiance Cache for reflections didn’t work out amazing, so it’s disabled for now. I was wondering whether there’s any benefit of using it also for GI, but never revisited it.
[Attachment Removed]
Hi Krzysztof,
Glad to hear answer from you personally. I’ve checked the CL and try to restore the sky prefiltering stuff on radiance cache trace only. Unfortunately the results looks over exposed. I am not sure about the reason behind as I’ve checked the mip levels calculated are roughly matching (mip 3.9 for radiance cache probe res 32 and mip 4.5 for probe res 16 while mip 0 cubemap has res 512).
I also have tried applying sky visiblity on radiance cache sampling of screen probe gather. It looks good, and maybe the best solution for now. Wonder why it’s not applied to screen probe gather by default? Maybe for performance considerations?
Below are the comparisons:
[Image Removed]
[Attachment Removed]
Typo: In the image the description of first row should be “No Prefiltered Cubemap”
[Attachment Removed]
Get it. So prefiltering does give the more theoretically correct sky lighting (negelecting the cone occlusion). But I’m afriad our light artists won’t be happy about prefiltering -- they need to redo all the lightings given such large difference in skylight brightness.
Applying sky visibility to screen probe tracings, on the other hand, does solve my problem here. It does make skylight more uniform between different world space radiance cache resolutions, without introducing any extra brightness. Since there seems no other side effects (which was what I worried about), the little performance cost is acceptable.
Here is another in-game comparision. Note how skylight gets dimmer as radiance cache probes gets far away from camera when with neither sky visibility nor prefiltering.
[Image Removed]
[Attachment Removed]
I think the case is solved, and you may mark it answered or close it or whatever, if you’d like. Thanks for your patient answers.
BTW if you have any spare time could you please take a quick check at another question: [Lumen Global Distance Field Trace Leaking due to Surface Cache [Content removed] here? I think you may provide with some useful insights.
[Attachment Removed]