Lumen GI and Reflections feedback thread

That does seem appropriate, yes. I’ve had similar conversations before on this thread, with the general sentiment being that the current highest-quality path for archVis is baked lighting via GPULM combined with RT shadows and reflections. RT reflections support lightmaps, so it creates an extremely coherent visual presentation, and the lack of dynamic objects requiring acceleration structure rebuilding also makes reflections cheaper.

I’m more than happy to help @Miguel1900, I’ve struggled with rendering decisions in the past before and am happy to lend any advice I can. I cannot wait for these corner cases with lumen to be closed and we can fully embrace it as the default lighting pipeline, but for now I’m happy to be part of the journey.

1 Like

Lumen in 5.0 is definitely not production ready. Speaking of 5.1 however:

  • I don’t bother with SWRT. It’s too much hassle. So my experience is entirely with HWRT. Of course that’s me just tinkering with a 3070. Realistically if you want to ship a game you can’t target 3070 as a minimum, and HWRT might be too limiting for a game released today.
  • Lumen offers the highest quality in UE in my opinion. It looks much better than GPULM + RT reflections for some reason. The rough materials are better shaded in Lumen, even if you crank up RT reflections max roughness, bounces, etc. Mirror reflections are the only thing that look inferior. And well, potentially noise depending on your setup.
  • Performance is kind of usable in 5.1, at least with a 3070. 70-90fps on a reasonably heavy scene, epic quality at 1080p upscaled to 1440p
  • A scene designed with lumen in mind might look atrocious if lumen is disabled due to scalability. This is a big problem if you want to target a wide range of hardware
  • A “many light” solution is definitely needed, because you can’t have many shadow casting lights without killing performance. But this isn’t really a new thing, it has always been this way except for static lighting. The lumen direct lighting might solve this.
1 Like

I agree with you, that’s about what I’ve found as well. Lumen can handle different levels of material roughness better, although it imposes different content limitations than standalone RT might.

I agree on SWRT, I’ve tested it enough to know it can offer a lot of perf. over hardware RT, and you can even mix and match the two, but it’s non-trivial and you’re asking for a lot of time to tinker content.

I’m surprised mirror reflections look worse on a recent 5.1 build, they pushed an update to github to improve very specular reflections a few months ago. Small object noise is currently the biggest issue I see, and no one I’ve talked to has found a scalability lever for this.

I tested NVRTX’s RTXDI, their many light solution derived from an optimized version of ReSTIR. Higher base cost for larger many light solution, but it ghosts and blurs tremendously at fast camera pace. I didn’t tinker with the system enough to see if better behavior could be extracted, but it its’ current form it is simply not practical for a First-person camera. May work for 3rd person or top-down quite well though.

To be fair I barely tested reflections on 5.1 because I already find the default, low quality lumen reflections good enough unless you have a literal mirror.

I tested the high quality reflections on transparencies and it’s very nice. Although you probably don’t want to pay that cost unless your game needs it (like city sample, where it’s very noticeable on cars)

What I would like is to have some baked lighting/shadowmaps + lumen middle ground, either to have better performance than pure lumen, to allow for more complex scenes with the same budget, or to allow more scalability. I believe they mentioned lightmass + lumen reflections a long time ago.

But I doubt we’ll get much, if any of that. Most big UE4 games were already fully dynamic, either because the game was too dynamic, or because of iteration times alone. With UE5 we’ll probably have even less interest in any offline solution. After all, if we had the budget, who wouldn’t want to design levels using HWRT Lumen? Productivity is so high compared to lightmass obviously, and even compared to fully dynamic UE4 where you had to waste time trying to make a scene look semi decent due to the lack of GI. And that budget will probably be 30fps on consoles

They did mention that a while ago, although truth be told I’m still trying to understand the utility of that decision. RT reflections generally work very well with baked lighting out of the box, although I suppose it could be useful if you wanted SWRT alongside baked lighting for lower-end hardware.

