I think you should check the Meerkat demo. Maybe not related 100% directly (or not only) to Lumen GI, but quite sure indirectly, at least. Or if you could report it to the respective team…:
With Lumen enabled: black spots on clouds. Eagle shadow visible even when it’s in Game view (it wasn’t visible on UE5.0, working fine). Virtual shadows “near clip” too far from camera. Global Illumination non existent or very weird:
In addition, in that UE5.0 RT GI enabled, you can see the high 70FPS framerate. If I enable Lumen, it keeps more or less the same, that’s ok, but if I additionally enable RT shadows on UE5.0 the framerate is higher, like 80FPS. However, if I do the same in UE5.1, FPS with Lumen are lower, like 55FPS vs 60 of RT GI. But, if I additionally enable RT shadows, the framerate goes to somethig like 4FPS! (versus 80 in Ue5.0)
In summary, you can create a Meerkat UE5.0 and 5.1 projects, and compare them using Lumen vs Lumen, but also RT vs RT and RT vs Lumen.
It’s probably a CPU bottleneck due to this high amount of draw calls then.
Have you found what’s causing it? I’m actually pretty curious.
Might it be an issue with occlusion culling in VR when loading the night scene?
Did you try enable/disable Round Robin Occlusion to see if there’s any difference?
IMO, the team should focus more on improving HW-RT Lumen and increase its speed compared to Software-Lumen. Otherwise, RT cores and Ray accelerators are being wasted and a lot of performance will be left on the table. @jblackwell @
I am aware that Software and HW-Lumen are different techniques (Signed Distance Fields vs triangle Raytracing) but there must be ways that combine the benefits of both techniques and speed up the calculations using the additional hardware in modern GPUs. 4A Games did an amazing job with their GI solution in the Metro Exodus Enhanced Edition that runs with HW-RT on consoles at 60 FPS, so I am pretty sure it’s possible for Epic to find a way to achieve that as well.
I’m trying to get the Lumen GI to look more like the path tracer. I really don’t like these dark AO-like shadows in the corners in Lumen compared to path tracing, but I can’t find a way to get rid of them.
I’m not understanding how the Lumen Reflections “Quality” setting is supposed to work. The tooltip says increasing the value is supposed to reduce noise. But it does not seem to be the case…
When using the Surface Cache as the ray lighting mode, the Quality setting appears to do nothing at all
When using Hit Lighting, increasing the quality makes the noise significantly worse the higher the setting used.
Using 5.1 with Lumen set to use hardware raytracing. The reflective material here is just a glossy mirror (albedo: 0.85, metal: 1.0, roughness: 0.2)
Anything above 4 isn’t worth using/trying. Increasing screen percentage/resolution helps a bit. light sources themselves are decently stable but anything emissive or reflections of that are pretty unstable.
Have you checked out the Lumen Team’s Siggraph presentation? Wright shared a link with me in the forums, and they also had a presentation on how ray-tracing large scenes works.
From what I’ve read and understood via the presentation and Github comments, they have already implemented perf. improvements for hardware lumen that didn’t make it into a few of the UE5 demos (Fortnite I don’t know about). It includes how they handle distant geometry via the far-field, how BVH trees are constructed and streamed, and a few other things. They did mention that that performance on PC may be improved when Unreal Engine gets bindless resources for ray-tracing, so there is room to go.
I agree with you that 4A’s implementation of RTGI in metro exodus is extremely competent. From what I’ve learned/played however, their system only robustly handles diffuse, opaque geometry; shinier, transparent, and alpha-masked geometry see limited or no support. Lumen trades performance for feature robustness in this case, but there’s nothing to say the tech couldn’t be made more scalable.
In terms of mixing SW/HW RT, I wouldn’t know the performance implications necessarily, but I’m curious what you see as the benefit. Lumen can hand off between different ray-tracing methods, so I suppose the performance would determine how useful it’d be.
For maximal tracing quality, you can always go lumen.screenprobegather.referencemode. It’s designed to match the path tracer by just cranking the ray count and disabling importance sampling, with generally good results.
Going off of the lumen team’s talk, the ‘AO-like shadows’ are their contact AO implementation to add some shadow resolve that lumen’s screen probe method can’t handle. There’s most likely a CVar to remove them, I wouldn’t know it off the top of my head alas.
I brought this to @'s attention, he mentioned that glossy reflection quality is a priority for them to fix. There are Cvars that let you raise/lower the roughness value of surfaces for lumen to trace better with, but that could mean a lot of art direction changes with legacy content.
I know they scrapped cone tracing for pipeline consistency/ technical issues, but I’m wondering if they’d consider bringing it back for SWRT. From all the lit. I’ve read, cone tracing can integrate varying roughnesses extremely well, and even the light leaking/over occlusion seems less distracting than the temporally-unstable fizzle.
Soryy for the late reply - your post totally escaped my attention. I haven’t found the cause. Activating RRCulling doesn’t do anything. Just did a new test - some objects were added to the scene since my last post though;
Day-GPUlightmass: 667 drawcalls
Day-Lumen: 1035 drawcalls for 5 moveable lights: 1 directional, 1 sky and 3 pointlights
Night-GPUlightmass: 650 drawcalls
Night-Lumen: 2975 drawcalls for 47 moveable lights (insane I know - just for testing Lumen)
As for a CPU bottleneck, I’m on a 5950x and its barely used for 20% in the Night Lumen scene. The rtx3080 is at 99% though.
Hoping 5.2 will come soon with some new improvements for Lumen & VR
Has anyone managed to get an ocean to reflect inside of Lumen reflections? (That is, one bounce with color instead of black.)
Even Epic’s water plug-in is not visible in reflections (though apparently you can enable them via a console command, which I wasn’t able to get working but Epic’s plug-in looks like Fortnite anyway and we need more realistic water).
Yes, one way is to use the Raytracing Switch in a highly reflective material to revert it to either a color or preferably some kind of environment map when calculating RT. I have a water example in a thread about this topic. I also have a YouTube video about it.
I believe in the current lumen implementation that it’s very difficult to impossible outside of screen-space. There’s no easy representation for the lumen scene to reflect water color correctly, especially considering how SingleLayerWater is made up of a lot of shader tricks and isn’t as physically based as other parts of the engine (laymen’s terms).
Theoretically, you could represent the ocean in software RT like this: Use the water height to drive a heightfield representation in the lumen scene (just like how landscapes are represented), with stochastic translucency to account for light partly reflecting off of and scattering into the water. That may even be something a tech artist could set up without programmer intervention, but it would certainly be a hack.
I don’t see an easy way to do anything for HWRT though: the densely, dynamically tesselating surface with constant movement would likely have massive BLAS update costs under the current lumen paradigm.
A while back in the lumen thread Wright mentioned the lumen team getting close to supporting a form of multibounce reflections with the radiance cache as fallback. While this isn’t quite the multi-bounce hit counter I think many of us wanted, it does serve to alleviate a bit of a content bottleneck in the form of no reflections being available in the lumen scene.
I love all of your hacks and strategies @BananableOffense , I think they’re an amazing asset in so many scenes and circumstances, but I also believe lumen having native support for these technologies without artist setup will be the key to seeing larger adoptation and freedom of workflow.
Having an issue with raytraced lighting popping in & out? (Bottom of the door frame) There’s some strange filament/solar flare looking rays coming from the door frame too. Any ideas what is causing this? I am new to UE so it’s most definately something I’ve done wrong but hoping for a solution as I can’t seem to figure it out.
I believe the first thing you’ll want to do is disable all post-processing effects, to eliminate the possibility of bokeh, bloom and/or lens flare causing the issue.
Assuming you’re using lumen (this is the lumen thread), then my guess as to what’s happening is that your mesh is emitting more light in the lumen scene (don’t know if it’s emissive or not) than the screen traces are recognizing. Thus, when the object becomes on-screen again, lumen decreases the amount of lighting.
Given how the flares appear and fade, it looks like some sort of temporal ghosting, which tends to happen when bright objects become occluded or revealed.
I have cleaned a basic scene I was using to test Lumen since time ago. It shows a good amount of weird things. One of then, because it even seems to be a regression from v5.0, is this light leaking:
But there are some more. In that scene you can also check:
Almost any Ambient occlusion in small objects (like the mouldings)
Black reflection surfaces
Strange translucent reflections behaviours (refractions?)
White halos around the huge fruits
Emissive light leaks
Some textures always blurry (in UE5.0 they always fully load, and texture streaming is disabled)
I’m sharing this scene with all of you, so you can make and share your own researchings. All furniture models are from Quixel Bridge:
Well, this is just not some random cvar that makes things randomly just look better.
“HELP for ‘r.Lumen.ScreenProbeGather.ReferenceMode’:
When enabled, traces 1024 uniform rays per probe with no filtering, Importance Sampling or Radiance Caching.
r.Lumen.ScreenProbeGather.ReferenceMode = “0” LastSetBy: Constructor”
This will make things look better, but at an extreme performance cost.
