Some new interesting information about valve's HDR implementation

tEd

Casual Member
Veteran
http://www.bit-tech.net/gaming/2005/09/14/lost_coast_screens/1.html


The coding team at Valve certainly sweated blood on getting HDR right for Source: in development since 2003, they went through no fewer than four different approaches to the HDR puzzle. Each method had pros & cons, so while one provided the overbright detail needed for blooming, its performance was "so-so" and it broke Multi-Sample Anti-Aliasing (MSAA). As cool as HDR is, Newell was adament that users would not have to sacrifice the ability to run AA in order to gain access to HDR.

By the fourth interation, the lads had cracked it: MSAA worked; it worked on all DX9 hardware, with reasonable performance on even a Radeon 9600; indeed the performance was the best of the four methods, with only a small performance hit over Half-Life 2's LDR solution.

To clarify, then: the HDR works on Shader Model 2 and Shader Model 3 hardware, and you can run it with anti-aliasing on.
 
....shouldn't the last sentence also add "if the HW supports it"? Or are they enabling MSAA through the application? I'm confused now.
 
maybe they doing something similar to what tb did in shadermark. Having a fp16(to do the hdr stuff) and integer render target(for AA) and combining them
 
I thought this was old news... what with all the talk back then about centroid AA or something (R300 vs NV30).
 
I guess this is a good way to promote "new tech". But i can't figure out why ATI has Valve by the balls until the end of time. Release this demo already.
 
Isn't centroid just a refinement for determining texture sampling coordinates (at the edges of triangles)?

Jawed
 
Will it look good though? If it looks like crap would you rather have AA with so so looking HDR, or awesome HDR with no AA?
 
I'll have a look at both and then actually play it in the highest resolution possible with just MSAA+ bloom ;)
 
If the performance hit is as slight as the article implies, and that it will work with MSAA across various GPU's (which only makes sense in the light of Gabe's comment) - then this is definitely A Good Thing.
 
CMAN said:
Will it look good though? If it looks like crap would you rather have AA with so so looking HDR, or awesome HDR with no AA?
AA over bloom anyday. jaggies or overbrights? are you kidding.
 
I'm waiting for the other foot to fall. It's not often that a solution is made that has no drawbacks. Performance, compatibility, quality, orthogonality. Seems like one of those must take a hit. Either that or everyone's been doing HDR all wrong.
 
Ars Technica have the gory details.

Analysis of textures for light values contributing to a large dynamic range, storing the HDR data in FP or integer surfaces depending on card, tonemap pass, use rendertargets to render into an MSAA'able surface, output (if I'm reading it right). That and some hand-tweaking of reflection maps and the skyboxes.
 
tEd said:
what's a 4.12 integer value?

fixed precision, 4 bits for the integer part, 12 bits for the fractional part.

For reference, formats that have 8 bits per component are read as fixed precision from 0 to 1 in the pixel shader (8 bits for the fractional part).
 
LeGreg said:
fixed precision, 4 bits for the integer part, 12 bits for the fractional part.

For reference, formats that have 8 bits per component are read as fixed precision from 0 to 1 in the pixel shader (8 bits for the fractional part).

ok thx
 
The system used to demonstrate the game to us today was an Athlon 64 3800+ with 2GB of RAM and a GeForce 6800GT

Valve are perhaps a bit happier with NV nowadays..

What i would like to know is, is FP blending used at all with this technique ?
 
Last edited by a moderator:
Back
Top