Epic's GPUlightmass

This sort-of-ao issue seems solved in 5.3 main so crossing fingers that one will launch soon.
I noticed that in both 5.2 and 5.3 main, ies lights are broken. No light patterns visible. Reported but not confirmed yet. In 5.1 it works as intended

2 Likes

Thanks for the heads up! I will try to get around to testing 5.3 in my scene.

is it the same issue?


I can confirm the overocclusion issue is fixed in UE5.3-Preview 1, so all seems good.

2 Likes

Just tested 5.4 (main) and the IES lights are still broken so for Archviz 5.1 is the only option at the moment if you prefer GPUlm instead of Lumen (for instance to build for mobile VR or high-framerate desktop VR).

Reported a while back but in the Unreal Bug Tracker its still noted as fixed (for 5.1 - it was broken as well in 5.0).

Can I ask if anyone at Epic is aware of this issue? Also, is GPUlightmass still under development? Not much going on in this forum. Also, I can’t remember if there were any updates in 5.2 and 5.3 for GPUlm besides the AO-like-issue that was fixed…

Without going into details, I’d say GPLUM is dead in the water. I wouldn’t count on any advancements at this point.

The ‘bus factor’.

Anyway, I hope he is going well.

I would find it very strange for a big tech company like Epic if they would just let GPUlm go to waste. It really is so much better compared to CPUlm and for some usecases, Lumen just is too ‘heavy’.

Sure! That would be strange, however, I always had that sensation :thinking:

If GPUlm really is dead in the water now - I’m crossing fingers someone (Luoshuang himself maybe?) can develop a similar plugin and keep on developing it for future versions of UE. I would gladly pay for that plugin on the marketplace. I expect I’m not the only one.

3 Likes

This would be crushing if GPULM is abandoned. Please tell me this is not the case.

1 Like

You know Luos was also the author of Epic’s GPULM, right? (I mean: he won’t be the guy you want)

Yes I know. If he’s not at Epic anymore, maybe he could pick up where he left his original GPUlm plugin? One can only hope…

1 Like

Is it a known bug that GPULM doesn’t work with Landscapes?

Unfortunately, in addition to the already identified emissive material issue in GPULM, there is also a severe shadowing issue present in UE5.3.

@Arkiras has been able to reproduce this issue as well.

Example of the issue. (5.3)

Exact same scene and settings in 5.1.1

I was able to make some progress on this issue by disabling “support stationary Skylight” in the shader permutation reduction section of the project settings.
image

However, not that I’m not actually using stationary skylights.

This did allow me to bake lighting in certain sublevels, however, others remained broken.


This scene has some shadowing, but light is appearing from underneath the elevator machinery, which is a flat shelf. There also are light blockers that should prevent any light from coming up.

Doing some additional testing in this area, at some point somehow the engine just reverted to the completely broken state, and I have not been able to get back to where it was partially working.

2 Likes

Steps to reproduce the above issue:

Step 1: Create new “Games/Blank” blueprint project
Step 2: Enable virtual textures, and virtual texture lightmaps, and hardware ray tracing.
Step 3: Set targeted RHI as Directx12 SM6
Step 4: Restart engine to rebuild shaders
Step 5: Make new “empty level”
Step 6: Add Static directional light, static height fog, static sky atmosphere and static skylight.
Step 7: Create two cubes, Scale (X=25.000000,Y=25.000000,Z=1.000000)
Step 8: Raise one cube 200 units above the other so there is a gap between them.
Step 9: Create a new material with a simple vector 3 color, apply and save.
Step 10: Apply new material to top cube
Step 11: Start GPULightmass bake.

Result: Top cube does not cast a shadow on the lower cube.

I have submitted an official bug report. It would be great if others could test this and let me know if you can reproduce this.

Hoping epic can figure this out and give us confirmation it will be fixed for 5.4

1 Like

Okay… so regarding the glowing light that @Ozykz posted about above… It seems like it has something to do with the material editor.

This is sort of difficult to explain but bear with me here. Consider the following actions:

A: Changing the material (can be as simple as just moving a node)
B: Applying the material (pressing the apply button)
C: Saving the material (pressing the save button)
D: Building the Lighting

Depending on the order you do these in, the lighting build will produce the glowing light error. Testing different orders of these tasks shows:

ABCD - :x:Glows
ABDC - :white_check_mark: Works Correctly
ACD - :x:Glows
ABD - :white_check_mark: Works Correctly

From what I can tell, it doesn’t seem to make any difference what the material logic is doing (as you can see from the video, literally all I am doing is moving a node). The only thing that matters is the order of saving/applying the material and building the lighting… I did test this with material instances, so long as the parent material works correctly the material instances (appear) to work correctly as well. If the parent material is glowing, the child materials will glow.

Nightmare bug tbh

4 Likes

What if you don’t use real-time preview ?

Doesn’t make a difference:

Summary

Different scene obviously, I created a new project to see if it was specific to something about my project… clearly it isnt.

1 Like

I have tested right now in 5.3 and 5.4 and it seems to be broken in 5.3 (just to confirm I’m not wrong), but working as expected in 5.4. We just need to wait, or to compile 5.4 from code.