Epic's GPUlightmass

Sure you can send me the empty scene. The discoloration really looks like the denoiser issue which is supposedly fixed in ue5-main/5.1

Wow, so fast!

Thanks Yujiang. Scene already sent. Also with this plant area, where there is the another big difference:
GPULL:


GPULE:

Thank you so much!

1 Like

I don’t seem to be able to bake stationary point and spot lights with GPULM in UE 4.27.2. Is it a bug or just not supported ?

Works for me

2 Likes

I have static directional and skylight in the scene, and stationary spotlights. Perhaps when there is a mix of lights it fails ?

Still working correctly for me.

If you’re using realistic light intensities for the sun then maybe your spot/point lights are just being drowned out by the light from the sun?

I definitely don’t use any realistic values. Just what looks good to me. And when I bake with CPULM, it shows as expected.
Are you sure in your screenshots it’s baked stationary and not real-time stationary ?

I don’t know what this means, can you elaborate

The direct lighting of stationary lights is rendered dynamically using deferred shading. This allows the brightness and color to be changeable at runtime

I guess this answers my question - I am using forward rendering :frowning:

1 Like

Your scene revealed some critical issues inside the volumetric lightmap renderer and I decided to expedite the planned rework to the renderer.

Volumetric Lightmap Renderer Rework

Animation

Instead of rendering the entire scene’s volumetric lightmap probes all at once, now the renderer progresses through the probes by batches. This breaks interactive preview for volumetric lightmaps, but has much better irradiance locality and saves significant amount of both work and GPU memory. Now it takes only ~1/4 of the original GPU memory to bake volumetric lightmaps. The computation needed for VLM is also cut down by 50% so things should be generally faster. The batches of probes are processed following Z-order curve to further improve locality.

Since the rework breaks interactive preview, now you may see weird things like black strips and seams in VLM while its being baked. They should be gone once the bake finishes.

Also, VLM probe placement has been tightened. The original idea was to place more probes to reduce leaks, but after some careful testing that was not really working as expected, while wasting space. After tightening we should have ~25% fewer probes now.

Reason why your VLM probes were turning dark was that since the probes were rendered all at once, they were poking the entire scene which had absolutely terrible locality and destroyed the content of irradiance cache. And in such cases IC had a bug that would return invalid samples (:flushed:) which made the VLM probes black. During the rework the bug was fixed so we shouldn’t get black samples even if that happens again.

Above changes should be visible on github up to

9 Likes

On the topic of the VLM… Is there any hope we’ll be able to use VLM with level streaming in the future, without having to bake all the levels at once? This seems like it’s going to be a really big pain point unless average GPU memory skyrockets in the near future

2 Likes

Impressive work! I wanted to try it and see if everything’s fixed, but UE isn’t working for me at that commit (some error about module not loading or something, it’ll probably get fixed soon).

With these fixes I think GPULM is capable of replacing CPULM in production, at least for my use cases.

I second that… Having it with level streaming is essential.

1 Like

So not surprisingly, this discoloration issue is caused by the denoiser. You have a point light right under the lamp which creates high dynamic range on the same object:

While I do have some idea to further improve the Intel denoiser, for such cases my best suggestion would be disabling denoising all together (or use Simple Firefly Remover in 5.1) and use a higher GI samples value like 4k. GPULM in 5.1 behaves very close to the OG Luoshuang’s GPULM when IC&FBRG is enabled denoising is disabled:


And the mesh actually has a Min Lightmap Res of 256 while the lightmap res in the scene is set to 128:

MinRes

After bumping lightmap res from 128 to 256 the left issues are all fixed:

Settings used:

Automatic Two Sided Lighting for Two Sided Materials


I’ve just submitted another change which should fix the black backfacing leaves. Interestingly this has been an issue since CPULM and I did a fix in Luoshuang’s GPULM but didn’t port it over. Be aware that since our surface lighting representation is inherently single sided (L1 SH but corrected to hemisphere), while it is not pitch black now there can be some directionality loss (less effective normal maps) and brightness issues, but better than before. To get ‘true correct’ results VLM (with high density) is needed which uses full sphere L2 SH, but as you guys have pointed out above, it is not really a practical advice without proper volumetric lightmap streaming support.

5 Likes

Another feature update for translucency in 5.1:

Translucency Compliance in GPULM 5.1

GPULM had limited support for translucency because of perfomance limits. The only translucency model it supports is Thin Translucent. Yet it seems like a lot of people do like CPULM behavior for translucent shadows. Thus in 5.1 GPULM supports translucency as follows.

When the shading model is Default Lit and blend mode is translucent, GPULM behaves like CPULM to cast colored shadows (from static lights). Internally this is actually emulated by a Thin Translucent model with parameters Opacity = 0, TransmittanceColor = lerp(1, BaseColor, OriginalOpacity). When the shading model is indeed Thin Translucent, GPULM behaves like the path tracer and uses the parameters the path tracer uses.

Note that GPULM does not support any open, single sided geometry. They are treated as invalid and GPULM uses them to remove invalid samples inside geometry (like, around the corners of two walls intersecting). Any single piece geometry should either be marked as two sided or with the front face facing the scene (like, you are baking an interior and the window glasses can be single sided with the front side facing the inside). When the requirement is not met expect certain features especially FBRG to break (grid patterns):

7 Likes

Really impressive stuff!

Do you think we’ll get support for streaming levels for GPULM in 5.1 or not just yet ? @Luoshuang @YujiangW

Huh, this is surprising. I remember reporting issues with GPULM volumetric lightmap creating invalid samples, causing high contrast probes with burnt black areas on UDN over a year ago. I was told that this was due to GPULM not supporting bent normal skylight illumination. That answer sounded odd to me, but I never disputed it. It’s crazy to believe that bug survived for such a long time, but I am glad it’s on the radar finally.

For me, the GPULM produced both faster and more accurate surface lightmaps, but I’ve almost never ran into a level where the volumetric lightmap result wasn’t broken/corrupted.

Well, the fixed bug was actually introduced in 5.1 by the solver refactor, so your problem is unlikely to be the same. That being said, since we don’t have spherical harmonics de-ringing in GPULM, you can indeed have negative values in high contrast lighting conditions. It could be a bug, if you are seeing high contrast probes in one case but not in another (similar) case.

Yes, I often see high contrast probes in scenario where the high contrast lighting should not be present. CPULM never has this problem. Anyway, if there are actual negative values, then there should be no question whether it could be a bug or not. Negative lighting value is always a bug. Even if there is no deringing, shouldn’t the probe light values as the very least be bottom clamped to 0? If a sample returns negative value, then obviously something invalid was sampled.

Well it’s slightly complicated than that - spherical harmonics is a representation that can generate negative values on its own, whenever there’s drastic lighting change over directions. Known as ‘ringing’, this effect actually improves sharpness on the non-negative part of the sphere. CPULM removes the negative values through de-ringing at the cost of blurring lighting overall. That being said, this is to be implemented but I haven’t got there

1 Like