Epic's GPUlightmass

The GPULM 5.1.1 fixes have been submitted to 5.1 branch and are visible on GitHub now: https://github.com/EpicGames/UnrealEngine/commit/0c50cb09979582d7cee299406b1e828f5c471624

Our 5.1.1 official release can take some time (probably longer than you would expect), so for people want to use GPULM in 5.1 they’ll need to use a source build for a while.

4 Likes

Is it still broken having volumetric lightmaps combined with level streaming? Last time I tried in UE4 it broke in different ways whether I was using CPU or GPU lightmass. And in case it’s still broken, is it known if there’s an intention to fix it some day?

Thanks!

Unfortunately there still seems to be issues.


Many lightmaps seem fine when up close, but when you get away (lower mip or LOD, not sure) they get messed up (basketball hoop, lamps). Others are just always wrong (ceiling and walls).

I don’t use virtual lightmaps, by the way.

The issues I reported before are not showing however.

(tested at commit 2527c8751a97d57c4a2d5b652587118a49725a15)

The map I tested with is a bit updated compared to the one I sent you, so maybe you can’t repro exactly. If you want my latest version let me know and I’ll send it.

Thanks a lot @Luoshuang - just build 5.1.0 and it works. Will test more in the coming days and will report back if I run into issues like @nSpeednSpeed

With the patch from @Luoshuang applied everyting seems to be working just fine (hurray!)

Just one remark:

  • Meshes containing glass are reported as unbuilt after building finishes
  • (related?) lights are reported to have unbuilt interactions

I was unable to repro the LOD issues with the scene you sent me (VT lightmaps disabled):

Did you get this upgrade notification when you clicked on build?


This is a new feature I added in 5.1.1. To ensure existing lightmaps and baked materials not get broken when we introduce a new auto lightmap UV gen algorithm into the engine, meshes always have their lightmap UVs generated with the algorithm they were originally imported, until the user modifies them and click build in the static mesh editor. That means assets migrated from old engine versions can have insanely old lightmap UV version that the user is not aware of. In 5.1.1 GPULM scans for such cases and prompts you for a potential upgrade as you are going to rebuild lighting anyway.
Also, while it says it can ‘break existing lightmaps’, it won’t save your map and mesh assets, so you can easily restore them by reloading them/restarting the editor.

Yes, I did get that prompt. I’ll try again later on a clean build just in case (instead of incremental). Also as I mentioned my map is slightly updated, so maybe that’s why you can’t reproduce. If it still fails on a clean build I’ll send you the updated map.

Just tried again with a clean build of everything, plus more recent 5.1 too (9a63ab16ee658737529fcb17eb1b15df3144ace1) and I can confirm it’s still causing the same issues.

The walls being messed up is a bit random, sometimes its one wall that’s messed up, sometimes another. The LOD thing however is always consistent.

I did get again the UV upgrade thing by the say (since I tested “from scratch”)

As a side note, in some intermediate test (in which I cleaned just the engine) I noticed that some engine files are getting upgraded. The engine files should probably come already upgraded maybe?

And lastly, there’s this room that gets really messed up. This already happened in previous UE versions and I thought it was because the light was clipping the geometry (CPULM handles it OK however), but I briefly tried to fix it and it seems to be something else. Edit: Yes, this issue was with these lights clipping with the geometry. If I move the lights outside of the lamp geometry it gets fixed.

By the way the path tracer seems to leak on those lights as well.

I have sent you a DM with my updated map so you can try to reproduce and investigate.

Edit: I tried replacing those lights with rect lights, placed differently, and the path tracer gets fixed but the lightmaps still end up wrong. Also when replacing these I also replaced the lights in the indoor basketball court with different lights and that fixed the LOD bug.

Edit2: I tried on another map and I can confirm the LOD issue happens there as well (completely different map and lights). Also that map has an issue that after building, it still says lighting needs to be rebuilt (for only a few objects), and DumpUnbuiltLightInteractions confirms.

I ran into some issues while testing a github 5.1.0 + the latest fixes by Luoshuang (22 nov) - build.

Tested a project in 5.0.3 and also converted it (a copy) to this new build. Didn’t change any settings in 5.1.0 - only started the GPUlightmass.

In the 5.1.0 build;

  • gpuLM takes a lot longer to calculate (x4).
  • the light is different (IES now supported)
  • some artifacts / seams appear on some meshes (see orange arrows). That walls has green-lightmap density so I see no reason for this.

Any suggestion what could be the cause for that ‘line’ ?


Things are getting quite weird now. I am still not able to repro the LOD issue:

Also, regarding the clipping issue, it is actually caused by the denoiser:


I wonder if this is the classical ‘high contrast’ case (high contrast of lighting appears on the same object and the denoiser isnt able to handle that dynamic range) - when the light is clipping with geometries, it is hard to sample which creates a lot of noise, including fireflies (super bright spots). These bright spots then confuse the denoiser and make it output darker

Can you at least reproduce it when you open the project I sent you, without building lights or anything?

When I open what I sent you “as is” (with the included lightmaps) I can already see the erroneous LOD lightmap behavior.

Yes.

I don’t know what it could be then. Maybe some hardware/driver specific bug, or just undefined behavior that depends on who knows what. If it’s any use, this is my setup

Windows 10 21H2
AMD 3900x
NVIDIA 2070 Super (driver 526.98)

I also built with VS2022, and only what was necessary (Ctrl+F5 on project solution, not building 100% of engine)

This led me into the idea of potential memory corruptions and I indeed found one.

You can try editing Engine\Plugins\Experimental\GPULightmass\Source\GPULightmass\Private\LightmapRenderer.cpp
search for ERDGInitialDataFlags::NoCopy and change it to ERDGInitialDataFlags::None

Unfortunately that did not fix the LOD thing.

Something I didn’t mention before is that sometimes, after building lights I would get some weird texture corruption, that would be fixed by reloading the map or editor. Maybe that’s fixed now with that change? Hard to tell because it happened like 1/3 or 1/5 times.

If it’s any use, this is what it looks like with no compression + no denoise + ERDGInitialDataFlags::None (which didn’t make a difference afaict)

At the moment I would suggest turning on VT lightmaps and watch the preview so we may have a better understanding about whats going on :thinking:

So I did a some testing with VT.

First I did a full bake

The LOD bug is still there (although a bit less bright). Left wall is also incorrectly lit, and something new is that some of the volumetric fog is messed up.

Then I did another full bake, slow mode and recorded it all. It had the same issues, but in addition when it finished denoising some very weird artifacts appeared (first time something like that happened).

Link to video sent in DM

Then I did a bake what you see, recorded it all too. It baked fine with no errors.

Link to video sent in DM

And finally I saved that bake what you see, and it denoised and ended up fine.

Everything was baked with 128 GI samples, and 50 volumetric density.

@Luoshuang I did some more tests with the 5.1 build + your additional fixes.
In a test project, seams / color differences are visible on some objects. See picture. Strange thing is, the position is not consistent nor matches the lightmap UV layout. Running several gpu lightmass builds in succession, they appear elsewhere.
I PM-ed you a link to a YouTube video showing this issue.

Meanwhile I downloaded and tested a few recent NVIDIA drivers, and the driver started behaving weird since 526.47. I would recommend using 522.25 instead.
522.25 vs 526.47 (and the later 526.98) with all my 5.1.1 fixes applied:


1 Like