Lumen GI and Reflections feedback thread

[Miguel1900]

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.

[glitchered]

@Miguel1900

how do you know it?

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.

[Krzysztof.N]

@Miguel1900

I have compiled it, but some features, like the cvars to enable stochastic shadows (if I’m not wrong), are not available anymore .

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.

[glitchered]

@Krzysztof.N

r.ManyLights

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.

[glitchered]

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.

[Miguel1900]

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:
  

• 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!!

@glitchered

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

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.

[Krzysztof.N]

@glitchered

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.

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

@Miguel1900

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?

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

@Miguel1900

Shadows are something like slightly more blurry in their edges, but the worse point is that it will be more noticeable in thin objects’ shadows (like the legs of a chair), looking a little pixelated.

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

@Miguel1900

Related to it, are the samples per pixel clamped to a max of 4? Would be nice to leave them free

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.

@Miguel1900

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).

Yes, one of the things on todo list.

@Miguel1900

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:

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

@Miguel1900

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 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.

[Miguel1900]

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

@Krzysztof.N

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

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 (the cvar was r.ManyLights.Temporal 0).

@Krzysztof.N

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

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.

@Krzysztof.N

Yes, they are clamped to 4, which translates to 1 ray per pixel. For now focus is on getting it working on consoles

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?

@Krzysztof.N

I don’t think anyone working on VSM or ray traced shadows reads this thread.

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.

@Krzysztof.N

Not sure how useful it is.

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 , but I understand your vision too).

Thank you very much!

[glitchered]

@Miguel1900

it is not working for directional light sources?

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.

[Miguel1900]

Hi @glitchered ,

Maybe you are still not correctly enabling (or testing) stochastic shadows.

I have created an empty project, from scratch, and with stochastic shadows enabled by default (in blueprint construct), so you and @Krzysztof.N can also check&test easily and quickly:

(At left, the default sun, projecting fine RT shadows, because they are not stochastic. At right, a Spot light, projecting stochastic shadows with their masked issues)

The masked issue it’s even more strange; it ‘works’ better when looking the masked sillhoutte ‘frontly’, allowing the light to passthrough:

Here you are the test project:

BUG-ManyLights_sun-masked.zip

[glitchered]

first of all it’s still a beta thing. and… now more properly tested and figured out.

solid geometry has no issues at all. for translucent or masked (and dithered) materials the caster’s geometry and normal orientation matters. it’s a screenspace contact shadow. maybe not well suited for flat planes or giant transparent overlays. proper grass level geometry looks okay. i’ve seen a similar option in T1’s port. i’d also not put a text renderer in a game, anyway. also… in case of “glitches”/artefacts it’s a job for the lighting artist to hide the hard contact issues.

also… screenspace typical artefacts. this is why the transparent caster geometry matters. you will step into this pitfall if you don’t understand how it works. at this point real geometry or really tight alpha masking may be the supperior choice for foliage, with this shadow technique.

i got a question @Krzysztof.N or team tho: should i be worried about this? some lamps expose complexity, some don’t. changing angles doesn’t change that. edit: changing color does. red light is more expensive then blue light? gonna be a cold world? this doesn’t make alot of sense. or is the light complexity “broken” for manylights? the shaders are all green. so i take that.

either way… not the primary topic of this thread.

[jblackwell]

I did just want to say, the screen traces toggle has been extremely useful from a testing perspective alone, it’s very helpful to have that immediate toggle rather than needing to enter CVars.

Also @Krzysztof.N, standalone SSR is currently broken in the most recent _main build:

Lumen GI with SSR doesn’t work, but SSR does work with either no GI or SSGI. Lumen GI with lumen reflections lacks the SSR component.

[jblackwell]

I finally got around to trying out translucent RT reflections-they work essentially as advertised, we now have greyscale transmitive caustics in Unreal. They do come with a massive performance penalty (as the CVar said it would), but it’s still a very cool effect.

