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: Rouben Rostamian <rostamian@um...>  20030208 10:01:58

Jeff Sawatzky <jtsawatz@...> wrote: > My problem is that glEnable(GL_NORMALIZE) does not seem to work. > When I scale an object down it becomes white because of the specular. > Also, when I play Tux Racer (an opengl game for linux) Tux is all > white. I think this is because the normals are not being normalized > when a nonuniform scale happens even though GL_NORMALIZE is enabled. GL_NORMALIZE has never worked with nonuniform scaling. I submitted a bug report to Sourceforge a couple of years ago along with a demo, but it didn't get anywhere. The problem is difficult to explain if you are not sitting next to the person you are explaining it to. To track down the problem, I looked into Mesa's source code which appeared to be doing the wrong thing with scaling. Digging deeper, however, it turned out that it's not Mesa's fault, really. Mesa is implementing the recommendation of the OpenGL specification. The problem stems from the original specification. As I recall from the time when I looked at this, the OpenGL specification suggests two alternatives for scaling the normals. Alternative 1: This is the faster of the two and is the one that is implemented in Mesa. I don't recall its precise assumptions, but I recall verifying that it gives correct results under uniform scaling. It also gives correct results under certain sorts of nonuniform scaling. E.g., if the faces of the object stay parallel to themselves under scaling. Nonuniform scaling of a cube falls under this category. Alternative 2: This second, slower, alternative allows for arbitrary nonuniform scaling. This one is implemented neither in Mesa nor in SGI's own OpenGL library. The OpenGL specification does not seem to recommend one method over another, thus giving the impression that the two alternative are equivalent. Unfortunately they are not. Ideally there should be a GL_NORMALIZE and another GL_NORMALIZE_EXPENSIVE to let the programmer choose between the two. Right now we have GL_NORMALIZE only. These comments are based on my recollections of reading the Mesa code and the OpenGL specification more than two years ago. I am not aware if things have changed since then.  Rouben Rostamian <rostamian@...> 
From: Carlos Pereira <carlos@pe...>  20030208 17:21:33

I had problems with lights and nonuniform scaling in my app, in versions above Mesa 3.0 (scaling cylinders). These problems disappeared since Mesa 4.0.3 (see the logs explaining what changed for that release) after a bug was tracked down and eventually corrected (apparently involving precompiled lists). Definitely Mesa 5.0 (the latest release) is working fine for me. Of course I dont't know if we are talking about the same thing... Carlos 
From: Rouben Rostamian <rostamian@um...>  20030208 20:03:40

Brian, re your message regarding nonuniform scaling, you wrote: > GL_NORMALIZE computes the magnitude of the normal vector, > then divides the components of the normal by the magnitude. > The result is a unitlengh normal vector, regardless of scale > factors. However, the _direction_ of the normal may not be > correct for nonuniform scales. Mesa/OpenGL can't do anything > about that. So we agree that the _direction_ of the recomputed normal vector is incorrect in general. Well, if that is not a bug, then what is it? What is the use of computing a vector which does not point in the right direction? I don't agree that "Mesa/OpenGL can't do anything about that". Consider a point P on a surface S and let N be the normal to S at P. Suppose that the tangent plane at P looks like this: ax + by + cz = d, therefore the normal vector is N = (a, b, c). OpenGL/Mesa receives the normal vector N from the user. Now suppose that the space is scaled by factors u, v, w in the x, y, z directions. Then the tangent plane transforms to: aux + bvy + cwz = d, which says that the new normal vector is N' = (au, bv, cw) which is easily computable. Compute N' then reduce it to unit length. > I don't see an open bug related to GL_NORMALIZE and I'm not > aware of any known issues with it. My recollection is that you looked into the issue and concluded that Mesa was doing the right thing. The bug report then was marked as closed/resolved.  Rouben Rostamian <rostamian@...> 
From: Brian Paul <brian@tu...>  20030208 22:57:07

