Does setting r.SkyAtmosphere.AerialPerspectiveLUT.FastApplyOnOpaque 0 and r.SkyAtmosphere.FastSkyLUT 0 actually disables FastSkyLUT for anyone on latest 5.5 release version? FastSkyLUT remains enabled for me after that..
It is an optimization, always disabled by default.
I apologize - I may not have expressed myself clearly enough.
According to the documentation (Sky Atmosphere Component in Unreal Engine | Unreal Engine 5.5 Documentation | Epic Developer Community), executing the CVARs mentioned in my previous message should disable FastSkyLUT, and its parameters should consequently stop affecting the SkyAtmosphere rendering. For configuring SkyAtmosphere with disabled FastSkyLUT, one could use, for example, r.SkyAtmosphere.SampleCountMin and Max .
However, I observe the opposite behavior. Executing the commands I provided no longer disables FastSkyLUT, and its parameters (such as r.SkyAtmosphere.FastSkyLUT.SampleCountMin ) continue to affect the render, which contradicts the documentation:
To use the fast sky LUT commands, r.SkyAtmosphere.FastSkyLUT must not be disabled.
I would like to note that disabling FastSkyLUT worked this way in previous engine versions. This behavior is unlikely to be explained by default optimization.
Therefore, I’d like to verify whether anyone else observes this bug, or if this might be specific to my setup.
EDIT: I found the cause. This was careless on my part, but there was a SkySphere present in my scene… I hid it and everything started working as needed. It turned out quite silly, considering I spent many hours banging my head over this. 
1 Like
Just out of curiosity, what is this useful for?
Sunshafts quality is superior when using per-pixel ray marching. I’m experiencing severe banding artifacts in the atmosphere with FastSkyLUT, which proves challenging to mitigate without substantial performance costs (have to set r.SkyAtmSphere.FastSkyLUT.SampleCountMin to 256 to get acceptable result). While these artifacts are nearly imperceptible against blue sky, they become distinctly visible during sunset conditions. Per-pixel ray marching employs a different approach, rendering such artifacts nonexistent.
Banding issue example on epic quality settings:
2 Likes
@SebHillaire I really wish there was a way to re-enable Lumen in DX11 just by editing the RenderUtils.cpp file from the Launcher version of 5.5.4. Sadly, not everyone has the resources to build the ENTIRE Engine from source just for two simple lines of code to restore a feature that was removed without any warning. 
The primary reasons users still want Software Ray Traced Lumen in DX11 is for the incredible performance gains in projects targeting older hardware, and for its excellent look-dev qualities when comparing between baked and real-time lighting options. I sincerely hope Epic will consider releasing a hotfix for this, as 5.5 fixes a lot of other headaches and control rig crashes present in 5.4 (the last version supporting DX11 Lumen).
Thanks so much for your consideration.
10 Likes
word! keep the prayers coming.
1 Like
With 5.5.4, Niagara Data Channel system crash (instantly when writing to niagara data channel) with shipped world partition build, but not with cooked staged build. Is there some settings to make it compatible with world partition or does packaging break it?
Did you ever find a solution for the HLOD build times?
I tried 5.6 and it has the same issue. But looking at HLOD build logs it’s because our compile shader compilation is crashing and it gets put back on a much slower legacy version.
My i9 13th Gen is affected by this 20+ mins to finish
My i9 10th Gen is not affected 40 seconds to finish and correctly compiled so it seems to be related to hardware and not software for only newer hardware. If you make a sample project and build the standard open world starter map it breaks reguardless. Only on a much older CPU is it fine
The only way is to wait 1 minute and manually build on the actors that have been created. But consumes more RAM this way.
I am using the HighResShot command in a C++ code plugin to take high-resolution screenshots, but the final output image is completely black. How did you resolve this issue?
Broken since 5.5
Well, you can understand everything from this piece of code.
#include "Engine/GameViewportClient.h"
#include "HighResScreenshot.h"
----------------
FString ProjectSavedDir = FPaths::ProjectSavedDir();
FString PlacholderPath = ProjectSavedDir + "Screenshots/Screenshot.png";
FHighResScreenshotConfig& HighResScreenshotConfig = GetHighResScreenshotConfig();
HighResScreenshotConfig.SetResolution(SizeX, SizeY, SizeMultiplier);
HighResScreenshotConfig.SetFilename(PlacholderPath);
HighResScreenshotConfig.SetForce128BitRendering(bForceRendering);
HighResScreenshotConfig.SetMaskEnabled(bCustomDepthMask);
HighResScreenshotConfig.SetHDRCapture(bCaptureHDR);
ThisGameViewport->Viewport->TakeHighResScreenShot();
----------------
# May be useful
# GScreenshotResolutionX = SizeX;
# GScreenshotResolutionY = SizeY;
# GIsHighResScreenshot = false;