Luoshuang's GPULightmass


This is a very simple and early version of my GPU lightmap baker. Don’t expect much from it! =)

Binary Installation:

4.19.1:…f6eEbmKRa?dl=0 [Updated 04/16/2018 18:13]
4.20.1: 4.20.1 - Orangedox (starting from here it requires NVIDIA driver version >= 398.26)
4.20.2: 4.20.2 - Orangedox
4.20.2 Unified Settings: 4.20.2-UnifiedSettings - Orangedox (see #478]( for instructions on how to use)
4.21.0 Unified Settings: 4.21.0-UnifiedSettings - Orangedox (Turing cards support, requring driver >= 411.31, not using RTX)
4.22.0 Unified Settings: 4.22.0-UnifiedSettings - Orangedox (FireflyClampingThreshold has been loosened to allow more contrast from skylight and correct brightness for emissives - if you start to see fireflies from sky or emissive you may want to set it to lower values like 10.0 (in BaseLightmass.ini))

Merge the zip’s content with your UE_4.19/Engine folder.
This installation overwrites your BaseLightmass.ini so you want to back it up if you have modified its parameters.

  • If you want to keep your BaseLightmass.ini, set bUsePhotonMapping and bUseRadiositySolverForSkylightMultibounce to false to avoid CPU computation.

Sorry for no 4.18 support, since some logic dealing with volumetric lightmaps changes a little bit too much in 4.19.

Automatic Script Installer:

@Situx has done a nice installer for GPULightmass that checks multiple things to help prevent problems:…11#post1519111

Source (Hybrid) Installation:

For versions prior to 4.20.2 unified settings, see…65#post1460865
For 4.20.2 unified settings, see…66#post1529966
For 4.21.0 unified settings, refer to 4.20.2 but use this one:


  • Written in CUDA so NVIDIA only.

  • 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)

Useful Tips:

  • 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.

  • Comparison of Brute Force vs Irradiance Caching:

  • Since adaptively placing more samples around corners (known as Retrace in vray) hasn’t been implemented you may see sploches.

  • You can use command line to launch the editor and bake lighting to save GPU resources for GPULightmass, especially video memory.

  • Engine/Binaries/Win64/UE4Editor-Cmd.exe “path o\your\project\yourproject.uproject” -run=resavepackages -buildlighting -allowcommandletrendering -map=/Game/Maps/MyMap.umap

  • Remember to replace Content with Game in the umap path

  • It is recommended to change Windows TDR settings to prevent the GPU from being timed out (unspecified launch failure and other Error crashes) under heavy workload

  • See…nce_last_patch for instructions.

  • A value of 300 is good

  • You need to reboot your system

  • Windows Update may reset this setting, so check again if you have problems after updating

  • Some stats:

  • A scene having 30M triangles and 150 1K lightmaps requires 7GB video memory and ~3hrs to bake on a GTX1080

Change Log:

[04/16/2018] Fixed attenuation calculation of spotlights
[04/14/2018] Further improved the adaptive hemisphere sampler to suppress visible artifacts
[04/14/2018] Fixed issues with sparse volume lighting samples and masked materials
[04/14/2018] Fixed a bug inside the adaptive hemisphere sampler. The number of samples is also raised. Now GPULightmass runs at Ultra High settings by default, which is a little bit overkill for most scenes.
[04/13/2018] Added support for sparse volume lighting samples
[04/13/2018] Fixed a bug which prevents GPULightmass from running on cards that are older than GTX10XX

Known Issues:

  • Ray hit rejection by LOD/HLOD hasn’t been implemented and you may see black splotches where lower LOD meshes poke out.

How to Get the Best out of GPULightmass:

  • Currently GPULightmass uses all emissive materials in baking regardless of ‘Use Emissive in Static Lighting’ option. If you see sparkles they are probably from some small bright emissive sources (especially, small LED panels in kitchen). You’ll want to use the LightmassReplace material node or set the EmissiveBoost to zero to remove them for GPULightmass. Starting from 4.20 GPULightmass respects ‘Use Emissive in Static Lighting’ option. However, t****he idea is to not use any small & bright emissive light sources in GPULightmass. If you want to get rid of sparkles, you can also try tuning down ‘FireflyClampingThreshold’.
  • GPULightmass uses ‘Two Sided Emulation’ on all two-sided materials which could be the reason why people are seeing darken environments and light leaks. Currently the workaround is to turn off two-sided on the problematic materials. See…32#post1477832

That was awesome!!!

Nice…Thank you for your work…

Hoolllyy shi…et. you are awesome !

This is amazing! Will this work if I have multiple GPUs? Does it support lighting scenarios?

I haven’t come to the point of supporting multiple GPUs, but it isn’t very hard based on the algorithm I’m using now. For lighting scenarios they are quite independent from Lightmass, so while I haven’t tested that, I guess they should work well.

I’ll be testing it today! I’ll let you know how it goes, this is extremely promising. Do lightmass settings like “Static Lighting Level Scale” still apply? Is this one ignored too?

Yes it is ignored since it is a parameter of Irradiance Caching which specifies the actual spatial resolution at which lighting calculation happens. Since GPULightmass uses brute force and calculates every texel you can just assume it is a very low value like 0.001.

I’m running into an issue where the rendering gets stuck (I can notice how my GPU has stopped working) and the following error is printed to the log:
LogRHI: Error: GetAndOrCreateGraphicsPipelineState RenderTarget check failed with: 1928 !

It might be because I have some materials that use Render Targets. I’m going to try to use a lightmass replace node in the material and use a flat texture for lightmass and report back to see if this fixes the issue.

I believe that is related to TDR settings. I’ll put an instruction on how to change it inside the useful tips.

Also I found a bug inside the program which can prevent GPULightmass from running on older cards. I’ve updated the link so you can download the newer version.

It seems to get stuck towards the end of the rendering! And my 1080Ti definitely stopped rendering.
Here is Swarm’s log:

It seems that it always stops rendering at the end:

here is the log:

Any idea what this may be? The error message of before is not showing up anymore by the way! I used the TDR fix with a decimal value of 30

Would you like to provide your scene to me for debugging?

Do you have some setups like precomputed visibility which can only be done on CPU currently?

Also I remember that currently the calculation of volumetric lightmaps doesn’t have a proper progression display, so if you see the GPU is not idle it may be working on that.

I’m not using volumetric lightmaps or precomputed visibility switch since both don’t support level streaming. I’m going to try to provide you with a scene where I can reproduce the issue, the entire level might be problematic to share. I’ll PM you when I have something!

Do you have comparision screenshots from cpu vs gpu versions. This is really interesting.

While I’m planning on it, I don’t want to “advertise” much now since it’s pretty premature :rolleyes:

I think I’m getting closer to the problem. The GPU calculation gets stuck, the GPU stops working, but Lightmass.exe sits at 62% CPU usage. This only happens when I’m using “Sparse Volume Lighting Samples”. Are these supported?

Sparse Volume Lighting Samples are computed entirely on CPU now. I believe it should be the problem.

I see! Does that mean the lighting needs to be recalculated entirely on CPU for the Sparse Volume Lighting Samples to work? I’m just trying to get an idea of how long it should take, as it seems to take forever and there is no output on the log giving me an idea that progress is indeed happening.

By the way, the results are amazing!!!