Great to see an update!
From initial tests, I am running into one specific issue where turning on the feature
’Use First Bounce Ray Guiding’ always results in the bake not saving / applied.
@yujiang.wang So, UE5.x is utter garbage when it comes to VR and standalone VR specifically. One very nice dev decided to save us all and made a fork of 4.27.2-plus that combines stability, performance and all features needed to be used for standalone VR projects: https://github.com/uno1982/UnrealEngine/tree/4.27-plus-meta
Unfortunately, CPULM in 4.27.x is much slower comparing to CPULM in 5.4+ and GPULM has a lot of limitations/issues. So baking lighting is problematic (from productivity perspective with CPULM and quality perspective with GPULM)
I am wondering if you could help improving GPULM in that branch and by doing so, save a lot of standalone VR Unreal devs by switching to Godot or Unity 
1 Like
Confirming I’m having the same experience. Also my log is full of
”Cached ray tracing scene is invalidated due to material changes”
Hi, it seems GPU Lightmass for UE5.6.1 seems to crash with AMD cards
Unhandled Exception: EXCEPTION_ACCESS_VIOLATION writing address 0x000000002000000c
amdxc64
amdxc64
amdxc64
amdxc64
amdxc64
amdxc64
amdxc64
amdxc64
amdxc64
amdxc64
amdxc64
amdxc64
amdxc64
amdxc64
amdxc64
amdxc64
amdxc64
amdxc64
amdxc64
amdxc64
amdxc64
amdxc64
amdxc64
D3D12Core
D3D12Core
D3D12Core
D3D12Core
D3D12Core
D3D12
D3D12Core
UnrealEditor_D3D12RHI!CreateRayTracingStateObject() [D:\build\++UE5\Sync\Engine\Source\Runtime\D3D12RHI\Private\D3D12RayTracing.cpp:655]
UnrealEditor_D3D12RHI!FD3D12RayTracingPipelineState::FD3D12RayTracingPipelineState() [D:\build\++UE5\Sync\Engine\Source\Runtime\D3D12RHI\Private\D3D12RayTracing.cpp:2963]
UnrealEditor_D3D12RHI!FD3D12DynamicRHI::RHICreateRayTracingPipelineState() [D:\build\++UE5\Sync\Engine\Source\Runtime\D3D12RHI\Private\D3D12RayTracing.cpp:3471]
UnrealEditor_RHI!FCompileRayTracingPipelineStateTask::DoTask() [D:\build\++UE5\Sync\Engine\Source\Runtime\RHI\Private\PipelineStateCache.cpp:3587]
UnrealEditor_RHI!TGraphTask<FCompileRayTracingPipelineStateTask>::ExecuteTask() [D:\build\++UE5\Sync\Engine\Source\Runtime\Core\Public\Async\TaskGraphInterfaces.h:706]
UnrealEditor_RHI!UE::Tasks::Private::FTaskBase::TryExecuteTask() [D:\build\++UE5\Sync\Engine\Source\Runtime\Core\Public\Tasks\TaskPrivate.h:527]
UnrealEditor_RHI!LowLevelTasks::TTaskDelegate<LowLevelTasks::FTask * __ptr64 __cdecl(bool),48>::TTaskDelegateImpl<`LowLevelTasks::FTask::Init<`UE::Tasks::Private::FTaskBase::Init'::`2'::<lambda_1> >'::`13'::<lambda_1>,0>::CallAndMove() [D:\build\++UE5\Sync\Engine\Source\Runtime\Core\Public\Async\Fundamental\TaskDelegate.h:171]
UnrealEditor_Core!LowLevelTasks::FTask::ExecuteTask() [D:\build\++UE5\Sync\Engine\Source\Runtime\Core\Public\Async\Fundamental\Task.h:627]
UnrealEditor_Core!LowLevelTasks::FScheduler::ExecuteTask() [D:\build\++UE5\Sync\Engine\Source\Runtime\Core\Private\Async\Fundamental\Scheduler.cpp:365]
UnrealEditor_Core!LowLevelTasks::FScheduler::WorkerLoop() [D:\build\++UE5\Sync\Engine\Source\Runtime\Core\Private\Async\Fundamental\Scheduler.cpp:724]
UnrealEditor_Core!`LowLevelTasks::FScheduler::CreateWorker'::`2'::<lambda_1>::operator()() [D:\build\++UE5\Sync\Engine\Source\Runtime\Core\Private\Async\Fundamental\Scheduler.cpp:188]
UnrealEditor_Core!FThreadImpl::Run() [D:\build\++UE5\Sync\Engine\Source\Runtime\Core\Private\HAL\Thread.cpp:69]
UnrealEditor_Core!FRunnableThreadWin::Run() [D:\build\++UE5\Sync\Engine\Source\Runtime\Core\Private\Windows\WindowsRunnableThread.cpp:159]
What’s weird is that my D: drive just contains my game library not ue5
Never mind, there is a weird bug where if lumen reflections are on while baked lighting is enabled it should give the crash above. :\
@yujiang.wang Thank you for your work!
I have an edge case that you may not have tried; I have some levels where I use “force volumetric lightmaps only” which crashes your version of GPULM. The error said something about addressing an array of 0.
Another thing that is an issue with 5.x workflows is the use of packed level actors. The lightmaps are shared between all instances in a PLA. I don’t know if there’s any way to address this or if we just shouldn’t use PLAs.
Finally, I noticed the option to supersample reflection captures. Love that! Is there any way to update my reflection captures without (re)baking the scene?
I’m having some issues with the “First Bounce Ray Guiding” setting. In the realtime viewport it looks like this during the bake process.
Resulting bake looks like this:
Bake with setting disabled (correct view)
Interesting, this looks like the volumetric lightmap is being used to light everything instead of the surface lightmaps
this looks like what @TB_JWONG was seeing. As always, it will be very helpful if you can send me a small repro scene to test.
I’ve reproed the issue locally and GPULM-5.6.1.7z has been updated. Also a landscape issue is fixed in the release.
3 Likes
@yujiang.wang Thank you so much for keeping this going! The work you’ve done on it looks amazing, and is very useful to our studio 
We’re just upgrading from 5.4 to 5.6, and have added the 5.6.1 GPULM patch. I’ve noticed a few strange artefacts, that are behaviours/results I haven’t seen before.
Have you encountered this at all?
What we’re experiencing is:
- What looks like possibly compression or interference artefacts in the finished build.
- Phantom shadows, or sections of the bake that have different brightness’ to others, such as a bright rectangular strip on a wall.
- Extremely pitch black zones. These often seem to be quite near to some foliage-painted rocks, set to static.
We’re trying to isolate possible causes right now, which could include GPU memory (I’m testing on my backup laptop), something strange to do with distance fields (I would guess not, but a lot of the artefacts seem to have a 3D influence that approximates the object’s shape), or something a little deeper.
Here are a few features of the level that might have an impact:
- Our landscape has its lightmap resolution increased, and a couple of surplus tiles deleted.
- Part of the level sits underneath the landscape - reached by a tunnel through a masked hole in the landscape.
- The skylight and directional light are set to static.
- We have a number of static mesh actors with a strong emissive influence.
- We’re not using ray tracing proxies, but rather high-res meshes (that we discard during package). The same effects happened when ray tracing proxies were turned on.
- When I run the bake, it is possible to see the phantom shadows and lighting artefacts appear. The square lightmap artefacts appear after the encoding step.
- We’re pretty confident this isn’t a lightmap overlap issue, as we’ve baked with this level before.
- We haven’t upgraded the lightmaps yet, as we created them manually. Happy to take recommendations on this.
This is a new set of behaviours, that weren’t in 5.4 with stock GPULM. I’ll keep exploring to see what might have changed, but so far, it’s quite perplexing. I’ll also run some tests in other scenes, to see if this is level-based or environment/project based.
Has anyone else experienced anything like this recently?
Part of the level sits underneath the landscape - reached by a tunnel through a masked hole in the landscape.
GPULM does not support landscape masks now
edit: there seems to be a switch for landscape masks, lemme have a try
1 Like
Instant crash for me (when clicking bake) AMD RX 6800
Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0x0000000000000008
UnrealEditor_GPULightmass
UnrealEditor_GPULightmass
UnrealEditor_RenderCore
UnrealEditor_RenderCore
UnrealEditor_Core
UnrealEditor_Core
UnrealEditor_Core
UnrealEditor_RenderCore
UnrealEditor_RenderCore
UnrealEditor_Core
UnrealEditor_Core
kernel32
ntdll
I don’t have an amd card, yet according to Epic's GPUlightmass - #736 by MeanLemur , maybe you can try disabling lumen before bake?
I’m switching back to dx11, I have found a bug where lights turn off If i get close, the opposite should be true.
I’ve updated GPULM-5.6.1.7z, which contains an attempt to resolve your issue:
so the square artifacts are from a bad interaction between GPULM invalid sample detection and landscape. Basically when you’re underground you’ll see back faces of landscape which then produces samples marked as invalid. This fix detects if a masked material is used on landscape and let GPULM treat it as two sided so that invalid sample detection is effectively disabled. If in the future your landscape don’t have a hole but still want the same effect you’ll need to mark the landscape material as two sided.
1 Like
After upgrading 3060Ti-5070Ti baked objects became black
Baked on 3060Ti
Baked on 5070Ti
After research i found problem “Use First Bounce Ray Guiding“ works perfectly on 3060 but causes black objects on 5070Ti.
Can somebody confirm this bug on RTX 50 Series? (Latest Studio driver, UE 5.5.3)
a few posts before: Epic's GPUlightmass - #741 by yujiang.wang
Fix only for Luoshang GPU Lightmass?
I use Epic version of plugin.
Is it possible for Epic version?
@9Evgeny9 the fix is only for the EPic version - not the original ‘old’ GPUlightmass
2 Likes