I would prefer that they create some kind of lumen static light that generates quickly, keeping the pixel information in the same place as the nanite (actually I have no idea what I’m talking about 
)
Ah, I think I see some of your logic here. So, you’re concerned that lumen performance tanks too badly when too many dynamic lights are on screen together?
As of right now, lumen is only an indirect lighting solver (although they are experimenting with lumen handling direct lighting as well). You are right in that lumen performance would degrade significantly as it’s handed more and more lights to process, but lumen is designed to pick the most important lights in the scene and only sample those to a certain limit (at least if they implemented the smarter sampling they said they would). Basically, instead of lumen costing more to evaluate GI from more lights, it’s instead limiting the # of lights that can contribute to GI in ways.
Pretty much all of this logic (the noise vs. perf. vs. light # tradeoffs) can be adjusted via CVars. For example, you could probably have more dynamic lights by having them noisier, or have fewer, but better-looking GI, etc. It’s all about what decisions you want to make performance-wise.
There may very well be good uses for mixing lumen with static lightmaps on lower-end hardware (cheaper dynamic outdoor GI mixed with very clean baked indoor GI), but between the VRAM management, the workflow limitations, and the divergent software paths, I could see it getting quite complex to manage
What about this?
As Lumen relies in temporal accumulation, it could still do it but without resetting the process endless. If lumen could be calculated for the whole scene once, and nothing is changed after that (nor lighting nor actors), why to update the Lumen calculations again and again? It could store the data in some way, isn’t it?
2 Likes
Being able to see the final light in the editor should be a given. I’ve been making lightmaps for 23 years, I don’t want to die making them. We need forward solutions, not backwars solutions, and can creates a static lumen might be the best solution for use in coffe machines computers.
2 Likes
You are correct, of course. It is indeed direct part of the many direct lights that is crashing performance. Again: imagine the City Sample with streetlights. Right now this is impossible to set up and it relies on emissive only to achieve the nighttime lighting.
In fact: a good workaround - that could enable a great many things - would be the ability to hide (emissive) meshes in the viewport but have Lumen take them into account. Probably very hard to achieve, but would be amazing 
This is already possible, but requires disabling screen traces for diffuse indirect light.
Also they can’t be hidden from offscreen reflections unless you’re using hardware raytracing with hit lighting. This was discussed more in depth here: Emissive lighting with a hidden/invisible object
At the risk of sounding stupid: How do I disable that?
Run this command in the command prompt: r.Lumen.ScreenProbeGather.ScreenTraces 0
There will be a loss in quality, though depending on your scene it may not be noticeable.
1 Like
And it does not affect reflections, so the SSR component of lumen won’t be broken.
Screen traces generally make a bigger difference in scenes using SWRT because the mismatch between the Gbuffer scene and the lumen scene are much larger. At hit lighting HWRT, I’ve found it’s generally better to disable screen traces because the imprecision of the depth buffer causes strange lighting discontinuities compared to the hit lighting.
1 Like