Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Close
From: Fabian Giesen <f.giesen@49...>  20090725 19:01:21

Joe Meenaghan wrote: > 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 > BlinnPhong BRDF and I'd like to know which is correct. In RealTime > 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? I went through the same thing a few months ago. See the discussion in the comments here: http://www.rorydriscoll.com/2009/01/25/energyconservationingames/ (Including a comment from Naty Hoffman who did the derivation mentioned in RTR). The exact normalization factor obviously depends on what variant of the BRDF you use. I did the computation for typical variants of Phong and BlinnPhong here: http://www.farbrausch.de/~fg/articles/phong.pdf (also referenced in the discussion above). Hope that helps! Cheers, Fabian "ryg" Giesen 
From: Joe Meenaghan <joe@ga...>  20090725 18:38:33
Attachments:
Message as HTML

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 BlinnPhong BRDF and I'd like to know which is correct. In RealTime 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 postprocessing 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 16bit 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 realtime HDR situations :) As always, my sincere thanks in advance for any assistance. Joe Meenaghan joe@... 
From: Fabian Giesen <f.giesen@49...>  20090725 19:01:21

Joe Meenaghan wrote: > 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 > BlinnPhong BRDF and I'd like to know which is correct. In RealTime > 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? I went through the same thing a few months ago. See the discussion in the comments here: http://www.rorydriscoll.com/2009/01/25/energyconservationingames/ (Including a comment from Naty Hoffman who did the derivation mentioned in RTR). The exact normalization factor obviously depends on what variant of the BRDF you use. I did the computation for typical variants of Phong and BlinnPhong here: http://www.farbrausch.de/~fg/articles/phong.pdf (also referenced in the discussion above). Hope that helps! Cheers, Fabian "ryg" Giesen 
From: Matt Pharr <matt@ph...>  20090725 20:43:42

(below) On Jul 25, 2009, at 12:00 PM, Fabian Giesen wrote: > Joe Meenaghan wrote: >> >> 1. I have differing information about the normalization term for the >> BlinnPhong BRDF and I'd like to know which is correct. In RealTime >> 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? Unfortunately RTR doesn't seem to have a derivation, so it's hard to see precisely where the difference comes from. One general note is that the PBR book is normalizing a microfacet distribution, but RTR is (from a quick skim) normalizing a BRDF. So I think that the 2pi vs 8pi difference in the denominator comes from the fact that 2pi works out to be the right denominator for a normalized microfacet distribution, but if you fold in the 1/4 term that comes in the TorranceSparrow BRDF (discussed on p442 of the PBR book), then that covers that difference. The (m+2) vs (m+8) stuff in the numerator I don't have any insight on. As far as I know the PBR derivation is correct and I just wrote a short program to verify the result numerically and it all came out as expected. Hopefully Naty can chime in? > > I went through the same thing a few months ago. See the discussion in > the comments here: > > http://www.rorydriscoll.com/2009/01/25/energyconservationingames/ > > (Including a comment from Naty Hoffman who did the derivation > mentioned > in RTR). The exact normalization factor obviously depends on what > variant of the BRDF you use. I did the computation for typical > variants > of Phong and BlinnPhong here: > > http://www.farbrausch.de/~fg/articles/phong.pdf I think there is a bug in the BlinnPhong normalization there. In particular, I don't think that the first step of going from an integral over cos theta h to an integral of cos theta/2 is right (or neededthe microfacet distribution can be normalized fine in theta_h land.) A related note is that the extra cos theta factor doesn't come from it being a BRDF, but comes from the geometry of microfacetsi.e. the projection of a microfacet with angle theta_h from the actual surface normal projects to a differential area scaled by cos theta_h on the actual surface. > > (also referenced in the discussion above). Hope that helps! > > Cheers, > Fabian "ryg" Giesen > >  > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithmslist 
From: Fabian Giesen <f.giesen@49...>  20090725 22:49:53

