Sign in to follow this  
Enrico

Disadvantages of Valve's HDR Implementation?

Recommended Posts

Hi, I was just reading "Post Processing in the Source Engine" and I am wondering why only Valve (as far as I know) is using this HDR approach? It gives antialiasing and blending and stuff and performs great on older graphic cards. Any ideas? Regards, Enrico

Share this post


Link to post
Share on other sites
It's fundamentally a hack, really. A clever and somewhat effective one, yes, but a hack all the same.

As I understand it, getting the exposure to work correctly is a huge headache-- remember that it never actually calculates luminance the way all traditional tone mapping operators do; it merely approximates said values based on occlusion queries using some histogram stuff. This is also post-tonemap, too!

As such, you're locked into using operators that work off histograms; there are not many and thus you further limit your options.

Meanwhile, you can use other forms of fixed-point encoding (such as NAO32) that have a comparable cost/overhead and (virtually) none of the limitations. In summary, it's been superseded.

Share this post


Link to post
Share on other sites
Well the (IMO) huge limitation is that you never have an HDR source image to work off. The obvious implication of this is that you can't just directly calculate average luminance (like InvalidPointer mentions)...you instead have to piece together an estimate using histograms and a feedback loop. IMO this approach doesn't give such great results, or at least in Valve's case.

You also have to remember that you don't have an HDR source image available for things like bloom and reflections.

Share this post


Link to post
Share on other sites
Quote:
Original post by InvalidPointer
Meanwhile, you can use other forms of fixed-point encoding (such as NAO32) that have a comparable cost/overhead and (virtually) none of the limitations. In summary, it's been superseded.


NAO32 doesn't support hardware alpha blending, the alpha channel carries part of the LogLuv encoded color. Still, NAO32 HDR in addition to an LDR buffer for transparent objects (or a half-res / quarter-res FP16 render target with fragment program blending on NV4X and above) would be a better option, yes. Valve's implementation was good while it lasted, Sadly it didn't last very long.

- Sherief

Share this post


Link to post
Share on other sites
Quote:
Original post by Starfox
Quote:
Original post by InvalidPointer
Meanwhile, you can use other forms of fixed-point encoding (such as NAO32) that have a comparable cost/overhead and (virtually) none of the limitations. In summary, it's been superseded.


NAO32 doesn't support hardware alpha blending, the alpha channel carries part of the LogLuv encoded color. Still, NAO32 HDR in addition to an LDR buffer for transparent objects (or a half-res / quarter-res FP16 render target with fragment program blending on NV4X and above) would be a better option, yes. Valve's implementation was good while it lasted, Sadly it didn't last very long.

- Sherief


You can also combine both approaches: do your opaque pass to LogLuv, calculate luminance, and then blend in your transparent geometry while tone-mapping in the shader using the calculated luminance.

Share this post


Link to post
Share on other sites
Well, hence the 'virtual' clause. It's pretty easy to solve, though, as both of you have pointed out. I also ran across another method that stores the *exponents* of the color channels that works almost as a drop-in replacement for the standard RGB method; I'm surprised it isn't more common.
Image Hosted by ImageShack.us

I added the bloom myself in Photoshop as a visual target, but all the encoding/decoding and placeholder tone mapping (non-dynamic, for now) is done in-engine; A8R8G8B8 backbuffer with alpha used for blending.
EDIT: That's F.E.A.R. if anyone's wondering. I didn't make LithTech, though I did pretty much redo their shaders.

:X

[Edited by - InvalidPointer on June 5, 2009 1:28:28 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by InvalidPointer
Well, hence the 'virtual' clause. It's pretty easy to solve, though, as both of you have pointed out. I also ran across another method that stores the *exponents* of the color channels that works almost as a drop-in replacement for the standard RGB method; I'm surprised it isn't more common.
Image Hosted by ImageShack.us

I added the bloom myself in Photoshop as a visual target, but all the encoding/decoding and placeholder tone mapping (non-dynamic, for now) is done in-engine; A8R8G8B8 backbuffer with alpha used for blending.
EDIT: That's F.E.A.R. if anyone's wondering. I didn't make LithTech, though I did pretty much redo their shaders.

:X


Are you talking about RGBE? And doesn't FEAR render in LDR? Post tone-mapping bloom is a shame IMO, if you're doing HDR => Tonemapping early then you're not doing better than Valve's implementation.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this