Good afternoon, can anyone help me solve this problem, right now I’m using Lumen render GI and Reflection Lumen too. But in my scene, these robots are moving really fast, like it’s a “time lapse”.
And the shadows behind my robots don’t have time to calculate, how can I solve this shadow problem?
Thank you.
If it’s MRQ, I might advise you to record at normal speed and speed up in post, if you can. Lumen can let you override temporal accumulation in the post-process volume, but that will cause flickering and noise unless you boost the tracing quality significantly.
Alternatively, since it looks like you’re dealing with a limited frame, you may be able to afford the cost to boost lumen’s settings for this one view, and regress to more performant specs when the scene is done.
How can I boost the tracing quality significantly?
I’m trying to fake scene cube capture (aka make 6 screenshots in up, down, forward, back, left and right directions) and each time the lighting quality is slighly different. It is very visible on the edges of each image…
Hmm, that would be an interesting puzzle. Truth be told, I’m not sure Lumen supports orthographic viewports entirely at this stage, so that may be challenging. The biggest issue is that lumen operates on what is directly in your viewport, and is scene dependant. It partly depends on how the error is manifesting that would determine the proper solution. Is it noise?
Also, if you’re doing so, make sure to lock our the exposure on your PPvolume, otherwise adaptive brightness and tonemapping things may be giving you trouble.
AFAIK the engine doesn’t support shadows in ortho views. Given how basic part of the lighting just mere shadows are, and they are missing, it’s kind of ridiculous to be thinking about lumen in such case 
Hey @jblackwell, thanks for reply. I’m not using orthographic viewport at all. I’m using regular perspective camera with hFOV of 90 degrees.
I’ve attached a few “interesting” images rendered via MRQ (default settinsg). Camera has pitch set to ~90 degrees and it is being rotated around Yaw axis by 30 degrees. I’m not sure what are those strange seams (I have a feeling it is somehow related to octahedron and screen traces(???))
It seems to me that Lumen + Movie Render Queue do not work well when camera even slightly rotated from frame to frame. For the reference, I disable all temporal effects in PP.
Is that possible to force Lumen calculate what it needs to calculate to avoid these weird seams?
UPD: It seems that r.Lumen.ScreenProbeGather.Temporal is causing these seams 
What can do with it?
I just find the problem is owing to shadow map. If I uncheck the option “Reuse Shadow Maps” in lumen settings, the issue will be fixed.
When I check the virtual shadow map cache, it seems those problematic surface are all appear black?? Green is cached, red is invalid, what does black means?
@ Any idea what might be causing these seams?
Any clue what’s causing this?
I’ve been experiencing this since 5 beta.
I have an emissive material on the light mesh and a pretty standard spotlight in that room.
I might have changed some project settings at some point so that could be it but it’s been so long that I don’t remember.
1 Like
I did more experiments of Lumen + MRQ and results are really awful. Not sure how such bugs end up in UE5 Release…
Here is the MRQ render of ArchVis test scene, the camera is only slightly rotated to the right but the seam is already there.
Uncompressed images:
Lumen + MRQ broken for rotating camera? Lumen settings are maxed out, all screen-space post process effects are disabled…
Try to crank up all Lumen settings via Post Process Volume. If it does not help then try to disable screen traces and see whether it helps. If that does not work then try to reduce Radiosity probe spacing to 2. Playing with Lumen console settings sometimes helps (most often not)
Figured it out. All the walls in that scene were one mesh and evidently, lumen doesn’t like that.
Cutting them up fixed the issue (and that’s all I did). The difference is quite literally day and night. There’s still a bit of fuzziness but that shouldn’t be too hard to iron out.
Using Lumen scene view helped me figure out it was the issue.
Lumen console settings can certainly be interesting, it seems epic has a lot of experimental methods and algorithems buried in the code that aren’t always used for active paths.
If you need absolute highest quality, I reccomend lumen_screenprobegather_referenceode. It basically disables all filtering and simply cranks the sample count to a massive number, but it resolves detailed lighting far better than lumen can do normally, which may help with screen-dependant artifacts as well. Simultaniously, you could disable lumen screen traces, although I’m unsure of the specific implications of that for your scene.
That would do it. Lumen places a few content restrictions (slightly looser ones for HWRT), but essentially all geometry has to be manifold, two-sided, and at least 10cm thick in order to reliably avoid light-leaking. Most of these are requirements for SWRT (one-sided distance fields are kind of a strange concept in the engine), but you can also put blocking geo around your hero geo to help supress leaking.
By the way, I just noticed that UE5_main’s Shaders subfolder hasn’t been updated in over two weeks, pure speculation but I wonder if it’s a development freeze to prepare for 5.1 preview, I would be very excited if that was the case.
Hello,
maybe some of you could give me advice…I do not know how to improve the quality reflections from Lumen. When "screen Tracing” kicks in, results are acceptable, but when it is reflecting things out of screen, then I have basically two “problems”: -there are a lot of “splotches” from the GI everywhere and metallic materials seem to be rendered in black…is this normal behaviour? is there a way to improve at least the “splotches”?
thank you!
This is normal behavior for lumen, yes.
When enabling hit lighting for reflections, you’re having lumen evaluate full-resolution materials and direct lighting, but indirect lighting is processed from a lower-quality GI method for speed. The splotches are from the low-quality GI method, and the only real way to improve them is to crank the lumen scene lighting quality higher- 8 is as high as it will go currently, unless you want to play around with CVars.
Metallic items are rendered as black due to a shading quirk. In a PBR workflow, technically speaking, default shiny metal has an albedo of black- it doesn’t really have diffuse lighting in a sense. The lumen scene doesn’t support multi-bounce reflections, only diffuse GI, and since there is no diffuse lighting for metals, they look black. This creates the weird scenario where metals can technically look better on the lower-quality reflections modes-metals look approximately grey because the surface cache grabs the base color instead of actually simulating light behavior.
In summary: both of your problems are normal behavior, and products of how lumen was constructed and optimized. One has an easy solution, the other has a harder solution that either involves losing lighting quality or performing some complex shader wizardry (look at some of @BananableOffense 's work for examples).
@jblackwell thank you for your complete answer!
I already have the Lumen scene lighting quality" at 6 and changing to 8 makes not visual difference. Do you know where I can find some documentation where it refers to the CVars that control reflections quality?
I have also tried the Ray Tracing Quality Switch node in the metallic materials to give a non metallic material in the reflections, and at least is not rendering in black
By all means @Idgi , happy to.
Ray tracing quality switch replace will indeed solve that problem. Unfortunately, my only recommendation is to search help in the console to get a list of all Cvars, search lumen, and look for notes.
Sadly, Epic’s documentation on lumen is largely surface-level. There is a lot of quality and performance on-tap if one knows the commands, but the commands themselves are not well documented. Beyond some of the more obvious ones, such as the reference mode and controlling the use of screen traces, your best chance is simply to experiment.
Fair warning though: crashes are to be expected, because some of the atlases in lumen are geared towards a given size and not meant to be expanded. It is also very easy to exhaust VRAM unless you are careful.