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 can 100% confirm I am still having the exact same issues with 528.49.
1 Like
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.
7 Likes
Thanks for the heads up. I just tested and can confirm this driver works nicely with GPUlm.
3 Likes
Thanks! Even my nightmarishly complex interior scenes work perfect on the new driver 
Unexpected turn of events 
1 Like
Nvidia already released a hotfix, AFAIK
1 Like
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 
Hmm, I see no news about GPULM in UE 5.2 public roadmap
1 Like
Hi @Luoshuang @YujiangW ,
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!
Thank you and sorry for being critical.
Regards
2 Likes
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.
1 Like
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.
@Warner_V Maybe you have not tried the ‘old’ Luoshuang’s GPU lightmass; do you?
Because I’m talking about a difference and a gap between both GPU ligthmasses, but you don’t mention it in your comment.
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.
1 Like
(post deleted by author)
@Miguel1900 You are 100% correct - it seems my brain was fried there for a moment and I didn’t understand the comparison you were making.
1 Like
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.
Did some more testing. Honestly In some cases I think that 5.2 has gotten further from the pathtracing reference than V5.1
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.
EDIT: Problem seems to be with 5.2 specifically.
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.
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:
5.2 appears to deal with occluded areas in a completely different way (or at least a way that produces very different results)
Not sure why this would be though… Same settings were used for both lighting builds (no aggressive leak prevention)
This actually looks like what I expect to happen when radiance caching is disabled…
3 Likes