Talk:Phong reflection model

message: Shouldn't L be the vector from the point on the surface to the light source?  All other sources I have seen on this equation define it as such. —The preceding unsigned comment was added by 24.42.196.192 (talk • contribs) 21:34, 3 December 2004  (UTC)
:Right, that got fixed shortly after your comment. Dicklyon 02:24, 30 May 2006 (UTC)
replies: text: Please sign your comments with four tildes as the editing talk page suggests. Dicklyon 02:24, 30 May 2006 (UTC)
thread_title:  Definition of L in Phong equation 

message: Shouldn't the equation be Color * Diffuse + specular and NOT Color + Diffuse + Specular? Starfox 23:40, 25 July 2006 (UTC)
replies: text: which equation are you referring to? Dicklyon 07:00, 26 July 2006 (UTC)

text: Perhaps the confusion is the ambient term? k_a is the ambient colour, k_d and k_s are diffuse and specular. There are actually three different colour terms, each making a contribution to the lighting. Neither of the formulae you suggest represent what is currently on the page, or proper Phong lighting, though the specular colour is often very close to white, which may be why you have omitted its multiplication by colour in your suggestion. - Rainwarrior 07:28, 26 July 2006 (UTC)
replies: text: Ah, I see it. The confusion is the picture diagrams below where the diffuse colour has been combined with the ambient colour. The "diffuse" picture should have colour to it, and the "ambient" picture should be much darker. I'll see if I can fix it. - Rainwarrior 07:31, 26 July 2006 (UTC)
replies: text: Oh, right, the funny picture equation.  It's not well explained, but if you interpret the text below it, where it explains that it's a gray object in a blue ambient environment, I think you'll find that it's not incorrect.  It could certainly be improved, though. Dicklyon 07:39, 26 July 2006 (UTC)
replies: text: Ah, didn't spot that. Well, I edited the image as best I could to be a more traditional example where the diffuse and ambient colours are the same. - Rainwarrior 08:03, 26 July 2006 (UTC)
replies: text: I don't think they add up to the left-hand image now. Maybe we should contact the guy who did it in the first place to do it over better.  He probably has a programmable way to do it.  Or write one, using a new object, maybe even with more than one color. Dicklyon 19:12, 26 July 2006 (UTC)
replies: text: Yeah, I couldn't get the colours quite right (my graphics editor didn't have the right controls for colour, I tried to approximate). I could rig up a demonstration program and redo it later. - Rainwarrior 21:21, 26 July 2006 (UTC)
replies: text: I think I might be able to provide some pics on the classic teapot. I can do a simple GLSL shader in RenderMonkey. Interested? Starfox 23:02, 26 July 2006 (UTC)
replies: text: Sure, go for it. - Rainwarrior 23:20, 26 July 2006 (UTC)
replies: text: I can redo the image with the correct idea and more than one color, thanks for the corrections. - T-tus
I don't know if Starfox is still planning to do this or not, but I wrote a little software renderer and made a new image out of it. Looking at it now, I wish I'd used a more curved surface like the original version so there'd be more interesting specular highlights, but for now this at least is accurate, colour wise. - Rainwarrior 04:16, 7 August 2006 (UTC)

