Epic's GPUlightmass

If you have large amounts of HISM instances, and you actually have them set to static and not excluded from the static lightmap, then of course you will get crashes, because you will run out of memory.

Yes, they are instances, but the problem is each instance is is still at unique place in your level, so it has to receive unique lighting. Lightmaps for HISM instances therefore can not be instanced, so running out of memory and crashing lightmap is expected if you are trying to bake for example a forest where each single piece of foliage is supposed to have its lighting baked.

Thanks for the reply. It happens with even 1 single HISM so I wonder if its supported by GPUlightmass at all. See my additional remarks in my previous post above yours.

To eliminate bounce light from the skylight, you could bake the skylight as stationary, and then in your master postprocess volume I believe there is an option to scale how much indirect light there is

This removes all indirect lighting, including from other lightsources. Really not a viable solution.

Edit 220325: issue is solved - was caused by a material. See Epic's GPUlightmass - #281 by maxbrown

Testing UE 5.0.0.p1 - GPU lightmass seems broken. Building lights seems to work as intended but after de-noising the lighting result looks bad. Wondering if I’m missing a setting;

  • brand new UE5 game project (or use Koola’s Lightroom for comparison to UE4.27.2)
  • enable GPU lightmass plugin
  • in project settings enable/set RHI 12, raytracing, disable GI, set reflections to screen space, enable virtual textures
  • in world settings make sure Force No Precomputed lighting is unchecked.
  • add Lightmass Importance Volume
  • set all lights to static
  • in console; r.RayTracing.ForceAllRayTracingEffects 0
  • Build lighting using GPU lightmass

After light building & denoising the result looks bad - see pic from launcher
gpulightmass

Edit 220325: issue is solved, see Epic's GPUlightmass - #281 by maxbrown
Testing UE 5.0.0.p2 - GPU lightmass still broken. Same result as in the picture in my post above.
Log reports ‘LogTemp: Static lighting system is removed for world…’.
Reported last week, no response back.

Hoping this gets fixed. Lumen is fantastic tech but for VR / Quest the good old lightmaps are still needed.

Hi maxbrown, there have been some important fixes to GPU Lightmass since P2 that will make it into 5.0. Any chance you are able to build a source engine from git and test it on the Koola scene? I see that scene in the marketplace but it doesn’t appear to be downloadable anymore.

In regards to the truncated log message you have here:

It is important to note that in 5.0, maps using World Partition do not support baked lighting. Are you testing a level with WP enabled? This restriction might change in a future engine release, but that is how it will be for 5.0 at least. Any projects needing baked lighting should continue to use traditional levels.

So, there is a use case for GPU Lightmass where forward rendering has to be enabled, along with Raytracing and DX12 RHI, to be able to bake lighting using GPU Lightmass for projects that require forward rendering (VR for example). It’s all cool, except with such setup Android Vulkan preview in the Editor does not work. It was the case for 4.27 and for UE5p2.

Any idea if that’s going to be fixed in UE5 release @jon_eg ?

Another issue I found is that when building lighting with GPU Lightmass, it doesn’t build whatever it needs to build for Precomputed Visibility to work. So naturally I have to build lighting using good ol’ CPU Lightmass (on Preview quality) to be able to utilize Precomputed Visibility and then on top of that I have to build lighting using GPU Lightmass. It’s not productive at all :frowning:
I don’t know if UE5 will have precomputed visibility, but if it will have that, it would be nice to get a fix.

Building the UE5-main at the moment. Will update here.
World partition is not enabled in the project settings so there must be some other cause for this error

A little safer to build the “5.0” branch but if you’ve already started UE5-main, maybe finish it out. I don’t think UE5-Main has any changes to GPULM not in 5.0, but it has many other differences.

Can you print the entirety of that log message? It might be a red herring anyway.

Haven’t heard about this one, I can ask/look around.

Regarding Precomputed Visibility, you are correct that it is not supported by building w/ GPU Lightmass. I can log an issue for this.

2 Likes

Much appreciated. thanks !

@jon_eg Can you tell us what improvements have been made since 4.27? Like is encoding/denoising lightmaps still being handled by the CPU? It’s such a performance bottleneck atm.

I was under the impression the ‘UE5-main’ was the most up to date branch. In the Github text you can find

Most active development on UE5 happens in the ue5-main branch. This branch reflects the cutting edge of the engine and may be buggy — it may not even compile. We make it available for battle-hardened developers eager to test new features or work in lock-step with us.

That’s all correct. “ue5-main” is newer than “5.0”, think of it as early 5.1. 5.0 is the stable release branch that the previews and eventual 5.0 release will actually come from, and the warning about being buggy or not compiling should be a lot less of a risk there, at least this late in the preview cycle.

Preface: I’m using the 5.0 branch built from source yesterday

Not the Koola scene but honestly it’s unnecessary. This problem is ubiquitous and it is an issue with the denoiser.

Here’s a comparison in one of my scenes:

Other noteworthy issues:

  • Volumetric lightmap doesn’t seem to get built at all (or isn’t influencing the scene) in GPU Lightmass. You can see in my screenshots, the calibration cube is set to moveable and is not correctly lit in the GPU Lightmass builds but looks correct when light is built with CPU. (This turned out to be due to the skylight being set to stationary)
  • Color influence from SkyAtmosphere system is still not being taken into account. The light in this scene is sunset lighting and you can see from my screenshots that the hue of the light in the scene is completely different in both the Pathtracer and CPU Lightmass.
2 Likes

Edit 220325: issue is solved, see Epic's GPUlightmass - #281 by maxbrown
In case more people are testing…Just tested the todays build of UE5-main and GPUlightmass still is broken, same result as in P1 and P2.

1 Like

Hi Arkiras,

Can you send that scene showing the denoiser issue? I don’t see the denoiser doing that in other simple test scenes with dark areas. Same with the VLM, works for me in basic tests.

You are correct that GPULM still doesn’t honor the SkyAtmosphere light color. I’ve double checked that that is logged and on the radar for the developers.

We were able to reproduce a “DEVICE LOST” crash launching Android Vulkan preview with those settings. Is that what you are getting? Does the Android Vulkan preview work for you if you revert any of those settings, and if so which ones?

1 Like

@maxbrown,
here is my GPU enabled 5.0 P2 following your instructions

I have enabled Local Swarm on CPU enabled LightMass which is much faster, my GPU is a GTX1050 my processor is Ryzen 5 6 core.
I use the Lightmass Swarm setting