// we remap some of the defaults
static const FName FormatRemap[] =
{
// original ASTC
FName(TEXT("AutoDXT")), FName(TEXT("ASTC_RGBAuto")),
FName(TEXT("DXT1")), FName(TEXT("ASTC_RGB")),
FName(TEXT("DXT5")), FName(TEXT("ASTC_RGBA")),
So I believe this will result in some divergence between the mobile preview you see in the editor and packaged games. Try to package and see if things improve.
After my conducting comparative tests yesterday, it seems that the influence of image compression is more significant. Additionally, there is a residual issue where GPULightmass does not affect whether “Compress Lightmaps” is enabled in the world settings. Both CPULightmass and LMCPULightmass function properly.
Additionally, do we have a better Lightmaps compression algorithm? The current quality is indeed very poor.
The LQ Lightmap generated after baking uses BC1, but the cooked assets are in ASTC format.Due to issues with the compression of the original LQ assets, the cooked ASTC assets also have problems.
I tested it, and the effect on the mobile device is the same as in the PC Mobile Previewer. I suspect that due to issues with the compression of the original LQ assets, the cooked ASTC assets also have problems.
Right now we don’t - though if your primary concern is about on disk size then Oodle handles that, yet in GPU memory size and texture fetch performance are indeed affected. As I’ve said before, maybe you can try hacking HQ lightmaps on and see if you have any luck
This effectively means HQ lightmaps have an extra 8-bit input into the texture compressor (16 bits) in total, and since this residual is stored on a second texture (the spherical harmonics texture’s A channel), it ultimately has more bits available after texture compression. I think this is the answer to why LQ encoding looks bad with texture compression, but I don’t have any good advice. Trying to represent HDR data (lightmaps are essentially HDR) in 8 bits (before compression) and ~3 bits (after compression) is just way too hard. If you want to take a look at the best GPU supported compressed format, see BC6H Format - Win32 apps | Microsoft Learn
Yes, it will be quite noticeable on light-colored textures. Another factor that affects this is the lightmap denisity. If it’s very hight. the impact will be reduced. And I haven’t found an option to set it to BC7 format.
In my test case, when I enabled compression, the lightmap was 9MB, but after disabling compression, it increased to 90MB. This difference is too large. It also seems that the lightmap doesn’t use Oodle when compression is off. I need to check why there’s such a significant difference.
I must say that I DO think Oodle compression does affect the size of lightmaps that are baked with compression disabled, at least it seemed that way based on our project.
That being said, I absolutely agree. I think it would be great if there was at least a lossless (or near lossless) compression option for lightmaps that saved disk space but kept the full quality.
It’s not #1 on my list though right now, there are plenty of improvements to be made with the actual baking quality itself.
I modified the source code to set the default compression format of the generated light maps to BC7, but there isn’t much difference compared to before.
I thoroughly reviewed the UE code and identified a crucial aspect. When Lightmap compression is enabled, UE applies compression at the final stage of Lightmap Encoding using Oodle, specifically through the FTextureFormatOodle class. When compression is disabled, it uses the FTextureFormatUncompressed class. I also referred to the documentation at Oodle Compression, which indicates that the compression quality shouldn’t be this poor. There might be an issue with the Oodle compression of the Lightmap, but I haven’t pinpointed it yet. The compression method in question is FTextureFormatOodle’s CompressImageEx method. The issue is likely in this part of the code.
I actually was messing a lot with this last night and I did get artifacts with rect lights too. However, once I got more or less proper normal map setup (I am combining baked normal map with tiling detail normal maps), artifacts went away. Could be that they became a lot less noticeable.
Btw, are reflection captures even supported by GPULM (I am still on 5.3.2) ? I have a reflective “metal” sphere and spherical reflection capture. I not sure why, but only some things get captured on it. Or rather, it looks like reflection is from the time I built lighting with CPULM and no geo I added since then got captured.
P.S. Never mind - I moved reflection capture actor a bit and rebuilt reflection captures. Now everything reflects. I don’t think anyone should ever nudge reflection capture actor to update reflections. Sounds like a bug to me.
Build > “Build Reflection Captures” doesn’t work for you?
The only thing I noticed is that I think Nanite doesn’t work perfectly with reflection captures, nor does the virtual texturing. Some of your meshes may not load fully or have blurry textures in your reflection captures.