I have recently tried to enable Lumen (and some other interesting rendering features) on my project, but I have not managed to make it anywhere near “ok-looking”.
The shadows are extremelly dark, the lighting is jittery around my meshes and folliage, the shadows are grainy and the reflections are an absolute nightmare.
I am not sure if it is my scene setup or my project setting causing the level’s lighting to look so terrible and I have tried absolutely everything to my knowledge to fix the mess, but I simply do not know how to.
My scene looked pretty decent before enabling Lumen and some other settings, but I have heard such good things about the lighting system and nanite in specific that I’d love to take advantage of those features in my own project.
Any suggestions or tips to fix some of these issues are so greatly appreciated… thank you in advance!
You have no antialiasing, you need to turn on TAA or TSR.
Also your foliage alpha has problems, looks like you’re using DitherTAA for the opacity but your alpha isn’t high enough contrast… Not sure. By far your biggest problem is that your scene has no antialiasing though.
Thank you for the tips! I enabled Antialiasing bit it seems like the most problematic issue of the bunch, the extremelly dark shadows within the trees, is still present.
I’m not too sure of what you mean by foliage alpha problem… could it be what is causing some of the issues?
The first thing I would do is check what the surface cache viewmode is telling you. If shadows are weirdly dark, that’s likely improper surface cache coverage. If you have foliage, you’ll want HWRT to be enabled if it isn’t already. Shadows would be a seperate problem than lumen, but the shading within them would be lumen. Do you have a video of the lighting instability?
Hey jblackwell! I’m sorry but I’m quite the newbie here and I don’t have much experience messing with this stuff… could you maybe walk me through what you mean through “check what the surface cache viewmode is telling you”? And how would I go about fixing said shadows caused by improper surface cache coverage?
I’ve tweaked a few settings since I’ve last updated this post and got a somewhat acceptable result now, meaning things don’t look nearly as bad as before, but here’s a clip of some of the issues I’m having:
To quickly describe the issue, I have essentially fixed the drastic shadows on one of my some of my tree models by enabling nanite and setting the Effects and Global Illumination in the Engine Scalability Settings to Epic. I’m not sure how it worked or if there is a proper solution but at the moment it seems to have been the only thing to have an effect.
As you can see in the video, my other tree model still has those drastic shadows I can simply not get rid of, and the leaves seem to dissapear as I go further away from the mesh…
Hello everyone, I’m updating this post since I’m still haven’t found a fix for some lighting issues I have been having.
The extremelly dark shadows in particular seem to be gone on some of my tree models after I messed around with the Engine Scalability settings, but it still seems to be happening on other tree models:
Here is a screenshot of the “fixed” trees. They still seem to have a few dark spots that don’t really bother me, but might be indicative of the underlying problem.
So, lumen generates global illumination through a series of world-space caches feeding a screen-space final gather. What that means is that a simplified version of your scene is created by lumen, and that’s what’s actually generating your GI. If your lumen scene is missing large amounts of data that your primary view has, you’ll see it as weird lighting discontinuities. You’ll want to go into viewmode, lumen, and choose ‘surface cache’. That will show you all the scene objects that the surface cache can’t represent in pink, and all the scene objects that it won’t represent for memory reasons in yellow.
That jittering initially looks to me like screen-space artifacts. Would you try r.Lumen.Reflections.ScreenTraces 0 and r.Lumen.ScreenProbeGather.ScreenTraces 0, to remove screen-space lighting and see what the lumen scene alone is telling you?
I also just watched your video: you had it set to medium scalability, and lumen just flat-out won’t run on medium. High is the minimum, and that’s mainly targeting open-worlds. Epic settings is what it takes to get genuinely high-quality GI.
Furthermore, your trees don’t appear to be nanite. While I couldn’t speak to their construction, lumen and nanite are pretty much joined at the hip as far as performance is concerned. Nanite allows for the fast construction of the surface cache, and without it I wouldn’t be suprised that lumen is behaving poorly.
Thank you for your response and for the in-depth explanation! I truly appreciate it!
That jittering initially looks to me like screen-space artifacts. Would you try r.Lumen.Reflections.ScreenTraces 0 and r.Lumen.ScreenProbeGather.ScreenTraces 0, to remove screen-space lighting and see what the lumen scene alone is telling you?
This is what my scene looks like with this viewmode at the moment:
I set some to medium to try and balance out my fps while working on my environment while still having lighting that reliably represents what the final product should look like.
Also, I believe all of my meshes do have Nanite enabled (unless I’m doing something wrong). If it did seem like they were not enabled on the video it might have been because I was toggling nanite off and on while trying to identify the problem, but I did end up enabling it on all my scene’s components once I realised it was not the problem.
Ah, I see. So, it appears your surface cache representation is at least capturing the trunk and some of the leaves, but the pink would mean that all those areas have no coverage and wouldn’t bounce light outside of screen-space.
What direct shadowing method are you using? Given the high-frequency detail, I’d heavily reccomend using either VSMs or RT shadows, as any other method is likely to not give sufficient detail for things to shadow correctly, which could be part of your problem. I’d raise that to epic and test.
I’m also noticing that your reflections are set to medium. That means lumen reflections are not enabled, which would mean specular surfaces would light-leak and your reflections quality will generally be quite poor. I’d bring that setting up to high or epic as well and see what it does for you.
As a general rule for a quality-first approach, you should ‘bracket’ your scalability. Basically, try everything on the lowest settings to understand how it looks, then try everything on the highest (or epic) settings to understand what the best visuals look like, and then selectively work backwards from epic, lowering settings and gauging your result, until you can find what gives the best visuals for the acceptable performance.
Thank you for the tips! I’ll make sure to put them into use from now on.
I’ll be working on testing around with VSM and RT shadows (I believe I had RT shadows enabled this whole time) and hopefully come back with some good results.
I wanted to quickly ask you if you have any clue as to why some of my tree meshes let light through much better and have less drastic shadows in comparison with the large tree mesh I’ve got:
It seems as if there would be something different about the material to make it this way that I might not be checking… It’s unfortunate since I’ll be having to mess with all shadows when it seems like there is only a problem with one of my tree meshes…
If you use some Megascans surfaces there is a common bug where the Megascans material sometimes gets created with constant value of 0 (completely black) plugged into the AmbientOcclusion material slot.
This won’t have an effect as long as the project has “Allow Static Lighting” project setting remains at the default ON state.
But it will cause black shadows on any meshes using Megascans base material as soon as this setting is turned off, since it allows Lumen to utilize the material’s AO value.
I’ve ran into this quite a few times. It could be your case too. Even if you don’t use Megascans, I’d still check the materials on problematic models if they don’t have black/0 value fed into the AO input slot.