By baked lighting/shadowmaps + lumen middle ground, how do you mean by that? baked direct shadows combined with dynamic indirect lighting doesn’t entirely make sense to me, unless you’re strictly talking about reflections.

And you’re right, many UE4 games went dynamic for ease of use or iteration utility, and I do believe lightmaps will gradually be relegated exclusively to mobile or VR games that can’t afford mass amounts of dynamic lighting. I think ArchVis will probably make the leap to real-time PT sooner rather than later, as they’re limited scenes that can afford massive quality.

Iteration is the biggest thing I love about lumen. Lightmap baking simply saps too much time, and they do offer a scalability method of using DFAO and SSGI if you need games to go below lumen, but that still won’t make a cheap game.

It could be a lot of things, basically anything where part of the computation is offline or cached.

The baked direct shadows do make sense. Basically the current stationary lights except only the shadowmaps, no lightmaps (the GI). I even think it kind of already works, probably accidentally.

They would be very useful for all artificial lights (so anything but the sun), because they don’t change position (so shadowmaps would stay the same), but it may turn off/on/change intensity (which you can currently do on stationary, but their GI will stay the same).

The benefits (compared to fully dynamic) would be improved performance. Currently on a fully dynamic lighting scenario, shadowing will be a good chunk of total frame time, plus require a lot of draw calls. That’s regardless of using lumen or not. Plus stationary lights can have better shadow quality than movable if it’s a soft light (although not as good as RT shadows)

And I think you could have almost real time iteration time. Because you don’t need to calculate the GI for lightmass (the expensive part), and the direct shadowing is very cheap to calculate I believe.

To be fair this has some overlap with shadowmap caching for movable lights, but I found these to be not that impactful because they would get constantly invalidated I guess.

The lumen reflections for lightmass would be cool, because, it would be (I guess) more performant than RT, not require RT, and less noisy on rough materials, which RT struggles on unless you crank the settings and kill performance. Basicallly improved cubemaps if you will (because instead of SSR falling back to cubemaps due to roughness or off screen, it would fall back to lumen (techically lumen itself handles the SSR)).

Start thinking out of the box :smiley_cat:

I had similar issues due to the 2:1 scale of my game (for gameplay reasons), and here (below the screenshots) are some of the tricks you can use to cover the things that Lumen cant do well.

This hall is 120m long, but there is only some visual “degradation” of Lumen:

Some of the “fakes” I am using to keep Lumen “in check”:

  • 2nd sun, that lights from directly below (this solves the “darkness issues” under roofs, which lumen has - should apply to your warehouse too.)

  • Spot light behind player camera, that covers the maximum FoV I offer. (This too solves “dark spots” or at least makes them less visible, but for walls.)

  • dont use emissive Surfaces for your lighting, use lights (emissive surfaces are useless for “our” use-case.)

  • use spot lights, and cover up their “circles” (if they appear) with the aforementioned fakes

  • use white, a lot of white. Lumen heavily relies on bounced light, therefore anything that is not white will start “sucking up” your light.

Some more examples:

every one of the 10 square shaped “things” on the roof contains a spotlight, and a rect-light(currently disabled) - they provide the “base lighting” where it would be too dark using Lumen (Lasers technically would provide light too, but due to a bug its disabled.)

Also note, how the Roof is lit enough, despite being 8-10m above ground:

This whole area here is mostly lit because of the glass roof, which would work fine in a warehouse too - just make large enough “holes” into the roof:

If you dont want the sun on the ground, then you can force indirect lighting with roof-windows like these:

If something still is too dark, spotlights, spotlights and spotlights (see roof here, there are plenty):

I still retain the fully dynamic GI, but I also made Lumens “faults” a lot less noticable, while allowing to simply disable all of this for performance reasons on low-end hardware.

==========
My results are far from perfect, but given that I am only a single person, the 2:1 scale etc - the results are very good, in my opinion.

