Same for me 
What takes the longest for Lumen GI to compute? Is it tracing SDFs, materials color, generating the global SDF, radiance probes?
What Lumen(and UE) lacks in comparison with other engine GI methods is the ability to take advantage of static objects. Lightmaps in UE are broken with leaking and memory and have alot of limitations regarding destructible objects.
Several Engines have used forms of baking reliable(static) world information, many games are static with dynamic lights and/or have anti-lightmap memory situations. But the only design Lumen makes sense for is FN where everything is destructible. I’ve already suggested interpolatible volumes, but more and more games are showing how wasteful Lumen GI is for their static worlds with basic interactions. The Robocop game and hellblade 2 are perfect examples.
This is why I’m wondering: What takes the longest and what’s most important to Lumens image(and what makes it difference from other GI methods like SVOGI?) I know ref is path traced.
Also, Lumen uses blue noise which doesn’t really look that good to be honest. MXAO uses the bayer matrix to reduce post process fixing.
this doesn’t even look that great. tbh. got some obvious errors cause it’s screenspace and basicly only can use the depthbuffer in reshade, afaik. just another fancy buzzword ao implementation.
using the normal vector you’d get more accurate obstruction. i mean… it’s still doing the math using the depth buffer to test for depth based obstruction. so… whatever.
the form of noise doesn’t even matter. it’s changing directions of vectors. those random samples always are accumulated or will need to be smoothed.
it was just a temporary daily build issue. try again and it’ll work. i’m cooking, rn.
1 Like
Am I correct in understanding that Groom Hair just straight up doesnt render properly in Lumen ray-traced reflections ( in strand mode )?
well now… pretested the stochastic direct light. it adds another layer of noise to safe computation per frame. result is decent at normal playing view distance from screen. the dev gotta use detailed textures. i also found shadow mode 2 for the reflections. at this point filmgrain is automatic. 
it looks good, but it’s kinda heavy in motion. i mean… mirrors are not perfectly stable motion and softshadows add the xtra noise. if the seed per pixel would match, maybe it would be lower. could converge all of it into… well… automatic filmgrain. no clue if this would work, tbh. i’ll for sure rethink doing overcast scenarios and lots of area lamps. there are limits. yo
volumetrics are currently nonfunctional. i did not check that light integration.
1 Like
A quote from this article: https://www.unrealengine.com/en-US/tech-blog/lumen-brings-real-time-global-illumination-to-fortnite-battle-royale-chapter-4
Other quality improvements came by surprise. Lumen GI downsamples heavily in order to fit into a four millisecond budget. This makes noise more noticeable, distracting from the game experience. We were able to reduce noise greatly by integrating NVIDIA’s Spatiotemporal Blue Noise, a technique that pre-optimizes noise patterns to cancel out quickly when accumulated over multiple frames. This gave much cleaner indirect lighting without requiring any more rays to be traced.
This accumulation is reliant on garbage TAA and/or expensive TSR. This is a major issue in the industry that Lumen current perpetuates. Lumen does not resolve this noise on it’s own. That is a major issue and it’s been solved in better ways.
nice screenshots. i’m not nose deep into the engine yet, but not all of it just noise that is easy to solve.
ofc lumen gi is downsampled. lumen is like realtime gpu lightmass and indirect probes on screen for dynamic meshes. compromises have to be made for performance. motion vectors are a thing too. i’m very aware of that. you can’t render every pixel raytraced every frame at interactive framerates. temporal accumulation is the way. gotta work with it.
if blue noise is the way the denoiser is trained you gotta follow the algorithm. quick math.
temporal accumulation is the way.
I can think as far back to MGSV where light is computed at half resolution and then upscaled per-frame. And very lite accumulation can work(3 frames, over 4 and you’re pushing it, Lumen uses 10).
Temporal accumulation is never been the main problem, the problem is needing TAA/TSR still for bad noise even though Lumen has its own accumulation.
Effects should not be tied to such broken AA designs. And TAA can be good if it’s adheres to certain rules(spoiler, good taa can’t hind broken effects)
Thanks for the demo
Is it much faster than non-stochastic mode? I think the idea is similar than stochastic shadows, better performance for small tradeoff in quality?
This was literally the first commit for this, I am sure there will be some improvements down the line.
This would mean 5.5 gets changes for higher quality (Hit GI) and better performance (stochastic lighting)
i did not test fps. i’d have to do that on a cold day. summer weather is not too great to run my laptop unlimited. sry
Hello fellows! I hope you are all doing great!
By any chance do you guys know what could be causing this strange light “flickering”? 
This is giving me headache trying to find a solution.
Thanks in advance 
I have a problem with metahuman
Likely there’s some mismatch between Lumen Sceen Traces tracing what you see on screen and Lumen Scene. Try enabling Lumen Scene Overview View Mode and check what actually Lumen sees there. You can also disable screen traces in order to prevent view dependent lighting, but it may reduce quality in some spots.
1 Like
Hi y’all just a quick question about Lumen & Hierarchical Instanced Static Meshes (HISMs),
I’m interested in using HISMs for my project since they allow for LODs but I noticed that they don’t seem to properly contribute to the Lumen Scene. I saw much earlier on in this thread that people had the same issue a few years ago. I did some of my own basic testing which seems to confirm this
The objects on the right circled in blue are basic static actors contributing normally to the scene as one would expect.
The two spheres in the middle circled in green are plain Instanced Static Meshes (ISMs) which appear to contribute normally as well.
The objects on the left circled in red are 2 different HISMs (one set is default spheres to confirm its not just my own mesh’s issue, and the other is my custom mesh). As you can see in the little Lumen Overview windows they are definitely not contributing. This simple level was set up in clean project using Unreal 5.3.2, but I also made a similar level in 5.4.2 with the same results.
I’ve tried some various fixes suggested in the troubleshooting section of the Lumen documentation, including playing with Lumen settings in a post processing volume, and increasing the mesh’s “Lumen Mesh Cards” value but, with no luck.
So with all of that said, my question is can anyone confirm whether HISMs work with Lumen and I’m just doing something wrong, or is it true that HISMs just don’t work well with Lumen? Also if it is true, are there plans to make them work together, or not really?
Sorry this is kinda wordy, but thank you in advanced for any help/guidance! 
3 Likes
HISM should work, but only with Nanite meshes. Given that Nanite is our default mesh rendering method likely we won’t fix HISM+non Nanite.
2 Likes
I tried enabling nanite on my mesh and just as you said my HISM works with Lumen now! Thank you so much for pointing me in the right direction : )
2 Likes
Hi all,
This is maybe not 100% Lumen caused, but related. Do you know any advise to decently illuminate hair strands?:
Path Tracing:
I have been trying to illuminate hair in interiors for a while, but it doesn’t seem possible to get a realistic lighting. As a retest-project and to confirm, I have downloaded this example project https://www.unrealengine.com/marketplace/en-US/product/raytraced-cinematic-lighting-interiors, changed to Lumen, deleted the rect lights, increased the lamp intensity to something more “physical lighting value” (not working fine, too?), and this is the result if you move the character to a GI illuminated zone.
Thank you very much!
rage moment? have you actually tested nanite? to destruction? i’m about to go in. foliage in my highrise map does not perform well. the city park asset pack was not build with nanite. gotta squeeze it. i for sure know howto avoid instance overdraw. intentional world building, not spamming generic rock assets (like the valley did). you gotta optimize your assets and world to draw effciently. hmmhmm.
It’s the same guy who previously spent all his time spamming the thread about how much Nanite/Upscaling/TAA sucks. It’s the only thing he has to say.
2 Likes