If I’m not mistaken, this is actually how nanite tesselation handles masked materials. It just simply deletes the polygons outside the mask. It works because it is basically at a per pixel level of detail.
Hi @Krzysztof.N ,
I pulled UE5.6.1, unfortunately the same issue is present, lumen does not seem to function properly with panoramic renders. Any chance you guys could investigate this issue?
Edit: It seems like the above problem happens when trying to render a panoramic image with lumen with a camera that has Auto Exposure enabled. If I set it to Manual exposure, it works as expected. Not sure if this is a bug or not, but I leave it here in case someone else runs into the same issue in the future.
Edit 2: After doing some more tests, it seems like this issue came in in 5.6. In 5.5, we could render a panoramic image even with auto exposure. So indeed, it is definitely a bug.
1 Like
Could you share some pictures? Thanks.
If the question was for me, here they are.
Auto exposure regular rendering and panoramic rendering:
Manual exposure regular rendering and panoramic rendering:
1 Like
Updated a project test to Unreal 5.6.1
Raytraced Refractions seems to be broken
1 Like
When I enable Ray Traced refraction. Lumen and Gi stop working inside glass objects.
for example: if you have glass jar filled with non-translucent objects like cookies. these will be dark like lumen didn’t affect at all. seems like only gets the light which leaks though glass and most of it blocked by glass after i enabled ray traced refraction.
Anyone able to tell me why my surface cache quality is absolutely horrid in 5.6.1?
For reference, here is 5.5.4:
Only an issue in areas with relatively low light, in this example the room is lit primarily by the skylight coming through the hole in the top left, this is a 10 lux directional light with an otherwise default skylight/skyatmosphere
this looks like your gpu driver is internally allocating the wrong buffer format. perhaps tryna conserve video memory. the colors look like R4G4B4A4. that’s all the knowledge i got there.
Dang you’re good. Updated my drivers and the issue is gone. Thanks man!
I’m dumb, launched the 5.5 project by mistake to check 
Issue is still present 
Your reply did give me an idea though and I tried switching the lighting format from R11G11B10 to Float16 RGBA and the issue disappears
Not sure how this could fix it, as I don’t think we use Float11 for surface cache. Maybe you switched from Float16 to Float32?
In that case likely the real culprit is r.Lumen.CachedLightingPreExposure. Try setting that to 0 to get 5.5 behavior.
Nope, r.Lumen.LightingDataFormat was set to 0 (R11G11B10) according to the cvar description, and switching to either 1 (float16) or 2 (float32) fixed it.
This indeed solves it! Is there any downside to leaving it at 0? I imagine you must have changed it for a reason
You can read more about in the CVar description, but it basically sets expected lighting range. New default is great for physically based values, which tend to be really bright (exposed around 0-16 EV).
And a downside increasing the lighting data format?
I have to ask, how are you guys able to work with realistic directional light intensities specifically? When using a 120k directional light I get extremely patchy indirect lighting in interiors, it’s especially bad with a moving directional light.
i gotta ask why are you using a directional light (sun light) in those kinda burried interiors? this doesn’t make sense. ofc culling and stuff will not make this work. the shadow casters will cull and it will bleed light and shadows and all. this seems like a graphics programmer logic issue to me. sry.
Because there’s an exterior? This is not the entire scene… Are we not supposed to have directional lights in scenes that have interior areas…?
well… if you do interiors in sun light you better have thick walls or ground to cast the shadows and gi occlusion from the sun light. i’ve done a minor test for thekj for his rtxgi based complaint. i don’t remember the numbers exactly but the lumen world space grid has very limits, before it starts to bleed light thru. i tested all the probe visualizers. with angled geometry and all. yep.
That’s great and all but this is a non-issue for me because these problems mostly go away if I just lower the intensity of the directional light, which is why I asked Krzysztof how Epic manages these issues without that.
My walls are a meter thick in the thinnest sections. If the answer (which I highly doubt) is that they need to be 2+ meters then I think I’d rather just lower the directional light intensity.
well… a meter should be good enough. in certain cases the probes will still leak a lil bit.
you know… angled surfaces do not line up with the lumen probe grid and they can leak some iight into interiors.
not a big deal tho. itsagame
This should not matter. If the entire system hinges on the spacing of the world space radiance cache then there would be no point bothering with screen probes or traces. You’re also looking at the distant lower resolution clipmaps of the radiance cache where as I am literally inside the room…
Anyway, I discovered that the light leaking is specifically caused by hardware raytracing. I suspect it may be due to how I built out the level geometry but I am not sure. Will need to do further testing.
1 Like