text: I hacked my raytracer to do some sort of ray-blob intersection (it was surprisingly tricky...), and made a new version of the image using a much curvier (and more specular) model. - Rainwarrior 18:09, 7 August 2006 (UTC
I think that must be R * L instead R * V in specular part of formula? —Preceding unsigned comment added by 87.116.153.207 (talk) 14:22, 28 November 2007 (UTC)
thread_title: Equation

message: See talk:Phong shading for why we are keeping these as two separate pages, and what we are trying to do to make it work better. Dicklyon 17:13, 30 May 2006 (UTC)
thread_title: Phong shading

message: I'm suggesting that we merge this article with Phong shading. While these articles cover two distinct topics, there is a great deal of ambiguity in the specific names for these things in real-world uses. The reflection model is very frequently referred to as a "shading model" (especially in this era of programmable shaders), or sometimes just "shading" or "lighting". I don't think the way we've separated them is appropriate, as the names really aren't so distinct in practice. The concepts are, but not the names. Neither of these articles is particularly long, and I don't think they have a great deal of potential for expansion. I think it would be best to merge the two, perhaps under "phong shading" with appropriate redirects, and clearly explain both the ambiguity of the naming of these two concepts, and the distinction between them. It gives us a good opportunity to explain their relationship as well. - Rainwarrior 03:46, 1 September 2007 (UTC)
replies: text: I'm OK with such a merge.  Merge this one into Phong shading? Dicklyon 04:45, 1 September 2007 (UTC)
replies: text: Done. - Rainwarrior (talk) 21:25, 16 December 2007 (UTC)

text: After a discussion on the talk page of Phong shading, it was decided to split the page again into Phong shading and Phong reflection model. This reflects today's usage in scientific literature and textbooks and it allows other articles (in particular articles on Wikipedia in other languages) to unambigiuously refer to one of the two concepts. --Martin Kraus (talk) 12:41, 7 June 2011 (UTC)
thread_title:  Merge 

message: OK, in order to avoid original research by Kri, I've removed the references to the cross product. I also brought back the discussion of the normalization. Thus, the benefit of requiring less normalization was mentioned twice, I removed the first one, and introduced a sentence to clarify that this normalization benefit is specific to Phong shading (actually, this should say Per-pixel lighting, which in practice is usually Phong shading; feel bold and change it if you think we should be more precise here). My question now is whether we should leave the discussion of missed highlights by the Lyon approximation. This isn't discussed in the reference, is it? If we don't have a reference, we should remove it. (It doesn't matter whether it is true or not.) --130.225.198.196 (talk) 08:21, 9 June 2011 (UTC)
replies: text: Since no one commented on it, I was bold and implemented all these suggestions (and also replaced x by (1 - beta lambda) for clarity; remember: lambda and beta are already new variables; thus, x introduces another level of new indirect definitions which might be difficult to read for the general reader). --Martin Kraus (talk) 17:54, 10 June 2011 (UTC)
replies: text: Looks mostly OK; I added a bit about the approximation's relative insensitivity to normalization error.  The idea about interpolating the D vector seems like a good one, but I don't recall whether I or anyone has tried it.  Does it have a source?  Dicklyon (talk) 19:26, 10 June 2011 (UTC)
replies: text: Oh, OK, I thought it was in the paper but if it isn't, then it is probably original work by Kri. I removed it. I'm not sure how relevant it is: when using a normal map, R would have to be computed per fragment; thus, the method doesn't apply. A problem of the method is that for the correct computation of D, the interpolated values of R and V have to be normalized again per fragment before the difference is computed, and that's of course not possible if D has been computed per vertex. The result is (as Kri pointed out in a long removed paragraph) that the highlight might be missed. Thinking about it, it might be better to compute D = R - (R.V)V per vertex (with normalized R and V) because this guarantees that the highlight is caught if this D is computed per vertex and V is constant and it might work well enough if V is almost constant. (Of course, when L is constant then one should compute D = R - (R.L)L .) But, OK, I've got no time to go that deep into research on optimizations of rendering specular highlights. Maybe Kri can work on it. --Martin Kraus (talk) 01:01, 11 June 2011 (UTC)
replies: text: Well, I bet the D interpolation would work without any normalizing per pixel, as an approximation.  But, as I said, I haven't tried it.  Maybe I can recreate my old code from the paper and modify it to try it.  Dicklyon (talk) 01:11, 11 June 2011 (UTC)
replies: text: OK. I'll take the bet! :) Actually, Kri has explained it very well. Imagine (normalized) V to be constant. Let the (normalized) R vectors at the vertices of a triangle point in different directions, such that the V direction falls into a convex combination of the R vectors (the direction intersects the triangle spanned by the three R vectors). Because of the normalization the interpolated R vector will always be shorter than V and therefore the length of D will never be 0 (the interpolation plane of D doesn't contain the origin, as Kri put it). But I guess one of us has to test it, to decide the bet... --Martin Kraus (talk) 01:19, 11 June 2011 (UTC)

