LightmapGI: Save directional lightmaps as ldr textures

[BlueCube3310]

Depends on #100640
Inspired by https://media.contentapi.ea.com/content/dam/eacom/frostbite/files/gdc2018-precomputedgiobalilluminationinfrostbite.pdf

Changes the way directional lightmap textures are stored: Previously they were part of the HDR lightmap texture array, despite being LDR textures. Now, they are saved as a separate .png file and compressed to DXT1/ETC2 RGB on import.

This approach improves their appearance when compressed, as well as reduces the memory footprint by half (when compressed as DXT1/ETC2 RGB). I've tested this with several scenes (many with a solid albedo, to see how the quality will be affected) and the low-quality versions don't look much worse than high-quality (BC7/ASTC 4x4) ones (even with etcpak).

In the future this will allow scaling them independently from regular lightmaps, making it possible to bake lower-resolution directional maps and save even more video memory.

TODO:

• Test with more scenes,
• Apply the other fixes to directional baking (see LightmapGI: Pack L1 SH coefficients for directional lightmaps #96114 (comment)),
• Implement an automatic conversion system for older lightmaps

[solitaryurt]

After baking the lightmaps with this branch, am I supposed to see a separate .png for the directional data? I am only seeing the .exr file right now.

[BlueCube3310]

After baking the lightmaps with this branch, am I supposed to see a separate .png for the directional data? I am only seeing the .exr file right now.

Yes, the directional lightmap has a "_directional.png" suffix

[Calinou]

Tested locally, it works as expected in all rendering methods (both baking and rendering). Visuals are identical to before, and code looks good to me.

Testing project: test_lightmap_directional_ldr.zip

Note that right now, you need to bake lightmaps again for them to render correctly. This shouldn't be required anymore once a conversion tool is implemented.

This provides a significant size reduction for lightmap data that is committed to version control:

• Before: 93.4 MB EXR
• After: 23.5 MB EXR + 16.6 MB PNG = 40.1 MB (2.33x smaller)

Note that like shadowmask images, we could benefit from saving to a lossless WebP instead of PNG to reduce file sizes of what you commit to version control: #101881
However, this may be challenging to do unless directional data is stored at a halved texel density, since it will frequently go over WebP's 16383×16383 limit. For example, in the MRP, the directional data texture is 8192×24576.

Bake times are very similar before and after this PR (note that bake times include the time taken to reimport textures with VRAM compression).

Also, this paves the way for making #50574 usable with directional lightmaps, since directional data is no longer part of the main lightmap image.

PS: With this PR, we now have two lightmap textures that can go unused depending on which properties you end up disabling. For example, if you bake with shadowmasks and directional enabled, then disable both and bake again, both the shadowmask and directional textures will go unused but remain within the project files. We should look into printing a warning after baking when unused textures have been detected based on naming patterns. This would complement the existing Project > Tools > Orphan Resource Explorer dialog.