So I found <this> post refering to a <livestream> where @DanielWright concluded that combining static lights and lumen was not a useful combination…
I just wanted to throw my 2 cents into this discussion.
Currently with Lumen, it’s still hard to produce environments with many lights, since each non-static light has a significant performance impact. This puts a hard limit on how many lights are feasible to use when using Lumen.
This limit would very much go away if we could combine Lumen with lightmaps. Performance-based switching would also become feasible this way (simply switch off Lumen for mobile, without having to make two completely separate lighting setups, for example).
It would generally be incredibly convenient to have, say, Lumen for the sun/skylight lighting (so you can have dynamic time-of-day, and all the other benefits) and baked lighting for the rest.
Moreover, since both technologies are already developed, shouldn’t it be relatively easy to just “add” lightmaps to the total Lumen result? I suppose Lumen reflections are more complicated, but in the livestream they said this part is on the roadmap anyway.
Yes, I am troubled by this issue. Lumen is only enabled when the scalability is set to high and epic. I hope to use lighting maps when the scalability is medium and switch to Lumen when the scalability is high, but unfortunately, when switching from medium to high, static lighting will not work. Is there a way to combine them?
As of a handful of months ago, UE_main received support for lumen reflections in lightmaps, so that is currently a solved problem for anyone interested.
Unfortunately, lumen GI and lightmaps can’t really work together due to a handful of issues, but it’s more fundumentally down to what would make sense from a systems perspective.
Lumen’s screenprobegather evaluates arbitrary scene radiance, from analytical light sources or emissive objects. If it is in the lumen scene, you’re paying the cost of evaluating it, even if you don’t ‘need’ it lit. Essentially, it’s hard to pay ‘partial’ costs for lumen features. Lumen reflections work because it can use the lightmap to terminate reflections with GI, but for lumen GI itself, it needs a surface cache and parameterized scene.
Basically all of that means that having lightmaps and lumen work together, even if it was feasable, is very unlikely to actually run better. Lightmaps eat up a lot of VRAM even if streamed (generally), and they constrain the scene to be static. Lumen’s various atlases and buffers also eat up a lot of VRAM, and require a fair bit of computation to boot. It’s not that static lighting and lumen can’t be combined together (lumen does this by sampling material AO instead of evaluating it at runtime), just that it wouldn’t really give any advantages to do so.
I’m not saying any of this to suggest your desires for more scalability/quality tradeoffs for lumen are stupid- lumen costs an arm and a leg for many games, and getting it to run at 60 FPS is incredibly hard- it’s just that the pipeline wouldn’t really work well with static lighting via lightmass. If you mean combining dynamic lumen reflections with GI, that’s totally viable. Similarly, baking out all the AO you can for static meshes and telling lumen to evaluate that will save computational time as well. And if lights are being a problem, try to replace them with hidden emissive surfaces in the lumen scene, they give excellent area lighting and are essentially free if you’re already paying for lumen.
Assuming you have the correct version of Unreal? It should just be allowed by triggering lumen reflections without GI, assuming you have lightmass data available. But this isn’t available on UE 5.2, just on _Main for now I believe. Will likely be available for 5.3 preview along with multi-bounce lumen reflections and a handful of other features.
I am on UE5-main, and this doesn’t appear to work. It falls back to SSR when Lumen reflections are enabled with lightmapped GI.
Do you happen to know the commit where this happened? It’s been a couple weeks since I built ue5-main but you say this happened months ago so I feel like my build should be recent enough
I would check in the lumen GI and feedback thread, I posted it there somewhere. I don’t know where the commit is alas. I believe there’s some specific settings twist to it but I don’t remember what it is.
Thanks, enabling hardware raytracing with hit lighting does work.
Is there any chance we will see lumen reflection support for lightmaps with software raytracing?
When this was originally announced as a planned feature I had hoped it would be an alternative to reflection captures, rather than just a replacement for the deprecated raytraced reflections.
I would be curious about that, but I’m wondering if it’s not already covered in DFAO? DFAO supports specular occlusion, and there’s no easy way I can think of to feed color information to SDFs without the surface cache (lightmap probe interpolation?), as otherwise you’ll be paying much of the cost of lumen already.
I can personally think of a fair number of scenes where proper occluder parallax would have made a much bigger visual difference than color-correct reflections. I think it would be a good feature.
I don’t think it really makes sense to use DFAO in a baked scene, since you can get actual correct skylight shadowing by simply using a stationary/static skylight. I don’t know if precomputed AO has the same specular occlusion benefits that DFAO provides though but the sheer difference in skylight shadowing quality would compensate for basically any reflection quality loss.
My main problem with reflection captures isn’t just the lack of correct parallax, it’s the fact that they leak like crazy because you end up having to rely heavily on sphere reflection captures.
It’s also incredibly difficult to use them in situations where you have a moving light, or need to change a light color for example, because reflection captures can’t be tinted or colored at runtime. All you can do is turn them on and off. On top of all that there’s a hard limit to how many you can place in a scene. Not even sure if they stream…
Anyway… I can understand if this is not reasonable from a performance perspective, I don’t really know anything about it, and I assume dumping resources into improving lightmapped scenes probably isn’t a high priority. I just kinda hoped
Main driver of this change is to cover all features of deprecated ray traced reflections so that we can finally remove them. Adding surface cache would be interesting, but it’s not a high priority as in general we are trying to move away from baked lighting.
If I may ask, what features are left that standalone RT reflections do support but lumen reflections do not? To my understanding, lumen reflections now support baked lighting and multiple bounces, so I cannot think of any other big-ticket items (although I’m likely misremembering).
At this point we should be covering all standalone ray traced reflection features and can safely remove those in a future release. Finally we will cleanup this confusion with standalone ray tracing features and Lumen
I see, so 5.3 won’t be shipping with standalone RT then in all likelihood? Or is it something further off?
By the way, I noticed that the experimental irradiance field path of lumen would crash upon initialization- is that deprecated, or just under maintenance? While I do know that is was pretty leaky, I think it could represent a good scalability option, assuming it actually was more performant than the screen probe gather.
My thought was to ‘just add’ the static baked lighting to the final result, after all the lumen calculations are done. Obviously you don’t want the baked lighting taken into account for the lumen bounces since it already ‘bounced’ in the static calculation.
Yes of course, with both systems using VRAM simultaneously there will be a hard limit. You seem in a much better position to judge if that would make the feature unusable than me
I would say the advantages can be very significant (from the perspective of designing environments, that is): When scenes are lit with many, many static lights (like a building with many rooms viewed from the outside or a street filled with streetlights), you become very constrained when fully dynamic lighting is required. In that scenario, using Lumen is effectively ruled out.
In the City Sample, for example, this is solved by completely removing streetlights and using only POM for inside buildings (so POM sort of becomes a substitute for static lighting). The moment you would want the option to actually go inside of a building in a scene like that, you would need more (dynamic) lights and you run in to issues.
