Epic's GPUlightmass

There’s a bug that is a dealbreaker for GPULM in my case.

When using
Stationary Directional Light
Static Sky Light
Volumetric Fog
Shadow Maps (NOT virtual shadow maps, if you toggle those then it looks fine)

The Volumetric Fog is not shadowed (so it glows in dark places)
This works correctly with cpu lightmass of course.

CPU Lightmass

GPU Lightmass

Sorry it’s not the best pics. In indoor places it’s even worse.

Yes, this is due to a technique called Static Depth Map not implemented in GPU Lightmass for stationary directional lights. Static Depth Map is used to compute volumetric fog shadowing for stationary directional lights. For static lights their shadows are baked into volumetric lightmaps so they sort of work.

Thanks for the reply. Is this something planned to be implemented in the future?

Yes.

1 Like

Glad to hear that! Have a nice day.

I am getting the following error in UE5 when trying to build lighting with GPULightmass:
Ensure condition failed: Index <= 0x8000 [File:D:\build++UE5\Sync\Engine\Source\Runtime\Renderer\Private\VT\VirtualTextureAllocator.cpp] [Line: 113]

This seems to happen when my scene is above a certain size. Unfortunately it’s only about 30% of what I was able to build in UE4.

However, it also seems to be somewhat random because I am getting crashes now on a level I was able to build on recently.

Interestingly enough, this seems to happen even when I uncheck all the virtual texturing checkboxes in the project settings.

New big update to GPULM has been submitted to ue5-main as https://github.com/EpicGames/UnrealEngine/commit/069ee84d687f9829c96206b673354b05a3c7ebd3

GPU Lightmass Solver Improvements

Irradiance Caching

  • Instead of setting a per-cell cap of samples, now we use the first X path samples of the receiver (lightmap texels) to adaptively distribute the irradiance cache samples. This will distribute them where BRDF sampling thinks the most important (more around corners and fewer in open area, for example). This is also the distribution that the old school irradiance caching’s distance-based heuristics approximates for.
  • New cache cells are only spawned during the first X passes. This avoids the case where the cache is constantly thrashed when it is not big enough to cover the scene.
  • The image is reset after the first X passes are done. Like path guiding, these passes are uncached and thus contain high variance. Mixing them with the passes later will actually increase overall variance.

First Bounce Ray Guiding

  • Now the FBRG passes run after IC passes are done. Way less input noise into the guiding PDF and better at locating importance sources.

New Parameter Tweaking Strategy for IC and FBRG

  • IC: set quality to 1/16-1/8 of GI samples. Increase when seeing bright splotches around corners, or color discrepancies over large area.
  • FBRE: set trial samples to 1/4 of GI samples. Increase when fireflies or small square-shaped artifacts are introduced by this technique.

General Cleanups

  • IC and FBRG passes now add to the total number of passes to render instead of being subtracted from the number of GI Samples to reduce user confusion.
  • IC buffer size reduction to save some GPU memory.

I picked @Miguel1900 's scene as a test. Note that this scene has unrealistic reflectance value (BasicShapeMaterial has a BaseColor of 1.0) and thus GPULM was having a hard time blasting bounces (up to 32!) around the scene, thus it turned out very bright. Nevertheless GPULM baked it in ~6min on a 2080Ti with GI Samples = 512, IC Quality = 256:

I then reduced the reflectance value to 0.8:

The old CUDA GPULM does not adjust bounce count based on reflectance but brute forcely reduces sample count on high bounces, and by default it clamps everything to be under FireflyClampingThreshold (default = 10.0), thus it has less noise but also losing a lot of energy.

Still, there are missing features like BSP and transparency (to a degree) :smiling_face_with_tear: Be aware that BSP support isn’t coming any time soon as it has very low priority.

I hope you guys have better experience with the new update :flushed:

5 Likes

Just a little update: This crash still occurs in the UE5-Main build as of April 20. In fact, it’s worse. A scene small enough that I could build lighting for it in 5.0 does not build in V5.1, with the same crash errors.

I suppose Epic expects you to have 12Gb of VRAM minimum

Perhaps, but it’s supposed to overflow to regular RAM, which is what it did in my scene in UE4. Although my scene is now a lot smaller and shouldn’t overflow much (if at all) onto RAM.

First test I’m happy with the new update;

  • results look good - smaller details seem more accurate
  • IES lights patterns are now calculated/visible for static lights
  • using the same settings, the new update takes about 25% more time to calculate compared to 427
  • it looks like the denoising & transcoding part at the end takes much more time compared to 427

Will test more…

1 Like

Have you tried lowering the number of samples? My initial tests showed the new update could reach the same quality with much lower settings

Good tip - makes sense after all you write

This will distribute them where BRDF sampling thinks the most important (more around corners and fewer in open area, for example).

Will try to find some time. Lowering render times always is nice!

Wow, great news, @Luoshuang ! Thank you for the good work!

Anyone wanting to use, test, or even improve the scene, can do it from here: Lighting Lab - Testing CPU, GPU(E) & GPU(L) light builds - Let's collaborate!

1 Like

Does anyone have a download for the new GPU Lightmass? I don’t have time to build it

I upgraded to a 3090 and I am now able to build much larger levels, however I’m still getting the same crash when the level gets too large. When I had the crash task manager showed 16GB out of 24GB of VRAM being used.

Haven’t tried 5.1/ue5-main, but I imagine if it’s like the results I was getting with my 3080, it will probably crash earlier than it is in 5.0, but I’ll give it the benefit of the doubt until 5.1 actually comes out.

1 Like

To be honest, bias in the energy amount is still significantly more acceptable than ugly splotches. Even on your screenshots above, you can see unacceptable amount of splotches in the corners. This is something that really won’t cut it with today’s architectural visualization quality standards. The old, unofficial GPU ligthmass could have lost some energy, but the overall result was much more acceptable since large scale splotches were not there.

1 Like

GPUlightmass should acquire ability to use CPU for baking too and thus be possible to use more memory as very few people can afford hyper size memory GPU’s now and in future. It would be slower. but at least it would be more robust and then it could be possible to drop old CPUlightmass. CPU option should be always possible even in far future as we never know when there could be some sort of CPU speed revolution/massive thread rise(graphene CPU as example)

1 Like




Having some challenges with GPU Lightmass.

If my directional light is using a reasonable brightness (25lux) my interior scenes lit by bounce lighting are incredibly noisy (see first pic). Raising the directional light brightness fixes that issue. (second pic)

However, when I do that, I get the exact reverse problem outdoors. High brightness on the directional light creates a lot of noise near edges. (3rd pic is low directional light brightness, 4th is high brightness)

All images have the same number of samples. I played around with increasing the IC samples, size, and corner rejection. I can get improvement with increasing the overall samples in the exterior shots, but not the interior ones, which remain noisy even with high samples.

Had a chance to test the latest ue5-main build on Github. For me it’s a bit of a mixed bag. quality in darker areas further away from light sources seems to be improved, but some new noise has appeared in the brighter spots (second set of images).

Both scenes were built with 8k samples. The 5.1 scene was built with the below settings. The 5.0 scene has fewer samples for IC and FBRG)