Thanks to @jon_eg , it turns out 1 material was causing the problem in this scene. The clothes material has a subsurface node that - in my scene - had a multiplier of 1.5. Reducing this value to 1.0 fixes most of the problems but still some white splotches are visible on some edges of walls. Removing the subsurface settings for this material altogether results in this image.
Tested on the current 5.0.0.p2. Strange thing is; in the output log it still reports ‘static lighting system is removed from world lightroom_day’
Going to convert some of my own projects asap and test again. Really hoping it works as well…
I don’t get any crash in 4.27.2 (at least Editor keeps working) when I switch from SM5 to Android Vulkan preview and back. The only thing that happens is that Editor simply won’t switch. So say I am in SM5 and I select Android Vulkan in the menu. Menu would close, nothing would happen on the screen and when I would go back to the menu - it would still be showing SM5 option selected.
I don’t recall what happens in UE5p2, I can check when I get off work. If there was a crash, I am fairly certain I pressed button from the crash log window.
I see the same splotch in the scene you sent, but it appears to be the reflection captures. It goes away if I rebuild the captures from the Build menu.
I was able to reproduce this in the demo scene that you sent. While it’s true that the denoiser is the source of the colored artifacts, the absolute values of those dark levels in the texture is extremely small and the artifacts wouldn’t be visible at a normal exposure. You have a large manual exposure set on the scene, EV100 of -6.19. It’s like taking a jpeg of a dark scene into photoshop and setting the brightness way up. If you run without the denoiser and with the exposure cranked up you can see that there is very little information available from the bake. I think your best choice of action is to address how you are lighting and exposing the scene so that you aren’t relying on extremely low levels of light in such large areas. I will also submit this to the devs to see if there is anything that can be improved in the future, but that’s your best choice of action for immediate results.
(If this is a regression from 4.27 please let me know but I don’t think anything changed with the denoiser.)
If you set the GI samples to 4k and watch the light build you get a nice high quality, clean result right up until the denoiser kicks in and destroys it.
I know this is on the very edge of reasonable light intensity, but this is really no excuse for the denoiser to be actively destroying light bakes.
I appreciate the advice, but I’m just reporting issues I encounter so that it can be improved. I plan to continue using CPU lightmass until GPU lightmass can match/exceed its quality/featureset.
There is an issue that I’ve submitted a ticket but got ignored, that is a deal breaker for GPULM.
If you have a stationary directional light (and static skylight), then the volumetric fog will be unshadowed everywhere, so you will see fog even in dark places.
With CPU Lightmass of course it works correctly
With GPU Lightmass and static directional light the fog works correctly, the problem is only with stationary light.
This happens both in UE4 4.27, and UE5 p2/github build.
hi @motorsep, @nSpeednSpeed. Raised a bug with support and the reply is that this is an Nvidia problem.
For me, this only occurs in one specific Marketplace project which of course has been converted from 4.27 and uses GPU instead of CPU. I also expect that many developers are using many drivers from 472.15 to 511.15 just released. The other problem is nobody has the same hardware ie GTX 10xx or RTX2xxx or RTX3xxx series and GPU problems and is very dependent on the Dedicated GPU Memory Size 2GB, 4GB, 8GB.
It does not matter whether its D3 D12 or D3 D11
Here is the rather good response to the GPU I reported
There is no exact workaround for this issue. Some people see the problem; others do not. A workaround may work for one person but not another. It is very dependent on the hardware and drivers, which differ from person to person. There are a lot of forum entries out there where people talk about how they get around the issue. I suggest checking those out for things to try.
Agreed this is buggy behavior and hopefully it can be fixed. GPU Lightmass uses Intel’s Open Image Denoise library (as does the path tracer), but perhaps it is possible to prevent it from doing that by adjusting its options or how the data is fed to it, or perhaps a fix can come from the library itself.
We haven’t seen this come up before, so thanks for the test case.
This crash is in DX12. Are you saying that when you launch Anroid Vulkan Preview the editor itself crashes, not the standalone game instance it launches?
That is correct. When I switch viewport from SM5 to Android Vulkan, UE5p2 Editor crashes.
RHI is DX12, Raytracing is on, Forward rendering is on. UE 4.27.2 didn’t crash Editor, but also wouldn’t even switch to Android Vulkan at all, with such setup.
@jon_eg There’s still something not right with GPUlightmass in UE5 (main). See the realistic rendering project from the marketplace. Enabled GPUlightmass, rhi12, raytracing, virtual texture lightmaps and converted all lights to static.
I’m seeing more artifacts in my own projects as well.
Update: GPU lightmass results seem ok using the new UE 5.0 from the launcher. Just like in 4.27. The github version I was testing was 5.1 so work/temporary breaks in progress I guess (duh). Will test more…
I knew! (But didn’t remember this was your actual username, sorry, hehe).
It’s a pitty. I hope to arrive soon the day when we can move from your incredible personal lightmass, to your (and Epic’s) official one, which will should be, I suppose, even better
, but many technicial and non-technical issues have drawn the development of the official one behind