Re: [PyOpenGL-Users] glNormal3f not working for me

[Mike C. F. <mcf...@vr...>]

McTaggart, Kevin wrote:
> When drawing a square, a call to glNormal3f doesn't appear to affect how
> the square is drawn.  I'm trying to get a coloured front and dark back
> by using the following:
>
> 	glColorMaterial(GL_FRONT_AND_BACK, GL_EMISSION)
> 	glPolygonMode(GL_FRONT, GL_FILL)
> 	glPolygonMode(GL_BACK, GL_LINE)
> 	glColor3f(0.0, 1.0, 0.0)	
> 	glBegin(GL_POLYGON)
> 	glNormal3f(0.0, -1.0, 0.0) # Doesn't appear to have any
> influence
> 	glVertex3f(1.0, -1.0, -1.0)           
> 	glVertex3f(1.0, -1.0, 1.0)          
> 	glVertex3f(-1.0, -1.0, 1.0)          
> 	glVertex3f(-1.0, -1.0, -1.0)         
> 	glEnd()                             
>
> It appears that calling glNormal3f has no influence on which is the
> front or back, and that I have to rearrange the order in which vertices
> are called (clockwise versus counter-clockwise).  Any hints on how to
> get glNormal3f to influence which is front and back?  
>   
AFAIK this is working correctly.  That is, the "front" and "back" faces 
of a polygon are determined by winding rules, not normals.  You can 
reverse the direction by setting the winding rule to CCW or CW, but I 
don't *think* you can make it use normals... after all, a polygon can 
have a different normal at every vertex, one pointing backward, another 
forward, then how do you decide which is "back" and which is "front".

I would imagine you might be able to write a shader program that 
implements the rules for you so that it *looks* like the normals are 
used in your situation, but I don't think you can readily do it in 
general OpenGL, as the engine is going to look at the front/back status 
long before it gets around to lighting calculations (I'm guessing, but 
that would make sense to me).

HTH,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com