text: Well, I tried my idea, and it turned out that it's a very bad idea. Let's forget about it as fast as possible. ;) I tested the situation I was thinking about: orthographic view (constant V) with large triangles, such that the highlight is between vertices; shineness  = 20; R and V are always normalized in the vertex shader. Results: computing D = R - V in the vertex shader misses the highlight (highlight is way too weak as Kri observed); same effect if D = R - V is computed in the fragment shader without normalization of R and V in the fragment shader. Computing D = R - V in the fragment shader from normalized interpolated R and V gives nice full highlight. Thus, I think you lost your bet. But then I realized that Kri's idea of D = R x V produces D vectors on a plane orthogonal to V, i.e. it should include the origin, i.e. guarantee to catch the highlight if V is constant. And in fact: Kri's approximation D = R x V in the vertex shader works very good (highlight has the right intensity but is a bit larger). Same result with Kri's approximation D = R x V computed from interpolated R and V in the fragment shader without normalization. With normalization in the fragment shader it produces the same (smaller) highlight as D = R - V with normalization in the fragment shader. Kri: you might be on to something (unless someone published this previously, I didn't check the literature). --Martin Kraus (talk) 02:39, 11 June 2011 (UTC)
replies: text: Checking the shader again I realized that the view vector is actually not constant since my shader just computes the difference from vertex position to camera position in any case. However, the R vector is constant since I was using a flat plane with parallel normal vectors and a directional light source. Doing some more testing with point light sources and perspective projection revealed a couple of strange behaviors (in particular inconsistencies between Unity's interpolation in the scene view and the game view which hit the method of computing D = R - V in the scene view in the case of perspective projection and in the game view in the case of orthographic projection; actually it is weird and I don't understand what's going on). Kri's method of computing D = R x V in the vertex shader appears to be more robust in general; however, more research would be necessary, as they say when they want to have more funding. :) --Martin Kraus (talk) 10:41, 11 June 2011 (UTC)

text: As to the D = R - L, I think it doesn't matter which of the two vectors get mirrored (viewpoint or light) to compare with the other.  Probably that alternative should be briefly mentioned.  I just checked my paper and was reminded that reflecting the L vector is more work when there are multiple lights.  Dicklyon (talk) 19:28, 10 June 2011 (UTC)
replies: text: True. That optimization is applicable in any case; thus, it should be mentioned before the whole technique. Makes me wonder why the Phong model is usually formulated in the other way. --Martin Kraus (talk) 01:01, 11 June 2011 (UTC)

text: The Householder transformation does perform a reflection (see the article) and was what I used when deriving the expression for R, although I negated L before transforming it (which I maybe should have mentioned) to indicate the direction of the light instead of the direction to the light source. --Kri (talk) 16:36, 14 June 2011 (UTC)

text: Looking at the article history, I see that I did mention that L was negated before the transformation. I'm restoring the previous version of the paragraph. --Kri (talk) 17:45, 14 June 2011 (UTC)

text: On the other hand, the link to Specular reflection#Direction of reflection that is currently in the article works too for explaining why the expression looks as it does. --Kri (talk) 18:36, 14 June 2011 (UTC)
thread_title:  Rewriting of the approximation section 

message: I am currently writing a 3D renderer using Phong shading. I have just wasted two days of work time as a direct result of this page violating Wikipedia's "No Original Research" policy. The approximation section, at the time of writing, contains the following:
    Furthermore, the value \lambda can be approximated as \lambda = (\hat{R}_m - \hat{V})\cdot(\hat{R}_m - \hat{V}) / 2, or as \lambda = (\hat{R}_m \times \hat{V})\cdot(\hat{R}_m \times \hat{V}) / 2. The latter is much less sensitive to normalization errors in \hat{R}_m and \hat{V} than Phong's dot-product-based \lambda = 1 - \hat{R}_m \cdot \hat{V} is, and practically doesn't require \hat{R}_m and \hat{V} to be normalized except for very low-resolved triangle meshes.
The former of these two approximations is the one cited in Lyon's (excellent) paper which is referenced for this section.
The latter claim, regarding \lambda = (\hat{R}_m \times \hat{V})\cdot(\hat{R}_m \times \hat{V}) / 2. is not mentioned as an approximation in Lyon's 1993 paper anywhere. It appears to be original research added by editor Kri (25-Aug-2015) over 4 years after the discussion on this talk page resolved to remove his original research from the page.
This approximation and its associated claims must be sourced with an appropriate reference which contains the derivation of the approximation and derivation of the claims about requiring no vector normalization.
If cited sources are not forthcoming then I will remove this sentence from the article.
--Ipeakiwi (talk) 23:32, 9 April 2022 (UTC)
thread_title:  "No Original Research" policy must be observed