Hi, maybe somebody had this problem and a solution for it
The problem is: Luoshuang’s starts building light, and stop’s immediately on first step BVH, so i make around a half of objects to movable, and it started to work.
The question is : what can cause this kind of issues? Geometry, or plugins maybe?
Hi @lskshenkaa ,
My guess is the VRAM on GPU is out of memory. You need enough VRAM to complete the Static Mesh first so making them mobile moves them to another section of the build. Just speculation, therefore make sure Swarm is set up correctly and the select the Log and look at the log which is very intense, but will show the reason for the failure.
LGPU Swarm setup
@Jimbohalo10
Hi, i recently replied to your post but i forgot to tag you on it, my bad on that. but i’m still troubleshooting this and still i got no progress i would appreciate a lot if you could guide me on this so i can have a better undertasing of those questions that I’ve asked on the last post and overall about lgpu because I’m on an unfinished archviz project and i’ve done everything but the vr level i need to bake my lights but first time when i tryed cpu lightmass everything went perfect up untill with the last build with production quality which it took 2 days and i had light leaks all over the wall corners no matter what i did with uvs and etc… it didn’t work and it was time consuming and i was runnig late so i tried the original epic gpu lightmass but too many bugs… finally i discovered lgpu and with a despair i gave it a chance and to my suprise it was perfect just like cpu lightmass but without any light leaks on the corners! so long story short i need a little help on this journey but there is literally almost nothing on the internet to help me on this except here!! i would be very glad if anyone could help me even a tiny bit.
-
Supports all 4 standard lights (point, spot, directional and sky)
- However stationary skylight is not supported so if you have one in your scene it will still be baked since it is treated as a static one
- Advanced lighting features such as soft shadows (SourceLength and SourceRadius) and IES are not respected when calculating indirect lighting. However you may still see some effect of them since their direct lighting is calculated on CPU
- According to some tests the direct lighting is low quality sometimes because Lightmass quality level is set to “Preview”. While this problem is actually irrelevant to GPULightmass, you’ll probably want to set the quality level to “Production” to avoid such kind of mysterious problems.
-
Supports baking of standard surface lightmaps, volumetric lightmaps (also with faster voxelization), and sparse volume lighting samples
-
Lightmass parameters and quality settings specified in the editor are ignored except for Num Indirect Lighting Bounces
- Current the number of samples (quality settings) is hardcoded in the program and you cannot change it since I haven’t found an reliable way to expose them to the user
- AO Mask generation is not supported
-
GPULightmass should work with Swarm distributed rendering naturally as long as you’ve correctly set up the environments on all machines. (esp. a sufficiently new NVIDIA driver)
-
GPULightmass uses Brute Force as its Primary GI Engine and some form of radiosity caching as its Secondary GI Engine, which is very similar to vray.
- Brute force is much more accurate than Irradiance Caching (Lightmass’s primary GI engine) but it is also slower. It is also more sensitive to lightmap resolution since it actually calculates each lightmap texel, while irradiance caching is more or less resolution independent. You may want to tune down your lightmap resolutions firstly then slowly tune them up when working with GPULightmass.
[/quote]
- Brute force is much more accurate than Irradiance Caching (Lightmass’s primary GI engine) but it is also slower. It is also more sensitive to lightmap resolution since it actually calculates each lightmap texel, while irradiance caching is more or less resolution independent. You may want to tune down your lightmap resolutions firstly then slowly tune them up when working with GPULightmass.
Hi @aydanyr, This is taken from the first post in this thread, nothing has really changed. I don’t really understand a lot of these statements. Information is sparse and takes a lot of work to read the CUDA code.
There is only sparse comments in the code and the documentation is for Epic Lightmass. Much of these settings as described do not apply to LGPU.
My skill is in converting the LGPU code to support new versions of Unreal Engine 5.
Although you say rectangular lights work they are not in code. Everyone on this thread uses work around described earlier and it wont be added as its need an array using up much need VRAM spaces most of the time this wont be used so emissive lights as described earlier .
3 Likes
Hi All,
Happy New Year for 2024,
buildlighting.rar (700 Bytes)
This is a way to get bigger baked light builds on your current hardware on Unreal Engine 5.3 and onwards
So here is a Windows 10/11 batch file. This uses to 5.3 binary release.
If you have forgotten to put in the LPGU 5.3 patches
Then will run CPU Llightmass instead, if not LGPU patched
If you need to just take the code open
$ notepad buildlighting.bat
REM uncomment the command below for silent bat build
REM ECHO OFF
REM This command below will build Baked Lighting from the command line
REM This will increase the VRAM available on Nvidia GPU allowing larger projects to be baked.
REM
REM You MUST have the Luoshuang’s GPULightmass 5.3 patches loaded documented on the Epic Forum at
REM https://forums.unrealengine.com/t/luoshuangs-gpulightmass/109474/2489
REM
REM Replace Owner with your UserName path
REM Replace StarterMap.umap with the umap you use to bake your lighting.
REM If you have not added the patches the CPU Lightmass will be run.
REM This is NOT for use with Epic GPULightmass which uses DX12 DXR Shaders
REM The command is below the output is in local file projlog.txt
REM DO NOT remove the double quotes in the command below
REM Print start time
ECHO Print Start time in minutes
TIME/T
"C:\Program Files\Epic Games\UE_5.3\Engine\Binaries\Win64\UnrealEditor-Cmd.exe" "C:\Users\Owner\Documents\Unreal Projects\MyProject 5.3\MyProject.uproject" -run=resavepackages -buildlighting -allowcommandletrendering -map=/Game/Maps/StarterMap.umap >projlog.txt
REM print end time
time/T
There has been requests to get the original UE4 Lighting command line builder to work with UE5.
So here is a Windows 10/11 batch file. This uses to 5.3 binary release.
If you have forgotten to put in the LPGU 5.3 patches
Then will run CPU Llightmass instead, if not LGPU patched
You must in all Lightmass adjust the PoolSizeVRAMPercentage=0 to save GPU VRAM as described in
How to Improve Texture Streaming GPU performance in UE5
This command line does not speed up the LGPU build. This way of building does not start the Unreal Editor and therefore saves the GPU VRAM and processing graphics. There is a very quick startup, because it removes the loading of the UE Editor and selection of the project, then opening the project.
I will admit there are other special commands to build sections i.e. only single maps, BUT when I tried opening the UE editor afterward I got the red message to Rebuild Lighting making the builds invalid. This is due to shadows that overlap not being taken into consideration as each map is built.
Therefore in my opinion this is a conflict that can only be resolved by using
Place Actors → Volumes → Lightmass Importance Volumes and adjust the area previously described in detail by another user in this thread
This procedure could probably on a fairly large machine allow you to do other work. I have noticed a significant speed (approximately 10%) up in CPU Lightmass but nothing else
Summary
This is a way to get bigger baked light builds on your current hardware on Unreal Engine 5.3 and onwards
4 Likes
For those who are up to date with the development of version 5.4 version. You guys know if the epic lightmass will be improved somehow? I’ve suffered a little with the 5.3 version in some projects. Thanks in advance
Unable to properly bake the stationary light source, there is no problem with the static light source
5.3 Not using Lumen GI, but enabling Lumen reflection by reflecting the hit light
Hi,
Maybe this needed stating earlier, when UE5 came out many new features like Lumen and Nanite can cause failures in LGPU. These failures are not documented
Please remember that the original base code was written based on UE4 version 4.21 to 4.26.
Lumen was introduced in UE5 as an ALTERNATIVE to baking. LGPU has been through community effort to made to work along side Lumen.
All the current work is supported by the UE community and the Nvidia CUDA code has been upgraded from UE4 to UE5 and will remain the same.
The core code will have to REMAIN the same to support both UE4 and UE5
The fact that new UE 5.3.2 onwards Nanite Displacement causes LGPU stop with an assertion that the input data is wrong.
Nanite/Lumen is NOT baked with LGPU as they are entirely different functions and the addition of Lumen to Static Meshes can cause many problems.
Therefore it is reasonable to say the Nanite and Lumen are not supported by LGPU the functions are tolerated.
The advice is to just turn off the Nanite/Lumen function causing the problem
The case of Epic GPU Lightmass may not be the same but is EPIC supported, not community supported
Hi all,
I hope this isn’t repeating queries, but does LGPU use Nanite Fallback meshes, or the full-detail Nanite mesh itself when baking?
Right now, Epic’s GPU Lightmass uses fallback meshes, which means you have to over-crank the fallback mesh’s detail to reduce artefacts. Which sort of breaks the point of a fallback mesh.
If LGPU can use full-detail Nanite, I’ll definitely be switching over 
As far as I know, Nanite is thought/intended to work with Lumen. That says all.
Many thanks! However, I may have got my terminology wrong whilst browsing through this topic.
Does anyone know if Luoshuang’s GPU Lightmass use Nanite Meshes or the fallback meshes, when baking static lighting?
Hi @Ahume,
You could use Nanite Fallback meshes,BUT you cannot adjust any parameters, because LGPU is describe as Brute Force, and ignores CPU Lightmass settings namely the function is speed.
The requirement is for compatabily with UE4.
I have as an example of converting in batch mode from Static Mesh to Naite mesh for 37 minutes then building the Nanite mesh the UE4 Marketplace Sample Infiltrator. In UE5 and it worked, but the moment you adjust ANYTHING in the converted mesh, the Mesh Editor aborts any Nanite changes are not saved they then baked as Static Meshes, because something in the baking process has changed the properties.
My very obvous question is when do you apply the Lightmass Importance Volume markers into Nanite converted Static Meshes. You cannot change them in the Material Editor or it will crash UE5.3.2 because the addition of Substrate Nanite Displacement.
Therefore as pointed before Substrate Nanite Displacement is not supported because of an assertion error “Input data is duplicated”.
Sorry this information and punctuation is incorrect, but it is hard to write technical english well.
Hey guys, may you guys help me with this issue?
I’ve been trying bake a scene, but I got different results using both Epic lightmass and Luoshuang Lightmass. As you can see on the pics attached, when I use Epic’s you can see the sun through the windows, but the same does not happens when I use LGPU. And this only happens when I try use a HDRI on the SkyLight. If I use the directional light, everything works perfect. Any of you knows why I got this different result using the HDRI? Thanks in advance.
hi @michaelmonte,
HDRI is not supported in CPU Lightmass and therefore LGPU ONLY Direct Light.
LGPU is a Brute Force calculation as its base code is based on UE4, where none of HDRI exists.
Epic GPU Lightmass works on Direct X Raytrace is a bunch of shaders which have support for HDRI.
LGPU will always be faster bakes because it works by allocate to each CUDA processor.
The blistering speed of RTX 40XX family is partly due to its over 8000 processors. This is still be supported in UE 4.26/27
For ArchViz community its very important as they still use 4.26/27
Many thanks, it certainly helps! I’ll keep exploring what options there might be and give LGPU a go
Hi @Jimbohalo10
Just a quick question please, I found that when I am baking the lights, my CPU is using 100% and GPU about 80%. Is that normal? I think before on the oldest GPU verisons it was CPU about 40-50% and GPU full 100%
Hi @Olegsbr ,
This problem is because Rect Lights is not implemented in LGPU CUDA. Therefore the code uses CPU Lightmass
The workaround is to use Emissive lights as in a past post.
Rect lights replace with Emissive Lights
Hi @Jimbohalo10, thank you for your reply! I am not using rect lights at all )) all the lights are emissive/spotlights and point lights.
I have an issue with the poin lights, after I baked them I can see a strange triangular shadow artifats on the walls. Then I put the lighting quality to high in Built menu. And after that UE started using my CPU at 100%…
Inside the project Lightmass configuration file you need to set Production values
Luoshuang’s GPULightmass -Early Documentation
Put this at bottom of Engine\Config\BaseLightmass.ini
[DevOptions.GPULightmass]
; Original Values
;NumPrimaryGISamples=32
;NumSecondaryGISamples=16
; new values for HIGH discovered
;NumPrimaryGISamples=64
;NumSecondaryGISamples=32
; Super Production is still fast and EXTREMELY better compared to
; CPU Lightmass and EGPU (Epic GPULightmass)
NumPrimaryGISamples=128
NumSecondaryGISamples=64