Appart of the limitation of the GI contribution of rect lights, GPULL works absolutely fine.
Just reading your first 2 points and both are wrong, as GPULL works perfect with point lights, it’s also available for the latest Unreal version too… where do you take the info from?
In addition, GPULL is much more faster than GPULE and it works way better, as GPULE is quite broken, as many users are frequently reporting in its dedicated forum’s thread.
I could continue, but I think this is more than enough. Is Epic paying you, maybe?
HI @ATNeo I had the same issue with Rectangle lights, very strange and sharp shadows, also no matter what setting changed in actor details, no effect. As the last option, I changed Lighting quality from Preview to High, in Editor, under Build tab. That fixed the problem. As I understand, Rect lights are not supported by GPU Lightmass, so it uses parallel CPU computation, so changing light and lightmass settings in the Editor will affect the scene.
Do you know if the Skylight is something like clamped to a max value Intensity of 10, 100, or 1000 (not sure)? I’m switching to use extended luminance EV100 exposure, so highest values are used in all light sources, but Sky Light doesn’t seem to not increase anything more after that Intensity value.
So its reasonable to say its been set to
SkyLightIntensity=0.880000 initially
in BaseLightmass.ini
bUseFilteredCubemapForSkylight=true
[DevOptions.ImportanceTracing]
AdaptiveSkyVarianceThreshold=.5
bUseRadiositySolverForSkylightMultibounce=True
[DevOptions.IrradianceCache]
; Sky occlusion has less noise than normal GI, dont blur away details
SkyOcclusionSmoothnessReduction=.5
[DevOptions.StaticLightingMediumQuality]
AdaptiveSkyVarianceThresholdScale=1
[DevOptions.StaticLightingHighQuality]
AdaptiveSkyVarianceThresholdScale=.5
[DevOptions.StaticLightingProductionQuality]
AdaptiveSkyVarianceThresholdScale=.5
So you can see there is a lot to play with, but LGPU probably is a combination of the values. When looking at the code this seems to be set to use only Production Quality.
a float of 0.50 is hardcoded throughout the CUDA code.
There is no way to adjust the as its fixed value into LGPU
CPU Lightmass says
Note that the physical lighting units are measured in cd/m2, like the Sky Light or Emissive Materials. Sun and Sky sources have that range in the thousands of units, which it does hand-in-hand with physical cameras where the Exposure Value (EV) are in the range of EV100:14 (see the "Sunny 16" rule). However, with the HDRI Backdrop asset, it is not required to use physically correct values, but you may need to set the EV to something significantly lower than the EV100:14. It's also worth noting that some HDR images range from 0 to 5.0 or greater than 5 cd/m2 while others are ranging from 0 to 100K units. This means that when you swap HDR images, there may be a noticeable difference in brightness changing.
Epic GPU Lightmass (EGPU) 5.3 documentation says
Stationary Sky Light is Not Supported Support is planned in a future release of the engine.
Thank you very much for your info @Jimbohalo10 ! There are some things to play with, so I will keep researching about this! (Even if I think It won’t be changed, but maybe, at least, will try to boost the ‘internal’ HDR brightness).
A question has been asked about Rectangular Lights (Rect Lights). They are they are processed by CPU Lightmass not processed by LGPU Lightmass.
The normal default for LGPU is Lighting Production set in BaseLightmass.ini at the bottom section.
Now people are leaving the Lighting setting as Preview. This means that Rect Lights look distorted and low-quality. Some users see it as a fault in LGPU.
You will need to set Lighting Production which will use more CPU and take more overall time to bake.
The way to solve this is the make Rect Light into Emissive light as has been described previously in past posts.
I hope this clears up the mystery with Rect Lights’ quality
Hi.
At the beginning of baking, the GPU works, then switches to the processor and counts something on it for 40 minutes… And only after that, everything is counted on the GPU very quickly… There is sun and sky in the scene, there are no other sources, and in the project there are only walls and that’s it. We bypassed this moment of switching to the CPU somehow, but I don’t remember how. Something LGPU does not support in my opinion, and therefore it takes a long time to count on the processor …
Who can help me with this?
The picture shows just the moment when it is being counted on the processor
(FireflyClampingThreshold has been loosened to allow more contrast from skylight and correct brightness for emissives
- if you start to see fireflies from sky or emissive you may want to set it to lower values like 10.0 (in BaseLightmass.ini))
This installation overwrites your BaseLightmass.ini so you want to back it up if you have modified its parameters.
If you want to keep your BaseLightmass.ini,
set bUsePhotonMapping and bUseRadiositySolverForSkylightMultibounce to false to avoid CPU computation.
Originally there was no support for static Skylight in UE4, however this seems to have been implemented at sometime.
The usual problem is Rect Lights are not implemented and therefore CPU based.
There are no intentions to implement these functions because they must be compatible with Unreal 4.
To really know what is going on you need to look at the Swarm Log to see what has happened, may be copy the text to notepad and upload the *.txt file
This is a particularly difficult question, which the remaining LGPU participants may not easily answer
Thank you for the info @Jimbohalo10 ! Let see if version .0 final is releaded before than a month.
Just for asking, when you update it to a new version, like 5.4.0, how difficult is to update if after to 5.4.1, for example? (As many times it even still works without needing to update too, right?)
hi @Miguel1900 ,
The update is just as hard as the making of 5.3. Probably I should have put my code makers in first thing, but only started late in conversion.
Hand patching is still the best way its just so hard you can only do a few patches a day. The old July 2023 patches are so out date!
Anyway 5.4 is good because new private branch creation is automatically when you add your first patch.
Superb saved so many days work. Deleted my original fork/branch downloaded the newly renamed branch and built it overnight.
UAT has gone replaced by UBR and for the first time you can used the much requested Multi-threaded automatically build which integrates with Visual Studio 2022 17.10.
Here is the quote from the new style 5.3 d Developer Iteration
Multi-Process Cook (Beta)
Multi-Process Cook helps reduce the total time it takes to get a cooked output from a build farm server or on your local workstation by leveraging available CPU cores and memory resources.
Multi-process cook is a beta feature for UE 5.3. Performance gains may vary, depending on the size of the project and how the data is separated. For best results, we recommend you test different CookProcessCount values depending on the project and available hardware specs documentation
UE5 is still the biggest application built on VS2022, at least 10 copies are being built every day and performance of VS2022 is mostly based on UE5 builds.
In 5.4 Visual Studio 2019 is obsolete you will get an error VS2019 has left the room!!.
Now and 5.4 preview is built on VS2022.