Valve’s HDR Source Implementation

We recently had the opportunity to head up to Washington to visit with Valve and talk about the new additions to the Source engine. After the issues and delays getting Half-Life 2 out the door, Valve's philosophy on game development has shifted. Rather than setting a long term goal to take one project from start to finish, Gabe and the team will be setting shorter term release goals. The idea is that five one-year projects on the road to a five-year destination can help keep them on track. We can also look forward to incremental updates to the Source engine allowing other game developers to benefit constantly from new technology, bringing us nice little treats like HDR.

As a result of the past year of development, Valve has met their goal to incorporate HDR into their Source engine and now we get to reap the benefits. But before we look at performance numbers and image quality, we will take a look behind the scenes to find out what is going on. At first glance, it is clear that Valve has added the usual blooming features that we would expect from HDR rendering, but there are a couple of new features that Valve has added to keep it interesting.

As we have said, HDR generally speaks to representable contrast in a scene. The way that developers handle this is to represent brightness data beyond the capabilities of the display (for instance, the sun is much brighter than a light bulb, but both could be the same color with traditional rendering). That isn't to say that a game or other HDR applications can make your monitor brighter than possible, but rather that internal light sources and objects in an application can be represented by more brightness than can be displayed. The final rendered image is then (in current incarnations) tonemapped down to a standard 8-bit display colorspace.

This allows objects that are only partially reflective to still reflect enough light to be as bright as what the monitor can display. For instance, a rock in a game may be 20% reflective. Normally rendered, even if a bright light source is perfectly reflected to the camera, the rock can only be 20% as bright as what the monitor can display. If the light source shining on a rock is 5 times brighter than the display, the rock will still be able to reflect a light that shines at 100% of the monitor's brightness.

In addition to this feature, very bright lights also make it more difficult for our eyes to clearly see objects occluding (or nearly occluding) the light source. The effect that game developers use to portray this "bloom" is to blur the light onto the foreground object. The high dynamic range allows light sources to be identified and properly handled.

One of the easiest ways to implement HDR from scratch is to use a floating point format with all art assets designed around HDR. Unfortunately, current hardware isn't able to handle full floating point data as fast as other methods, and no hardware (that is currently out) can allow MSAA to run on a floating point render target. The size of the artwork needed to make this work is also huge and floating point assets cannot be compressed currently using built-in hardware texture compression techniques. On top of this, Valve is working with an existing engine designed around Half-Life 2, so this method would also require a redesign of art assets and how they worked. These problems and others add up to make it difficult to incorporate this technology in the Source engine.

