I can confirm that on my end Nvidia Driver version 528.49 (I tested the Game Ready version) appears to work perfectly fine on my 5.1.1 project. GPU Lightmass Bake results are accurate and clean.
Thanks for your update, I have now upgraded to 528.49 and will report any issues here should I come across any.
PS: Luoshuang would know best, as you can see his post below states 528.49 still has issues so as of this moment 522.25 is still the recommended driver for now, although a fix is in the works on Nvidia’s end. I will keep my posts updated regarding this topic.
We’ve contacted NVIDIA and they have made a fix which will make into a driver going to be released later. I tested 528.49 and unfortunately it still causes bugs with certain combination of feature (IC/FBRG) and still requires the UNROLL_N workaround to work on some computers. We have tested the fix from NVIDIA internally and it fixes all problems without the workaround and works in all feature combinations.
I’ve tested 531.18 which was released today and it passed my tests locally without the UNROLL_N workaround. It is like to be the version which contains the fix for GPULM.
I am still wondering when precomputed visibility building functionality comes to GPULM. With the removal of software occlusion culling from UE5+, precomputed visibility is the only viable option left for mobile/VR and waiting for a whole day+ to build that with CPULM for a complex level is a no-go
Without wanting to offend no one, I have been re-testing the GPULM after some time, but I still think the some-years-old GPU lightmass is still much more better. How is it possible? Don’t you have a team and more resources now, to develop it?
I have tried in a simple but real-case scene, and in parity of rendering time (4 minutes), the quality difference is huge.
Also tried to equilibrate the quality gap, but the difference in time is huge too. Current GPULM is slower but also with worse quality, so, to achieve the same quality (I don’t even sure if it can), it would be much much slower than the old GPULM:
Even tried the Main UE5 branch, to get the last version and improvements, but it’s more or less the same (but even slower):
And you need to have Ray Tracing enabled, a capable RTX card, the UE editor (and computer) completely freezes (or GPULM will be too slow, if you enable real-time viewport)… does it have any advantages 2 years later?
I think if Epic would have decided to continue the development of your old GPULM. I can’t immagine where you were arrived nowadays… to the moon!
I tested 5.2 p0 and was getting consistent ue5-gpu-crashed-or-d3d-device-removed crashes for a few converted projects (copy of course) that work fine in 5.1.1 when running GPUlightmass.
Some objects used materials or were meshes from the TwinmotionContent plugin. When opening the project in 5.2 it warned that the TwinmotionPlugin was 5.1 but it loaded anyway and worked fine with Lumen.
Turns out it caused the plugin crashes with GPUlightmass. No crashes anymore when the TwinmotionContent plugin is disabled. So, we’ll have to wait until a 5.2 version of that plugin is released (or until someone has an idea / tip what in that plugin could be causing this).
Edit: the strange thing is, in the output log the last object the GPU lightmass plugin was working on could be any object in the scene - not anything that was using anything from the Twinmotion plugin.
It’s not without problems, but I’m seeing very different results from what you’re describing. On big maps with a lot of detail, CPU lightmass was taking me over 16h on a 32core processor. The same thing with comparable quality takes under an hour on my current GPU (RTX3090).
Also: I find the look often more natural and less sensitive to leaving visible edges on meshes where the lightmap is cut.
So I’m quite happy with GPULM and it’s getting better with each iteration.
Btw, I have not seen any updates to GPULM in release notes for 5.2.x and I don’t see any commits to github repo. I wonder if they think GPULM is 100% done and if it’s entered maintenance mode.
Anyone else having washed out results using GPUlm in 5.2.0 when using a (large) converted 5.1.1 project? Some settings have changed maybe? Will test with more simple projects now.
It almost looks like A/O, but it’s not. The edges are being over-occluded for some reason.
I used the same GPULM settings in 5.1 as I did in 5.2.
I think the first texel is partially inside the mesh. Instead of being partially lit inside, it seems like the current version of GPULM has the shadow extend outside. Perhaps this was to reduce leakage.
However, I do have the Agressive Leak Prevention setting turned OFF.
I need to do more testing, but so far when I reverted back to a previous backup of my project and built lighting in 5.1.1 the result was good. I need to do a bit more testing. I’m going to upgrade my backed up project to 5.2 and rebuild there to confirm that there is nothing inherent in my scene causing the issue.
