Lumen GI and Reflections feedback thread

nice demo. i won’t spend 20x the geo buffer tho. my video memory and fillrate is limited.

both scenarios showcase the same lack of instance z-presorting. way too much overdraw.

edit: a short nap later… i don’t think this overlay is even correct. i mean… the z-prepass should look like that. it’s a blast thru pass. for every other (expensive) render pass the raster stage should kick in and reject any fragment shader call unless it is below or equal to the depth value in the z-prebuffer. this should limit the technical “overdraw” to a single fragment shader execution per pixel.

and… this doesn’t belong in the lumen thread, really. somebody else coded the instance transform routine.

Hi all and @Krzysztof.N ,

Sorry for the side question, but you are here so Nanite experts too; please, do you know why some static meshes, when enabling Nanite, look this ultra low poly? (It’s quite detailed and high poly when Nanite disabled):

(I know I can workaround this setting the fallback relative error to zero, but it dosn’t sound to be like it should).

Thank you!

Not really a Nanite expert, but likely there’s something preventing this mesh from being rendered using Nanite. Like a translucent material or something. Should be visible somewhere in logs.

Thanks for reporting. This was recently fixed in main, and should make its way into one of the hotfixes.

3 Likes

Oh, that’s it! Didn’t remember that thing. Thank you so so much :partying_face: !

When using Lumen in some situations it produces these artifacts

Already reported a year ago, unfortunately. But, at least, they added to the TODO list for 5.5 (now moved to 5.6…)

@Krzysztof.N , I have noticed an issue with Packed Level Actors regarding AO, GI contribution or both, I would say.

Unfortunately I can’t test it now in UE5.5 as my main PC GPU is in a RMA process. But in 5.3 in my laptop, I have noticed this:

Cube directly in scene:

That same cube converted to PLA:

(All my floor rocks must be suffering the same, unfortunately, as they are all in a PLA).

The repro is really easy, jusy place an actor in scene and create/convert to PLA. Please, could yo confirm if it still exists in 5.5 and/or provide a fix, maybe? It looks like an important effect to get lost.

Thank you very much

EDIT:
Looks mainly a non-GI response, with and without HW RT. PLA vs normal:

Basic test project: Dropbox

EDIT:
Ok, some inquiries here! (Remember, this is 5.3, I will be able to confirm in 5.5 in one week, if you don’t do it earlier):

  • Non-nanite meshes will be packed in PLAs as HISMs, while Nanite ones will be packed as ISMs
  • HISMs won’t bounce lighting if they are non-nanite, but will do, if they were ISMs (so, why package them as HISMs?)
  • But even being ISMs, it also seems like non-nanite ISMs won’t cause ambient occlusion, additionally. Also if being HISMs, which seems the worst case.

In Lumen scene is very easy to see the differencies in surfaces debug colors.

1 Like

Just an update…hotfix is out but it doesn’t look like r.Lumen.Supported.SM5 made it into the list.
Also tested with a project

12345 shaders? coincidence? either way… here we go again.

Is there a solution to this issue where a mesh obstructs the view and causes problems? I’ve tried various console commands related to Lumen, but none of them seem to work. The only one that “fixes” the issue is r.Lumen.ScreenProbeGather.DownsampleFactor 0, but in that case, Lumen’s calculations become extremely demanding, even with my RTX 4080. This is a significant issue that completely disrupts the visual quality.

Of course, I’ve tried reducing the maximum number of frames Lumen uses for temporal calculations, but it doesn’t help in fact, it only makes Lumen increasingly unstable. Screen tracing is enabled, but even disabling it doesn’t help at all.

It is very unfortunate that view occlusion by an object has such a significant impact on Lumen.

For your information, I am using Unreal Engine 5.5.1.

Thanks.

2 Likes

Check the lumen debug views of the scene and make sure the building is well represented in the lumen scene view.

Since lumen is an accumulation based approach, it is going to struggle with dis-occlusion. Depending on lighting conditions, I find it can take up to 4-8 frames to resolve a clear and stable image.

Decreasing temporal accumulation will only make the rest of the frame as bad as the dis-occluded part.

The only way to really fix it is to improve the spatial quality of Lumen so that the image is clearer on frame one. It can also be improved by running a faster frame rate, so that the 4-8 frames have less persistence on screen.

Tech such as Nvidia Ray Reconstruction will probably help this case too.

Strafing against high parallax scenes is also a worst case scenario for this kind of issue.

1 Like

There isn’t really a solution to this issue. Ray reconstruction is unavailable and doesn’t support Lumen’s global illumination, so it’s not a viable option either.

Additionally, any solution would need to be compatible with all types of GPUs (AMD, Intel, and NVIDIA).

Increasing Lumen’s settings to improve quality while reducing frame reliance for temporal stability would also come at an enormous performance cost. Considering that Lumen is already resource-intensive by default, there’s no practical way for me to increase its computational load further and I don’t want my future players to have to play with 33% upscaling either.

