gdalgorithms-list

[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...

Re: [Algorithms] Lighting (HDR)

[Fabian G. <f.g...@49...>]

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 
> 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?    

I went through the same thing a few months ago. See the discussion in 
the comments here:

   http://www.rorydriscoll.com/2009/01/25/energy-conservation-in-games/

(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 Blinn-Phong here:

   http://www.farbrausch.de/~fg/articles/phong.pdf

(also referenced in the discussion above). Hope that helps!

Cheers,
-Fabian "ryg" Giesen

Re: [Algorithms] Lighting (HDR)

[Matt P. <ma...@ph...>]

(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
>> 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?

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  
Torrance-Sparrow 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/energy-conservation-in-games/
>
> (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 Blinn-Phong here:
>
>   http://www.farbrausch.de/~fg/articles/phong.pdf

I think there is a bug in the Blinn-Phong 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  
needed--the 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 microfacets--i.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
>
> ------------------------------------------------------------------------------
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] Lighting (HDR)

[Fabian G. <f.g...@49...>]

> I think there is a bug in the Blinn-Phong 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  
> needed--the 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 microfacets--i.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 Blinn-Phong 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 multi-bounce 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

Re: [Algorithms] Lighting (HDR)

[Matt P. <mat...@gm...>]

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 microfacets--i.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 Blinn-Phong 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 multi-bounce 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

Re: [Algorithms] Lighting (HDR)

[Fabian G. <f.g...@49...>]

> 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