[Algorithms] Lighting (HDR)

[Joe M. <jo...@ga...>]

Hey All,

Just a few random questions pertaining primarily to HDR lighting that I'm hoping to get some insight on. 

1. I have differing information about the normalization term for the Blinn-Phong BRDF and I'd like to know which is correct. In Real-Time Rendering the authors suggest (m + 8) / (8 * pi) based on a derivation from Sloan and Hoffman. However, in Pharr and Humphrey (Physically Based Rendering, p.446) they calculate (m + 2) / (2 * pi). The definite integral solution demonstrated in the latter appears reasonable to me, so I'm uncertain. Normally I've associated the m+2 version as the normalization term for plain Phong, yet, Pharr and Humphrey are very explicitly referring to the Blinn BRDF and are using the half vector rather than the reflection vector in their discussion, and they are convincing. Is there something I'm missing?    

2. Despite a variety of different ideas tried, I have yet to come up with a satisfactory method for dynamically estimating the white point term for use with Reinhard's Photographic Tone Reproduction tone mapper (global). I'm using Krawczyk et al. for computation of the estimated key and it works well, but for white point, I currently just wind up setting some arbitrary value until it looks good. Of course, this ultimately has implications for the variety of light intensities we can use and still benefit from having the term (e.g., the very nice contrast it can introduce). I'd like to avoid having to hand place regions of tonemapping inputs throughout the scene to account for different lighting conditions. Has anyone come up with a way of estimating this parameter without the need for such manual intervention?  Reinhard's paper on parameter estimation has not worked well for me in practice, although I am open to the possibility that I am doing something improperly (see next question). While I don't have a runtime histogram, I do have access to arithmetic and log average luminance as well as min/max luminance, so hopefully there's a way to cobble something together here that works?  Arguably, I can ditch the white point altogether (or just always use values close to some percentange of the scenewide max lighting intensity) and use our post-processing pipeline to manipulate contrast and so on, but I figured I'd see if anyone has any suggestions before I throw in the towel.  

3. Somewhat related to the last question is the range of the irradiance values used in the first place. In our system, we've got a light source color (speaking only about direct sources like point, spot, etc. not IBL textures) and a separate HDR intensity scalar per light. The idea is that the former can be used in LDR lighting scenarios as is (it is a float3, so it can technically go outside [0,1] although we rarely go past 2 or so for LDR) and that the intensity scalar can adjust it as desired for HDR situations (in HDR our framebuffer is RGBA16F). However, based on my troubles with trying to automatically compute reasonable key and white point values, I am wondering if the difficulties I am having are perhaps related to the fact that many of the algorithms I've tried to experiment with are likely working with proper real world data and as such the resulting luminances are more ideally suited to yield plausible behavior. I am considering whether our light intensities need to be more carefully tuned to match their real world counterparts (admittedly, under certain conditions the 16-bit range concerns me a little if that is the case) so I'd like to better understand what sort of values work well in practice -- i.e., what is the tradeoff between physical realism where all values have to be very precise (SI units, etc.) and artistic control? Certainly there's an argument to be made for something that visually looks like it is illuminated by say, a 60 watt bulb, and if that is the desired end result then so be it, regardless of what intensities were used to create the effect. But if this sort of arbitrary artistic experimentation is preventing me from implementing algorithms correctly, as per above, that would be good to know. Ultimately, I guess I'm just looking for a bit of guidance as to what inputs work well in real-time HDR situations :) 

As always, my sincere thanks in advance for any assistance.

Joe Meenaghan
jo...@ga...