That said, if anyone wanted to have stained glass-style windows in Unreal, I’d definitely just go with the fake rect light technique shared somewhere above in the thread- you have better resolve, better shadows, far less noise, and improved responsiveness.

That said, PT behavior is completely different (likely a product of substrate), but I can’t say I’m overly surprised.

[TheKJ]

Yo(@jblackwell), Idk I didn’t hear about this but is this a “AMD rip off” of Lumen or improvement speed wise?
Unfortunately relies on disgusting TAA.

GDC 2023 - Two-Level Radiance Caching for Fast and Scalable Real-Time Global Illumination in Games

[jblackwell]

I wouldn’t call it a ripoff any more so than any other technique is ripped off in computer graphics; the industry’s progress is largely a result of share and share alike.

Without solid perf numbers (EG UE, same GPU, same scene, resolution, and quality level) everything is speculation, but it should be said that this system only targets diffuse GI-reflections are a separate problem to be solved. That said, the idea of using screen probes to query a world-space data structure, and using screen-space techniques to fill in for sparse sampling, is definitely and openly borrowed from lumen. Beyond that however, there is a lot of new research and differing implementation and choice of techniques. It’s similar to lumen, but it isn’t lumen.

I think many other real-time GI techniques are going to come to similar conclusions for basically the same reason Danial Wright laid out in the original lumen presentation: filtering real-time GI data is hard and a screen-space/world space hybrid system seems the way to go for now.

[TheKJ]

I should have said AMD ripoff(FS2/DLSS, frostbite SSSR/AMD SSSR etc). It’s not an insult or meant to be derogatory towards AMD, it just means if it’s their closely resembled iteration of somebody else’s effect which they do often. You could say that about any effect, the point is supposed to be an advancement. If it doesn’t advance in a area, then just call it the same technique, credit, etc.

From what it seems(I didn’t stick around for the whole thing) from your comment it is their modified and generic Lumen GI only solution.

[BananableOffense]

Couple of interesting developments in the presentation. One in particular that caught my eye was around 22:30, which appears to solve the temporal instability of small emissive light sources by biasing away the unstable portion of the light. Maybe that could work for Lumen, since the slightly darker final image seemed like a worthwhile trade-off for temporal stability. Lumen’s spotty emissive resolve has been a hot topic for a long time now.

[jblackwell]

We don’t have a ManyLights (formerly Stochastic shadows/sampled direct lighting/etc) thread yet so I’ll just put it here:

I’m getting the feeling that between the need to evaluate hit lighting to solve alpha occlusion, and nanite’s behavior, it’s probably best to lean more on actual geometry vs. alphas in future art?

[glitchered]

more to test? lemme sync (or reclone this conflict -_-) then… and rebuild.

and… the last test i did suggests using actual geo is better for certain alpha cases. simplifies the shader load. will see what this push looks like. just applying in a simple user case scenario. hmm

daily… running comfy 720p on my lil rig (i gotta cheat, always. i like the magician that is dlss. that will raise the quality later). translucent shadows look good.

test runs fine. seems the native performance was improved. (or i don’t remember what resolution i used for the older shots). nvm.

screenspace seems fixed in many lights. hmm.

aight.

[Miguel1900]

Oh, so great, they read us silently! Thank you @jblackwell

It’s working fine now! But I still wonder why the sun is not stochastic. Is it intended, maybe? (Notice its shadows are not blurry, but still ray traced):

Unfortunately, It seems it won’t be included in 5.4, at least right now, but well, it’s still experimental.

Additional feedback about Many lights (and a little about Lumen translucency) @Krzysztof.N :

At the beginning it’s about Lumen translucency volume flickering. Firstly with RT translucency enabled, and disabled secondly.

After that, it’s about enabling Manylights. Screen Traces causing some glitches. Many lights being very noisy in some situations (under the table, just 2 common lights over it, with 0 in their source radius):

In this less compressed video, the noise is more evident. But it’s much more noticeable “in person”:

Thank you very much!!