From: Rouben Rostamian <rostamian@um...>  20010124 22:27:19

Brian, thanks for your comments about Mesa's scaling routines. Re your remark: > Also note that the regular GL_NORMALIZE operation isn't always > going to help with nonuniform scales either. With shapes like > cylinders and cubes it just happens to do the job. But with other > objects a nonuniform scale is going to transform normal vectors in > a way which is not consistent with the underlying surface geometry. The correct transformation of normals under arbitrary scaling should not be hard to implement in Mesa. I know how to do it mathematically, but I don't know enough about Mesa's internals to write a patch for its code. When we transform the space with an arbitrary linear mapping P : R^3 > R^3, i.e., y = P x, normals to surfaces transform according to: N'(y) = P' N(x) where N(x) is the old normal, N'(y) is the new normal, and P' = inverse of transpose of P Does GL_NORMALIZE apply this formula correctly? Important: 1. In general N'(y) and N(x) are not parallel! 2. In general N'(y) is not of unit length. Normalize by dividing it by its own length. > The behaviour with Mesa 3.2, 3.2.1, 3.3, 3.4, and 3.5 appears > identical. With Mesa 3.1, however, the results are different > but I'm not sure it can be called better or worse. It may > actually be that Mesa 3.1 was broken. I don't think "better" or "worse" are the proper adjectives, since right or wrong is not a matter of degrees :) Actually, the behavior of Mesa3.4 is correct and Mesa3.1 is wrong. For a simple demo program which I mentioned in my previous post, I can analytically calculate the exact location of the highlight. Mesa3.4 puts the highlight in the theoretically correct place. Mesa3.1's is off quite a bit. But after the scene is scaled, both highlight are wrong :(  Rouben Rostamian <rostamian@...> 
From: Brian Paul <brianp@va...>  20010125 00:13:27

Rouben Rostamian wrote: > > Brian, thanks for your comments about Mesa's scaling routines. > Re your remark: > > > Also note that the regular GL_NORMALIZE operation isn't always > > going to help with nonuniform scales either. With shapes like > > cylinders and cubes it just happens to do the job. But with other > > objects a nonuniform scale is going to transform normal vectors in > > a way which is not consistent with the underlying surface geometry. > > The correct transformation of normals under arbitrary scaling should > not be hard to implement in Mesa. I know how to do it mathematically, > but I don't know enough about Mesa's internals to write a patch for > its code. > > When we transform the space with an arbitrary linear mapping > P : R^3 > R^3, i.e., y = P x, normals to surfaces transform > according to: > > N'(y) = P' N(x) > > where N(x) is the old normal, N'(y) is the new normal, and > > P' = inverse of transpose of P > > Does GL_NORMALIZE apply this formula correctly? Yes, that's what the OpenGL spec calls for. I believe the transpose is just a technicality of whether you represent normals as row or column vectors in the expression. > Important: > 1. In general N'(y) and N(x) are not parallel! > 2. In general N'(y) is not of unit length. Normalize > by dividing it by its own length. > > > The behaviour with Mesa 3.2, 3.2.1, 3.3, 3.4, and 3.5 appears > > identical. With Mesa 3.1, however, the results are different > > but I'm not sure it can be called better or worse. It may > > actually be that Mesa 3.1 was broken. > > I don't think "better" or "worse" are the proper adjectives, > since right or wrong is not a matter of degrees :) > > Actually, the behavior of Mesa3.4 is correct and Mesa3.1 is wrong. > > For a simple demo program which I mentioned in my previous post, > I can analytically calculate the exact location of the highlight. > Mesa3.4 puts the highlight in the theoretically correct place. > Mesa3.1's is off quite a bit. > > But after the scene is scaled, both highlight are wrong :( It's been a long time since I worked through the arithmetic but I seem to recall that transforming the normal by the transpose of the modelview's inverse still isn't good enough to correctly transform a surface normal when the modelview matrix has a non uniform scale. That is, the transformed normal may not be exactly perpindicular to the surface, as it was before the scale. If I get a few minutes tonight I'll try going through the math by hand to refresh my memory on this. Maybe someone else here has an authoritive answer. Brian 