Hello, perhaps someone wants the list in a pdf, json, csv…
William has a video about it
Why does Lumen have such a massive CPU cost?
its unusable.
I enable it, not GPU limited, but lose 20-30 fps for no good reason. ~80 → ~50
This needs serious improvement.
EDIT: To be fair, trying to get 60 fps with lumen etc. isnt easy. (for more complex stuff)
EDIT2:
There also is some other bug at work, which halves performance (render thread) after changing maps for a while, it gets back to normal (100+) after a big hiccup. Guess I will wait for 5.1
Best practices for lighting large closed interior spaces? I have a large interior space like a warehouse. In real life, such an area would be lit with many bright hanging ceiling lights. With baked lighting I could use as many static lights as I wish with no cost. With lumen, I can use emissive surfaces which have little/no cost but create plenty of noise. Since there is no such thing as a static light, it means that all the lights would have to be moveable which is too expensive. Even if you group lights together and represent them as fewer rect lights performance is still bad. Spot lights show the tell tale v shape when you have fog and aren’t ideal and also not so performant. We have tried combining much larger hidden emissive plane meshes with groups of lights and supplemented that with a few dynamic lights but noise is still a huge issue. By noise I mean large scale blotchy noise as opposed to fine grained. To make matters worse, most of the surfaces are shiny dark metallics… 
I need to be able to turn groups of lights on and off dynamically at play time which makes baked lighting a real headache too. Lumen promises so much and yet the noise from the emissives (even when quite large) and the lack of a “static” type light makes it really hard to use for some situations.
Hi @angelman ,
I agree that Lumen is not “as good as they told”. It’s like I can’t find real use cases, like if it were only suitable for huge, open worlds, with only a Directional Light, where it works very well. But there is a lot of limitations for other environments, like noisy shadows, poor performance, horrible reflections, loss of AO or small shadows details…
Some really cool and promising features and effects with Lumen, but still so immature, from my point of view. Currently, I think we don’t have any dynamic light system ready for production: ray tracing was working great, but GI was poor and expensive. Lumen has the mentioned problem. The best solution, for me, would be something like Lumen GI, ray tracing shadows, ray tracing translucency and ray tracing reflections (with Lumen GI allowed in reflections). It’s like every dynamic lighting system is unfinished, and I’m not sure if they are planned to be totally finished or not… like ray tracing, being deprecated now, when it’s even better than Lumen in many ways. We should end having a fully functional RT system, for high quality, and a fully functional Lumen, for high performance, and also the possibility of combine both, instead of none of them, as right now.
Well, you can try to enable Ray Traced shadows, which, lot of times, gives better performance than Lumen shadows. You could also try to only “use” some of the lights; make a few of them (only the necessary ones) casting shadows, and disabling it for the rest. This way, you will have your scene illuminated, but not with lot of shadows crossing around, only with the main ones.
PS: why you should need any “static” lights if you are mentioning that baking lights in your scene is a headache…?
PS: right now, Lumen is fully dynamic and it can’t be combined with baked lighting (AFAIK), which should be a Must in terms of trying to gain performance, like baking Skylight, for example.
2 Likes
Hi all!
Some feedback (and help request, if you can, please) over here. After playing around with loooots of cvars, I can’t improve the “detail shadowing” on maybe small or near objects, like the ceiling moulding here, which has a little offset (like 5cm) from the wall:
Curiously, when the moulding is not in the center of the screen, it tends to have its shadowing (it should be the opposite, I guess):
And an additional issue, about poor reflections, even when Hit reflections enabled: some black zones on models, even rising a lot the Lumen Cards number. Come on… are we supposed to change every Card number setting (in the case it would work) of every mesh if we want to avoid black-horrible erros in reflections?
Do you know how I could improve or solve those issues?
Thank you and best regards!
Lumen shadows? Do you mean VSMs? Lumen does have a low-cost direct lighting system via the final gather, but it only came out a handful of weeks ago and it most likely not in a usable state at the moment.
And I can absolutely see where you’re coming from, lumen definitely has some substantial limitations, and it is a quite complicated beast of a piece of software. It requires nanite to run well at any scale, noise can definitely be a problem, the reflections require tuning, and I believe you need bent normal enabled in order to achieve any good small-scale AO or shadowing. It certainly needs more development, and I know Epic spent some time trying to make a hybrid dx11/dx12 renderer, which limited them in significant ways.
In terms of causing noise, I think you may have a few options. The big one would be changing your materials or their reflection cutoff threshold. Lumen does not handle rough reflective surfaces well, but it can do near-specular or near-lambertian just fine. You could tweak the roughness of your materials, or use a CVar that makes specular surfaces utilize lumen’s hacked rougher reflections, I’ll need to remember it.
We have been experimenting with “stationary lights” and lumen, using the virtual shadows and then there are some cvars you can set that cache static objects. This helps performance just a little bit but not hugely. Also been experimenting with some kind of transition from an emissive mesh light in the distance that fades into real light sources in the background, the problem being that those emissive meshes get so small they just either stop contributing to any light or of course cause a great deal of noise in the distance.
I do wonder if more and more games come out using Lumen whether players will just come to accept Lumen noise as part of the experience, a trade off for the more detailed occlusion, GI, more dynamic environments. Screen space reflections have obvious limitations but I think many people enjoy the extra detail and fidelity they bring and in the heat of gameplay they quickly ignore the way the reflections fade off as you look away from a specular light source.
As for static lights with Lumen. Of course there is no such thing, every light has to be dynamic, but of course that’s too expensive for most cases. Lumen needs some kind of “static/free/cheap” alternative. Quite what that would be I am not sure. We tried creating a sort of combination light of a real light source with either no shadows or very small attenuation plus an emissive mesh, but light leaks, general complexity to setup requiring a lot of tweaking on a case by case basis makes this not so ideal. One of the big attractions for me with Lumen is that everything gets shadowed and occluded correctly. So many great games with great graphics (even the mighty Cyberpunk) get spoiled (for me) when I see some props or other small item unshadowed and unoccluded sitting on the ground/table etc.
Lumen - so close… and yet so far. I am worried though that Epic will continue to push Lumen and stop supporting investing in lightmass/ traditional raytracing etc.
Has anyone tried RTXDI (NOT RTXGI). This looks very promising but doesn’t seem to be easily available or much developed. We tried RTXGI and it seemed very underwhelming at least compared to Lumen.
I actually wrote a pretty substantial review of NVRTX a few weeks back, should be under the lumen tag. I experimented with the different light transport options and generally found them buggy to the point of being unusable, and when they did work, with inferior quality to lumen. RTXDI is powerful, but it causes strong blurring during fast camera movments, which essentially means you get a much softer picture in its’ current iteration. It also doesn’t appear to support emissives like straight-up ReSTIR, which is again a limitation. They did update the algorithem though, and I’ll be excited to try a better version of it.
I can answer one of those questions, perhaps unfortunately though. Lightmass will continue to get development resources, as it can yield incredibly high quality even compared to lumen, but standalone ray-tracing is getting depricated, and for good reason in a few cases. RTAO and RT reflections were both very powerful for the cost, but RTGI was essentially unusuable. RT reflections didn’t support dynamic GI or occlusion in reflections either, so even RT reflections could cause light-leaking. The system wasn’t very coherent or scalable, and lumen was meant to solve those problems. At the very least, it solves occlusion and diffuse indirect pretty well if you know how to work with its’ limitations.
That being said, I agree that it needs better perf and more feature support. 5.1 will bring reflections on translucency and SLW, WPO, PDO and masked material support for nanite (which also means better lumen support), SSS and two-sided foliage receiving GI, and perf. improvements among other things. If they can drop the cost further, improve local occlusion, and perhaps add in support for colored shadows/transmission, then I believe we could be seriously looking at something that could replace lightmass.
Caveat: RTGI was unusable for most devices with the UE4 standard denoiser. Epic used Nvidia’s SVGF denoiser in Fortnite and that worked extremely well. Lumen denoises GI at the probe level so the overall potential quality is much higher for the cost.
Hi Blackwell,
Thank you for your reply!
Yeah, I see it’s enormous potential and I’m quite hyped, but I’m just afraid of ending it non-finished as the other methods, and I cross the fingers to finally have a fully functional dynamic system (without the need to do infinite tweaks to every mesh and every material).
Anyway, I don’t know why UE5 has it enabled by default (and to fully disable it, you need to delete the DefaultEngine.ini to not interfere with other methods), if it’s so inmature.
Maybe they could have a dx11-12 version and a non-limited dx12 version. Being Lumen a tool of the future, I can’t understand quite well doing it compatible with DX11 and, specifically, limiting the tool because of this fact, if it’s the new Epic’s flagship.
About the reflections, I have tried what you said and I have serached for any related cvar, with no luke. But I must mention that I have created a new material (just with a base color texture and nothing else!), and the black zones are still there.
Regards!
I have been following lumen development quite closely, and I am almost certain it will be ‘finished’ (to the extent any piece of game software can be). Epic has clearly poured an immense amount of time and money into the technology, with excellent results so far.
The big updates that have been offered but have not materialized yet include a hit lighting mode for all aspects of the pipeline (GI as well as reflections), multi-bounce lumen reflections (a personal favorite), and probably a few that I am forgetting. Lumen does ask for tweaks, including manifold geometry and a certain amount of modularity, but I much prefer these over hassling with lightmap UVs or rigging fallbacks for when SSR/SSGI fails, or budgeting for planar reflections.
I’ve found lumen to suit almost all of my use cases so far, but I am in the middle of doing more offline work, where I can afford a less ideal framerate.
And that would definitely be possible, but I get the feeling the dx11 version was simply too much work for the limitations. I believe they made it to faciliate last-gen support to an extent, as it would basically be Distance Field Reflections and global illumination, which I think a very early version of UE4 even supported. Dx12 means hardware RT, which facilitates better quality, scalability, and versatility in lighting.
In complete honesty? I think the tail end of this generation could see a lot of this replaced with full real-time path-tracing. Nvidia’s already made it work in simple cases, and with the new ReStir revisions, we’re achieving many-light sampling in ms, not seconds or minutes. It will vastly simplify the current lighting paradigm down to a few scalability levels, and make lighting work a lot more straightforward. Just a bit of speculation.
And the CVar is r.Lumen.Reflections.MaxRoughnessToTrace and the roughness value you want. The default is .4 I believe, which essentially means anything more reflective than .4 will trace rays, and anything else will use their fake lighting method (fake in the sense of derrived from diffuse GI, it essentially clamps the value).
Lumen using fake reflection.
Lumen using real reflection. Change the value to force it to GI and that should eliminate the noise with limited visual difference.
1 Like
With a bit of luck, UE 5.1 might solve that, since they add Lumen support (with high res tiling?) to MRQ:
Lumen is working in mrq
But lumen panorama is not working in mrq
Already I compiled latest 5.1 built 3 days ago
Nothing fixed in panorama section
The programmer who is responsible for the panorama part in MRQ should be fired by epic games!
Hi Blackwell. I like your vision! I hope you are right (sure!), thank you for the details 
Bout reflections, I already tried that cvar, but with no luck. Black zone are still there, and I think they are due to Lumen Cards, but not sure. Would you have any other ideas, please?
And with Nanite enabled (just to try), it’s even worse:
Thanks!
Do you have the card visualization? That could let you figure out where the match is failing.
That being said, cards shouldn’t necessarily be relevant when dealing with the hit lighting. The cards parameterize the materials for the surface cache, but hit lighting overrides the cache to evaluate direct lighting and material at the ray’s hit point-cards wouldn’t make a difference.
I’m seeing what looks like SSR behavior in some of the shading, try disabling screen traces with lumen.screenprobegather.screentraces 0 and see what the lighting looks like. If it’s all weird and blotchy, then it would appear the hit lighting isn’t engaging. Try placing a point light next to the objects and see if it looks better, direct lighting in reflections is handled well by lumen and may be a visual improvement.
Thank you @jblackwell for your reply.
In this screenshot, I show you the cache view, if it was what you were asking for, and I have disabled SSR reflections with a command line and also applied your command line, but the result is the same.
Certainly, with a spot light focused on the third seat, it’s reflected fine, so it seems to be related with GI reflections and Lumen Cards, but in a lot of situations I couldn’t direct-illuminate every surface in my scenes. It’s using Hit reflections (with surface cache it’s worse, like even less resolution textures):
Regards!
I see, I think I’m beginning to understand the problem more.
Essentially, the hit lighting only works for analytical light sources, but as you pointed out, you cannot directly illuminate many parts of your scene without causing serious changes to lighting.
r.Lumen.Visualize.CardPlacement will let you figure out how exactly the cards are missing. This should not be a tough scene for lumen, but it also depends on the geometry of the couch.
Honestly? It may be that you’re having problems renderering it due to the concave nature of the couch cushons preventing the surface cache from evaluating the scene. Given this, you have effectively two easy choices: either find some way to apply direct lighting to the couch in such a manner that the hit lighting has radiance data, or swap out the couch mesh for something more manifold.
Your best option would probably be to break the couch apart into its’ individual components- have each cushion be its’ own separate mesh with its’ own card set. This is where lumen does impose some frustrating content limitations, but at least you have options.
Failing all else? Use the path-tracer if your project is offline. Easiest solution.
Thank you @jblackwell ,
I have been trying some changes, but none of the options is fine
Just to clarify and not to seem lazy:
I can’t illuminate it. It would need a too shinning light to illuminate the black areas and “smooth” them, so it looks so weird.
I couldn’t edit every mesh of my models library.
Other couchs are showing, more or less, the same (or very similar) issue.
It’s thought to be a real-time ArchViz walkthrough, so no Path Tracing too.
Right now, my unique option seems to be going back to baked lightmaps for ArchViz, with Ray Tracing reflections and Ray Tracing shadows for movable/interactive objects. Lumen can’t work in that kind of “scenario”, currently.
Would be interesting to have an official reply about if this will be the usual behaviour, or if it will improve, and in which ways. Or, at least, the intentions about it.
Thank you again for your time and effort, @jblackwell !