There is a LOT of pink in that Lumen scene, and according to @ s post here, that should tell you, that those scenes are not built properly to be supported by Lumen:
You might want read Yaekos advice about how to do it better, his scenes seem to work pretty well:
I know meshes are not correct
Question is why they work well in early access ?
Why early access handle this complex meshes ?
No clue, maybe you just got lucky, that it still worked, despite being built i a way, that Lumen cannot handle.
I guess, instead of trying to figure out, what kind of feature or bug still allowed those renders to look good, it´s time for all of us to build the meshes in the Lumen Way, starting with splitting and separating your walls, floor and ceiling.
I’m not sure actually. We did change the surface cache generation method completely since Early Access. In all tests it was an improvement. We’ll continue developing the automatic surface cache generation, but for 5.0 we can no longer change it.
Try setting MaxLumenMeshCards to 36 on that mesh that’s not getting any coverage.
Thank you everyone for all of your bug reports.
The window for fixing visual issues for 5.0 has now closed so there’s no more time pressure on figuring things out.
Thanks in particular to GKan, Yaeko and for taking the time to push Lumen and show us where it fails. We made some last second improvements to foliage, lights near surfaces and hit lighting as a result.
We can still fix crashes for 5.0, and we’ll still be watching out for any issues you report but that development will be toward 5.1.
Thank you @ for being so attentive to the reports! Is it possible to know if there will be a Preview 2 with the fixes mentioned in this thread (e.g. foliage)?
In fact, my Scene works so well that there isnt a single pink surface, despite being far more complex than the archviz stuff (Surface cache view):
@ glad I could help, Lumen is an awesome feature after all and I am really thankful that we now have access to it. And I am confident that the few remaining “shortcomings” will be sorted out in the future.
Thank you for being so open with the issues etc.
I too would say that, especially performance when loading maps etc. improved dramatically.
I just want to add that I wish more features / threads looked like this one, if other teams would/could be as transparent as you @, the ecosystem on the forums would thrive. +1 for how it was handled!
Ray Traced Translucency doesn’t yet work together with Lumen GI, so you’ll get unshadowed skylight. That’s something we hope to improve, but it will be a long way out.
These comments are also so so so much better than the usual silence other features/requests/issues get. We know that you’re aware of the issue, want to fix it, but no promises because it’s complex / you have other priorities / etc. Perfectly understandable!
Even though I’m not an artist and doesn’t really have interest in Lumen, I’m glad to see that communication from teams can be done right! 
Hi
I want to explain that this case [Black Ceiling] or [No Ceiling Light] was always in Early Access
This Black Ceiling is always created when I add SkyLight
But once I saved it, everything will be fine and the ceiling will light up
This does not happen after saving in Preview 1 !!!
Save no effect in Preview 1 !!!
Please watch this video and see what a positive effect saving has on Early Access
That is actually the way it should work, when “it works”, its a bug. (I also cant replicate this in the project.)
The Sky Light lights the floor, and the walls, from above - therefore you only get reflected light at the ceiling. More precisely: reflected light that bounced back from the floor. (PS: the 50 for your skylight is completely overkill 
(I think mine is at .1 - but that depends on your exposure settings.)
Sky Light only:
Sky Light + Sun:
Sky Light + Sun + “Fake Light Actor”*:
*That “Fake Light” is a 2nd Sun that doesnt cast shadows and lights straight up, it is needed due to Lumen having issues “lighting upwards” from what I can tell - at least compared to reality.
While Lumen is awesome, it still needs some “help”, which I previously described as “some faking required” to get a good result.**
Low light situations are also troublesome for lumen… I had to come up with a dozen new lights/lamps for my game to deal with that. In fact, the only reason I still have a sky light enabled when Lumen is enabled, is its inaccuracy in dark scenes/areas, thats where the sky light “covers” that.
**This isnt explained anywhere, and it is project-specific. While you will have a relatively easy time lighting up a single room in archviz, dealing with large and complex game-interior that has multiple layers vertically is troublesome. It took me quite some time and experimenting until I got lumen “dialed in” on my specific game with its very specific needs due to the gameplay - just enabling Lumen wont get you anywhere, thats the reality.
I am even lucky, my game has a 2:1 scale for general architecture, therefore I get away with things that wont even work for other games, lumen simply lacks the precision (in software mode) for a lot of the things I do on smaller scale, and even then, sometimes I have to make something slightly larger to still get the visuals I want when the viewport is further away.
Back to that sun temple project… getting the roof lit up at reasonable light settings will be an issue with lumen, at least without faking. (Unless someone has a magic solution that I am unaware of after almost 9? months of Lumen usage now.)
EDIT: That said: I am by no means an Expert when it comes to Lumen, I am just confident in the results I achieved to get with my workarounds.
Thanks for the report Arkiras. You should check out 5.0 build, as now this behavior is improved and you should be able to place lights very close to the geometry.
I’m amazed at the work the team has done on Lumen and willingness to respond to feedback directly, I definitely hope we can have more threads like this in the future for other features of Unreal so problems can be sussed out. I have a more general question as to where hardware ray tracing stands within Lumen, since most discussions and showcases up until this point have focuses on the software tracing. Previously there were drawbacks to using it for large Nanite worlds when compared with SDFs like number of mesh instances recommended, with full support now for hardware ray tracing GI, and large worlds mentioned, does this imply it should work well in any scenario software tracing does or is it still less flexible in scope?
Just built and tested it, issue seems to be completely resolved! REALLY happy you got this in for 5.0, it was the main source of lighting instability in my scenes 
We added an optimization which checks if a surface point of a mesh sees over 20% of back faces around it. If yes, then we assume that that surface is inside mesh and doesn’t need any surface cache coverage. Your ceilings are modeled as a single mesh with three one-sided ceilings inside it. Making a mesh per ceiling or making ceilings have closed geometry would fix it.
I have an odd issue with Lumen showing serious light bleed when not using Raytraced shadows and I am sure will be able to be fixed by a cvar or something, I just cannot find the setting.
The situation is that if I run the map with Raytraced shadows on (RTX3090) Lumen completely blacks out the room except for the single point light in the middle of the room.
If I turn off Raytraced shadows in Project Settings (or run the same map on our 1080Ti test machine) then you can see a really odd “light bleed” as you move away from the walls.
If I move close the shadows are working as expected and nice and black all the way to the edges in both raytraced and non-raytraced lumen.
I have included some screenshots to show both the raytraced and non-raytraced scenene.
Exacltly same map, nothing changed, just turning off Raytraced Shaodows.
Obviously we would like to have people with non-RTX cards get nice lighting as well so I am hoping it is just a cvar we are missing (I think this will be related to distance field settings but I am not sure)
Thanks for any advice anyone can give
NOTE: This is in UE5-Preview and fresh project with default lumen settings except I have enabled hardware raytracing in project settings.
The map is also deliberatly simple and the room is 32m across. (and empy except for the point light) - oh yeah, floor, walls and ceiling are all modular pieces with 10cm thickness.
Raytracing on:
Raytracing off:
Lights in scene:
Unlit so you can see what the room looks like:
Than you for reply
but the problem in preview is beyond meshes
sun temple ceiling in early access
Lumen scene
===========================================================================
sun temple ceiling in preview
Lumen scene
Lumen is broken in 5.0
I Hope we see better Lumen in 5.1
I Need Keep working with Early Access until 5.1 arrive
Lumen is not broken in 5.0, that particular Demo is.
I couldnt get Lumen to work there either, while I have it working for almost 9 months now in a bunch of other Projects.
In fact, it is so broken int hat project that even the Lumen visualization doesnt work…
PS: Yes, i turned it on in the project settings, the post process volume, built the mesh distance fields, no static lighting, sun is movable etc… no idea why it isnt working.
Just use something else to play with lumen, but not that Sun Temple demo (or its spatial audio copy).
Because its the only project I cant get to work with Lumen, so its likely something project-specific.
At some point, by accident, we had working GI from Subsurface Surfaces… now its gone again - I dont see “worked in EA1/2” as something that means it should still work now, things changed since then.
I will now investigate if I can get the assets to work by moving them into another project… and if other 4.26 → 5.0 projects work fine, if so… then its most likely something with that 8 year old project.
@ see, it works fine if it is imported into another project:
It seems to be something with that project…
but as expected, Lumen doesnt like that scene, it goes funky on it, in fact is completely unstable.:
MDFs etc. are fine though.
EDIT:
That reminds me of an issue that existed for projects taken from EA1 to EA2, where lumen outright refused to work…
EDIT2: Lumen seems to rely on screen traces for 100% of the GI there… weird.
EDIT3: Yes, something definitely is broken there, compared to my game where lumen is rock-solid in terms of “retaining its data”.
Comparison:
Yes, allthough I forgot to show, Sun Temple has MDFs in place.
@ I think there is a bug somewhere, which is in every project besides my game, even in the TreeDemo i made for you, which shows the same reliance on Screen traces (or loss of data), while my game (with the same settings) doesnt?
That should also mean: anything that isnt “my game” wont work properly with lumen? (I mean, technically… fine for me, but that will undoubtedly cause complaints when 5.0 goes public.)
As you can see above, in the video, the other projects “stability” in terms of Lumen is nonexistant in comparison, while my game doesnt suffer from this.
The problem is, I dont know what the “workaround” is, my game always worked and it too comes from 4.26 → EA2 → several Github builds → PV1 - it always worked, but for some reason I cant replicate the “it just works” for other projects now?
EDIT4:
Believe it or not, if I drop the Sun Temple into my game, it just works (of course, I removed the sky, ppvs, sun etc. since I have my own.):
Idk… I think we have an issue here?
Lumen only behaves the way it should in my game? weird.
Just for some more clarification: Only the pink surfaces will be ignored?
After some playing, it seems, that simple crosses are fine, L-profiles and U-profiles most of the time too. Even simple cut outs. But beyond that the risk of not working anymore seems to rise drastically (like H-profile).
Some Test meshes, to find out, what works and what will cause trouble. One area was constantly pink, another one didn´t work properly for reflections.
Yep, an H-profile doesn´t work properly.
