Re: [Algorithms] approximation to pow(n,x)?
Brought to you by:
vexxed72
From: Nathaniel H. <na...@io...> - 2009-11-11 21:17:14
|
Half-vector doesn't break down for very smooth surfaces, you just get a very peaked NDF that is vanishingly small outside a very small solid angle - so there are only reflections when H is very close to N. In the limit you get the perfect mirror behavior where there are only reflections when N == H (which is the same as saying V == R). In other words, H formulation behavior converges cleanly to R formulation in the limit. Getting "half-vector" like behavior out of an environment map (which is inherently R-based) is possible, but more expensive than traditional methods. There are a few approaches in the literature (note that I haven't tried out any of these myself): 1) The paper "Antialiasing of Environment Maps" by Andreas Schilling has an approach that could be implemented using TEXDD (if hardware supports anisotropic filtering of cubemaps) or with manual filtering. 2) The body of work on prefiltered environment maps could be used for this as well, though there are complex fitting procedures to follow. The relevant papers here are "A Unified Approach to Prefiltered Environment Maps" by Kautz et. al., "Approximation of Glossy Reflection with Prefiltered Environment Maps" by Kautz and McCool, and (much newer) "Efficient Reflectance and Visibility Approximations for Environment Map Rendering" by Green et. al. 3) BRDF importance sampling approaches have also been applied to environment maps. Colbert and Krivanek's work is most relevant here: a SIGGRAPH sketch ("Real-Time Shading with Filtered Importance Sampling") and a GPU Gems 3 chapter ("GPU-Based Importance Sampling"). 4) The SIGGRAPH Asia 2009 paper "All-Frequency Rendering of Dynamic, Spatially-Varying Reflectance" by Wang et. al. warps reflectance lobes from H-space into L-space, for use with prefiltered environment maps. Their technique can even work with a single lookup (in this case it just shrinks the lobe rather than distorting it, but this is still better than the naive approach which results in grossly oversized highlights in some cases). Naty Hoffman > The progression Jon mentioned between a rough surface and a smooth one is > interesting to me though. The use of the half-vector does break down for > very smooth surfaces, it seems. It could be worth considering what that > means exactly. > > I just finished a game where we used cube maps for specular lighting > contributions from the sun & sky. Several cube images were used, each > "pre-blurred" to a set specular power around the reflection vector. > Half-vector was not an option I think (every pixel in the map is a light > source). Is there a way to get this "half-vector-like" behavior out of a > cube lookup? Feels like the answer is no... > > On Wed, Nov 11, 2009 at 12:31 PM, Nathaniel Hoffman <na...@io...> wrote: > >> Jon, >> >> It is inarguable that H produces much more realistic results - a simple >> observation of light streaks on wet roads and similar scenes with a >> comparison to renderings of the two formulations proves this without a >> doubt. >> >> However, there are also good, fundamental, theoretical reasons to prefer >> H. I seem to be explaining this poorly - I will give it another try, but >> first, here are some pointers to other explanations: >> >> There is a good diagram illustrating the difference in behavior of the >> two >> vectors in Figure 7 of this paper: >> http://people.csail.mit.edu/addy/research/ngan05_brdf_eval.pdf. >> >> There is also some discussion about it in Appendix A of this paper: >> >> http://graphics.stanford.edu/courses/cs448-05-winter/Schilling-1997-TechRep.pdf >> >> "Real-Time Rendering, 3rd edition" also has some discussion of it on >> pages >> 249-251. If you don't have a copy of the book, you can "look inside" at >> Amazon: >> >> http://www.amazon.com/Real-Time-Rendering-Third-Tomas-Akenine-Moller/dp/1568814240 >> , >> click on "search inside this book", look for "half vector" (in quotes) - >> you will get a link to page 249. >> >> OK, now I'll have another go As we both agree, the reflection vector is >> fundamental for a perfectly flat mirror. Imagine a directional or point >> light shining on the mirror. There are only visible reflections when V >> == >> R(L, N) (view vector is equal to the reflection of the light vector >> around >> the surface normal). >> >> Now how should we treat a surface which is not perfectly flat? A good >> model (which comes to us from fields outside graphics but has been very >> successful in graphics) is to treat such a surface as a statistical >> collection of stochastically-oriented perfect mirrors, each one too tiny >> to be individually visible. A useful description of such a surface for >> purposes of rendering is a normal distribution function, or NDF, which >> gives the statistical distribution of the microfacet normals relative to >> the overall macroscopic normal. >> >> Given a light direction L and a view direction V, how bright will we >> observe the surface to be? Let's assume for simplicity that each of >> these >> mirrors is 100% reflective at all angles (silver comes close to that). >> Then it is clear that the brightness is proportional to the percentage >> of >> microfacets from which there are visible reflections, in other words >> those >> for which V == R(L, N_u) (here I use N_u for the microfacet normal to >> distinguish from the overall surface normal N). >> >> It is simple to demonstrate that this is equivalent to N_u == H. >> Therefore >> we should "plug" H into the microfacet distribution function, which >> yields >> the (N dot H) formulation for isotropic surfaces. >> >> I can think of no similarly-principled way to derive the reflection >> vector >> formulation, and none has appeared in the literature. >> >> I hope this has convinced you that the H formulation is superior to R >> both >> in terms of realism and theoretical soundness. >> >> Thanks, >> >> Naty Hoffman >> >> > But that's equally true for the reflection vector! If all the >> > micro-mirrors were perfectly flat, then an infinite specular power >> > would be applied, and you'd get a perfect reflection of the lighting >> > environment -- in fact, this is what environment mapping gives you. >> > >> > As the mirrors start deviating from the perfectly flat state, the >> > specular power would decrease, and the specular reflection area would >> > grow in size. I don't see how you can say that the half-angle >> > formulation is more meaningful. We're still talking about reflected >> > light. In the perfectly reflected case, clearly the reflection vector >> > is 100% meaningful and accurate, and any other formulation would be >> > less meaningful. I don't see how "meaningfulness" would change as >> > smoothness goes from 100% to 99.9% or 95% or 50%. >> > >> > I do agree that the math gives you a different assumed microfacet >> > distribution in the case of the reflection formulation versus the >> > half-angle formulation. Both are approximations, of course. However, >> > what I don't get, is why the reflection vector approximation is >> > considered so inferior to the more expensive half-angle vector >> > approximation. Does it have anything to do with the space integral of >> > the reflection cone formed by the vector in question spread out by the >> > power function? If so, how? >> > >> > Sincerely, >> > >> > jw >> > >> > >> > On Sun, Nov 8, 2009 at 9:41 AM, Nathaniel Hoffman <na...@io...> wrote: >> > >> >> The half-angle formulation is not just more physically correct than >> the >> >> reflection-vector formulation, it is fundamentally more meaningful. >> > ... >> >> The half-vector comes from microfacet theory. Imagine that the >> surface >> >> is >> >> actually a large collection of tiny flat mirrors when viewed under >> >> magnification. Recall that a mirror only reflects light in the >> >> reflection >> >> direction. For given light vector L and view vector V, only mirrors >> >> which >> > >> > >> > -- >> > Americans might object: there is no way we would sacrifice our living >> > standards for the benefit of people in the rest of the world. >> > Nevertheless, whether we get there willingly or not, we shall soon >> > have lower consumption rates, because our present rates are >> > unsustainable. >> > >> > >> ------------------------------------------------------------------------------ >> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> > 30-Day >> > trial. Simplify your report design, integration and deployment - and >> focus >> > on >> > what you do best, core application coding. Discover what's new with >> > Crystal Reports now. http://p.sf.net/sfu/bobj-july >> > _______________________________________________ >> > 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 >> > >> >> >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and >> focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> 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 >> > > > > -- > Jeff Russell > Engineer, 8monkey Labs > www.8monkeylabs.com > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. > http://p.sf.net/sfu/bobj-july_______________________________________________ > 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 |