it’s basicly this… gi “color transport”
I see, so skeletal meshes now have support for casting GI? I didn’t even think to test that, but that is really exciting. Between support for skeletal meshes, support for GI from animated materials, and what @BananableOffense has documented, we have a much more robust lighting path. Particularly with the directionality-influenced materials from substrate, the lighting can support those complex materials in a much stronger way.
at some point i set her up and bounced a spot lamp on static world geo, but… i never checked if it bounces on herself. this is good for believable character interaction. or a general lighting detail you can throw in. yep
When you enable hit lighting for everything you will get materials and direct lighting calculated at every hit. Just like it was in case of hit lighting for reflections, but now you can enable it also for GI.
Still, secondary bounces and skylight depend on the surface cache. Something for the future release…
defo cool looking. almost pathtraced. i can’t imagine how you did it to run in realtime. i know pathtracing is mostly backwards reliant. like… hit the arm from the camera. bounce and sample gi somehow and follow the reflection vector to hit the chest. sample gi again and bounce to get the light to make the red material shine. then go back and apply it to the arm as reflection. it’s kinda magic code to me. but it loooks goood. 
I know it’s been said that the cost is pretty heavy. Is there any possibility to have this overridden on a per mesh level? It seems like most meshes would not benefit from this feature greatly, but every now and then it might be important. Turning it on for the whole scene could be overkill. If we’re can exercise more control on when to evaluate the material, maybe it’s open the door for secondary bounces and whatnot. This could look like “Number of material hits to evaluate” for reflection and GI each. Setting to 0 would force surface cache only.
Can you try a driver update? We have seen similar issues on NV GPUs and reverting driver to a previous version fixed it.
Are there any Lumen lighting related processes done as objects are drawn to the main render targets?
I’ll talking about a lighting render target that’s updated along with the albedo/roughness/velocity/ etc (if so can you recall the changes if any over versions?)
Maybe it’s just skylighting that’s done, no harm in asking here first before doing a software capture.
(Edit, it’s just skylight related processing)
Also, I know making Lumen more compatible with non-nanite HISM instances doesn’t follow the “make everything nanite” agenda but nanite is such a joke in terms of performance and visual quality. Also, please work on denoising Lumen better with these settings:
r.Lumen.ScreenProbeGather.Temporal.RejectBasedOnNormal 1
r.Lumen.ScreenProbeGather.Temporal.NormalThreshold 2.7
r.Lumen.ScreenProbeGather.Temporal.MaxFramesAccumulated 25
Almost fine for fast motion except salt and pepper aliasing on anything newly disoccluded or objects in the distance that get shaken up by camera jogging movement. Either work on detecting these area’s and force computations on resolving them quicker or denoise it better with something effective against salt and pepper (such as FXAA of all things, you’ll notice it). Or just implement a good fallback interpolation.
EDIT(hardware)
Hardware: Desktop 3060 at native 1080p, this is a 13 teraflop machine and I have 3 instances of faster/more stable GI that run great on this hardware. It’s also not that far from 9th gen and no PS5 pro is not target and should not be target since everything on base ps5 looks like temporal SLOP or runs at a resolution so high gameplay takes a massive hit in standards that should be set by now
Software(cheaper than hw) probe gather on High cost 3.5ms The cost is does not change based on how dynamic the scene is, so again I ask and URGE your efforts to work on making ways to take advantage of less dynamic environments such as static rooms that need to light up when a door or window opens. Adjusting the update rate globally is inefficient.
EDIT:
Please implement subpixel jitter awareness to the RejectBasedOnNormal mode.
If I use half competent TAA(we plan to run post process edge AA before DOF to anti-aliasing staircased edges x2 subpixel jitter misses)
Lumen fails to remain stable on object edges due to no good, coherent fallback.
Please test with these r.AntiAliasingMethod 2(TAA) at 1080p, v-synced to 60fps :
r.TemporalAA.Quality 2
r.TemporalAACurrentFrameWeight .6 (with vsync)
r.TemporalAASamples 2
r.TemporalAAFilterSize 0.09
r.TemporalAA.Upsampling 0
r.TemporalAA.R11G11B10History 1
r.TemporalAA.HistoryScreenPercentage 100
r.TemporalAACatmullRom 0
If you are on a 4k monitor, use
r.ScreenPercentage 50
r.Upscale.Quality 0
Test if r.TemporalAA.HistoryScreenPercentage looks more clear/stable at 50 or 100
you’ll capture it anyway. you’ll figure it out. disassemble it. do a deep dive into the engine for a video. not this shallow bash style video disassembling the frame output. you can also pick up the engine source code and see how it works. maybe mod the engine. hmmhmm…
If you’re aiming for maximum performance, why not port Nvidia’s RTXGI plugin from version 5.0 to the engine you’re using? It was a highly efficient version based on dynamic probes, offering significant scalability across various configurations, and it runs on Nvidia, AMD, and consoles.
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.
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.
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)
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.
