Thanks for the additional info. I made a short video to better show what I’m experiencing. If I set the directional light to stationary and then bake, the shadows look a whole lot like VSMs. Maybe they’re not VSMs, but they look either tack sharp like VSMs or blobby and weird. Only after I toggle to moveable and back do they start to look like CSMs again.
Not an issue with GPU lightmass, go into your directional light settings and enable “use area shadows for stationary lights”
Thank you! totally fixed it. why that’s on by default is a strange one. more expensive maybe?
Might actually be slightly cheaper to enable area shadows since it will just be sampling the texture without any extra steps.
By default the engine stores stationary shadows as a 2D distance field, great for sharp shadows as it lets you use a lower lightmap resolution and still get a nice crisp shadow at the cost of rounding corners so its a tradeoff. And as you’ve discovered: It doesn’t work at all for soft shadows.
I’m on 5.4.4 with my project and I noticed that after upgrading my GPU to the 50s series, that there is a problem with emissive lighting. I dont’ get any emissive lighting at all when I use “Use first bounce ray guiding”.
However I need to use this option, because the interiors of my levels will not bake properly otherwise. There would be strong artifacts everywhere, especially in darker areas. but when using first bounce ray guiding my bakes are super clean, which is also the reason why I’m a great fan of GPU lightmass.
But now I can’t use it anymore if I want emissive lighting to contribute to my scenes.
I strongly suspect it has to do with my hardware upgrade… but what can I do now? Upgrade to a new engine version?
I’m thankful for any advice.
hi @ut20040x0r
RESOLVED: Known issues with NVIDIA 576.02 drivers on RTX 50-series GPUs | Epic Developer Community
(post deleted by author)
https://downloads.luoshuangfw.io/gpulm-releases/GPULM-5.7.1.7z
Back to release list
Fixed a quality issue when Use First Bounce Ray Guiding is enabled:
Hi @Jimbohalo10
I’ve updated to the latest driver 591.59 as you suggested, but I was already on 581.80, since I did a clean new install of windows just a month ago.
Edit: I’ve discovered that using the Intel Denoiser is disabling any emissive light contributions. Using the Simple denoiser gives me correct emissive lighting from meshes and materials.
Since everything else is working fine, are there perhaps any cvars I could tweak to make the intel denoiser recognize emissive lighting?
I’ve been able to save my project by moving it to 5.6.1.
Here I get clean, great looking bakes with emissive lighting. Let’s just hope nvidia won’t make older plugins useless again with some driver update… That must have been the cause of my problem.
I am still curious though if something similar has happened to somebody else? Because this is a real trap, I was lucky I didn’t get much problems when upgrading my project besides recompiling some bp’s and fixing some missing variables… This could easily turn nasty with a more complex project.
Well anyway thanks for the help here and I hope epic makes baked lighting more of a priority instead giving customers 15 fps with lumen/nanite/vsm on a gtx1070…
Hello @yujiang.wang and @Jimbohalo10
After running several GPU Lightmass baking tests across different versions, 5.7.1 has proven to be the most stable so far, at least for archviz workflows.
That said, I still have two issues that I haven’t been able to solve:
As shown in image 00, there is a boiling/flickering issue in low-light areas that I can’t get rid of. The bake settings are using 4096 samples, the 25% rule for the remaining parameters, and First Bounce Ray Guiding is enabled (which, in earlier versions, completely broke the results when activated).
The second issue is shown in image 01: when Nanite is enabled, a series of isolated artifacts appear. It no longer crashes automatically when baking with Nanite enabled—as happened in previous versions—and the amount of artifacts is much lower, but for archviz standards, this still needs to be resolved.
The hardware used is an RTX 5090 with the latest available drivers. I tried performing a DDU rollback to driver version 560, which was the recommended one, but it is not compatible with the RTX 5000 series.
That said, congratulations on your work—this latest GPU Lightmass version is undoubtedly one of the most stable so far.
Thanks in advance!
GPU Lightmass does not generate anything dynamic. If you’re seeing the ‘shimmering’ artifact it probably comes from something realtime. For Nanite meshes, GPULM can only use the fallback meshes, which means there will always be discrepancies. I can only suggest you disable Nanite on problematic meshes.
Hi @yujiang.wang. Thanks for the quick response. You were right, the console commandr.RayTracing.ForceAllRayTracingEffectswhich is normally set to 0 by default in Base Lightmass was not responding properly. I modified it, re-entered it, and the smearing disappeared.
Regarding Nanite, the results are much better when it’s disabled on the mesh. Is there any option to improve the fallback meshes and reduce the artifacts that I might be missing? I’ve tried quite a few things, and aside from disabling Nanite, nothing else seems to have any effect.
We usually work on mixed experiences, and being able to keep a single executable without having to duplicate geometry makes the workflow much easier.
Thanks again!
In 5.7 you can change the raytracing fallback to use triangle percentage (instead of auto) then make sure the percentage is set to 100 and press apply.
Seems at some point Epic split the fallback mesh into a render fallback and a raytracing fallback, which makes sense. Not sure what version this happened in.
Hi @Arkiras . What you suggested made it work, but only by adjusting the Nanite Settings fallback, the Ray Tracing one had no effect at all. Still this is better than disabling Nanite entirely, although we’ll need to be careful with the polygon load of the assets where this is applied to avoid heavy and overly complex fallbacks. Thanks a lot!
@Arkiras In fact, the ray tracing fallback is always ignored by GPULM for a few reasons:
@yujiang.wang Can you please give some tips on where to look for when determining why GPULM doesn’t generate lightmaps for HLODs in 4.27-plus (this fork https://github.com/uno1982/UnrealEngine/tree/4.27-plus-meta ) ? Since you are unable to help, I figured maybe someone else might, but they need to know where to look. Thanks
GPULM has never had special handling code for HLOD. It is sort of expected if it doesn’t work, and you need to implement it. Since pre-UE5 legacy HLOD no longer has its place in UE5, I’m not going to support this part.
https://downloads.luoshuangfw.io/gpulm-releases/GPULM-5.7.2.7z
Back to release list
HLOD is in UE5 (at least it was in 5.4.x).. What I am asking is to point whoever will be implementing support for HLOD lightmaps, in the right direction.
People who need baked lighting don’t use UE5 at all because platforms that require baked lighting cannot run UE5 well. So they use UE4.27-plus(-meta) forks.
