Proper Per Fragment Lighting - need help

Hi, I´m new here and to Shading Languages also.
I tried to write a per fragment lighting - shader, and it´s working quite well - exept the fact that it ´s more smooth shading than phong shading, because the edges of the polgons are brighter than the rest.
The shader is very similar to this one: http://www.clockworkcoders.com/oglsl/tutorial5.htm .
So I thought a bit about that and found out, that it makes sense. I am using the vertex position and the normalvector of the vertex in my fragment shader, not the real fragment data; Code of Vertex Shader:

 
varying vec3 normal;
varying vec3 pos;

void main(void) {
	normal = normalize(gl_NormalMatrix * gl_Normal);
	pos    = vec3(gl_ModelViewMatrix * gl_Vertex);
	gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;	
}
 

But the resulting question is not:
“How can I get the fragment´s position and normal, or how can real per fragment lighting / phong shading can be done?” Not yet.
What irritates me, is a phong shader from ATI or 3D-Labs, don´t know now, which is coded very strange with the gl_TexCoord0 - 7 as variables for the lights ect. instead of uniforms, and which also has these lines in the Vertex Shader:

eyeNormal = gl_NormalMatrix * gl_Normal;
gl_TexCoord[0] = vec4( eyeNormal, 0.0 );

(like i said, they don´t use own uniforms, don´t know why)

It doesn´t need the position, because it´s for directional lights and so doesn´t need the distance between the fragment and the light. (I need the position)
This Shader looks very well!
Is the reason, that the normal the vertex shader gives to the fragment shader is the normal of the fragment, and the position it gives to the fragment shader, is the position of the vertex???
I´m really confused!!!
Excuse my bad English please.
I will be pleased if there will be some answers,
Andreas

I found this thread : http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=11;t=000234
And changed 2 lines (I now normalize the normal in the fragment shader) - and it works fine.
It´s extrem cool that GLSL interpolates the values itself!

Originally posted by splat:
I found this thread : http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_t opic;f=11;t=000234
And changed 2 lines (I now normalize the normal in the fragment shader) - and it works fine.
It´s extrem cool that GLSL interpolates the values itself!

I think you are confused.
GLSL doesn’t interpolate values unless you program it that way.

The hardware is doing a bilinear interpolation of the build in vertex attributes and varying types across the polygon as it gets rasterized.

That’s not something that can be changed. It is hardwired that way.

If you think about it, any unit vector you send down the pipe will get denormalized due to this interpolation.

The only case where it doesn’t is where all the vectors on the poly are pointing in the same direction.

If I´ve understood you right, not GLSL, but the hardware does the interpolation of the built in varyings, and it can´t do this if i normalize them in the vertex shader, because due the interpolation
it wouldn´t be normalized after that?

Partially correct.

GLSL covers some of the vertex and some of the fragment pipeline.

The rest is hardwired as usual. Vertex attributes are bilinear interpolated as usual.

it can´t do this if i normalize them in the vertex shader, because due the interpolation
it wouldn´t be normalized after that?
No, it always interpolates, no matter what you code in your shader.

hardwired = non-programmable and non-overrideable

but when I moved the normalize()-call of the normalvector from the fragment to the vertex shader, I got correct per-fragment-lighting, and before not.
This I don’t understand :frowning:

Linear interpolation of vectors doesn’t preserve unit-length.

a  c  b
\  |  /
 \ | /
  \|/

If a and b are two unit-length vectors which are being interpolated across a triangle, an intermediate vector c = alpha*a + (1-alpha)*b will not be unit-length. So you have to re-normalize.

As an extreme example, think about what happens when a and b point in opposite directions. The length of c will be zero at alpha=0.5.

Now I understand, thanks.
(of course i mean “from vertex to fragmant shader” in my last post)

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.