Passing Colour through shaders

Previously with only Vertex and Fragment shaders I have typically passed the current OpenGL colour through thus:

Vertex Shader : gl_FrontColor = gl_Color;
Fragment Shader : gl_FragColor = gl_Color;

I’ve always thought it’s a bit counterintuitive as if you don’t do the ‘pass-through’ in the Vertex shader I understood that gl_Color has no value in the fragment shader. So the two identical labels gl_Color mean different things…

Anyway, perhaps I am misunderstanding something because now with Geometry shaders the best I can get the compiler to accept is this…

Vertex Shader : gl_FrontColor = gl_Color;
Geometry Shader : I can re-define gl_FrontColor again if I wish, or not.
(But I cannot access gl_Color in the Geometry Shader.)
Fragment Shader : gl_FragColor = gl_Color;

However, for some reason whatever I do now, the colour is not getting to the fragment shader.

What am I missing? Thanks. :slight_smile:

Note : I have fixed this problem by using my own colour variables, but am curious as to how the FF pipeline maps to what I should be doing, mainly to keep some backwards compatibility on pre shader4 cards in my shader code…

It is the same thing for me. If I use:

Fragment Shader : gl_FragColor = gl_Color;

It does not work so I have to use a Varying to pass the color from VS to FS… why does it happen? is empty in FS? why is available then? is fixed in the last version of FS?

I have curiosity too.

I don’t know whether anyone in the ARB ever considered this case, and i am pretty sure, that they don’t really care about it, because you are supposed to use generic vertex attributes anyway.


I dont follow you with the vertex attributes, if the color dont change for each vertex, why is it supossed I should use them? why dont they care about it? If they dont, why do they allow to use it? Could you explain a bit more this topic?


I can understand this being a victim of the problem of running the programmable pipeline API in a state of constant flux / development alongside the aging FF API. Totally. Something has to give at some point, and it’s not a head-scratcher to solve…

And I guess in a purist sense people could be expected to handle this using their own vertex attributes, uniforms etc. After all this is how Capagris and I both solved this ‘problem’ for ourselves…

It is however still useful to use FF stuff for quick and easy prototyping when developing. Certainly less effort to use some of the FF stuff while it is still there than setup attributes / uniforms for everything all of the time. But I accept that is where we are going. ALso some of us are integrating things like Geometry shaders into older code bases which are not going to get rewritten anytime soon, where it may be more convenient to be able to ‘patch-in’ some of the more global FF attributes rather then re-factor…

Still, in the present, it seems a little shortsighted and confusing to have various FF attributes / commands which are still valid and yet do undefined things. Personally until the old GL FF stuff is no longer part of the spec I think it’s reasonable to view this oversight as such at best, and a bug at worst. Just my opinion. :slight_smile:

Furthermore several Geometry shader examples out there have ‘Hello World’ source which does indeed suggest passing through the colour in the way I posted originally!

I was doing some further reading on this and during my second read through the full spec I found this…

Geometry Shader Inputs

The OpenGL Shading Language specification describes the set of built-in
variables that are available as inputs to the geometry shader. This set
receives the values from the equivalent built-in output variables written
by the vertex shader. These built-in variables are arrays; each element in
the array holds the value for a specific vertex of the input
primitive. The length of each array depends on the value of the input
primitive type, as determined by the program object value
GEOMETRY_INPUT_TYPE_EXT, and is set by the GL during link. Each built-in
variable is a one-dimensional array, except for the built-in texture
coordinate variable, which is a two- dimensional array. The vertex shader
built-in output gl_TexCoord[] is a one-dimensional array. Therefore, the
geometry shader equivalent input variable gl_TexCoordIn[][] becomes a two-
dimensional array. See the OpenGL Shading Language Specification, sections
4.3.6 and 7.6 for more information.
The built-in varying variables gl_FrontColorIn[], gl_BackColorIn[],
gl_FrontSecondaryColorIn[] and gl_BackSecondaryColorIn[] hold the
per-vertex front and back colors of the primary and secondary colors, as
written by the vertex shader to its equivalent built-in output variables.
The built-in varying variable gl_TexCoordIn[][] holds the per- vertex
values of the array of texture coordinates, as written by the vertex
shader to its built-in output array gl_TexCoord[].
The built-in varying variable gl_FogFragCoordIn[] holds the per- vertex
fog coordinate, as written by the vertex shader to its built- in output
variable gl_FogFragCoord. 

slaps head

You can basically use gl_FrontColorIn[0] and copy it once to gl_FrontColor at the top of a Geometry shader to affect all subsequent vertices…

That cleared a lot of things up for me. So I am posting it here for others.

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