Lumen GI and Reflections feedback thread

What is the reflection quality set to? Found in the PPV.

It’s set to 10
image

r.Lumen.Reflections.Temporal 0

I entered this but I didn’t see any changes

Also worth noting that the lower the screen percentage is, the worse your reflections will be, especially at a distance. So you should ensure that your screen percentage is set to 80 or higher.

This has been the first thing that has changed the quality!

  • Setting it to 80 is super blurry
  • Setting it to 100 is super blurry
  • Setting to 120 is moderately blurry
  • Setting it to 150 is okay
  • Setting it to 200 makes it look like raytracing

Unfortunately, I can’t really justify running the game at 200% and scaling it down.

r.Lumen.Reflections.DownsampleFactor

You legend, this was it. This makes the metal look like metal even at 50% screen percentage. I have filled the area with the rough amount of reflective materials I would have, and it runs at 60fps at 1440p. I think this should work? I will add it as a game option, but the reflections are tied to the gameplay.

Oven now with correct reflections:

One last question regarding:

If that is set to something very low (like 0.25) then it will look terrible

Having spent far too long looking at spheres, going from 0.25 to 100 quality changes absolutely nothing.

0.25 quality:

100 quality:

Same for Max Reflections Bounces, changing this number makes no difference. 1 looks the same as 100. Both these settings barely make a dent in my FPS either. Setting both to 1000000.0 leads to a 2fps drop and no change in reflection quality from the lowest values.

Ray lighting mode makes a huge difference, surface cache is terrible and HIT looks great. (Exactly what I expected). High quality Translucents also work correctly, so only two of the options are maybe bugged? (For me)

(EDIT: Just the quality slider now, the max reflections does have an impact, just less than I thought)

Found someone with a 750ti and sent them the game, with a lot of tweaking and settings altering we were able to get a ~50fps at 1080p while keeping the reflections/game looking great. ( r.Lumen.Reflections.DownsampleFactor set to 0). This mainly included changing TSR to TAA, screen percentage, etc. Lumen is blowing my mind, being able to run this quality of reflections on a 10 year old card is amazing!

Thanks everyone for your help figuring this out

2 Likes

In a 750ti, it must be using software raytracing for Lumen, wich should look slightly (because a great development work) different.

Anyway, your shown scene is so simple that you shouldn’t use it to try to notice performance drops nor visual differences between different methods and/or settings.

You should make a quite more complex scene, even if done with simple blocks, but creating different “ambiences” and situations.

In a 750ti, it must be using software raytracing for Lumen, wich should look slightly (because a great development work) different.

It looked slightly different, but I wouldn’t notice unless I was really trying to pick out details. Phenomenal job by the lumen team.

Anyway, your shown scene is so simple that you shouldn’t use it to try to notice performance drops nor visual differences between different methods and/or settings.

So with r.Lumen.Reflections.DownsampleFactor at 0, I notice no difference between Lumen and raytracing. With r.Lumen.Reflections.DownsampleFactor at it’s default value, it’s super clear the difference between Lumen and raytracing.

You should make a quite more complex scene, even if done with simple blocks, but creating different “ambiences” and situations.

I did this after and was how I realised the max reflections slider was working. Even with lots of dynamic lights, different colour blocks, different areas with different lighting, a lot of reflective materials, etc, I couldn’t get the quality slider to do anything. It always looked perfectly raytraced unless I increased r.Lumen.Reflections.DownsampleFactor again. I am not too worried about this because my performance didn’t decrease either.

Pretty sure the quality slider is the downsample factor. Setting r.Lumen.Reflections.DownsampleFactor off just turns off downsampling, which is why your quality slider does nothing.
Quality .25 (aka downsampled)


Quality 1 (same as downsample factor 0 I believe)

I can’t tell the difference between any other level though, so it may actually be somewhat broken. 0.5, 1 and 2 all look the same to me. Only 0.25 is clealy downsampled…

This only has an effect if two reflective surfaces are next to each-other, and are not covered by screen traces.
Max bounce: 1 (screen traces off)
image
Max bounce: 8 (screen traces off)
image

In this test scene, a downsample factor of 0.25 saved about 0.50-0.70 ms. In scenes where all of the metal is rough, this is a worthwhile optimization, because the downsampling is not really noticeable once the metal is sufficiently rough anyway.But in cases where you need a high quality mirror/chrome finish it is worth paying.
Increasing max reflection bounces only cost like 0.1 ms, this is probably because only relatively fewer pixels are included in each bounce, as the reflection gets smaller and smaller.

2 Likes

