Hdr Meets Black And White 2

HDR meets Black&White 2 Francesco Carucci Graphics Programmer/Lionhead Studios [email_address]

What’s HDR rendering? We all know…  … rendering the scene to a format which can represent color luminance greater than 1.0 (usually floating point) Display devices are limited to LDR (8/10 bit): the HDR image must be converted to LDR (tonemapped) before it can be displayed

Why HDR? An HDR image can represent bright and dark areas in the scene ‘equally’ well Different scenes with drastically different lighting conditions can be handled the same way without saturating Does your game need it? No: Go To End. Pub. Yes: Go To Next Slide.

Black&White 2 by night (1) Day/night in BW2 cycle makes it difficult to find the right lighting set up for all cases Night scenes in BW2 are suffering from severe low dynamic range HDR rendering and auto exposure as a solution to improve visual quality in night scenes

Black&White 2 by night (2) More than 95% of the pixels have luminance smaller than 0.5

Color luminance Quick and simple: luminance is a color property defined in the HSL space and intuitively represents color brightness To compute luminance from RGB: luminance = dot(color,LUMINANCE_VECTOR) A typical LUMINANCE_VECTOR: (0.2125 0.7154 0.0721)

Tonemapping (1) Here’s the simplest tonemapping operator: if (luminance > 1.0) color = white Simple but not very interesting, let’s try another one: new_luminance = luminance / max_luminance new_color = color * new_luminance / luminance

Tone mapping (2) For a better operator give a look at: “ Photographic Tone Reproduction for Digital Images ” … but it doesn’t matter how hard you try: Tone mapping is an artistic process, and it does require input from an artist .

HDR in Games Some games are now supporting HDR lighting or HDR rendering: Half Life 2 Lost Coast (HDRL) Far Cry and Splinter Cell (HDRR) Some XBOX 360 games

HDR “a la” Half Life 2 (1) Compute the light equation using high dynamic range values Tone map at the end of the lighting computation before writing the result to the framebuffer Render to a standard i8 (D3DFMT_A8R8G8B8) render target

HDR “a la” Half Life 2 (2) Pros: It doesn’t require HDR hardware support Compatible with MSAA on a broad range of hardware Relatively cheap

HDR “a la” Half Life 2 (3) Cons: Need to touch each and every single shader to include tone mapping Not easy to understand and control the overall dynamic range of the scene Can become expensive it there’s lots of overdraw (but a depth pass can save the day here!)

HDR: The “floating” way (1) Compute lighting at high dynamic range, write the result to a floating point (16, 32 bit per component) render target (D3DFMT_A16FG16FB16F) Compute average and maximum luminance from the HDR image Tone map the HDR image to a LDR render target

HDR: The “floating” way (2) Pros: Fixed and predictable cost per pixel High precision in representing the color (16bit per component) Easy to control exposure using average and maximum luminance directly computed from the scene

HDR: The “floating” way (3) Cons: It’s expensive! Lots of bandwidth required, lots of memory to store the fp16 render target It requires special hardware support available on latest hardware It doesn’t play well with MSAA (needs hardware support to resolve MSAA of a floating point render target)

Other ways to do HDR Use RGBE to represent HDR colors Blending must be done manually No MSAA Convert to HSL color space before writing to the frame buffer, allocate more bits for L for HDR expensive, hard to implement “right”

HDR: Fran’s way  But first, a word from the sponsor: <insert animation of a silly Black&White 2 creature here >

Average luminance and the GPU Computing the average luminance of a scene is a typical ‘gathering’ operation The GPU is not good at gathering data Where the CPU is very good at it

Average luminance on the CPU The HDR image data has to be transferred to the main memory SLOW! (not so slow on PCI-E) not a problem on next-gen consoles Why only average luminance? Compute the entire image histogram!

