Lumen GI and Reflections feedback thread

Hi, I have a wired lumen reflection problem

as this picture, the SM_TVStand use a reflective material, and it should not reflected the cloud in the red arrow position, all the reflection of the outter view should come from the window! Does anybody encountered this?

this is the setting i’m using in this scene @Daniel_Wright

This is interesting, and somewhat strange. The first things I’d suggest would be to disable screen traces and then assess your scene, view-dependant lighting can make things hard to debug. Beyond that, are you using software or hardware ray-tracing? Software ray-tracing requires a minimum surface thickness of 10cm in order to render consistently into lumen , so you may be looking at light-leaking from that.

Any idea how to get rid of these shadows? I’ve narrowed it down to being related to r.Lumen.ScreenProbeGather.RadianceCache. When I turn that cvar off it disappears (although it’s very noisy when I turn it off) It also seems to be connected to the skylight and/or hdri’s. When I use rect lights without any skylight or hdri the probe shadows aren’t present. I don’t mind turning off the cvar but I’m not sure how inner connected it is to lumen and if I’m going to be losing out on quality somewhere by disabling it. I do cinematics so performance isn’t as much of an issue. Any idea’s would be great.

This issue also is brightness-related.

As is clearly visible here, it becomes more visible in less bright areas (to the right):

No idea what it si though, but I think it is just lumens lighting-grid that affects the world.

Yeah Brightness/Exposure just makes it more noticeable. Even if I crank up the brightness or exposure the shadows are still there. I read the docs on lumen and from what I gather it’s related to the screen probes for World Radiance Cache which are used for distant lighting. It seems the spaces between the probes are causing the shadows. Completely goes away If I’m not using a skylight/hdri. I just don’t know if it’s possible to fix this or if it’s just something you have to deal with.

My solution/workaround is to have some light sources there, which will hide the effect very well. (And in my case, thse light sources also are decorative, win/win situation.)

This issue probably affects “flat/simple” surfaces way more than others, since anything with an actual texture would cover up these patterns pretty well - sand/rocks etc. for example.)

In general, low-light scenes and “simple surfaces” arent the best combination for Lumen, at least from what I figured out the last year.

1 Like

Lumen definitely has some interesting (hidden) requirements. Working best on opaque, rough, textured geometry. Their screen probe-world probe system is very powerful, relatively scalable, but also important, and I’m excited to hear they’re planning on adding ‘hit lighting’ options for many more aspects of lumen: multi-bounce GI without the lumen scene radiosity, multi-bounce reflections, and perhaps even improved translucency. At least the tech is more scalable than many alternatives.

1 Like

Hey guys. is it possible to turn on lumen reflections without global illumination?

Yes, actually, but I believe you need to do a few things before hand:

On all of your lights, set your Indirect Intensity to 0.
On every mesh you have, toggle Affect Dynamic Indirect Lighting off.
Lastly, set r.Lumen.ScreenProbeGather.ScreenTraces 0.

Hey, I wanted to share some findings of what I think is a limitation.

If someone actually know what is happening I would appreciate any feedback.

Ray Traced Translucency seems to behave differently in 5.0.2 and 5.0.1
What is unexpected is that it is way more broken in 5.0.2

^ here we see a groom on the car and a Niagara Fluids system. This is in engine version 5.0.1

  • Raytracing translucency is on

^ Here is exactly the same scene in 5.0.2

  • Raytracing translucency is also on.

This behaviour persists in other cases. If I have any fog material behind the translucent object it renders as opaque. If a fog material intersects the Translucent object it cuts it like below

I am pretty sure this isn’t new behaviour. However it seems to be behaving better in a previous version. Has this happened to anyone?
Anyone knows a workaround (while using raytraced refractions)?
Does anyone know if it’s in their plans to improve on raytraced translucency soon?


While I’d need to know more about the fog material in question (blend mode, shading model, etc) to understand the particular behavior, my understanding of the RT pipeline (RTGI, RT reflections, RT translucency) is that they’re not in any further development, and lumen will take precedence. So while more features of RT translucency will probably be rolled into Lumen, I’d doubt if the standalone feature would receive more support.

By the way, have you changed your DOF mode or settings? DOF makes transparency sorting and blending decently strange, even on the newest features. Furthermore, UE5 got support for order-independent transparency, which may solve what looks to be your sorting problem, if you can take the hit to perf.

I have tried with different materials. From a simple translucent material to a more complex volume fog.
i have messed with per vertex translucency, sorting priorities (when availeable) and many other settings. Results are the same. Anything that uses transparency is broken while rt translucency (with refraction) is on. Even a default niagara fluids gas emitter appears all black.
I have noticed these problems begore and you even helped me back then if im not mistaken. I wrote because I found it weird that it is working decently in 5.0.1 but completly broken in 5.0.2.

But I haven’t knowingly altered DOF in the project other than setting quality to max.
This is for rendering in MRQ so I can do whatever achieves best quality. What can I do about DOF.

I appreciate the help

I thought I did, and I even went to check, but I thought the post I found had a different username, my mistake.

Have you found the hotfix list for 5.0.2? I’ve been trying to dig it up but haven’t been able to find it. There may be some explaination there, potentially.

If it’s MRQ rendering, I’d honestly just go with the path-tracer if you can afford it, the denoiser lowers the sample count to something generally easier to swallow. In the PPvolume, path tracing has a ‘high-quality DOF’ toggle that makes the path-tracer actually simulate DOF instead of adding it as a post-process. I used that method and it solved some strange sorting issues for me in a test.

I hope your project goes well by the way, it still looks extremely interesting and the groom on the vehicle is fabulously inspired. Given the combination of multilayer hair and translucency, I definitely think it’s good you’re working with MRQ, for anti-aliasing if nothing else.