level created by ue4arch
2 Likes
for me that should be optimized / fixed cause isn’t production ready?
FIXED but it cost alot:
r.Lumen.ScreenProbeGather.DownsampleFactor 5
FIX
also in PPV - but cost even more - similiar result (need to be set to 6 value to see)
this command help a little but it cause smearing:( :
r.Lumen.ScreenProbeGather.Temporal.DistanceThreshold (type number)
smearing
@Krzysztof.N Is there a global illumination system planned that would be lighter than Lumen, possibly allowing for GI baking and the interpolation of various scenarios, perhaps with a probe-based system? Lumen is very resource-intensive (even though performance can be optimized with various tweaks, it still remains quite demanding given the current PC setups most players have).
It could be useful to have a GI solution where developers handle the pre-calculations instead of passing the cost onto the player, which is unfortunately still far too high for players’ hardware.
Not sure if I understand this question correctly.
The main cost of Lumen is tracing GI and reflection rays per pixel, but this is also what allows it to skip baking, unifies lighting, reduces leaking to minimum and doesn’t require any parametrization like UVs.
If you start baking GI and reflections into probes, then basically you arrive back at Lightmass + reflection captures, which we already have in the engine.
I’m talking about a solution similar to what NVIDIA’s RTXGI was, for example: probes that could be dynamic, very low-cost, and adaptive to scene changes in real-time, while also being bakeable if needed. “The Final” uses it as well, for instance. 
It was less precise than Lumen, but in terms of computational load, it was very lightweight.
So you mean DDGI. The issue with DDGI is that by default probes are being placed in a regular grid around the camera, which means that you need to have really thick walls to prevent leaking, and some things like non-axis aligned walls, doors or cars just can’t be really handled by it as you can’t make them thick enough for the low-res VSM visibility.
Also VSM used by DDGI makes things look weird, as it basically looks like a sharp shadow casted from the center of the probe. Imagine that you have one probe in a room with a table. Now everything under the table will either cast a black shadow or will leak if you force reading from nearby probes.
It works kind of OK for outdoors, where leaking isn’t a big issue, but hen you start adding indoors now you need to somehow mark outdoors/indoors or manually place probe volumes to fix the issues. And if you manually place the probe volumes based on the scene geometry, you can’t really handle geometry changes.
Now if geometry needs to be mostly static, why would we even trace any rays at runtime? Tracing rays is pretty expensive so why not cache ray hit points and just relight hit points at runtime using a cached GBuffer? Baking form-factors also allows for better visibility functions than VSM, making it look more like GI than a point light shadow. So now we again arrive back at Lightmass, but with an “Enlighten” twist added to it. Which I believe would be a useful addition, but it’s not really Lumen at this point, as it has more in-common with Lightmass.
1 Like
Interesting, yes, I’m referring to DDGI. I believe that in their solution, Nvidia allows for setting an approximate global DDGI, as well as a much denser one attached to the player.
I’ve already made several general tweaks to Lumen in my game ( A Silent Desolation on Steam ), but I still can’t reduce the costs as much as I’d like. That’s why I’d love to have the GI calculations only occur at key moments (like when the directional or skylight moves) and remain inactive the rest of the time. However, I imagine this isn’t so simple.
Also, baking with GPULightmass takes too long and is completely static, which isn’t great 
2Maenavia - recently I’ve finished “The Talos principle II” and it’s a quite nice example of UE5-based game, with tons of foliage and it’s still runs fast enough with DLSS set to “quality” (monitor resolution is 1920x1080) on maxed out graphics, so I’ve got 50-60fps for my mobile RTX 3070 (desktop equivalent is ~RTX 2080 I guess). And it’s clearly Lumen lighting - spotty & moving GI artifacts at 50+ m distance are there, reflections also Lumen (clearly visible switching between screen-space and Lumen cache on water). Maybe worth checking out how they did that (there was a video on youtube from developers, as far as I can remember), at least if those numbers looks desirable for your project.
MOAR screenshots if needed.
1 Like
Taking this discussion, @Krzysztof.N ,
If the main limitation of the DDGI are the probes, wouldn’t be possible to automatically set their spacing based on geometry? (More dense around them, like in Importance Volumes).
But, more important and more “current”: why keep hit points relighting, if there have been no changes in light sources nor geometries? I mean, if lights and geo is keeping their same values, wouldn’t be possible to keep the cache and lighting “static”, without the need to update it in every frame? And only do it if anything changes (and only around that change, not in the whole scene).
talk about lumen freezing? you can do that using a cc. be aware it will freeze with the importance/lod in place where you froze and will not update or enlarge or shrink or compute any surfaces tiles beyond that point. literally frozen.
lumen is like gpu lightmass with lod for performance. it needs to evaluate the lod from the player position to update. performance management. you do not want full updates for the whole world. and partial updates may introduce propagation glitches and hitches in the lighting. that’s why it is temporal and runs all the time. gotta deal with that. hmmhmm.
you could tick that freeze/unfreeze with an interval. the consequence is you gotta run a couple of frames for the temporal update and you loose surface cache reflections.
(nvm… the edit. i did not find a bug. just left an emissive light that looked truly static. weirdge.)
Have you seen Lumen Performance Guide? There we propose a following scalability scheme:
- Epic GI + Epic Lumen Reflections
- High GI + High Lumen Reflections
- High GI + SSR
- Medium GI (DFAO)
- Low GI (Unshadowed skylight)
“High GI + SSR” is what we usually use on XSS, which should be comparable to lower end PC GPUs. Is this still too expensive? Can you show a ProfileGPU with async disabled (r.RDG.AsyncCompute 0) and explain what performance are you expecting there?
Yes. Lumen caches the most expensive things in screen space, which allows to not be limited by parametrizations like probes or lightmaps, and to automatically adjust quality to what’s visible on screen. The downside is that screen space is a lot of data and there’s always something changing, so you need to recompute a large part of it each frame.
There are also a few other caches like World Space Radiance Cache or Surface Cache, which employ aggressive caching based on this assumption that usually things don’t change in the scene, but they still need to update slowly as tracking scene updates would be even more expensive.
If you want to cache more aggressively then you need to move away from screen space and cache your lighting in e.g. world space probes, like DDGI, but this comes with various downsides. We did experiment with it and there’s a prototype under r.Lumen.IrradianceFieldGather, though it seems to be broken now. But it just not clear whether a grid of probes around camera would be a good tradeoff. There’s lots of leaking and other issues and the only way around them is manual volume placement. Runtime DDGI probe update may be expensive too, as you need to trace a ray and then evaluate material and direct lighting at each hit point.
So basically at that point it feels like this solution would be in this weird spot between Lightmass and Lumen, where it’s neither fast enough to cover all Lightmass plaforms (mobile, Switch, VR), nor good enough for Lumen platforms (consoles, PC). It still may be a good solution for some games, just like LPV was, but it’s unclear whether it would be used by many engine users.
Yes, it’s possible, but it won’t fix all the issues. The general limitation is that probe has limited resolution and can’t represent lighting changes between two probes. DDGI augments that using VSM as a shadowing function, but it’s a very lowres shadow map, which behaves just like you would expect a 32^2 shadow map to behave :). The problem is that those lighting changes aren’t just small scale indirect shadows or similar detail, but it maybe be for example outdoor lighting leaking indoors and breaking the entire scene.
You can’t also increase the amount of probes too much, as their cost grows really quickly due to them being a volumetric representation. Like if you would want to get per pixel quality instead of a single value per pixel you would need to have ~8 probes, where each one has like 64 values for each pixel.
Usually it’s just impractical to track updates. A door opening may influence half pixels/probes in the scene, but to know which ones you would need to trace rays… But if you only trace rays for entire scene if something changes in the scene then you either get hitches on any small movement or some of those movements will result in incorrect lighting.
Yes, but it could move towards a solution like Enlighten, where only form-factors (visibility) is baked, but then you can adjust your lighting in real-time. That feels like a good tradeoff and likely could cover all Lightmass plaforms.
1 Like
Yes, I’m already using all of that, and performance is generally good on my end. However, the lack of scalability with Lumen on low and medium settings can sometimes make it challenging to reduce costs. I need at least a minimally acceptable and stable global illumination because the game requires players to use their flashlight to explore in darkness, so simply disabling Lumen isn’t an option.
From what I’ve seen (in GDC talks or on their YouTube channel), Enlighten does indeed seem very efficient. It’s not perfect, but it would probably be a very nice middle-ground solution to explore with this kind of approach.
If this is mostly about a single flashlight then LPV would be a perfect solution for scaling down. The Last Of US used it on PS4 to get some really nice results. LPV has pretty good quality and is cheap, but unfortunately doesn’t really scale beyond a single light source, so not the best fit for UE where we try to keep amount of features and complexity manageable through building more general solutions.
1 Like
nice tech talk. where would the irradiance cache sit in this? it does not have a visualizer. or is the world space probe grid? this is all of it.
i could defo see the leaks happening. yes… i know the limitations of radiance volumes from 3.x blender eevee. they gotta be authored volumes to get the light details where required. and need a couple of traces. certainly not realtime material. yo
It reuses world space radiance cache to spawn a new grid of probes. Each probe stores depth in order to do visibility testing DDGI style and after tracing is converted into irradiance. This thingy replaces final gather, so instead of using ScreenProbeGather it does final gather from world space probes. Basically a DDGI prototype.
Though it was done like 2 years ago or something, so likely nowadays is completely broken :).
2 Likes
The visuals also need to stay consistent across different scalings, just a bit more approximate and less precise between settings like high and epic. Currently, Lumen really lacks the ability to scale below high. It would be beneficial if we could lower it further without making the entire rendering unstable or overly temporal, for instance. Many players still have lower-end setups on Steam (RTX 2060 and similar) and are somewhat left behind in the current state.
That’s why I had thought about Nvidia’s approach with their dynamic probe, while the rendering wasn’t as precise as Lumen, it provided a lot of scalability to run on a wider range of hardware. Even if it’s naturally less precise, it’s not a big issue it’s often an acceptable visual/performance trade-off.
DDGI was poorly implemented
which means that you need to have really thick walls to prevent leaking,
You and @Daniel_Wright of all people should be aware of the solutions made for this problem.
For GI and baked scenarios.
low-res VSM visibility.
Why are you assuming we want to use VSM? Nanite is 101%+ slower than optimized topology and VSM’s abuse temporal AA/Upscaling smear. This is the MOST voted feedback regarding UE.
Stop ignoring it.
You could also work on baking info the visibility of probes. Baking probes around static objects and then only dynamic objects such as doors darken indoor probes dynamically.
Have you seen Lumen Performance Guide? There we propose a following scalability scheme:
Yes, and medium promotes garbage quality compared to 8th gen world lighting systems and Lumen is too exspensive for the majority of games(which are made of around 70% static objects, not 99% not 30%, 70%)
nor good enough for Lumen platforms (consoles, PC).
The spoltchyness of Lumen is kinda insulting to 9th gen consoles so not sure what you’re trying to infer here? Infinite bounce does not make up for the ghosting, poor normal rejection logic, the noisy AO nor cost in static scenes.
You can’t also increase the amount of probes too much, as their cost grows really quickly due to them being a volumetric representation.
Yeah, that’s why we need a more optimized layout for mostly static scenarios. It’s shouldn’t be volumetric, it should be based on a hierarchy of distance between static geo.
Yes, but it could move towards a solution like Enlighten,
And 3rd party studios use UE to move away from 3rd party tools.
Enlighten doesn’t solve the static room scenario where a window or door floods the scene with light via interpolation.
I would stop bringing up UE’s baked solutions like lightmass since it’s a horrible and outdated system. It’s extremely heavy on memory and has severe leaking issues. Several studios and engine producers during 8th gen moved away from lightmaps in favor of interpolated baked solutions. Quantum break, MGSV, The Division, yet look better and perform better than your suggested medium scalability.
When UE was announced you guys talked about how you guys noticed was was missing in UE titles. Geometry and lighting. Well UE makes both those issues worse. Most games are not fortnite. Most games are static environments(that need darkening from dynamic objects like doors, moving lights etc) and dynamic lights. UE has no system that caters to this scenario that doesn’t harm performance drastically or even match the quality achieved in 8th gen games.
Many players still have lower-end setups on Steam (RTX 2060 and similar) and are somewhat left behind in the current state.
I’m talking about the poor quality being produced on 9th gen consoles which even that hardware doesn’t stand against with.
Thousand of people are sick of the quality being produced from UE’s systems.
Again, in case you missed it, read my suggestion for Lumen’s temporal normal rejection issues: Lumen GI and Reflections feedback thread - #1929 by TheKJ
I’m in contact with developer who will be releasing a cheap(as in FXAA cheap) post process AA that can run beneath the TAA(including DLSS, TSR, etc) values shown there since it doesn’t do well jagged edges.
Please stop assuming devs want to abuse TAA’s issues. This is has mentioned several times in the forums for years and now its officially the most important issues to the voting community
i think you failed on the buzzword there. vsm in radiance probe lighting i think refers to variance shadow maps, not virtual shadow maps. what i can google it’s the coarse shadow/depth info baked into the probe.
baking static probes is basicly what lpv, irradiance volumes and/or the volumetric lightmap is. updating those is maybe not hard but compute intensive and you may still get artefacts. cause the grid resolution is limited, the grid - if not authored - is bound to the world grid, directionality is not there but matters in many case and getting a good average look needs balance and propagation between probes. was all explained by krzysztof.
the whole probe lighting tech is limited, cause you have a static grid size, maybe some grid lods, no detail refinement and rng sampling strategies. cause you can’t shoot tons of rays per frame. realtime GI is a coarse solution and temporal.
your whole instability rant schtick ignores the fact that every realtime gi solution is temporal. even the ea engine needs a couple seconds to “converge” (i call it “stabilise”). you look at static images and say “this looks good” and has some sort of millisecond budget, but you miss the point that it’s a screen shot. in motion this stuff is still noisy. and will continue to do so. and it’s compute intensive as soon as you introduce new data. that’s why it runs all the time and spreads computation across multiple frames. temporal compute load.
somebody at valve® at some point said in a tech reveal “noise is your friend”. seems it’s not yours. endless battle tho.
at some point we may reach stable filmgrain convergence, tho. i’m sure.
2 Likes
I’m not saying they shouldn’t. I’m saying they should resolve without incompetent/abuse TAA such as DLSS or TSR which Lumen for the past 3 years in dev time still cannot do. Nor can Lumen handle 2x subpixel jitter without breaking into a flicking mess.
You’re also completely wrong. SVOGI, radiance cascades, and you’re not exactly defining what “realtime GI” means. MGSV uses large SM and accumulates lighting in real time, The division computes bounce light in real time. Realtime does not mean shooting optimization and efficient caching in the foot.
you look at static images and say “this looks good”
If that where true, I would love TAA and DLAA. But no, I’m the only tech influencer showing how poor motion looks in games nowadays. I literally just posted here talking about the motion instability from Lumen regarding subpixel jitter in motion.
i think you failed on the buzzword there. vsm in radiance probe lighting i think refers to variance shadow maps, not virtual shadow maps.
Fair enough, though I should continue to advocate for Lumen’s independence from Nanite as they have stated they are not focusing on doing so.
back to TAA rant? ohh well… -_-
this is a whole different topic away from lumen.
in general… deferred rendering computes raw vaules per pixel. there’s no easy way to antialias that. you do frame disassembly. you should know what a raw output buffer looks like. now think about how you would code a shader and do some math to filter that. not just complain about what’s not working in your opinion. do it better.