<p>The rasterizer determines, which pixel is rendered depending on vertex positions that come out of the vertex shader. For each rasterized pixel, the rasterizer knows where it lies inside the triangle formed by its three positions. With the known position inside the triangle, the rasterizer can also interpolate the vertex values for each pixel. So it also calculates the interpolated color, in case your vertex shader passes a color down the pipeline. The interpolated value is then provided to the fragment shader. However, the fragment shader can still modify the color before it is finally rendered to the screen.</p>

<blockquote>
  <p>Does that mean rasterizer has access to color attribute</p>
</blockquote>

<p>It has full access to everything that comes out of the vertex shader. A vertex shader must always have a position as output (<code>gl_Position</code>). In some special cases also other outputs are required. However, if your initial vertices had a color, but the color is not passed down the pipeline by the vertex shader, the rasterizer won't produce an interpolated color. It only interpolates each variable/attribute, that comes out of the vertex shader.</p>

<blockquote>
  <p>how is the color attribute passed to the rasterizer, as the inputs for rasterizer are vertices?</p>
</blockquote>

<p>You can define arbitrary outputs in your vertex shader. Even if the initially submitted vertex, did not have a color attribute, you can add a color output in the vertex shader. The data the rasterizer gets per vertex is just the vertex shader outputs. A vertex is a data point containing a position and optional additional values/attributes. So if a vertex has a color attribute, the rasterizer can see it, since it is part of the vertex. </p>

<p>Note that the vertices you pass into the vertex shader and the vertices that come out of it are not the same and might differ.</p>

<blockquote>
  <p>Or is it happening in the fragment shader?</p>
</blockquote>

<p>No, the fragment shader receives already interpolated values as input. But it can decide to pass it directly, ignore it or modify it as you wish. If you just pass it through, you will see the interpolated vertex colors. </p>

<p>Further information can be found <a href="https://www.khronos.org/opengl/wiki/Rendering_Pipeline_Overview" rel="nofollow noreferrer">on this site</a></p>

CC BY-SA 4.0
2020-04-28T12:33:11.067Z
So i understand color is being passed down the graphics pipeline but how would the rasterizer identify the color variable as both vertex and color attributes are passed, especially if they are both defined as varying attributes?
Anu
CC BY-SA 4.0
2020-04-28T13:22:41.353Z
This is what the linker does for you. If you have a vertex shader with the output variables `position`, `color`, and `tex_coord`, then your fragment shader needs the exact same variables as inputs (assuming geometry and tesselation shaders are not used). Otherwise, the linker would complain when you try to link the program. Since the linker takes care of the connection between the variables, the rasterizer does not need to know about the purpose or name of a variable he is interpolating. All he needs to know is where it comes from, which type it is and where the result must be written to.
wychmaster
CC BY-SA 4.0
2020-04-28T13:30:32.053Z
Additionally, `gl_Position` is a required output of a vertex shader. From that, the rasterizer knows the position of each vertex. That is all he needs to perform the rasterization.
wychmaster
CC BY-SA 4.0
2020-04-28T13:46:00.783Z
Imagine the vertex shader passes attributes `a0` and `a1` as `varying`. The fragment shader may set the color based on `a0`, `a1`, some combination `f(a0, a1)`, or just set everything to red. The rasterizer, which executes _before_ the fragment shader has no idea of the eventual color. So how can the rasterizer decide any color? One way could be that it interpolates every attribute that passes through it. But then all that work will go to waste and need to be redone if the fragment shader sets everything to red. Any thoughts on that?
wsaleem
CC BY-SA 4.0
2020-04-28T14:14:59.227Z
The final color you see is determined by the fragment shader. It is whatever you write to `fragColor`(GLSL). The rasterizer just interpolates whatever you pass down the pipeline and does not know what `a0` or `a1` are supposed to be. In the fragment shader, you just get their interpolated values based on their position in the triangle. If you decide to discard those values, the interpolation was pointless, right. It's been a while since I have written my last shaders, but...
wychmaster
CC BY-SA 4.0
2020-04-28T14:18:25.193Z
... as far as I can remember if the compiler figures out, that a variable does not contribute to the output of a shader, it is optimized away. This will lead to a program linkage error since you have an output variable in the vertex shader but no corresponding input in the fragment shader. This should automatically prevent pointless interpolations. As I said, it has been a while. So I might be wrong here.
wychmaster
CC BY-SA 4.0
2020-04-17T11:32:21.197Z
2020-04-17T11:32:21.197Z
wychmaster
<p>I am trying to program my own version of WEBGL graphics pipeline in python, however, I am confused as to where the color interpolation takes place in the pipeline. According to my research, it happens after the rasterizer has calculated the points covered by the primitive. Does that mean rasterizer has access to color attribute, if so, how is the color attribute passed to the rasterizer, as the inputs for rasterizer are vertices? Or is it happening in the fragment shader?</p>

CC BY-SA 4.0
2020-04-17T09:52:15.843Z
The vertex shader usually sets ups any number of "varying" variables which are then passed to the fragment shader, it's these varying variables which get interpolated across the primitive.
PaulHK
CC BY-SA 4.0
2020-04-17T10:17:07.283Z
See the function `triangle` for reference: https://github.com/ssloy/tinyrenderer/blob/master/our_gl.cpp
lightxbulb
CC BY-SA 4.0
2020-04-17T10:45:39.180Z
@PaulHK  so the interpolation uses variables from fragment shader? Then that means it does not happen inside rasterizer but rather in fragment shader?
Anu
CC BY-SA 4.0
2020-04-17T17:28:57.760Z
*Some* part of the interpolation is done outside of the fragment shader, be that interpolation of the actual vertex colours (or texture UVs etc). or it might just be barycentric coordinates which can be used to generate the interpolated values.
Simon F
<interpolation><rasterizer><fragment-shader>
Interpolation in Graphics Pipeline
Anu
# Interpolation in Graphics Pipeline

