Hi, Sorry, I’m quite new and having issues with a 5090 not engaging when baking lighting (thrashing my CPU though) - reading up lead me to here to try GPU Lightmasss something soimething and then read about more issues and now reading about this patch.
Would someone mind pointing me to the 5.6.1 Patch and explaining how to install it?
All the best, Simon
I’ve treid copying across from the 5.6.1 patch but got this error The following modules are missing or built with a different engine version:
GPULightmass
GPULightmassEditor
Engine modules cannot be compiled at runtime. Please build through your IDE.
If your game project is a C++ source project you’ll need to launch it from Visual Studio (to recompile it)
Thank you so much for looking into this 
I’ll run some tests and report back
I’m not sure about “original“ / “old“ / “EPIC version“.
I’m asking for GPU Lightmass, which can be enabled as plugin (red square) on UE 5.5.3.
Not “Build Lighting only“ option (green square).
The question is: Did “5.6.1 GPULM” can be applied in my case?
The one that you enable in de plugins section by Epic games (see right in your picture) is the official gpuLightmass so yes, you can aplly the 5.6.1 version.
@luoshuang Testing UE 5.7 preview. Getting constant crashes on some objects if nanite is enabled on those objects. Not all objects with nanite enabled crash though when running GPUlm.
Assertion failed: (Index >= 0) & (Index < ArrayNum) [File:D:\build++UE5\Sync\Engine\Source\Runtime\Core\Public\Containers\Array.h] [Line: 1096]
Array index out of bounds: 2 into an array of size 2
No missing materials on the object. Nothing special set on the object. Re-imported the fbx - still crashes if nanite is enabled. Works fine in UE 5.6. Suggestions?
I haven’t release any patch for 5.7 so you’re using the vanilla GPULM and experiencing all the old bugs.
I hoped you might have had a suggestion what I could look for myself to fix this issue while your patch for 5.7 is still in development. Never had this issue of Nanite being the cause for a gpuLM crash.
There is actually a post above about Nanite crash - try disabling ray tracing proxies in project settings to see if it can mitigate your issue. Proper support for that is included in the 5.6 patch
Thanks for the suggestion. Disabling nanite proxies didn’t fix it. Eventually I found the object that for some reason crashes gpuLM when nanite is enabled on it. It was SM_TableHigh12 from the Twinmotion Chairs and Tables Pack 1 in case someone else runs into this issue.
Hi @yujiang.wang, just a quick update after a few more rendering tests. I’ve been testing the GPULM quite a lot, and have encountered a few issues. I am not sure whether the issues are local to my environment somehow or are things that could be worth investigating. I’ll list them below with images. But first, another huge thank you for working on this. It is our dream static lighting solution, as we build for VR and Flatscreen, and so need to prioritize perf and fidelity at the same time.
Phantom Shadows:
These still seem to be present, after switching to another machine and applying the latest patch (assuming it is the same download link?). I’ve turned down the EV a little, to highlight them in some more detail.
I have to admit that I am a bit stumped, as they aren’t appearing consistently, and I don’t believe that they’re from another part of the lightmap that’s been translated somehow. The effect seems to be spatial, as a couple of meshes are picking up the same shadows (landscape and some rocks in the same spot).
The phantom shadowing is also manifesting at a bigger scale: here are some very odd artefacts that seem to be stamped into the landscape’s lightmap. If you look at the centre of the image, it almost seems like there could be some other lightmap that’s applied on top.
As a piece of nuance for this scene, I deleted a few landscape tiles around the edge of the landscape to safe on triangle count. Maybe this is affecting things.
Lightmap Artefacts:
I’m also experiencing some lightmap artefacts, that seem to manifest as compression areas over key lightmaps. I’ve shown a couple of images below. These don’t appear until the encoding stage. However, the phantom shadows that I mentioned above were present during the preview as well, so there are possibly two issues here.
(this one shows some strange lighting/shadowing (on the wall as a sort of slanted block of brighter area) and also some lightmap issues on the floor.
HISM not baking(?)
As a smaller behaviour, I believe that HISM meshes don’t seem to bake as static. I recall this could be a known issue with HISM’s in general, but if the class has the potential to receive static light properly, is it meant to be supported?
(The image below shows a few rocks around the glowing sphere/orb that seems to be referencing the volumetric lightmap for its lighting, and isn’t casting a shadow).
Mystery Crash
Finally, we’re receiving a crash when initializing GPULM on another level. It doesn’t reach the stage of giving us a preview, so I believe this is at the ingestion stage. We must have a nullptr or some mesh/actor that the system doesn’t like - but we’re unable to figure out which, as it is a large level. For this one is there a chance of some form of verbose logging to catch crashes or meshes that cause crashes? We experienced this in 5.4 as well (annoyingly, for a completely different level), and were never able to find the mesh, despite rebuilding and splitting the level to try and find it forensically.
Thank you again so much for working on this! Happy to keep running tests and experiments.
As a final longer-term question, what do you think of the possibility of supporting HLOD baking (more the classic HLODs than World Partition HLODs, as we use these for Mobile VR perf optimizations). I know that CPULM uses a very different method to bake, and can use some form or ray rejection. For path tracing, the implementation would be quite different. If this is ever of interest to you, we’d love to help you test it.
Thanks again for the amazing work
To investigate the issues I need your map, otherwise it won’t be better than guesses
Sure thing - we’d be happy to provide you access. It’s a commercial project though, and I don’t want to make too much work or friction for you.
In the meantime, I also built 5.6.1 from source, and applied the latest updates as a patch from your GitHub. The results were the same, but I believe that I have isolated the cause of the phantom shadows to painted Foliage, which uses HISM.
I deleted them from the level, and the compression artefacts and also the phantom shadows disappeared, leaving a great bake in their place.
I can try to replicate the issue, but it looks like the foliage actor may be the cause. We’re using VTs for, and some parallax occlusion as the only two unusual features on our Foliage meshes.
Perhaps I can also try to replicate this issue in a simplified project, and send that over.
I will also try to catch some of the crashes, and report back
Update:
I also tested the crash in the other level, and found two causes. The simple one was a duplicate instanced foliage actor, that wasn’t associated to the level but did contain geometry. It might have been because the instanced foliage was split between streaming levels. The error was here:
The more complicated one seems to do with Landscape RayTracing data.
The crash ends at check(RayTracingGeometry != nullptr) in RayTracingMeshDrawCommands, but steps up to LightmapRenderer.cpp, line 1347, with RayTracingMeshProcessor.AddMeshBatch(MeshBatches[SegmentIndex], 1, nullptr);
I believe it is to do with setting up the landscape for baking, but I haven’t found what’s missing yet. Any tips for digging deeper?
Update 2:
I’ve had some luck fixing the phantom shadows with r.RayTracing.InstanceBuffer.RLE 0.
'I’ve also had some luck fixing the landscape crash with r.RayTracing.ResidentGeometryMemoryPoolSizeInMB 800.
I’ve found a crash or two to occur at different steps, which I’ll look into. But in short, I think the phantom shadows were from the foliage transform upload bug. I think the random crashes seemed to be a raytracing geometry memory pool issue, but I’ll keep looking to see if there were other issues.
Either way, I’m able to get bakes, and the project is moving along
Update 3:
Handling the foliage actor’s InstanceLightShadowUVBias is currently causing a crash on another level. I couldn’t find it being calculated or set above on a quick glance, which might possibly mean that InstancePayloadData.Emplace(InstanceGroup.InstanceLightShadowUVBias[InstanceIdx]); will always crash. I guess I’m missing something, but I’m looking into a fix.
Update 4:
After a day of internal screaming and testing, I have extracted these facts that may help developing the tool, and also may help other GPU Lightmass users:
Landscape Foliage may cause dense shadows, as yujiang.wang already mentioned. using r.RayTracing.InstanceBuffer.RLE 0 will help.
Landscape Foliage will also cause a crash if any of the foliage types are set to use Volumetric Lightmaps, because the code tries to write an InstanceLightShadowUVBias that isn’t there (I believe). This crash might just say something like Array Index out of Bounds as the crash message.
First Bounce Ray Guiding and possibly Irradiance Caching causes errors, but not consistently. These errors don’t show up during the preview, but appear after the encoding as black landscapes and heavily artefacted lightmaps. The best that I can figure for now is that it happens in levels with more complex lighting setups, as I don’t see this in new or small levels. I have found that disabling them results in cromulent bakes. I do miss their ability to throw light into internal scenes, but getting shippable bakes is, for me, the priority, and I’ve achieved that.
I ran out of ray tracing geometry memory a couple of times, and I found that r.RayTracing.ResidentGeometryMemoryPoolSizeInMB 800 helps that. You may need a larger value, if your scene is colossal.
GPULM looks great, and we would love to keep using it. If it is helpful, we’ll keep testing
Thank you again for working on it! It is a saviour for games that need to target 90-120fps on a range of performance targets, but want to look like they’re from this decade! For us, the final missing piece is the ability to bake HLODs, but that is not a trivial thing to solve, I believe.
I am using 5.6.1 binaries for my scene, but getting a crash. Because no debug symbols for GPULightmass I can’t get any usefull out of that crash. Anyonce can share debug symbols?
hi @RyuMaster ,
this is instructions for symbol table from Epic Docs
Steps to Enable and Download Editor Symbols:
Open the Epic Games Launcher: Launch the Epic Games Launcher on your computer.
Navigate to Your Engine Library: Click on the Library tab to view your installed engines and projects.
Select Your Unreal Engine Version: Find and click on your specific Unreal Engine 5 installation to expand its details.
Access Installation Options: In the engine’s details, find the 3 Installation Options (or a similar menu) and click on it.
Enable Editor Symbols: In the options menu, locate and check the box for Editor symbols for debugging.
Apply Changes: Click the Apply button to begin the download and installation of the symbol files.
Hi! thanks for the reply.
I have the symbols, hence I see all the code, but up to the point, where GPU lightmass starts, and then it crashes inside it where I do not have editor symbols anymore as I overwrote original epic binaries.
It is because I am using
https://downloads.luoshuangfw.io/gpulm-releases/GPULM-5.6.1.7z
and I guess it does not include debug symbols, I hoped someone who builds from source can provide.
But it seems there is no eay way for me =( Will need to build UE5 fully from sources with GPULM fully from source too to debug that.
Greetings, i am using quadro p5000. Do you think i can somehow trick the version 5.6.1 of unreal to use it for light baking? In v. 5.4.4 it works like a charm using exactly the Luo Shuang plugin… any help will be much appreciated! Thank you for the time reading my comment.
I compiled from source, and that is the error the crashes for me. I am on the latest 5.6.1 custom gpulightmass branch with all latest fixes.
I am not using nanite meshes, but I still enabled that “proxy” thingy in settings, but crash is all the same. Hmmm
this seems to be a new one. if possible i’d like to get your project to investigate (a minimal project that just repros the crash is preferred)