We need to cater to Lumen, if we want to get it to work.
The most basic thing here is: Use White walls, Lumen needs it, as you can see in the above screenshots - it works wonders.

Also, if you are Instancing a lot, one of the two is broken with lumen (either HISM or ISMs, and HISMs still cull too early from Lumen scene.)

1 Like

It was a great post, @Yaeko ! Why did you deleted it?

I was making a try and comming back to tell you that you could also use just a Directional light (to “lit” the “sky sphere”) and a sky light with a high Intensity value, to bounce all around the scene. Well, anyway here you are my test:

Regards!

Its undeleted again - I kinda felt, like it could upset some readers/people, which wasnt my goal. (In the end I am just “some random guy”, even after all the time I invested into Lumen and trying to find bugs etc. People generally dont really like “randoms” coming around and telling them things, from my experience.)

I also didnt want to say something “wrong”, given the quirky workarounds I use - to some these will look plainly stupid. (My gameplay being built around lasers, that (if it werent for another lumen bug) emit light themselves… doesnt really help the whole situation, so i come up with “stupid things” at times.)
In the end, I too am just trying to make things work, learn new things, report bugs here, provide something useful.

Your factory image looks fine, thats what I would expect.

I also don’t know what I’m doing lot of times! Specifically with Lumen, now. Just trying and researching a lot. But I think it’s useful to publish our ideas and achievements. I don’t think anyone would be upset because of this.

Anyway, I’m also trying to not dirty the post (and I will not until I test the UE5.1 improvements), so I understand you.

Regards!

I think I understand what you’re saying, and a semi-cached method makes more sense to me. And you are correct on that, RT shadows are generally the highest-quality option but baked lighting can be very diffuse. And direct shadowing can be done extremely fast, although I’d be curious about the VRAM implications depending on implementation.

And I agree with you on lumen reflections. The way I think about them is that they’re basically parralax-corrected cubemaps, with the same low-resolution and distortive properties, but more correct to shape and scale. Either way, still a massive upgrade over the previous available methods.

I’ve found everything you’ve offered to be extremely helpful. In an ideal world, lumen evolves and improves its’ handling of the corner cases, and these workarounds become less and less essential, but until then tips like yours are instrumental in actually achieving a good and playable quality, imho. Besides, while the documentation is great for solving a lot of easy fixes, they don’t cover everything, and community knowledge is one of the most essential ways the really complicated stuff can become approachable. UEForums has solved more problems for me than I can count.

Flickering lights with lumen when I’m in play mode, enabling ray traced shadows seems to fix it but it’s not the best solution, I tried changing to shadow maps, disabling AA and nothing worked.

1 Like

The compression makes it challenging for me to tell if it’s aliasing, GI flickering, or direct light flickering. From what I see, it looks less like a lumen problem and more like something to do with direct light behavior, but I could be wrong.

I gotta say the video doesn’t show the problem very well I’ll try to record a better one.

I’m curious what causes this, because ray traced shadows fixes it completely.

Edit: Include Video.

The issue appears more often the more quantity of lights there are on scene, and it comes with stuttering.

@CastillaStudio Can you start deleting things of your scene until you get the most simple scene as possible, preserving the issue? That way, you could even share it, so the rest can check/test it.

How can I share it easily? my project folder is 50gb already.

Then, in a more drastical way, you can try copying the uproject and Config folder to a new folder, to create an empty copy of your project. After that, you can make a copy of your original map, but only with the walls and light sources, for example. You must corner the issue.

So, I found another interesting thing, when my metahuman is rendered the issue fires, and in the reflection you can see that the walls are being culled, I don’t know what to do now.

It’s interesting that RT shadows seem to be solving the problem. Out of curiosity, what scalability setting are you on? I’m seeing some big ghosting artifacts, and by and large lumen is only designed to work at Epic settings for interiors. High is tolerable for open-world settings, and it can’t really go much below that.