Does anyone have issue with directional light not contributing to VLMs when all lights (at least directional and skylight) set to be static, with only static shadows, and sky sphere (with unlit material; also static actor) surrounding your play area on the level?
If I bake the same setup with CPULM, everything works perfectly well.
Hi, thank you. Could you please share what exactly and where to put, please? Just the plugin itself (It wasn’t a workable scheme) or the full archive content to an engine folder? I’ve tried both; neither is workable, as it still crashes the engine editor.
you should extract the 7z and copy the contents of the engine folder from the extracted file into the contents of the engine folder of Unreal 5.6 (normally C:\Program Files\Epic Games\UE_5.6\Engine). You will see the same folders in the extracted files as in the official unreal folder so just say ‘yes’ when windows prompts if you want to override
Thank you for answer. Yep, this way I’ve already tried and still getting exceptions in both engines, either source, or the launcher version:
hi All,
Please use the correct method of merging. The errors occur because GitHub has not indexed the source files.
Please use the patch supplied by @motorsep
gpulm-5.6.patch
Note: You can first preview what your patch will do:
First the stats:
git apply --stat gpulm-5.6.patch
Then a dry run to detect errors:
git apply --check gpulm-5.6.patch
This command applies the patch
git apply gpulm-5.6.patch
If you want to add files from the repository as they are updated
use
git fetch repository
git merge repository
Just decompressing the source into a source repository will give Visual Studio exception errors as the reference pointers are not created.
Well, I’ve identified that your case is an issue of Nanite fallback mesh support in GPULM, especially when ray tracing proxy is enabled. I need some time to come up with a proper fix.
I think you’re suggesting someone else - I wish a had enough knowledge to code patches…
Thanks, corrected that!. Still you understand whats going on in EGPU, so thats clever enough!.
I hope Epic will pull all these fixes into main, because I really don’t want to mess with the patches for upcoming Meta forks 
I hope Epic rehires him…
That too
I’ve uploaded a new version which should resolve your crash. You can redownload and try again. Note that while GPULM won’t crash with Nanite ray tracing proxies now, it can only trace against them (which are low quality and can have serious mismatch issues between on-screen meshes and the generated lightmaps, especially foliage), so don’t expect high quality from them.
@yujiang.wang I noticed, some projects crash when starting GPUlm when using nanite and the ray tracing proxies are not enabled. Until now, I used a trick to use nanite AND GPUlm by changing (in the SM editor) the fallback target to ‘relative error’ and setting that value to 0. That way, I didn’t see any artifacts when baking lightmaps.
So my question is; whats your recommendation for using GPUlm and nanite in a project? Use lods instead of Nanite? Epic seems to invest heavily into nanite so wouldn’t that become the more performant standard at some point (or already now) ?
Send me the files with Nanite proxies that crash GPULM and I’ll investigate. Crashes are what we want to eliminate. Regarding your general question about static lighting with Nanite, there is another layer of complication, that is surface lightmaps vs volumetric lightmaps on highly detailed geometry, i.e. foliage. @Arkiras may give you a rough idea about that, and I think I’ll give a better answer after investigating your geometries. Also to mitigate some artifacts with Nanite ray tracing proxies the file was updated once more at UTC 06/14/2025 11:51am. It can change how GPULM behaves with the proxies so you may want to take a quick test to see if it crashes.
So when the level was loaded I saw:
which was the reason of the crash. When it’s over budget some ray tracing geometries get streamed out/destroyed and GPULM wasn’t aware of that. I’ve updated it so that now GPULM fails softly by showing a warning:
The meshes will simply be missing from the scene until you adjust the cvar r.RayTracing.ResidentGeometryMemoryPoolSizeInMB to a higher value and restart the bake.
Your second crash was internal to GPULM and now it should be fixed.
Great you found the causes and fixed the second one.
I saw that RT error and put a executeConsoleCommand with that cvar and value in my VRpawn but didn’t know it would effect GPUlm. Will put the value in the DefaultEngine.ini so it loads at startup.
I tested the fixes on my laptop and it didn’t crash. The laptop is too slow so had to abort the calculation. Will test tomorrow at work again.
Thanks!
It’s >7 days and I can’t edit my original post. So there’s one thing more. Compared to https://github.com/AlanIWBFT/UnrealEngine/tree/gpulm-5.6, the more active development happens on https://github.com/AlanIWBFT/UnrealEngine/tree/gpulm-no-luoshuang which has also been rebased to release branch, which should make diffing with release tags easier.
Hi, thank you, but unfortunately it didn’t help. I’ve tried unchekcing the nanite support flag, changing the fallback target to ‘relative error’ and setting that value to 0. Always the same SM despite on any actions with SM in the editor. I was able to locate SM’s which have cought exceptions. Could you, please, have a look at them? I’ve uploaded both versions, assets and fbx just in case: GPULM_crashed_asetss - Google Drive Among them the SM_Flight_Case_50x100_Closed craches editor every time. Log:Error LogOutputDevice Ensure condition failed: RayTracingInstance.GeometryRHI->GetNumSegments() == MeshBatches.Num() [File:F:\UnrealEngine-5.6\UnrealEngine\Engine\Plugins\Experimental\GPULightmass\Source\GPULightmass\Private\LightmapRenderer.cpp] [Line: 877]
Unfortunately I was not able to repro your crash using the asset. Maybe you need to create a small project containing it.
Sure, I’ve done the one. It contains just a vehicle template and my two crashing SM’s (SM_Flight_Case_50x100_Closed and SM_WaterTank). The crash is reproduced here aswell! Replacing them from a level helps to solve GPU light building, but this is the last way for handling this type of crashes. image|690x170 Please find the project here: Nebiros777 / GPULM Crash Test · GitLab