Hello folks,
I have a problem rendering chrome and highly reflective materials, especially small objects. Please watch the video.
Video
The first scene is the render output. The handrails and stairs in the background flicker.
Strangely enough, not or significantly less when I move around in the editor (second scene as a screen capture). At the end of the video are my settings.
I’ve tried a lot of things but can’t find the error.
What could be the reason?
Thanks for hints.
Chris

Bloom is the main issue looks like. Bloom in unreal is completely broken without strong TAA/TSR frame blending even with positive roughness mipmaps. Looks like the first render was missing frame blending.

EDIT (after seeing video settings): Yep, you had AA set to none.

You can try r.BloomQuality 4 with FXAA(should have SMAA but Epic doesn’t like morphological AA) but it still might have issues if you haven’t managed the specular aliasing. (Positive mip bias for roughness maps included)

1 Like

Yup, it’s specular aliasing from insufficient resolution and/or lack of anti-aliasing.

Pretty sure the quality slider is the downsample factor. Setting r.Lumen.Reflections.DownsampleFactor off just turns off downsampling, which is why your quality slider does nothing.

That makes sense, unsure why the slider wasn’t changing the value for me though. Not too bothered as it seems to work okay using the command

I can’t tell the difference between any other level though, so it may actually be somewhat broken. 0.5, 1 and 2 all look the same to me. Only 0.25 is clealy downsampled…

Kinda glad I wasn’t completely crazy lmao

This only has an effect if two reflective surfaces are next to each-other, and are not covered by screen traces.

Yeah, realised that once I filled a scene with reflective objects and started playing with all the settings. Kinda obvious in hindsight, but we live and we learn I guess

In this test scene, a downsample factor of 0.25 saved about 0.50-0.70 ms. In scenes where all of the metal is rough, this is a worthwhile optimization, because the downsampling is not really noticeable once the metal is sufficiently rough anyway.But in cases where you need a high quality mirror/chrome finish it is worth paying.

Sweet, thanks for the tips!

I have used and tested the Unreal Engine 5.21 and 5.31 RTX-DI branches. It is only Direct Lighting (RTXDI/ReSTIR DI) and not ReSTIR GI. You can enable Sampled Lighting (RTXDI) for Lumen Surface Cache and Sampled Lighting (RTXDI) for Lumen Reflections. GI is still Lumen, but it is still not ReSTIR GI. There is another branch Unreal Engine 5.21 caustics, NV Enhanced Restir GI including Diffuse GI, Reflection GI, and Translucency Refraction GI in this version. It is similar to Cyberpunk 2077-2.1O-verdrive

3 Likes

UE5.4 branch is already in the GitHub. I think 5.4 preview must be coming, finally!

I have compiled it, but some features, like the cvars to enable stochastic shadows (if I’m not wrong), are not available anymore :frowning: . Maybe it’s still there in the Main branch only (I won’t compile it), for an upcoming, farer, future release. But I was happy even with its current early state, it’s a pitty to loose it in 5.4.

Oh, that’s would be very nice! But are you sure, how do you know it?

Are they a kind of ray traced shadows? Because if I disable ray traced shadows, it goes to old cascaded shadows or to Virtual shadow maps. And they are perfect (when RT shadows enabled), without any of the pixelations I shown some weeks ago. In addition, some of the cvars were useful, to tweak things like the temporal accumulation, for example.

Also compared with 5.3 scene; RT shadows look the same, cascaded shadows look the same, VSM look the same.

So, everything leads me to believe that it has been removed.

i have a test scene. and i see the performance without changing anything. somehow it defaults in my project. so…

it seemed already established 2 weeks ago. apparently advanced to a new branch. and they fixed the hair glitch. nice, btw. :slight_smile:

It was renamed to r.ManyLights. It’s more of a prototype than a real feature, so you need to enable it using r.ManyLights 1 to force all local ray local lights to go through this path, or r.ManyLights 2 to force all local lights (including VSM) to go through this path. At some point we need to make a new thread for it, but for now it feels to early to publicly announce it :). Still please post any feedback, it’s always interesting to see what issues people run into and what we need to focus on.

6 Likes

how do you come up with those names? don’t say it was my test that triggered that change? i had to bench the performance with multiple shadows, tho. that’s what it’s good for. good ambient shadows. hmmhmm

edit: we skipping 5.4? or is it finalised? daily build says. 5.5. okay. :slight_smile:

1 Like

a daily one: emissive reflections were shelved? they seem to disappear at random distances now. the unreal logo is one texture but the ring and the U disappears and pops back in at different distances. i shelved the idea of a neon city anyway. so… not much of an issue to me, rn.

