Guess it’s time for TheKJ’s monthly routine of baiting people into arguments again
i’m over this argument stage. i watched his videos and drop some technical comments when i find some unfounded allegations. i get it. content. i think he needs more information about internal functions. something the debugger or frame disassembler doesn’t show. the actual computing. tryna find a way to bash it for his clickbait titles. lol
gotta dive into the engine code to find out what it does and why it’s taking it’s very time.
jsyk… i got a 3060 too. (a laptop model tho. but it boosts to stock desktop clocks and sometimes a lil higher on less load - it should be good to compare ;)) and it runs fine on my end with all the shabang enabled. tbf… for temperature’s sake it always fps throttled. and yes… some stuff is not well optimized, yet. but it’s good enough to make pretty games.
RTXGI plugin from version 5.0 to the engine you’re using?
Nvidia’s names are a bit much, are you talking about the DDGI plugin? The problem with it is you can’t scale down properly at least with that implementation and has serious reference problems. You can slow down the update rate (rays) but it won’t update perpixel lighting like normal SH. Makes no sense and looks really weird if you’ve seen it.
jsyk… i got a 3060 too. (a laptop model tho.
I was asked this months ago, I have both desktop and laptop.
and it runs fine on my end
You don’t know what “fine” is then when it comes to static environments that can’t use lightmaps And you’re also not giving proper feedback about real issues happening for years now. You say it runs “fine” and I’m pointing out visual problems with additional ideas on how to fix them. Start thinking about cost to visual ratios.
What does reference problems refer to?
Spherical Harmonics?
So I finally found some settings that’ll make the Archvis crowd stop complaining about noise under indirect light, especially in reflections. Maybe I’m late to the party here and someone else found this, but here it is:
Default:
r.LumenScene.Radiosity.Temporal.MaxFramesAccumulated 4
r.LumenScene.Radiosity.HemisphereProbeResolution 4
Default (Low) Probe Resolution, Very High Temporal Count:
r.LumenScene.Radiosity.Temporal.MaxFramesAccumulated 32
r.LumenScene.Radiosity.HemisphereProbeResolution 4
High Probe Resolution, Moderate Temporal Count:
r.LumenScene.Radiosity.Temporal.MaxFramesAccumulated 8
r.LumenScene.Radiosity.HemisphereProbeResolution 16
This cost me about 1 ms in editor at native 4k in this test on a 3080. Basically, the quality issue appears to be a combination of trying to get away with both low probe resolution and low temporal accumulation. The sweet spot for quality here seems to be at spatial * temporal = 128
But I’m guessing it’ll vary by scene.
Going too low on temporal, even with very high spatial does not work well because you need enough frames for things to become stable. 4 frames was basically never enough for a temporally stable image.
Ultimately, scaling this up is definitely real time viable so for anyone looking to get cleaner reflections, here ya go.
it’s late and i’m too tired for your troll tirades.
you think you enter input into the engine development? you throw some random sh*t on the board and see what sticks. you could do it in a more friendly manner. actual tech. you’re just a youtube sh’thead, now with clickbait titles. does it work? feels good? can you be more productive in engine and actually fix things, not just rant about it. be a coder. doesn’t make money but fixes things. hmm…
i should be more productive too tho… ngl, mhh.
This is awesome. My last big complaint about lumen was the lack of high-quality multibounce, and this pretty much solves it.
I just quickly tested the settings- while it takes about 20% of my scene performance, indirect lighting is very stable, and if you need Archvis-like image stability, temporal accumulation matters less.
That said, I did notice some light-leaking with those settings enabled that wasn’t there absent, plus the probe occlusion artifacts (that I thought got fixed?)
Update: I found a bug: Applying your high probe count and temporal accumulation strategies to a lumen scene with a lumen scene lighting quality at 8, breaks indirect lighting.
When I pushed the hemispherical probe resolution past 4 for hemispherical lighting quality, the entire scene freezes up, and indirect lumen lighting stops updating entirely. That black smear is where I moved the cube in the lumen scene away from the wall; that said, direct lumen scene lighting is still updating. Do you think these more esoteric uses of lumen would qualify for a bug report @BananableOffense ?
Bug report/unexpected behavior:
System: i7 9700k RTX 4070 32GB RAM W10 (SM6).
There is a noticable loss of energy between lumen in surface cache and lumen in hit lighting in 5.5 preview.
(ignore the white streak in the test scene, that’s from a landscape that refuses to hide for some reason)
Lumen with surface cache:
Lumen with hit lighting. Note the significant darkening in the scene.
And the PT, which has a significant amount more light bounce present than either version.
I understand hit lighting would be different from the surface cache, but it’s strange to me that hit lighting would be losing so much more energy than the surface cache relative to the ground truth of the PT.
Fixed in https://github.com/EpicGames/UnrealEngine/commit/6bfa613964d89f1ab885689b3cc204a9dddfffce
Thank you for reporting!
Yes, I also noticed a significant loss of energy with hit lighting on the 5.5 preview.
While trying to replicate this, I found a bug as well - possibly related.
Hit lighting GI does not respect the indirect lighting intensity slider for lights. It works as expected only when set to surface cache or hit reflections.
I did not notice any unexpected energy loss or gains in my tests as long as indirect lighting intensity was set to 1.
Also one bit of feedback that has bothered me for a long time. Fully metallic objects eat all light that hits them and don’t contribute anything to indirect lighting, despite the fact that they should be bouncing light into the scene.
If you shine a spotlight onto a mirror, all of the light just disappears into the void.
You can kind of circumvent this by using the raytracing switch to make the object nonmetallic for raytracing, but this has a side-effect that it would also appear nonmetallic in reflections.
Default Lumen:
PT:
RT Quality Switch Manually Reduced Metallic:
Is it possible to use Substrate to build a two layer materials ? One for the metallic look and properties and the second layer non-metallic for light bouncing ?
Or maybe two different objects in the same position ? With different checked properties - something like - one invisible but used for light bouncing.
Just out of curiosity, can you remind me which level this is? I feel like I saw it on one of the lumen Livestreams a long time ago.
Is it worth using card capture switch in expensive materials? So that Lumen can evaluate a less complex version of the material when capturing the surface cache?
I don’t see why not. The little performance gains might add up. But I’d probably save it for an optimization pass later on if needed.
My main use would be for disabling features that Lumen card capture doesn’t properly work with.
I’m not a light expert, but my assumption was that any reflected light off metal would be caustic reflections only, and since lumen doesn’t do that, it’s ignored, BUT shouldn’t even semi rough metal caustic reflections be treated as normal diffuse GI light bouncing?
We disabled Lumen in DX11 alongside the push towards HWRT by default. Now DX12 is required for all UE5 features like Nanite, VSM etc. What’s your use case for using DX11? At this point DX12 should be in a pretty good spot.
Thanks, will fix.
They shouldn’t. Yes, Lumen Surface Cache treats all objects as fully diffuse, but all metals should be approximated using EnvBRDFApproxFullyRough()
. It’s just an approximation so sometimes it’s too dark and sometimes too bright.
Here’s an example of a fully metallic sphere:
i think @BananableOffense means this bounce back.
and… (this is 5.5) it does work. mostly on plane geometry. it’s just scattered alot, when shot at curved surfaces. i done the laser on the copper ball before, too.
also… lil glitch i just found. (it’s not lumen but lighting related) maybe you could pass it along.
raytraced directional is misaligned in a retro game setting. not that it’s usable with all the temporal shadow noise but even on full resolution (without any aa) a slight ghosting edge is noticable on the character.