Rouben Rostamian wrote: > Brian, re your message regarding nonuniform scaling, you wrote: > > >>GL_NORMALIZE computes the magnitude of the normal vector, >>then divides the components of the normal by the magnitude. >>The result is a unitlengh normal vector, regardless of scale >>factors. However, the _direction_ of the normal may not be >>correct for nonuniform scales. Mesa/OpenGL can't do anything >>about that. > > > So we agree that the _direction_ of the recomputed normal vector is > incorrect in general. Well, if that is not a bug, then what is it? An unfortunate sideeffect of linear algebra. > What is the use of computing a vector which does not point in the > right direction? > > I don't agree that "Mesa/OpenGL can't do anything about that". > Consider a point P on a surface S and let N be the normal to S > at P. Suppose that the tangent plane at P looks like this: > > ax + by + cz = d, > > therefore the normal vector is N = (a, b, c). OpenGL/Mesa > receives the normal vector N from the user. > > Now suppose that the space is scaled by factors u, v, w in the > x, y, z directions. Then the tangent plane transforms to: > > aux + bvy + cwz = d, When we're transforming normals, we don't have individual u, v, w scale factors; we have the modelview matrix. We use the upperleft 3x3 part of the inverse of the modelview matrix to transform the normal. The 3x3 part has rotation factors (and possibly shearing) in addition to the scale factors. Perhaps you can extract the correct u, v, w values out of there but I'm too lazy to go through the arithmetic right now. > which says that the new normal vector is N' = (au, bv, cw) > which is easily computable. Compute N' then reduce it to > unit length. If it's that easy, why didn't OpenGL define that behaviour from day one? I can't remember the details, but I think it's a little harder than that. >>I don't see an open bug related to GL_NORMALIZE and I'm not >>aware of any known issues with it. > > > My recollection is that you looked into the issue and concluded > that Mesa was doing the right thing. The bug report then was > marked as closed/resolved. OK. Brian 
From: Brian Paul <brian@tu...>  20030208 15:30:04

Rouben Rostamian wrote: > Jeff Sawatzky <jtsawatz@...> wrote: > > >>My problem is that glEnable(GL_NORMALIZE) does not seem to work. >>When I scale an object down it becomes white because of the specular. >>Also, when I play Tux Racer (an opengl game for linux) Tux is all >>white. I think this is because the normals are not being normalized >>when a nonuniform scale happens even though GL_NORMALIZE is enabled. > > > GL_NORMALIZE has never worked with nonuniform scaling. I submitted > a bug report to Sourceforge a couple of years ago along with a demo, > but it didn't get anywhere. The problem is difficult to explain > if you are not sitting next to the person you are explaining it to. > > To track down the problem, I looked into Mesa's source code which > appeared to be doing the wrong thing with scaling. > > Digging deeper, however, it turned out that it's not Mesa's fault, > really. Mesa is implementing the recommendation of the OpenGL > specification. The problem stems from the original specification. > > As I recall from the time when I looked at this, the OpenGL > specification suggests two alternatives for scaling the normals. > > Alternative 1: > This is the faster of the two and is the one that is implemented > in Mesa. I don't recall its precise assumptions, but I recall > verifying that it gives correct results under uniform scaling. > It also gives correct results under certain sorts of nonuniform > scaling. E.g., if the faces of the object stay parallel to > themselves under scaling. Nonuniform scaling of a cube falls > under this category. > > Alternative 2: > This second, slower, alternative allows for arbitrary nonuniform > scaling. This one is implemented neither in Mesa nor in SGI's > own OpenGL library. The OpenGL specification does not seem to > recommend one method over another, thus giving the impression > that the two alternative are equivalent. Unfortunately they > are not. Ideally there should be a GL_NORMALIZE and another > GL_NORMALIZE_EXPENSIVE to let the programmer choose between the two. > Right now we have GL_NORMALIZE only. > > These comments are based on my recollections of reading the Mesa > code and the OpenGL specification more than two years ago. I am > not aware if things have changed since then. Here's my two cents: The GL_RESCALE_NORMAL option only works for uniform X/Y/Z scaling. It's a bit faster than GL_NORMALIZE. GL_NORMALIZE computes the magnitude of the normal vector, then divides the components of the normal by the magnitude. The result is a unitlengh normal vector, regardless of scale factors. However, the _direction_ of the normal may not be correct for nonuniform scales. Mesa/OpenGL can't do anything about that. I don't see an open bug related to GL_NORMALIZE and I'm not aware of any known issues with it. Brian 
Sign up for the SourceForge newsletter:
No, thanks