So, rather than carry HDR data through the entire pipeline and all art assets, Valve made a different choice that gives a good balance of performance and HDR characteristics. Data is represented in fp16 or integer 4.12 linear space through in light sources cube maps and static lighting data. This method is unable to store overbright information directly, but Valve is still able to add a blooming shader. Our understanding is that this method eliminates the possibility for transmissive or refracted overbright data (we won't be able to see a bloom inside a stained glass window or from sand under water through which light has passed). But blooming light sources and direct light reflection is still possible and well used in the Source engine.

But on top of blooming, Source also allows for dynamic tonemapping that works something like an auto exposure or a human pupil. This helps maintain a high dynamic range effect without overbright data by allowing the natural lighting of a scene to dictate the exposure of the rendered image. This means that in a dark room, the tonemapping scale will adjust to (essentially) make the brightest parts of the darkness bright enough to see with the natural light. The mapping isn't linear so that very dark pixels are brightened less than lighter pixels. In a bright room, the opposite is true, but in both cases, the definition of HDR is fulfilled: the contrast ratio between bright and dark areas on the same image is greatly increased.

To handle the tonemapping, Valve artists design three different images for the skybox at three different exposures. HDR light maps are built from the environment using a global illumination model and radiosity that uses 8 bounces. The process of generating HDR light maps takes a while, but (together with the HDR cube maps built from the HDR light maps and the skybox) this also allows Valve to represent correctly the lighting of the world. Entire maps can be lit with only the sun as a light source. Normally, to brighten hallways or dark areas away from static lights, small point lights are used. This is no longer necessary and can actually make the scene look bad. Not to worry though, level designers can build HDR lighting information into the same BSP as non-HDR lighting data and the engine will select the right ones to use depending on the mode in which the game is running.

The HDR SDK for source will ship when the Lost Coast level is released. This will allow modders to implement HDR levels in their games by adding the three exposure sky maps, building HDR and non-HDR lighting into levels, and setting bloom and exposure ranges per area if desired. While bloom and exposure can be handled automatically, it is nice to give the developer control over this.

And now that we've seen how it's done, let's take a look at the end result in performance and image quality.

Index Test Setup


View All Comments

  • Frackal - Friday, September 30, 2005 - link

    I actually meant to ask about the resolution too.

    In my own bench, starting from spawn point at anzio and then running to the other end of the map while doing some shooting with the bazooka, at:

    4AA/16AF All High/Reflect All
    MultiSampling AA
    Forced Trilinear mipmaps

    I get just over 70FPS

    4400+ @2.65
    BFG GTX @ 480/1360
    2gigs mushkin at 241 1:1 2/3/3/8
  • ashay - Friday, September 30, 2005 - link

    Is it just me? In EVERY screenshot of HDR vs !HDR that I've seen, I've thought the !HDR looks better. Maybe I need to play and see for my self.

  • wanderer27 - Friday, September 30, 2005 - link

    I have yet to see where either Bloom or HDR makes things look better.

    AOE III - HDR/Bloom looks worse.

    Day of Defeat - HDR/Bloom looks worse.

    Oblivion - Bloom effect looks bad, haven't seen a shot of non-Bloom on this game yet.

    Maybe it will do something for darkly lit games, but so far they all look too glowy (AOE), or washed out (DOD).

    So far this looks like a useless technology they're trying to shove down our throats. Thankfully, in AOE you have the option to turn this crap off.

    My advice to the Devs, stop wasting time on this and find something that'll actually make things look or play better.

  • overclockingoodness - Friday, September 30, 2005 - link

    The image with HDR is smoother. Reply
  • Frackal - Friday, September 30, 2005 - link

    Frankly I was blown away by the graphics in DOD-S and I've played COD2, FEAR, BF2, etc... If you're running the right rez with all details turned up, its like being in a photograph much of the time.

    Valve should have gotten way more props for this

    I hope I don't have to see you guys exclaiming how good FEAR's crappy graphics are if you ever review that game..

    Anyway I love AT but I thought this really downplayed the impressive graphics here.
  • Gigahertz19 - Friday, September 30, 2005 - link

    The very bottom image looks the best to me. Compare it to the top which has alot of the jaggies but witht he HDR the jaggies are missing, it looks alot smoother. Wish I had a better GPU then a 9700 pro. Reply
  • Bonesdad - Friday, September 30, 2005 - link

    All the jaggies are definately still there, the entire image is just more washed out...I think the top image has richer colors. Not really impressed, personally. Reply
  • toyota - Friday, September 30, 2005 - link

    all the jaggies are still there in the bottom pic. they are just a little washed out. its not any smoother. Reply
  • DerekWilson - Friday, September 30, 2005 - link

    We did top end and upper midrange ... this was really just a taste though -- believe me, we'll have more benchmarks with this game soon :-) Reply
  • PrinceGaz - Friday, September 30, 2005 - link

    Interesting article though like many others I was distinctly unimpressed by the static screenshots showing the "benefits" of HDR. Maybe it works a lot better while actually playing the game...

    The choice of cards tested seemed a bit strange to me though. Either a 7800GT or GTX would have been enough for top-end nVidia performance, as would a single good card from the X800/X850 line-up to show how ATI compares with their current generation (ideally figures from an X1800 would be thrown in, but NDAs currently prevent that). The omission of a 6800GT or similar was the main problem with the benchmarks though, as many of us have one of them and would like to know well they fare.

    Along with the 6600GT for current mid-range performance, ideally you'd also include an FX5900/5950 series and a 9800Pro as not everyone buys a new card when a new generation of hardware is released. The 9800Pro is still very capable and should be included in all reviews, and an FX5900/5950 should be included too for reference even if it does suffer badly with modern pixel-sharder intensive games, so that people can decide if an upgrade is worthwhile. Anything less than those cards would probably be a waste of time for this review though as they'd be too slow.

    In fact I'd say a 9800Pro and FX5900/5950 should be included in *all* graphics-card / game-performance reviews, in addition to the usual 7800, 6800, 6600, X800/850. You must have them lying around somewhere ready to drop in a suitable box I'm sure :)

    I'm looking forward to the updated/follow-up article with additional benchmarks, I understand if time was pressing you could only test on a limited number of cards.

Log in

Don't have an account? Sign up now