> I think there is a bug in the BlinnPhong normalization there. In > particular, I don't think that the first step of going from an > integral over cos theta h to an integral of cos theta/2 is right (or > neededthe microfacet distribution can be normalized fine in theta_h > land.) theta_h is not theta/2 in general, correct. That's why I specifically note that L=N and hence all angles are in the same plane; for general configurations, the halfway angle might lie in a different plane than the angle between N and L, so the result depends on the second angle (phi) as well and the whole process gets a lot more complex. > A related note is that the extra cos theta factor doesn't come from it > being a BRDF, but comes from the geometry of microfacetsi.e. the > projection of a microfacet with angle theta_h from the actual surface > normal projects to a differential area scaled by cos theta_h on the > actual surface. I didn't mean to imply that you tack on an additional factor of cos(theta) because it's a BRDF, but rather that the reflection equation (and also the rendering equation) contain the cos(theta) normalization term, while the original Phong and BlinnPhong shading models don't, so the BRDF for these original formulations has to divide through by cos(theta) to get rid of the term in the integral, violating reciprocity in the process (and being generally physically implausible). Which is why modern formulations don't do this. Anyway, Naty already explained the discrepancy between this and the formula from RTR in the comments of the article I linked to. I'll quote, first from Rory: "I did manage to talk to Naty about this at GDC. He said that a few people have asked him about the derivation of the specular factor in the book, and that he had gone through it himself and got the exact same answer as Fabian. The value they mention in the book is just an approximation of that result." And then from Naty: "About the approximation we chose, we were not trying to be strictly conservative (that is important for multibounce GI solutions to converge, but not for rasterization). We were trying to choose a cheap approximation which is close to 1, and we thought it more important to be close for low specular powers. Low specular powers have highlights that cover a lot of pixels and are unlikely to be saturating past 1." Fabian "ryg" Giesen 
From: Matt Pharr <matt.pharr@gm...>  20090725 23:23:42

On Jul 25, 2009, at 3:49 PM, Fabian Giesen wrote: >> >> A related note is that the extra cos theta factor doesn't come from >> it >> being a BRDF, but comes from the geometry of microfacetsi.e. the >> projection of a microfacet with angle theta_h from the actual surface >> normal projects to a differential area scaled by cos theta_h on the >> actual surface. > > I didn't mean to imply that you tack on an additional factor of > cos(theta) because it's a BRDF, but rather that the reflection > equation > (and also the rendering equation) contain the cos(theta) normalization > term, while the original Phong and BlinnPhong shading models don't, > so > the BRDF for these original formulations has to divide through by > cos(theta) to get rid of the term in the integral, violating > reciprocity > in the process (and being generally physically implausible). Which is > why modern formulations don't do this. That's sort of an over simplification. For example, The Torrance Sparrow BRDF has both 1/cos theta_i and 1/cos theta_o terms, not to make the old shading models match with the new reflection equation, but intuitively to account for the fact that as you approach grazing angles, the total projected area of all microfacets seen along a ray increases (and goes to infinity at grazing when you hit the point of your ray going through all of the microfacets!) (It is also reciprocal.) However, one generally includes a microfacet geometric attenuation term which (lo and behold) accounts for microfacets shadowing each other and in turn makes things behave properly at grazing angles. (At least 'modern formulations' in my world do, for what that's worth.) (I'm still not following what this other normalization term is attempting to achieve or how exactly it was derived.) matt > > Anyway, Naty already explained the discrepancy between this and the > formula from RTR in the comments of the article I linked to. I'll > quote, > first from Rory: > > "I did manage to talk to Naty about this at GDC. He said that a > few people have asked him about the derivation of the specular > factor in the book, and that he had gone through it himself and > got the exact same answer as Fabian. The value they mention in > the book is just an approximation of that result." > > And then from Naty: > > "About the approximation we chose, we were not trying to be strictly > conservative (that is important for multibounce GI solutions to > converge, but not for rasterization). We were trying to choose a > cheap > approximation which is close to 1, and we thought it more > important to > be close for low specular powers. Low specular powers have > highlights > that cover a lot of pixels and are unlikely to be saturating past > 1." > > Fabian "ryg" Giesen 
From: Fabian Giesen <f.giesen@49...>  20090725 23:36:14

> That's sort of an over simplification. For example, The Torrance > Sparrow BRDF has both 1/cos theta_i and 1/cos theta_o terms, not to > make the old shading models match with the new reflection equation, > but intuitively to account for the fact that as you approach grazing > angles, the total projected area of all microfacets seen along a ray > increases (and goes to infinity at grazing when you hit the point of > your ray going through all of the microfacets!) (It is also reciprocal.) Yes, if you divide both by cos(theta_i) and cos(theta_o) it's reciprocal again (since it's symmetrical in both angles), but you cannot divide by just one of them. Fabian 