as far as I remember GPULM has known issues with real-time capturing skylights. switching between mobility (and other property modifications) can force the skylight to refresh
Hi there.
Just a quick question. Is it possible to run GPULM via command line, to integrate it into a CI pipeline? It’s fine if a rendering window opens, as it will run on an agent with GPU and desktop GUI, but automatize it for all the different maps, might be cool.
Hi! I’m having an issue using this plugin… no matter what I do or change in my project config, it always tells me
LogTemp: Static lighting system is removed for world [Whichever world I’m trying to bake]
I’m genuinely clueless and at a loss for what to do. Using 5.7.3 and the corresponding updated version from this thread. Any help is appreciated ![]()
Hi there - without knowing for sure, there could be two first possibilities to check:
-
Have you checked world settings? Is the ‘force no precomputed lighting’ box checked? It shouldn’t be for static lighting.
-
Worth checking project settings as well - is Allow Precomputed Lighting (I believe the setting is called) checked? Effectively, you can enable or disable static lighting in an entire project, and it may be off by default in newer UE templates. Worth a check.
-
As a sanity check, are you using world partition worlds? I don’t believe this plugin supports WP worlds at present. Classic levels would be needed.
-
And finally, it is also possibly useful to see if CPU Lightmass works, or if an unpatched GPULM works.
Perhaps you’re already past this stage, but some starting points worth checking out ![]()
Hi everyone,
I’m experiencing a critical issue with GPU Lightmass on UE 5.6.1 using yujiang.wang’s community patch for version 5.6.
Setup:
Engine: Unreal Engine 5.6.1
Version Control: Git
Team: 2 computers (Computer A and Computer B)
The Problem:
When Computer A builds lightmaps and pushes to Git, Computer B pulls the changes but the lightmaps appear broken in the editor. However, when Computer B rebuilds the lighting and pushes, Computer A then sees broken lightmaps after pulling. This keeps alternating - whoever didn’t bake the lighting sees corrupted results.
This issue now affects both editor AND packaged builds, making it impossible to deliver our project.
What We’ve Already Tried:
Confirmed both computers use the exact same patch version
Synchronized Nvidia drivers to the same version
Verified UE 5.6.1 Changelist numbers match
Deleted Saved/, Intermediate/, DerivedDataCache/ folders
Confirmed *_BuiltData.uasset and *_BuiltData.uexp files are tracked in Git
What’s Different:
The two computers have different GPU models (Computer A: RTX 4060 Ti 16GB, Computer B: different model)
Questions:
Has anyone experienced this issue where lightmaps appear broken on one computer but correct on another?
Could different GPU models cause incompatible BuiltData even with the same patch version?
Is there a way to force deterministic lightmap builds across different hardware?
This is blocking our entire workflow. Any help would be greatly appreciated!
This is likely because you have mismatched lightmap UV versions between static mesh assets. Try upgrading lightmap UV versions, resave the static meshes, then delete derived data cache and rebuild to see if things resolve.
Thank you so much for your reply!
- I have tried both a WP and a Classic level.
- The default CPU Lightmass works
- Lighting settings seem to be correct
- Allow static lighting is on
- Force no precomputed lighting is off
- Tried Nvidia and AMD GPU (on same machine)
I feel like I’m going crazy! I had it run once but I can’t seem to get it to run ever again…
Okay, that sounds much stranger. There is a very (very) small chance that it might be a GPU memory issue, and the manifesting message is trying to tell you that the static lighting build process has been removed because it crashed or shut down. Try this:
r.RayTracing.ResidentGeometryMemoryPoolSizeInMB 800
This fixed some memory crashes for me when GPULM was running out of memory a few months ago, but I do believe that this issue was sorted.
More likely, this bug is something very odd to your setup. I had a similar bug, and I had to:
-
Download and build UE from source.
-
Patch in the GPULM build that is being worked on here.
-
Run in debug mode so that I could catch and trace the crash. Mine was because volumetric lightmaps in foliage actors cause a lightmap nullptr issue of a sort. Switching to standard lightmaps fixed it. This issue will be different, but it might be catchable.
Sorry I can’t be of more help, but hopefully this is something that can be caught ![]()
Hi again @yujiang.wang, how are you?
First of all, congratulations on the results and how well GPU Lightmass is working in Unreal 5.7.3. It feels very stable, including the implementations for interactive mode, and there are no artifact issues anywhere, not even the ones I previously had to fix by tweaking the mesh Fallback or disabling Nanite.
On another note, I have a question. I’m trying to bake Emissive Materials, and unlike in previous versions, it’s not working. Things I’ve tried so far:
-
Enabling “Use Emissive For Static Lighting” with the mesh set to “Static”. It is enabled on the emissive mesh just like in previous versions, but it doesn’t work.
-
Significantly increasing the emissive intensity. This doesn’t work either, and it also starts introducing a lot of noise into the reflections.
-
Disabling Nanite on the meshes.
I’m not sure if there are any additional considerations in the latest versions to get this working. Thanks in advance.
Cannot reproduce. Is there any thing like Substrate or Lumen reflections going on? How does the Lighting Only view mode look like?
Hi @yujiang.wang ,
I have attached an image with the parameters. No dynamic lighting or Lumen is being used, and the materials use the traditional methodology.
I have tested various intensities for the “Directional Light”. The value of 100-150 lux is because in previous versions it had to be increased for the Volumetric Lightmaps to work correctly, especially with GPU Luoshuang. I have also tested it with a value of 10 lux, and it generates the same problem.
I have done another series of tests, but it still isn’t working. Thanks again.
I would then suggest you make a minimal repro project and send it to me for further investigation.
Ah, now I see why. Unlit materials are always ignored by GPULM as they are frequently applied to sky boxes and block lighting of the entire scene. Switching to default lit and setting other parameters accordingly should do what you want.
Wow! The solution was simple. It’s true that we have always treated emissives as an unlit material, and in previous versions, their influence was calculated without any issues, even with Luoshuang. But we will keep this in mind for our current projects.
Thank you very much for your help, and congratulations on the stability and results achieved in this version!
(post deleted by author)
hi thanks for ur work i have question in 5.6.1 there is no
[DevOptions.GPULightmass]
NumPrimaryGISamples=32
NumSecondaryGISamples=16
FireflyClampingThreshold=1000.0
this option file
i have same prroblem and i just delte thhis objects from scene if u find something better pls let me know laso
Release 5.7.4 2026.03.11
https://downloads.luoshuangfw.io/gpulm-releases/GPULM-5.7.4.7z
Back to release list
Hello @yujiang.wang, first of all, thanks for your hard work, it works better than the regular CPU Lightmass for me and it’s truly amazing. But I have recently stumbled upon a problem with landscape splines.
I am using your version of GPU Lightmass on 5.7.3 and landscape splines do not receive shadows of other objects correctly. I have constructed a simple scene with a landscape spline made out of engine’s default cubes and one big cube - you can clearly see that the spline segments act as if they have a very low lightmap resolution, even though this is not the case:
There is no such problem with the regular CPU Lightmass (with the exact same scene), so I think my setup is fine. Another developer confirmed that they can’t get the plugin to work with Landscape Splines too. Are you aware of this behaviour? Is there some kind of workaround?





