HDR and Baked Lighting

The last years HDR has become a big buzzword in the gaming industry. I personally think it's still being used a bit immaturely. This image posted on the realtime rendering blog makes an excellent point and this industry still have some work to do on tone mapping in order to turn HDR rendering into more than a way of simulating people being blinded when moving between dark and bright areas or the other way around.
Users of baked lighting have to consider HDR data regardless of if they are planning to use it for tone mapping and bloom effects or not. In contrast to many other material texture and vertex types such as diffuse reflectivity, transparency or ambient occlusion, lighting has no upper limit (maybe if you ask Einstein, but I guess even Kratos can't take environments close to those intensities) and can't be properly represented by storing a value between 0 and 1.
This is how burned out lighting behaves differently with dynamic lighting and non HDR light maps

Dynamic Lighting. Note how the burned out lighting goes towards white even if it's yellow. With some proper tone mapping the color tint of the lighting may have been preserved better, but the result is still good.


Baked Lighting. Note how the burned out lighting goes towards the texture albedo. This result is not acceptable in most cases.

The background for this is the lack of HDR in most texture formats. This is how it works for dynamic lighting. The LDR framebuffer will act as clamp so your typical lighting computation will end up looking something like this:



Where:

is the resulting color in the framebuffer
is the diffuse color of the material
is the incoming lighting. Typically computed as the light intensity times a dot product of the surface normal and the light direction for each light source. This component is very often above 1.
is a function that makes sure all values below 0 is 0 and all values above 1 is 1. This happens implicitly when storing the intermediate HDR values in the shader into a LDR framebuffer

When working with light maps the clamping happens when storing the lighting in the LDR light map giving a computation looking like this:


Since the clamped lighting never gets above 1 the maximum value this computation can output is C_d, i.e the texture albedo.
So how do we encode the HDR data efficiently? Let's save that for another post in order to keep this one somewhat shorter than the gamma correction post. The answer is generally not to use floating point textures and framebuffers.

Nice CG Video

Got a link to this beautiful video of New York being destroyed by old fashioned video game monsters from a friend today.

San Francisco out of Texture Memory?

Found this shadow on a building in San Francisco the other day.
Seems like we finally ran out of texture memory. A better choice of filter would definitely have saved the situation...