   Disadvantages of Valve's HDR Implementation?
  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   
  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.   ;  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.   ;Quote:Original post by InvalidPointerMeanwhile, 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;Quote:Original post by StarfoxQuote:Original post by InvalidPointerMeanwhile, 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.- SheriefYou 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.  ;  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.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];Quote:Original post by InvalidPointerWell, 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.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.:XAre 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.