Unfortunately AA None in Movie Render Queue is not working correctly with Lumen in 5.0 release.
@ and @Yaeko , can you give me the exact steps you did to reproduce that brokenness in SunTemple? And what video card do you have?
I did:
Download SunTemple from launcher
Open project in 5.0 latest, change Dynamic Global Illumination to Lumen, restart
Add skylight, set Intensity to 10
I don’t see any major artifacts, certainly nothing like either of you are seeing.
Are you on an AMD card by chance? Krzysztof fixed some bugs that affected AMD, but you’d see those artifacts in any project.
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?
When you see very view dependent GI and only Screen traces working, that means there’s something very wrong with Lumen Scene, or a code bug that we need to fix.
Thanks for the reply @ , I tnhought it might have to do with shadowing as I found if I turn off the directional light outside then the issue goes away. (I need the outside light as there will be windows shining light in at some point)
Where you say “making the walls thicker”, how thick is the recommendation. The walls, ceiling and floors are all built with 10cm thickness.
Walls are 400Hx200Wx10D , ceiling and floors are 200Hx200Wx10D.
In addition to this I am already using Virtual Shadow Maps, that is the default with a new project in 5.0Preview.
I am afraid that if I go thicker than 10cm for all parts I am going to run into other assembly issues. I really thought 10cm would be thick enough LOL but maybe for software traced lumen maybe not 
can you give me the exact steps you did to reproduce that brokenness in SunTemple? And what video card do you have?
1: download it from the launcher
2: open it in 4.26 (since its not a 5.0 project. To reduce “conversion issues” I let 4.26 “do its thing” on the project first.)
3: open in 5.0 (conversion in place)
4: do “the usual stuff” to enable lumen (i really couldnt get it to work properly, despite not doing something wrong.)
5: see what I have shown in the video above
Are you on an AMD card by chance? Krzysztof fixed some bugs that affected AMD, but you’d see those artifacts in any project.
Indeed, RX 6900 XT. (given that the consoles run on RDNA2 too, it shouldnt be neglected :P)
The bugs appear in any project, besides my game… no idea what causes “the fix”. (Sun temple though is especially bad.)
Looking back, I dug up a lot of bugs in the last 9 months, some of them very tricky… but what I am seeing now, I have not seen before.
When you see very view dependent GI and only Screen traces working, that means there’s something very wrong with Lumen Scene, or a code bug that we need to fix.
I would argue that its a bug, given that it works perfectly fine in my game, but not as a standalone project. (yes, sun temple works flawless in my game, allthough I didnt show it in the video.)
Lumen Scene also is fine, I checked “the usual culprits” before even considering that it is a bug.
I mean, I can replicate it, and there is video evidence, I am not making that up.
Hi
I am Using Custom SunTemple Version, which [Architectural Section Tool] Using as a demo
Materials are different - Project is DX11 No RayTracing
I removed All SpotLights
Removed Static Lighting Data
Add SkyLight
Set Lighting To Lumen
I ask you to please test with both versions, not just Preview
EarlyAccess Result
=========================================================================
Preview 1 Result
Download Link (Removed BluePrints)
1 Like
Checked the source control history and last AMD fix didn’t make it to the Preview 1 and those artifacts were similar to what I see on screenshots posted here. Can you check if it happens also in Preview 2?
Seems to work fine in PV2 (tested multiple projects, all behave like “my game” now.), so it most likely was one of the AMD-Bugs.
Thanks for fixing, if I see anything else I will drop it in here.
EDIT. PV2 - packaging is broken.
EDIT2: created a topic about it here: Preview 2, "ICU data directory was not discovered" when launching packaged game
Landscape Grass does currently not contribute to GI. I assume, this is because having distance fields for all the Grass instances would be extremely expensive
Suggestions
-
Add an option per Grass Type Mesh to be captured along with the landscape. Basically having the Grass Types on top of the Landscape be “baked”/“combined” with Lumen capturing the landscape. That comes with its own set of issues probably, but would be a nice flexible option to have. Would just be a boolean to expose per each Grass Mesh.
-
Add the option to use Distance Fields for certain Grass Meshes, including a warning that this can quickly get out of hand performance wise. Again, a boolean exposed per Grass Mesh. There’s a few usecases where FoliageTypes don’t cut it (ie mask based procedural placement can only be done with Grass,. FoliageTypes only support Landscape Layer as a filter). So having the option for grass could be quite useful.
I can provide a test project, if necessary 
In Preview 2, no matter what AA i’m using on Movie Render Queue (None, TAA, TSR) , still renders are producing a lot of artifacts. I tested 3 scenes, including architectural templates
Something like lumen GI artifacts
Bloom explodes when using realistic sunlight intensity values for directional lights in Lumen. In this example I used 75k, because that’s what the SunSky actor is set to in the plugin that is bundled with Unreal.
This appears to be specific to Lumen, as I tested the same scene with baked lighting via GPU/CPU Lightmass with normal results:
In the Lumen map, all lights are moveable. Lumen final gather set to 2.
In the Lightmass maps, lights are stationary except skylight which is static and Lumen is disabled via post process.
Everything else is the same.
HDR debug, not sure if this is just another symptom of the issue or the cause but the pre-exposure value is extremely high compared to Lightmass:
1 Like
Another issue I encountered with more realistic sunlight intensity: The probe grid(? voxels? idk) becomes very visible when using high values.
I have tested this in ea2, and there some careful use of exposure and especially the bloom threshold
fixed the brightness. Not tested in preview but try adjusting threshold should help.
edit: also source radius on the sunlight smoothed out some of the rough shadows.
The light complexity viewmode also blows up when using high intensity directional lights, the VS/PS instructions go through the roof. But I think this is just erroneous output on the visualizers part, as this extreme increase in complexity seems to have no impact at all on the performance of the game.
Won’t help in this case, as these are indirect shadows.
may I ask, why you are using 120k lux instead of just adjusting exposure and “not having all of that trouble”?
It really doesnt matter, visually, if a light is 10 or 120k lux if things are set up properly. (afaik, my sun is set to 1.0 and I only adjusted the exposure to get what I wanted.)
Yeah it does; the relative intensity of other lights is way off if you lower the sunlight intensity and no amount of exposure adjustment will remedy that.
No particular reason. I’m not terribly attached to having realistic light intensities and I will happily just use a 10 lux sunlight if that is what is necessary.
I just figured it was worth reporting, especially because anyone who has become reliant onthe SunSky plugin that Epic provides will run into these problems as it has a 75k lux directional light.
3 Likes
The issue from UE5EA is still here regarding sometimes light dissapearing when close to the object in the center of the scene…
Hey,
anyone knows where these weird lighting splotches are coming from? Backwall.
Preview 2 Lumen in hardware mode on a 3090. LumenGI pretty much maxed out (everything set to 5).
Almost everything Nanite, environment solid.
I changed the lumen settings, changed the amount of lumen mesh cards, changed the lighting but the splotches look the same. Not even switching to software Lumen changed much about the result.
Pathtracer:
Lumen:
Update:
I can change the result by blocking the window on the other side of the room:
That means some lumen required representation isn’t working correctly.
Could be signed distance field meshes, surface cache, or something else.
Check out your lumen scene debug view. visualization for signed distance field meshes.
Check lumen docs for more info.
Lumen relies on these systems to work.
Thanks but I checked all that. The scene looks solid. Also I could reproduce the error by recreating the scene with simple boxes. You can just create a long corridor closed on one side it will give you the same result.
Yes, the object is a modular BP and made with several thiny parts. So, too small to be computed.
Is there a minimal bound size? I noticed that +/- 30cm is the limit as I tested with the default cube with a scale of 0.3.
This is annoying because complex objects have to be spliited in separates ones to be part of lumen computation, but in this way, we encounter this kind of issue due to scale…