LightmapGI: Pack L1 SH coefficients for directional lightmaps

[BlueCube3310]

Depends on #96113

Packs the L1 coefficients of SH lightmaps into a 0.0-1.0 range, which will allow compressing directional lightmaps as BC6U. This is an approach based on https://media.contentapi.ea.com/content/dam/eacom/frostbite/files/gdc2018-precomputedgiobalilluminationinfrostbite.pdf.

The packing is currently performed as an extra step after the image has already been denoised as a way to avoid precision errors.

TODO:

• Add a testing project,
• Compare the visual results between unpacked and packed,
• Add a versioning system to LightmapGIData so as to not load old lightmaps and ask the user to rebake.

Future work:

• Fix overdarkening caused by the colors becoming negative (https://web.archive.org/web/20160313132301/http://www.geomerics.com/wp-content/uploads/2015/08/CEDEC_Geomerics_ReconstructingDiffuseLighting1.pdf),
• Consider saving L1 as LDR images. This will increase their precision, but the size will remain the same as they will require BC7 compression due to etcpak's BC1 being too low-quality,

Comparison:

bake mode	4.4-dev1	PR
Static
Dynamic

Testing project:
sh-lightmaps.zip

[BlueCube3310]

I've added a basic versioning system with the use of a new internal property whose purpose is to notify the LightmapGI node if the directional lightmaps are packed or not. I'm not sure if this is a good solution though.

[clayjohn]

Since the packing is implemented as a separate pass, could we not just run that pass when we encounter an old lightmap and upgrade it automatically for the user?

[BlueCube3310]

I thought about it, but older lightmaps wouldn't work the same way since they use different coefficients

[clayjohn]

Oh right, I guess #95888 technically breaks compatibility already for existing lightmaps so this PR fixes the compatibility breakage from that.

[clayjohn]

• Fix overdarkening caused by the colors becoming negative (https://web.archive.org/web/20160313132301/http://www.geomerics.com/wp-content/uploads/2015/08/CEDEC_Geomerics_ReconstructingDiffuseLighting1.pdf),

Here is an MIT licenced implementation of the Geomerics technique. Its a but more expensive to unpack, but it looks really good.

https://github.com/kayru/Probulator/blob/4a97a2b021eb2ca7ef696f4ddf36ba9a9432cbb6/Source/Probulator/SphericalHarmonics.h#L136-L151

• Consider saving L1 as LDR images. This will increase their precision, but the size will remain the same as they will require BC7 compression due to etcpak's BC1 being too low-quality,

We can probably switch to BC1 once we merge #95915

[Calinou]

Tested locally (rebased on top of master b6223c0), it works as expected in all rendering methods. This allows using VRAM compressed directional lightmaps with any rendering method, whereas you'd get error spam previously (and a black screen).

Testing project: test_lightmap_directional_compress.zip

Preview

VRAM Uncompressed

VRAM Compressed (this PR)

PS: I noticed directional lightmaps generally represent light direction in a more faint manner compared to real-time lights, even when there is only a single clear light direction at a given texel, no indirect light involved and when lightmap bounces are set to 0. Is there a way we could get the directional lightmapping appearance to make normal mapped surfaces closer to how they'd look like with real-time lighting? This isn't an issue specific to this PR, but I thought it'd be worth pointing out.

[clayjohn]

PS: I noticed directional lightmaps generally represent light direction in a more faint manner compared to real-time lights, even when there is only a single clear light direction at a given texel, no indirect light involved and when lightmap bounces are set to 0. Is there a way we could get the directional lightmapping appearance to make normal mapped surfaces closer to how they'd look like with real-time lighting? This isn't an issue specific to this PR, but I thought it'd be worth pointing out.

I have been thinking about this a lot. I think it has to do with our discussion above about the coefficients. Right now I think something is off with the spherical harmonic baking process that results in the average light being roughly correct, but the directional light being too weak.

[akien-mga]

Thanks!