HDR lightmap compression

Started by
8 comments, last by Krypt0n 8 years, 9 months ago
hello! I'm using LogLUV to encode HDR light map. I think I can use two DXT5 texture to compress the xy and zw components separately with 1 to 2 compression ratio. Is this the way to go? Thank you!
Advertisement
Why not BC6?


L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

If you want to support older hardware (or you need to) maybe this presentation about lightmap compression & optimization techniques from Bungie can be helpful:
http://halo.bungie.net/images/Inside/publications/presentations/Lightmap_Compression_2008_02_22.pptx

They actually use two DXT5 textures to store SH coefficients (see slides 14 onwards).

store luminance as BC4 and chrominance in quarter resolution as BC5. that gave me best results. BC6h is somehow challenging for current compressors to get good quality and is slow to compress and as lightmaps tend to have smooth gradients and are rather stretched, you see those tiny block artifacts a lot. BC5+BC4 are simple to encode (fast) and there are barely any banding or anything, on top you'll end up with just 6bit/texel.

the only down side is that you need to fetch from two textures, but that's really fast for lightmaps.

LogLUV will have artifacts because of hardware filtering. Storing luminance in BC4 and chrominance in BC5 won't work with HDR lightmaps. If you target new GPUs, then just use BC6H. It's a really great format for HDR data and depending on quality requirements you can even compress in real-time.

BC6h is somehow challenging for current compressors to get good quality and is slow to compress and as lightmaps tend to have smooth gradients and are rather stretched, you see those tiny block artifacts a lot.

Try my tool.

L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

I'm stuck with DX9 api. LogLUV did have artifact when bilinear filter is on.

Is LogLUV only good at being a slim HDR color buffer?

Can I implement a HDR deferred shading pipeline, while using LDR light map at the same time?

BC5 is called 3Dc on dx9. you could use also 3Dc to replace tye BC4. it will end up with 10bit/texel, but still the same nice quality.

I'm stuck with DX9 api. LogLUV did have artifact when bilinear filter is on.

Is LogLUV only good at being a slim HDR color buffer?

Can I implement a HDR deferred shading pipeline, while using LDR light map at the same time?

LogLUV is also fine for lightmaps if filtering artifacts are acceptable. You could also filter manually in the shader, but without DX11 GatherX instructions this won't be too optimal. Another possibility is to use other encoding schemes like RGBE, RGBM, RGBK etc. All of them have different kind of artifacts, but maybe something will work better for your's content.

I wouldn't recommend doing a HDR rendering with LDR lightmaps. At least rescale lightmap LDR values to a ~[0;4] range, so there will be some additional range at the cost of worse precision.

At least rescale lightmap LDR values to a ~[0;4] range, so there will be some additional range at the cost of worse precision.

usually the scaling factor per lightmap(tile) is be based on min/max of the actual HDR lightmap(tile), just an arbitrary range will cause clamping in some cases and artificially banding in other. e.g. outdoor vs indoor can be 100x to 1000x difference in brightness.

This topic is closed to new replies.

Advertisement