I’m having an issue getting light to pass into headlights on vehicles in a studio setting in Lumen with HWRT turned on and Substrate materials. This studio environment is entirely geometry / light based, (no hdri) and is primarily lit with bounce light (walls are illuminated and bouncing light into the car). Very little direct light is pointed at the stage. This is to mimic our studio’s physical photo set. All is working quite well in 5.5 with Lumen HWRT, except for this issue with the headlights/tail lights.
All the bells and whistles are cranked, and this is the result I’m getting. Seems like almost all the reflections are terminating on the headlight cover, instead of passing through and hitting the chrome inside the headlight.
My question is, is this currently a limitation of Lumen, or is there a setting/CVAR somewhere for Lumen to be able to calculate bounced light colliding with a chrome surface after colliding with and passing through a transparent material?
And I’m quite shocked, specifically about the mirrors quality. Gap between Lumen and RTXDI is HUGE. Any explanation about it, just to understand and out of curiosity? Any chances to get ideas from here to implement them in Lumen, maybe?:
Lumen is still an approximation that relies on various shortcuts to run in real time across a wide range of hardware, including consoles not just the latest high-end GPUs. In contrast, ReSTIR PT (path tracing) aims for accurate real-time simulation and depends on a proprietary denoiser if you disable it, the entire rendering becomes incorrect.
Lumen is already very demanding right now, even with all the existing shortcuts so Lumen Path Tracing probably won’t be around anytime soon.
I tested Lumen in 5.6, and I really hope we’re still far from the “final” version and that there’s a lot of development time left it’s so unstable and completely unusable on the main branch. I’m a bit concerned.
The main branch exists to be cutting edge. Frankly, it’s a coin flip if it even compiles. That said, I’ve been away for a little bit- what have they been adding to 5.6?
I was experimenting with fast Lumen updates for minimal ghosting again and I feel like something is off with r.LumenScene.Radiosity.Temporal.
With this enabled, changes from dark to light take about 24 frames to fully apply. It’s clearly visible when setting t.maxFPS to a very low number and watching the brightness change to slowly creep in.
With r.LumenScene.Radiosity.Temporal disabled, the update is significantly faster.
That’s somewhat expected. But I was surprised to see the default r.LumenScene.Radiosity.Temporal.MaxFramesAccumulated is 4. It takes way more than 4 frames to accumulate. I also get the same slow update when setting r.LumenScene.Radiosity.Temporal.MaxFramesAccumulated to 1.
According to LumenRadiosity.cpp a value of 1 should basically be the same as temporal disabled
Outside of temporal, there’s also time slicing (we only update a portion of radiosity atlas each frame). This is controlled by r.LumenScene.Radiosity.UpdateFactor.
BTW the main source of lighting lag is World Space Radiance Cache (r.Lumen.ScreenProbeGather.RadianceCache.* has controls for opaque).
I have included many ingame options to switch almost every relevant feature, so you can easily switch between PT and Lumen in the edition called “v2.2” (RTX Branch), to better understand the pros and cons. You can also download the “v1.2” (UE5.5) edition to get/understand the actual Lumen performance, as that’s an isolated version without the Nvidia code included in the RTX Branch.
PS: @Krzysztof.N , by the way, I have noticed when enabling RT Nanite Mode 1 (pressing ‘G’ in v1.2), the GI is destroyed, or totally different against normal fallback Nanite meshes. Nanite Mode 1 doesn’t work as good as Mega Geometry against Ray Traced light sources (still black patches, as in Mode 0, but reduced). Additionally, and regarding the previous post to this, the one regarding GI update speed, I needed to use “r.LumenScene.SurfaceCache.Reset 1” when switching from Day to Night, or the lighting would remain forever during night (?).
I’ve just tested the new Lumen version in 5.6, and the High quality mode is currently not usable. Global illumination shows noticeable artifacts such as splashes or flickering when moving closer or farther from surfaces.
While it may be computationally efficient, the visual instability makes it impractical.
Foliage rendering remains highly unstable, even with fully 3D assets and Lumen Hardware enabled.
Even at Epic settings, it’s far from stable. This becomes especially apparent when trees overlap in the background, where noise and flickering become very distracting. I’m unsure whether new console commands were introduced to improve this behavior.
I’m still having issues with vegetation and Lumen in 5.5.
For information:
The trees are fully 3D models, they don’t use any masked materials. Nanite is enabled, as well as Lumen Hardware Ray Tracing.
The problem is that it just looks terrible visually it’s extremely unstable, flickers a lot, and the lighting is very inconsistent. It’s honestly awful.
I tried increasing r.Lumen.ScreenProbeGather.Temporal.DistanceThreshold, which helps slightly, but honestly the improvement is minimal. It also introduced ghosting on the character in some lighting scenarios, especially when the character is lit by indirect lighting.
I’d like to know if there’s a real solution, or if this is just a limitation of how Lumen works internally. I’ve spent a lot of time tweaking values and testing tons of console commands, but nothing really helps. I really get the feeling that Lumen is just not friendly at all when it comes to rendering vegetation whereas other RTGI algorithms manage it much better.
Would the best option be to disable ray tracing/distance fields on the trees and try some material and SSAO tricks to avoid having them feel too disconnected from the scene?
I saw that 5.6 introduces a proxy system for RT, with a parameter that lets you bias foliage representation in the proxy to reduce AO based on the user’s preference. But honestly, for it to be “stable” (and that’s a stretch it’s still not really stable), you end up with almost nothing left of the tree in the proxy.
Looks quite good for me, can’t even spot the issue, really…
Lumen shivering GI blotches is a problem, but for this particular case (no monotone flat surfaces to expose the issue) it works quite well from my standpoint…
Would you mind sharing the tree, to play around? Just isolating it in a ‘reproduced’ scene, with blocking or whatever you consider to force the issue be very noticeable. All with a grey material, for example.
I don’t have a video, but I am doing the bajillion blades of grass (nanite) and over time and I get splotches between the blades, more pronounced if I use screen-scaling. It seems similar to what I am seeing in your video, when the leaves/branches bend, sometimes they get a bit darker than they used to be a second before. Particularly the on just top-left of center-screen.
I used r.TSR.History.SampleCount 32 to help address the issue. Not perfect in my case but noticeably better. Hopefully it helps you.
Thanks, but I’m already using DLSS 4 (preset K) in 4k anyway with DLAA.
It still doesn’t provide the level of stability I’m aiming for no ghosting, no flickering, and stable lighting in the trees like other RTGI solutions can deliver.
Lumen is still very temperamental when it comes to providing stable GI in foliage, even in 2025. I imagine that won’t change anytime soon probably not until a completely new algorithm comes along in a few years (UE6 ?).
Yeah, feels like it - Lumen reached it’s top shape in 5.5 and there will be no more substantial improvements, only polishing, till UE6 with per-pixel path tracing. Adapting to the current state of things is the way it seems…
5.6 Lumen looks far better now that shortrange AO has proper support for independent temporal accumulation. It’s also much more stable with modified TAA.
Lumen reached it’s top shape in 5.5 and there will be no more substantial improvements, only polishing,
It’s still too expensive and splotchy. Right now all major RT lit games use DDGI+ScreenSpace GI.
Days Gone also does probe+screenspace GI without RT. Unreal doesn’t have a quality indirect option for forward or deferred. Skylighing is awful, lightmaps take long+too limited and Lumen should look perfect for the cost it introduces.
if you don’t need dynamic scenery you can still bake lightmaps or just lowres proxy gi+ao maps and volumes. you can use lumen only for reflections and megalights for static or dynamic lighting with all shadows. plus you could abuse ML to fake bounces where you want or need them. it’s a fixed cost.
those lightmaps are also required when you put mirrors or reflective glass in a scene, cause the surfache cache looks disgusting in them. yes. there was a cvar for that before, but it’s currently not functional. also if you run a full config you can still switch lumen on and off depending on the scene you render. full artist control. i guess you’re not an artist and never tried things to work around those “issues”?
