I’d assume the sphere is being captured by the skylight?
Emissive surfaces will still be picked up by screen traces even if distance field lighting is disabled for the mesh, the only way to stop this right now (as far as I know) is by disabling screen traces
r.Lumen.ScreenProbeGather.ScreenTraces 0
No it’s just a flipped sphere no skylight.
Unfortunatly r.Lumen.ScreenProbeGather.ScreenTraces 0 doesn’t work.
Hi all and Epic Team,
Here you are a comparison between Ray Tracing and Lumen. Lumen is showing some artifacts, like GI flickering on the reflected cube, reflection errors when Hit Lighting for Reflections is selected (look at that ‘squary’ white zone near the reflected right cube) like with less quality than Cache, or shadows pixelation near the base of the right cube:
RT:
Lumen Cache:
Lumen Hit:
And a lot of more issues when Hardware Ray Tracing is disabled:
Regards
This probably is a shadowmap problem as Yaeko said. You have 2 ways to fix this. The first one and more cheaper is that u can turn on the old shadow maps instead of the new virtual shadow maps, in case that you want 100% virtual shadow maps, try to convert this mesh to nanite and see if that works. hope it helps
Yeah, I know it’s a VSM issue and not Lumen related but there is no dedicated VSM thread to report issues, therefore posted it here.
@Rawalanche I had already bumped all the settings to max. Of course glossy reflections in real-time is a tough one no doubt.
Hi and Lumen team, Lumen shows great quality but still costs too much gpu time of my game. For large open world games with mostly static meshes and static lights, is there any plan to improve the performance of lumen? The purpose to use Lumen is more about replacing baking. Ignoring the GI of dynamic objects is acceptable for my game.
Oh man… for a single line of code we can bring back raytracing to all our GTX cards.
Please Epic games, bring this feature back to the command line and let us (users) decide if we want to use it or not, it is not harming anyone!
Framerate is not an issue for some of us, since we tend to do offline rendering or experimental projects.
It was working perfectly on the early access build until someone decided to remove it from code.
Newer graphic cards are still hard to come by, and if a line of code fixes it, then why would you prevent us from using it?
We do not want to compile code for every single upcoming build 
I hope a Dev listens to our simple demand and bring it back…
Thank you!
Tired of black ceiling in lumen
works fine in early access but …
.
.
.
.
[exposure in post process is not working]
Hi Lumen Team, congrats on the great engineering!
I have a few questions regarding the DF representation of the scene.
Is it the same code as in UE4?
Is it posible to only use it for large scale ambient occlusion to avoid the performance and memory cost of GI (I’ve noticed that UE5 traces 200m while the UE4 version can only do 15m) ?
Tbh, I have no idea what went wrong with lumen between the github builds I had from shortly before release, and the 5.0.0 release-date.
It is, as if a bunch of things didnt get into the release anymore or broke suddenly.
The most obvious one is the Plants suddenly being “weird” again, while they were “just fine” before release, and then the other things that seemingly are not working properly anymore.
Like… its a tree in direct sunlight, and thats what I get now. (detail tracing fixes this, but detail tracing needs too much performance just for that.)
- guess waiting for 5.1.0 is on the menu now.
I can’t argue with that at all. I tried out the Epic SciFi hallways demo, and it the noise was bad to the point of being profoundly distracting, even after red-lining the settings. I still had room in the performance envelope to make things better, but it appears that lumen reflection quality doesn’t improve past setting it to 8. I understand glossy reflections are one of the hardest surfaces to solve for in real-time (you can’t make any lambertian generalizations, and you still need to denoise unlike perfectly specular surfaces). That being said, I do think lumen will need to get better to truly handle the full range of material roughness values like they promised.
I had the same exact problem, and it’s baffling to me. I can understand them cutting nanite for masked materials (it worked most, but not all of the time for me), but mirror translucency and improved GI on foliage were both promised features for 5.0 and both worked essentially perfectly in my testing with the github build. I’m not part of the dev team and I can’t speak for them, but I truly am confused.
https://github.com/EpicGames/UnrealEngine/commit/b05f55ff97c12605ed84b4b78f0913dc42bfbb8f
maybe it has been reverted in this commit on march 2?
Not sure 
I am amazed by the new features so far! Especially Nanite is going to make my life so much easier.
There is one problem I encountered with Lumen Reflections, though - they start flickering, once an object begins to move. The issue does not occur when using screen space reflections with Lumen:
YouTube link
Hello, thanks for new features.
My feedback about lumen and shadows.
I have some grainy shadow issue like that :
I searched and read about it in forum. As I see, people could not solve this problem especially on whitish areas.
Thanks!
I’m having the exact same issue. It’s been driving me insane… been trying to figure it out for a few days and nothing. I assume it’s a bug, because I never had this issue in the early access and preview from what I can remember. Let me know if you figure it out.
Hi Lumen team (I think I tagged all the right people 
)
I’ve been having a lot of fun playing around with Lumen but I have found a situation where it could perhaps offer some more user options. If that is the right way to phrase it.
Before UE5 came out of preview I was using UE4 with RTXGI and it had an option that I think Lumen could use as well (if it is possible to add it in or not I am not sure). With RTXGI, when a large scale lighting change occurred the saved temporal GI was “reset” as to avoid a slow fade out of light.
To better explain what I mean I recorded a video in my project of the exact situation this feature was useful for. Please see below.
As you can see when I turn off the light things update fine enough, however, when I turn off the light it takes a good second or two for the indirect light to fully be gone (I know the GI with Lumen is gathered over multiple frames, RTXGI behaves the same way). This is with both Lumen scene update speed and Final Gather update speed set to 4, with them set to the default 1 the effect is even more pronounced. With UE4.27 using RTXGI the indirect lighting would be immediately removed when the light was turned off as it was above a threshold for a large lighting change (the threshold value could be set in the DDGI Volume settings). This avoided the issue of the indirect light fading away slowly. I don’t know if this could be added with the way Lumen is programmed, or how exactly it would work with multiple lights (I don’t know if the GI from each light is “stored” as it’s own contribution allowing only specific lights’ GI to be removed), but I was wondering if anything like that could be added.
Thanks for your time and seriously great work with Lumen. It’s super cool to see how distance fields evolved from DFAO/Experimental DFGI to how it works now with Lumen.
EDIT: So um, I actually just found a console command that pretty much solves my issue. Setting r.LumenScene.Radiosity.Temporal to 0 made the bounce lighting update much faster (pretty much instant) and I have not seen any undesirable effects as of yet. Yay!
There’s an update speed setting in the post processing volume as well.
I already have those set to 4 (highest value that works).