(Asked by: username_0 on 2020-04-17)

I am trying to program my own version of WEBGL graphics pipeline in python, however, I am confused as to where the color interpolation takes place in the pipeline. According to my research, it happens after the rasterizer has calculated the points covered by the primitive. Does that mean rasterizer has access to color attribute, if so, how is the color attribute passed to the rasterizer, as the inputs for rasterizer are vertices? Or is it happening in the fragment shader?

**Tags:** interpolation, rasterizer, fragment-shader

> **Comments:**
> **username_1**: The vertex shader usually sets ups any number of "varying" variables which are then passed to the fragment shader, it's these varying variables which get interpolated across the primitive.  
> **username_2**: See the function `triangle` for reference: https://github.com/ssloy/tinyrenderer/blob/master/our_gl.cpp  
> **username_0**: @username_1  so the interpolation uses variables from fragment shader? Then that means it does not happen inside rasterizer but rather in fragment shader?  
> **username_3**: *Some* part of the interpolation is done outside of the fragment shader, be that interpolation of the actual vertex colours (or texture UVs etc). or it might just be barycentric coordinates which can be used to generate the interpolated values.  

---

## 1 answers

### Answer by username_4 on 2020-04-17. Score: 2

The rasterizer determines, which pixel is rendered depending on vertex positions that come out of the vertex shader. For each rasterized pixel, the rasterizer knows where it lies inside the triangle formed by its three positions. With the known position inside the triangle, the rasterizer can also interpolate the vertex values for each pixel. So it also calculates the interpolated color, in case your vertex shader passes a color down the pipeline. The interpolated value is then provided to the fragment shader. However, the fragment shader can still modify the color before it is finally rendered to the screen.

> Does that mean rasterizer has access to color attribute

It has full access to everything that comes out of the vertex shader. A vertex shader must always have a position as output (`gl_Position`). In some special cases also other outputs are required. However, if your initial vertices had a color, but the color is not passed down the pipeline by the vertex shader, the rasterizer won't produce an interpolated color. It only interpolates each variable/attribute, that comes out of the vertex shader.

> how is the color attribute passed to the rasterizer, as the inputs for rasterizer are vertices?

You can define arbitrary outputs in your vertex shader. Even if the initially submitted vertex, did not have a color attribute, you can add a color output in the vertex shader. The data the rasterizer gets per vertex is just the vertex shader outputs. A vertex is a data point containing a position and optional additional values/attributes. So if a vertex has a color attribute, the rasterizer can see it, since it is part of the vertex.

Note that the vertices you pass into the vertex shader and the vertices that come out of it are not the same and might differ.

> Or is it happening in the fragment shader?

No, the fragment shader receives already interpolated values as input. But it can decide to pass it directly, ignore it or modify it as you wish. If you just pass it through, you will see the interpolated vertex colors.

Further information can be found [on this site](https://www.khronos.org/opengl/wiki/Rendering_Pipeline_Overview)

> **Comments:**
> **username_0**: So i understand color is being passed down the graphics pipeline but how would the rasterizer identify the color variable as both vertex and color attributes are passed, especially if they are both defined as varying attributes?  
> **username_4**: This is what the linker does for you. If you have a vertex shader with the output variables `position`, `color`, and `tex_coord`, then your fragment shader needs the exact same variables as inputs (assuming geometry and tesselation shaders are not used). Otherwise, the linker would complain when you try to link the program. Since the linker takes care of the connection between the variables, the rasterizer does not need to know about the purpose or name of a variable he is interpolating. All he needs to know is where it comes from, which type it is and where the result must be written to.  
> **username_4**: Additionally, `gl_Position` is a required output of a vertex shader. From that, the rasterizer knows the position of each vertex. That is all he needs to perform the rasterization.  
> **username_5**: Imagine the vertex shader passes attributes `a0` and `a1` as `varying`. The fragment shader may set the color based on `a0`, `a1`, some combination `f(a0, a1)`, or just set everything to red. The rasterizer, which executes _before_ the fragment shader has no idea of the eventual color. So how can the rasterizer decide any color? One way could be that it interpolates every attribute that passes through it. But then all that work will go to waste and need to be redone if the fragment shader sets everything to red. Any thoughts on that?  
> **username_4**: The final color you see is determined by the fragment shader. It is whatever you write to `fragColor`(GLSL). The rasterizer just interpolates whatever you pass down the pipeline and does not know what `a0` or `a1` are supposed to be. In the fragment shader, you just get their interpolated values based on their position in the triangle. If you decide to discard those values, the interpolation was pointless, right. It's been a while since I have written my last shaders, but...  
> **username_4**: ... as far as I can remember if the compiler figures out, that a variable does not contribute to the output of a shader, it is optimized away. This will lead to a program linkage error since you have an output variable in the vertex shader but no corresponding input in the fragment shader. This should automatically prevent pointless interpolations. As I said, it has been a while. So I might be wrong here.  

---

