If you would like to do something like that, the vertex shader allows you to read the z-values of vertices. You can then set up a variable which is sent from the vertex shader to the fragment shader, and the fragment shader can use this variable to decide on whether or not to change the colour of the current pixels.

It might be important to note that pixel values are interpolated between vertices. So if one vertex has a z-value of -10 and we tell the pixels for that vertex to be red, and the next vertex has a z-value of -20 (both for the same geometry), and we tell the pixels for that vertex to be green, then we will see a smoothing between red and green.

While we have full control over our pixels, we can’t access them straight on an x,y basis and say, I want this pixel at this location, to be this. The pixel shader is applied to geometry, and the pixels created by the geometry are what are manipulated.

Cheers,
Swiftless

I have followed the 5 GLSL tutes uptill now, but I am unable to understand that, how have we achieved per pixel/ vertex effects, I mean we have called our shader program inside the ‘display’ function and this will update per frame. Thus the code in shader program will affect each and every pixel/vertex in same way. How have we achieved control on each vertex/pixel?
How can we in same run, say change color of few pixels to red and few white depending on their z values?

I see what you mean, but I stick by my position it call it position to keep the transition simple from the fixed function mode. But I should explain this better when I do a rewrite of the tutorial eventually. I’m pretty sure I explain it on the OpenGL Tips page, but that is a bit of a round-about trip. Also, it’s not the fact that it’s dotted and normalized that makes it a direction. You do the same calculations for a position light (It shoots out in all directions). It’s just a minor change in the rest of your code to switch from positional to directional in appearance.

I’m not sure you understand what I meant in regard to the number of variable fetches.

“As for varying variables, it is not always optimal to do all your lighting calculations in the fragment shader this lets us offload some parts to the vertex shader.”

For example, you do the dot product calculation. If you do it per-vertex, you may have 1000 vertices and this means 1000 dot product calculations, as opposed to possibly 1000×1000 calculations if you do it on a per-pixel basis. Yes, there is a difference in quality, this is per-vertex lighting compared to per-pixel lighting, but it’s a valid example of the speed difference.

“This also saves us reading the variable every pixel from OpenGL, we can read it per vertex which can save quite a few fetches. ”

Take bump mapping vs displacement mapping. Either way you have a texture read. But in the vertex shader, you only have one texture fetch per vertex, as opposed to a texture fetch every pixel.

These examples are more on the extreme differences side, but it shows the point I am trying to make clearly.

Just a note on what you mentioned. Uniforms vs Varyings in regard to speed. Uniforms are passed from system memory to GPU memory, this has a MUCH higher cost associated with it compared to a varying variable which is created on the GPU and requires no passing around in memory.

I’d like to know where the information is coming from that the more varying variables you have, the less vertices you can have. Vertex output relies on the hardware capability, not the amount of varying variables you have. Imagine the kind of trouble geometry shaders and tesselation engines would run into if that was the case, where you can effectively output several times the number of incoming vertices.

Cheers,
Swiftless

As for the cost of reading uniforms in a fragment shader, that simply doesn’t exist. Reading uniforms costs just as much as reading varyings.

Also, passing varyings has a very real cost associated with it. It makes the per-output vertex data bigger, which means that per-output vertex data takes up more room in the post-T&L cache. Which means you can have fewer vertices in the post T&L cache. Which slows things down.

The cost of reading a uniform doesn’t compare to the cost of an additional varying.

While your comments have a point, I call it vertex_light_position because OpenGL refers to it as light position. Also, it depends on the type of light, if you have a point light, it has a position and no direction while a directional light is opposite and has a direction but no position.

As for varying variables, it is not always optimal to do all your lighting calculations in the fragment shader this lets us offload some parts to the vertex shader. This also saves us reading the variable every pixel from OpenGL, we can read it per vertex which can save quite a few fetches.

Thanks,
Swiftless

Also, there’s no reason to pass it as a varying, since it doesn’t change. It’s just the light direction accessed from the OpenGL variables. Which the fragment shader can access just as well as the vertex shader.