Tested it in my scene, just like yours, GPU lightmass in 5.2 produces darkness in the cavities that isn’t visible in 5.1, really accentuates where meshes contact eachother:
I thought the darkness was because the texels were leaking around the base, which it seems like it is but I noticed something interesting when I moved the pillar to see:
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
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…
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’.
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.
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.
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.
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
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 - Glows
ABDC - Works Correctly
ACD - Glows
ABD - 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.
Glows
Works Correctly