1
\$\begingroup\$

I have 2 versions of a program. The only difference being that in one, a geometry shader is compiled and in the other it is not.

In all other regards both programs are identical, character by character. The only change is whether there is a geometry shader in the main shading program or not.

The geometry shader in question is:

#version 450

layout (triangles) in;
layout (triangle_strip, max_vertices=136) out;

uniform  float height = 128;

void main()
{
   for(int layer = 0; layer < int(height); layer++)
    {
        gl_Layer = layer; // built-in variable that specifies to which layer we render.
        for(int i = 0; i < 3; i++) // for each triangle's vertices
        {
            vec4 pos = gl_in[i].gl_Position;
            pos.z = 0.5;

            gl_Position = pos;
            EmitVertex();
        }    
        EndPrimitive();
    }
}

I am checking for compilation errors. As a matter of fact if I were to add a random string to the shader I will get a full explanation of where the error occurred (i.e a message saying that the compiler did not understand the random string).

I am also calling glError() extensively to check when something goes wrong and it does not return an error upon compilation but it does return an error ont eh first opengl operation attempted after it.

If I comment everything in the sahder so that it looks like an empty function:

void main(){}

The error still happens. But, once again not having the shader causes no issue.

\$\endgroup\$
  • 2
    \$\begingroup\$ Where are you getting invalid operation errors? \$\endgroup\$ – Nicol Bolas Mar 9 '18 at 1:26
  • \$\begingroup\$ I just figured out what the issue is, there was a variable being passed using the keywords "in" and "out' form the vertex shader to the fragment shader that would break the program. Removing said variable fixes the issue. I am not sure if I should fully delete the question or modify it to ask why this is the case. \$\endgroup\$ – Makogan Mar 9 '18 at 1:40
  • 2
    \$\begingroup\$ You didn't answer my question. OpenGL errors do not spring up out of holes in the ground. Where did this one come from? Also, compilation and linking don't cause OpenGL errors (not for GLSL reasons, at least). So if you're using that to determine if compilation succeeded or failed, you're doing it wrong. \$\endgroup\$ – Nicol Bolas Mar 9 '18 at 1:49
  • 2
    \$\begingroup\$ You still haven't answered my question yet. What OpenGL function do you call that causes the invalid operation error? Also, I assume you're using the appropriate function for program linking error detection too, right? \$\endgroup\$ – Nicol Bolas Mar 9 '18 at 4:14
  • 2
    \$\begingroup\$ If that's true, then either every attempt to touch the program is written incorrectly, or you did not properly load, compile, and link it correctly. And considering the fact that OpenGL requires that inputs to a stage match to outputs from the previous one, and if you don't do that, the implementation must give you a linker error. Since a GS that consists solely of void main(){} violates many linker rules, yet you get no linker errors, I strongly suggest you look at your linking code. \$\endgroup\$ – Nicol Bolas Mar 9 '18 at 5:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.