Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Nathaniel Hoffman <naty@io...>  20090727 05:16:05

There are two ways to get a normalized BRDF with a cosine power term. One is to construct the BRDF empirically (e.g. as a modified BlinnPhong), and then normalize the BRDF by computing an upper bound for the directionalhemispherical reflectance and dividing by it. The other is to derive the BRDF from physical principles (e.g. microfacet theory), treating the cosine power term as a normal distribution function (NDF) and normalizing it as such. The derivation on page 446 of "physicallybased rendering" (PBR) relates to the second way. "Realtime rendering, 3rd edition" (RTR3) does both kinds of derivations, and compares them to each other. The empirical approach results in the (m+8)/8pi term (page 257 of RTR3). Unfortunately, we did not include the derivation in the book; we did the exact same derivation as Fabian Giesen (see page 2 of http://www.farbrausch.de/~fg/articles/phong.pdf), but approximated the integral with a simple function rather than using it directly. Since we were concerned with realtime rendering and not global illumination, we did not try to make the BRDF strictly energyconserving (integral always less than 1) but just approximately so (integral close to 1, doesn't matter if slightly above or slightly below). We chose an approximation which was relatively accurate for low specular powers, which in our opinion is perceptually important. The physically based derivation starts with the derivation of microfacet BRDFs included in Ashikhmin, Shirley and Premoze's 2000 SIGGRAPH paper and "plugs in" a cosine power NDF (page 259 of RTR3). the result, like PBR, includes a (m+2) term, which is not surprising since the same normalization by projected solid angle is included in the derivation (the 8pi instead of 2pi term in the denominator is the result of converting between incident and halfvector angles). I wouldn't necessarily say (m+2) is "more correct" since it results from a physical derivation. Both are equally "correct", just based on different assumptions. In my own work, using relatively simple BRDFs, I have had good results with the (m+8)/8pi term (in most game engines the pi cancels out, so this is just (m+8)/8). If you are trying to include shadowing / masking and foreshortening terms and otherwise closely emulate a microfacet BRDF, you might want to go with (m+2)/8 instead. Thanks, Naty Hoffman > From: Matt Pharr <matt@...> > Date: Sat, Jul 25, 2009 at 4:29 PM > Subject: Re: [Algorithms] Lighting (HDR) > To: Game Development Algorithms <gdalgorithmslist@...> > > > (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 
From: Joe Meenaghan <joe@ga...>  20090730 15:33:57

First, let me thank you guys for the interesting discussion surrounding the normalization factor and its derivations. In the end I've decided to go with Naty's suggestion and (continue) using the m+2 approach as indeed I am including an approximate geometry/visibility term of 1 / (4 * L.H^2) (i.e., Kelemen, SzirmayKalos) and treating the cosine power function as an NDF. To be honest, all three approaches (m+2)/(2pi), (m+8)/(8pi), and (m+2)/(8pi) have produced nice results for me, so it is basically down to what works visually for us I guess since they all seem to have some legitimate grounding in theory. So with that bit of business pretty much wrapped up, that leaves me with just the outstanding issues on dynamic white point computation (vs. ditching it altogether) and practical advice on empirical vs. physically meaningful inputs for my direct light sources. Any insights on either of these two issues would of course be accepted gratefully. Thanks again! Joe 
From: Nathaniel Hoffman <naty@io...>  20090730 16:39:08

> To > be honest, all three approaches (m+2)/(2pi), (m+8)/(8pi), and (m+2)/(8pi) > have produced nice results for me, so it is basically down to what works > visually for us I guess since they all seem to have some legitimate > grounding in theory. Well... if you are using BlinnPhong (N.H), then dividing by (2pi) is unambiguously wrong (it is correct for Phong  (R.V)  though). I agree that the two with division by (8pi) both have theoretical legitimacy. Note however that most game engines use units that cause the (pi) factor to be removed, so you would just be dividing by 8. Naty 
From: Zafar Qamar <zafar.qamar@co...>  20090729 18:09:59

Just thought of another way of describing the animation... The animation effect I'm after is a bit like a lavalamp. Hope that clarifies at least slightly the look I'm after. Cheers Zafar Qamar Original Message From: Zafar Qamar Sent: 29 July 2009 18:30 To: 'Game Development Algorithms' Subject: Trickly Water Hi, I'm trying to create the effect of water spray landing on a camera with a small lens size, thus making the drops rather large. The bit I really need is how to generate animated normal maps that resemble big blobs of water that warp and trickle to form new shapes. Imagine I've drawn a few blobs of normalmap in Photoshop and put them onto the screen as a postprocess effect. I now need to warp and move them. Are there any utils that could generate this kind of thing? Any ideas and suggestions at all would be most welcome. Cheers Zafar Qamar ********************************************************************************** Disclaimer The information and attached documentation in this email is intended for the use of the addressee only and is confidential. If you are not the intended recipient please delete it and notify us immediately by telephoning or emailing the sender. Please note that without Codemasters’ prior written consent any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. Attachments to this email may contain software viruses. You are advised to take all reasonable precautions to minimise this risk and to carry out a virus check on any documents before they are opened. Any offer contained in this communication is subject to Codemasters’ standard terms & conditions and must be signed by both parties. Except as expressly provided otherwise all information and attached documentation in this email is subject to contract and Codemasters’ board approval. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters. This footnote also confirms that this email message has been swept by SurfControl for the presence of computer viruses. ********************************************************************************** 
From: Megan Fox <shalinor@gm...>  20090729 18:42:18

When it comes to morphing effects, your best bet is to start with noise. Start by reading this: http://freespace.virgin.net/hugo.elias/models/m_clouds.htm ... which is a great primer, and generally good way to do clouds period. You could get a lavalamp appearance by simply adjusting the low/highpass on his output. Past that, consider the source of your noise. The usual idea is to go with nonpatterned noise, it being... well, noise... but you can get some very, very interesting results when you treat a nonnoisy data set as noise. An image's color values, for instance. (sorry I can't offer specifics, but this is at the core of the water tech I made for LU  NDA's and all that, etc. Still, the above should get you started) On Wed, Jul 29, 2009 at 11:32 AM, Zafar Qamar<zafar.qamar@...> wrote: > Just thought of another way of describing the animation... > > The animation effect I'm after is a bit like a lavalamp. > Hope that clarifies at least slightly the look I'm after. > > Cheers > Zafar Qamar  Megan Fox http://www.shalinor.com/ 
From: Robin Green <robin.green@gm...>  20090729 20:14:04
Attachments:
Message as HTML

I think the initial question was about droplets on a camera surface. Water droplets coalescing into larger droplets is more of a Poission points problem than a noise one. As two droplets come into contact they will generate a new droplet at the mean point between the two centers with a radius proportional to their two volumes. Making them run down the picture plane under gravitational accelleration means animating it's center and altering it's mass as it picks up surrounding droplets. Trails could probably be faked using a small heightfield that you decrement each frame. The droplets themselves have a very specific shape depending on the surface tension and hydrophilic properties of the surface they land on, specified by the contact angle and the contact radius. These subtle curves around the contact edge of the droplet are important cues to interpreting what is being dropped onto what. http://physicaplus.org.il/zope/home/en/1185176174/water_elect_en Trying to find a formula for the shape, ISTR it's a pretty regular analytic polynomial.  Robin Green. On Wed, Jul 29, 2009 at 11:41 AM, Megan Fox <shalinor@...> wrote: > When it comes to morphing effects, your best bet is to start with noise. > > 
From: Zafar Qamar <zafar.qamar@co...>  20090730 10:49:24
Attachments:
Message as HTML

Hi, I don't have procedural stuff going on  I just want to play with art textures and do some shader programming to just give the appearance of lavalampy kind of effects. The cloudmap stuff using the noise approach that Megan mentioned is particularly the sort of thing I'm going to now try. Thanks very much for for all your responses so far. Some interesting reading on your posted links  cheers! Zafar Qamar ________________________________ From: Robin Green [mailto:robin.green@...] Sent: 29 July 2009 21:14 To: Game Development Algorithms Subject: Re: [Algorithms] Trickly Water I think the initial question was about droplets on a camera surface. Water droplets coalescing into larger droplets is more of a Poission points problem than a noise one. As two droplets come into contact they will generate a new droplet at the mean point between the two centers with a radius proportional to their two volumes. Making them run down the picture plane under gravitational accelleration means animating it's center and altering it's mass as it picks up surrounding droplets. Trails could probably be faked using a small heightfield that you decrement each frame. The droplets themselves have a very specific shape depending on the surface tension and hydrophilic properties of the surface they land on, specified by the contact angle and the contact radius. These subtle curves around the contact edge of the droplet are important cues to interpreting what is being dropped onto what. http://physicaplus.org.il/zope/home/en/1185176174/water_elect_en Trying to find a formula for the shape, ISTR it's a pretty regular analytic polynomial.  Robin Green. On Wed, Jul 29, 2009 at 11:41 AM, Megan Fox <shalinor@...> wrote: When it comes to morphing effects, your best bet is to start with noise. Click here <https://www.mailcontrol.com/sr/ZfaQhFWJHa!TndxI!oX7UlpW6f62H1zmG+2Q6DBw xKE6KzkmIuM8MsS4FsH4Qq9nbMA6wkmdxWTQE4zD1Sgchg==> to report this email as spam. ********************************************************************************** Disclaimer The information and attached documentation in this email is intended for the use of the addressee only and is confidential. If you are not the intended recipient please delete it and notify us immediately by telephoning or emailing the sender. Please note that without Codemasters’ prior written consent any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. Attachments to this email may contain software viruses. You are advised to take all reasonable precautions to minimise this risk and to carry out a virus check on any documents before they are opened. Any offer contained in this communication is subject to Codemasters’ standard terms & conditions and must be signed by both parties. Except as expressly provided otherwise all information and attached documentation in this email is subject to contract and Codemasters’ board approval. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters. This footnote also confirms that this email message has been swept by SurfControl for the presence of computer viruses. ********************************************************************************** 
From: Zafar Qamar <zafar.qamar@co...>  20090729 18:18:24

Hi, I'm trying to create the effect of water spray landing on a camera with a small lens size, thus making the drops rather large. The bit I really need is how to generate animated normal maps that resemble big blobs of water that warp and trickle to form new shapes. Imagine I've drawn a few blobs of normalmap in Photoshop and put them onto the screen as a postprocess effect. I now need to warp and move them. Are there any utils that could generate this kind of thing? Any ideas and suggestions at all would be most welcome. Cheers Zafar Qamar ********************************************************************************** Disclaimer The information and attached documentation in this email is intended for the use of the addressee only and is confidential. If you are not the intended recipient please delete it and notify us immediately by telephoning or emailing the sender. Please note that without Codemasters’ prior written consent any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. Attachments to this email may contain software viruses. You are advised to take all reasonable precautions to minimise this risk and to carry out a virus check on any documents before they are opened. Any offer contained in this communication is subject to Codemasters’ standard terms & conditions and must be signed by both parties. Except as expressly provided otherwise all information and attached documentation in this email is subject to contract and Codemasters’ board approval. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Codemasters. This footnote also confirms that this email message has been swept by SurfControl for the presence of computer viruses. ********************************************************************************** 
Sign up for the SourceForge newsletter:
No, thanks