Image Histogram Find maximum and minimum absolute luminance (Lmax, Lmin) Divide the luminance range in a certain number of slots (e.g. 1024) For each slot, find the number of pixels with that particular luminance Divide each slot by the number of pixels to obtain its frequency

Histogram Equalisation (1) Once we got the image histogram we can equalise to cover the whole available dynamic range

Histogram Equalisation (2) From “Digital Image Processing”, page 91-93: map each slot with luminance level R in the input image, to a slot with level S where S is the sum of all frequencies less or equal than R The result a good approximation of an equalized histogram

Autoexposure (1) From the equalized histogram compute Lnew_min, Lnew_max, Lnew_avg: Lnew_min is the first slot where S is greater than Pmin Lnew_max is the first slot where S is greater than Pmax Lnew_avg is the first slot where S is greater than Pavg Typical Pmin, Pmax and Pavg are 0.01 (1%), 0.99 (50%), and 0.50 (50%)

Autoexposure (2) Minimum and maximum percentage can be chosen to ignore very small bright and dark areas and have a more uniform behaviour

Autoexposure (3) Auto exposure is implemented by tracking the actual minimum, maximum and average luminance to reach the values computed earlier: act_value += new_value * (1.0f - pow(1.0f - speed, 30.0f * elapsed_time));

Luminance mapping (1) Create a 1024x1 linear texture to store the luminance mapping: Luminance less than Lact_min is mapped to 0.0 Luminance greater than Lact_max is mapped to 1.0 (and then bloomed) The rest of the range could be mapped with a simple gamma ramp: float xp = 1.0f + (Lact_avg - Lact_min) / (Lact_max - Lact_min); gamma_ramp = powf(x, xp + bias);

Luminance mapping (2) The bias value is adjusted to increase or decrease contrast in the scene Higher contrast during the day Lower contrast at night

Luminance mapping (3) To reduce banding artefacts, the luminance map should be D3DFMT_R16F The pixel shader fragment in the tone mapper: float Li = dot(colorIn, LUMINANCE_VECTOR); float Ld = tex1D(LuminanceMapSampler, Li); colorOut.rgb = LuminanceScale * (colorIn.rgb / Li) * Ld;

Histogram based HDR Pros Trade bandwidth from GPU to CPU (usually spare but scarce) for GPU power More control over image characteristics Very flexible and simple pixel shader tone mapper Easy to plug into color correction techniques based on 3d textures

Histogram based HDR Cons Needs a lot of GPU to CPU bandwidth but free on console Needs a lot of memory to double buffer the HDR image but downloading a scaled version will help Needs CPU cycles to analyze the HDR image what about that idle core there?

HDR in Black&White 2 (1) Plugging HDR into Black&White 2 required only localized changes to the post processing framework NO shader needed to be touched NO change to the art asset But to take full advantage of HDR the artists should take part in the process!

HDR in Black&White 2 (2) A fp16 render target is used to render the main rendering to have good color precision in input for the tone mapper A scaled down (4x) version of the HDR image is downloaded to system memory and analyzed every frame (at 30fps)

Performance analysis A scaled down version of a 1024x768 fp16 render target requires approximately 11mb/s of bandwidth It takes about 10ms to download the image and about 1ms to analyze it on a AMD64 3500mhz It’s bandwidth bound

BW2 HDR Patch The HDR Patch of Black&White 2 will be released soon (April) It will support MSAA where available

References “ Photographic Tone Reproduction for Digital Images ” Game Programming Gems 4 “ Digital Image Processing” – Gonzales, Woods “ High Dynamic Range Rendering on the GeForce 6800” – Simon Green, Cem Cebenoyahn

Black&White 2 Engine Team Thanks to the Black&White 2 engine team who have made an amazingly looking game: Ben, Dave and Mark

Hdr Meets Black And White 2

More Related Content

What's hot (20)

Viewers also liked (18)

Similar to Hdr Meets Black And White 2 (20)

Recently uploaded (20)

Hdr Meets Black And White 2