also… there was a cvar (i can’t remember, rn) that allowed control of the dynamic/physics props (the blu cubes) to retain their color in the mirror over a longer (very long) distance. this seems to not work anymore. i reckon this is a lumen mirrored surface cache thing.

i’ll have to build a proper level now anyway. a real scenario. yep.

Oh, so great, thank you for writting @Krzysztof.N ! It is working now.

Maybe still experimental, but so, so promising and funny! About this, I have noticed that when temporal is enabled, the shadows are more pixelated than when only spatial filtering is enabled (it is just more noisy). Any chance you will find thw way to soft the temporal sampling?

Related to it, are the samples per pixel clamped to a max of 4? Would be nice to leave them free (to reduce the spatial noise, for example, if we had disabled temporal accumulation and still have performance headroom).

About Lumen, I find it quite stable and solid (with the classic long-term challenges, like the noisy reflections), but, for me, it has 2 weakest points. Lumen is like a soft road now, but it has these 2 small, but very deep holes, and if you have the ‘luck’ to encounter one of them, the dissaster will happen:

  • Clear mirrors might be quite ugly, being very noisy and showing some (intermitent) black faces in some objects (checked in Lumen scene view, all fine). This can be another long-term challenge, of course:
    image

  • This is my very weakest one: ‘Shadows/lighting’ (?) can look really weird. This is something more like a bug, I think, which can destroy a whole experience, if encountered:


    This happens with RT shadows enabled, when a surface is directly lit by a light with a source radius higher than 0, and when ‘drawing’ the silhoutte of this lit surface over a GI-‘shadowed’ surface.

And just as a recursive suggestion, would be soooo great to have a cvar to enable/disable emissive GI contributions, as with Path Tracing. (We already talked about workarounds time ago, and they reduce the issues, but don’t solve them).

Thanks!!

I pointed 5.4 has its own branch now. Probably they have already closed the most ‘experimental’ development to start releasing it to the public soon, I hope.

2 Likes

There are settings in PPV or you can toggle “Emissive Light Source” on the mesh.

I wonder how are you disabling temporal sampling and why do you want to disable it?

That should be improved today (CL 31257831 in 5.4):


Yes, they are clamped to 4, which translates to 1 ray per pixel. For now focus is on getting it working on consoles, where it seems to be a realistic budget, but at some point we’ll look into scaling it up and definitively unlock the number of samples.

Yes, one of the things on todo list.

I’m not sure which shadowing method, but I don’t think anyone working on VSM or ray traced shadows reads this thread.

We could do that, but it would only work for world space traces, so for it to work properly you would need to disable screen space traces. Not sure how useful it is.

5 Likes

Wow, thank you so much for your reply @Krzysztof.N !

I just disable temporal accumulation in some scenarios, like when wanting to experiment and to try to get more ‘sharp’ or accurate details (I did in Lumen too, for example, but also increasing other values to compensate). In summary, to get a higher (but expensiver) quality. In this certain case, I just disabled it to check how it could look ‘increasing’ its quality, by this method, and then, I noticed Temporal was the responsible of pixelation. I love to try and play with almost every cvar :sweat_smile: (the cvar was r.ManyLights.Temporal 0).

Can’t wait to test it!!! (Still not updated in Github, if I’m not wrong).

BTW: In some additional tests I’m making before that update, ManyLights doesn’t seem to correctly project the shadows of a 2D text (maybe it’s not working with masked materials, in general?).

In addition, is it also possible that it is not working for directional light sources? It seems to apply to all lights’ shadows, except to those projected directly by the sun.

Great, but just for curiosity: why the need to clamp it, if it already has its default value into the budget margin and/or if it’s just optional to developer criteria. I mean, is it not just enough to only advice it to the developer, but let him the freedom to bypass it? Or only camp it if platform is not equal to PC?

Sorry; confirmed it’s not Lumen related (I thought it was only happening in combination with Lumen). But please, could you have any possibilty to link the post to any RT shadows engineer? I have reported it twice, months ago, but just ignored (as usual in the bug report form). I would be very glad if you could spread the word.

Quite, I think! You could make a survey to check it and I’m sure it will have many votes, if well explained, documented and compared. Lot of users have already shown their concern about emissives, even if it will only disable it partially (world traces), but it would be always helpful, in any sense, I’m sure. (I hope it’s not very very complicated to add :smiling_face_with_tear:, but I understand your vision too).

Thank you very much!

it works on my end. all of the screenshots i shared got a directional sun in it, with soft shadows. so… something wrong with your settings? jsyk… i’m rocking default, just bumped up the bounces and enabled volumetric injection (cause… i need/want that).

also… masked (and dithered) materials should be working, rn. ellie’s hair looking good.