I hope that one day Epic will develop a more performance-efficient solution that incorporates baked lighting with interpolable probes for various scenarios. Even if it results in more approximate global illumination, it would still be a worthwhile tradeoff. Lumen, as it stands, is far from perfect, and a solution with significantly reduced or minimal reliance on temporal methods would be a substantial improvement.

In any case, it’s really frustrating as it stands and genuinely a deal-breaker. I hope for improvements in the future time will tell!

I think that in this case that geometry isn’t represented in SDF or BVH and is only picked up by screen space traces, so it’s bright for N frames until the entire cube thingy comes on screen. Try to disable screen space traces to confirm this.

BTW this scene has nice lighting

2 Likes

Thank you, the mesh (or rather, it’s actually several meshes) is properly represented in the global distance field. I also tried with hardware ray tracing, but unfortunately, the issue with disocclusion is still present. It also occurs with other pillars and various elements, such as tree leaves when they move, especially when there’s a building in the background and the camera is very close. However, in this case, it’s less frequent. On the other hand, the disocclusion issue with pillars and similar elements is often present and quickly breaks the visual experience.

Disabling the screen trace doesn’t solve anything either.

The only method that fixes the issue is setting r.Lumen.ScreenProbeGather.DownsampleFactor to 0. However, Lumen then costs 16ms to 22ms of processing in 4k, which is not viable.

So lumen wouldn’t work well on Seige of Shanghai in BF4 for example? Urban environment, lots of depth-planes, much parallax.

I love the tech, the results are amazing and speak well for themselves in terms of (final) visual-fidelity, but knowing it’s a sample/accumulate approach means it will always be a lagging-indicator type thing. It seems a poor trade to have a persistent effect that breaks-the-illusion for GI. As good as it looks, it the experience is ‘oh, there it is, and there it is again, and again’…

From what you’re suggesting, the solution here is simply ‘better hardware’ so we have enough oomph to do in 1 frame what we’re doing across several?

1 Like

well the disocclusion is a kinda issue. spatio temporal stuff. and motion vector dependence. i reckon you could circumvent it drawing the scene back to front which would add a lot of overdraw, tho. and it might still f up if you motion wipe it.

the solution i got is to not push the autoexposure too much. and eyeball the light ranges. so you have a small basic numeric range of change in the temporal buffer. this is a technical artist fix. the more exposure and contrast you add the more the numbers differ. it’s easier to balance with a close to neutral range, rather then under and overexposed.

i did a semi motion wipe test in a neutral “unified lit” setup. it held.

2 Likes

Its more about the relative depth of those planes. In the post, we have a very close object panning against a very far one, so the movement can reveal large occluded portions per frame. But I think its fair to say this artifact will likely show up more in urban environments.

Lumen is also at its fastest (for resolving clearly) when well lit. The overcast scene, while pretty, makes it take a bit longer to reach a stable frame.

It would certainly go a long way, but I think we’ll see software improvements helping a lot too. I mentioned Ray Reconstruction for example. Yeah its hardware locked for now, but so was upscaling and frame gen and we saw how quickly that changed.

My 0.02 is that every real time raytracing technique is making big compromises. I’d like clear/sharp, full 4k, 120 FPS, artifact free raytracing as much as anyone. But until then, we pick what compromise we are willing to accept just like always.

Personally, I don’t find the artifact Maenavia is facing to be particularly distracting or anywhere near the level of “completely disrupting the visual quality” - I think the scene looks pretty great. But I also totally get wanting to deliver the best possible image.

IMO things like SSR artifacts, light leak, the utter lack of depth in indirect lighting - things that gamers accepted with minimal complaint for ages - are far worse visual compromises than a few frames of temporal dependency and modest upscaling.

I’m rambling here, so long story short… I think a combination of software and hardware improvements will get us to a very good spot soon (at least for the high end PC market) and I think that the compromises can be well worth it for lower end hardware, so I’ll take it for what it is.

But obviously this is a feedback thread, so by no means is this meant to dispute that there is room for improvement.

2 Likes

I’m looking to make some realtime archviz presentations on ipad pro devices (M4). Currently however despite the ipad having m4 chip doesn’t seem to support lumen or nanite. I can work around the nanite limitation but definitely need lumen.

Is there some setting i’m missing or is it just completely not doable at this point?

Dear Krzysztof,

I’m trying to expose r.Lumen.Supported.SM5 in Unreal Engine 5.5.1 but couldn’t find any related changes in the UE5-Main branch on GitHub. Could you share any additional information or guidance on this?

Thank you!

It’s here: https://github.com/EpicGames/UnrealEngine/commit/b06de9ae3eda937c32a7a3fbec13c3b3165b43ff

1 Like