<p>So as @Thomas mentioned, the issue seems to be the fact that I was passing &quot;GL_LINE_STRIP&quot; instead of &quot;GL_LINE_STRIP_ADJACENCY&quot; to the glDrawArrays() call. Apparently, &quot;GL_LINE_STRIP_ADJACENCY is needed when there is a geometry shader involved (&quot;https://www.khronos.org/opengl/wiki/Primitive#Adjacency_primitives&quot;).</p>
<p>Edit: Originally I meant to use &quot;GL_LINES_ADJACENCY&quot; and somehow got mixed up with &quot;GL_LINE_STRIP&quot;. Don't code at 5am.</p>

CC BY-SA 4.0
2023-11-29T19:19:39.233Z
"Apparently, "GL_LINE_STRIP_ADJACENCY is needed when there is a geometry shader involved" that's not 100% correct... You need the ADJACENCY because your GS wants to operate on 4 input vertices. When only working on 2 input vertices within the GS you can simply use GL_LINE_STRIP
Thomas
CC BY-SA 4.0
2023-11-28T19:04:37.513Z
2023-12-05T02:22:33.950Z
2023-12-05T02:22:33.950Z
TFamIdoing
<p>The geometry shader should look something like this: the fragment shader should be changed to match.</p>
<pre><code>#version 460 core
layout (lines_adjacency) in; // converting lines to triangles?
layout (triangle_strip, max_vertices = 4) out;

in VS_OUT
{
    vec2 position;
    vec3 color;
} gs_in[];

// tl, tr, bl, br
out GS_OUT
{
    // vec2 pos; the fragment shader isn't using it so why output it?
    vec3 rgb;  
} gs_out;

void main() {
    for (int i = 0; i &lt; 4; i++)
    {
        //gs_out.pos = gs_in.position; -- don't output it if it isn't being used

        gs_out.rgb = gs_in[i].color;
        gl_Position = gl_in[i].gl_Position;
        EmitVertex();
    }
    EndPrimitive();
}
</code></pre>

CC BY-SA 4.0
2023-12-12T12:49:58.973Z
Can you add some more explanation why this would solve the OP's problem and what issues with his shader it actually fixes? Because right now I can't really see how this is related to his issues (and "use this code instead" doesn't exactly help with that). The output might have been superflous in his example, but that's not an error (and any reasonable shader compiler would do what you did internally anyway). Also changing the output from an array to a single variable changes his entire algorithm. How does that help?
Christian Rau
CC BY-SA 4.0
2023-11-28T13:22:13.720Z
2023-11-28T13:22:13.720Z
pmw1234
<p>So I seem to have some trouble getting a geometry shader working with &quot;glDrawArrays(GL_LINE_STRIP, 0, 4);&quot;. When I omit the geometry shader and make some minor variable changes, the vertex and fragment shader outputs the line strips properly, but adding the geometry shader somehow doesn't output anything (there doesn't seem to be any compile issues).</p>
<p>I have also tried modifying the geometry shader to be a passthrough shader, and even that fails to output anything.</p>
<p>Code attached below. Intention of the pipeline is to interpolate 4 colors across corners of a quad given as 4 vertices, so geometry shader is for coalescing data. Note that &quot;pos&quot; in &quot;GS_OUT&quot; in the fragment shader is unused right now because code has been heavily modified after testing.</p>
<p>Vertex Shader:</p>
<pre><code>#version 460 core
in vec2 in_Position;
in vec3 in_Color;

out VS_OUT
{
    vec2 position;
    vec3 color;
} vs_out;

void main(void)
{
    vs_out.position = in_Position;
    vs_out.color = in_Color;
    gl_Position = vec4(in_Position, 0.0, 1.0);
}
</code></pre>
<p>Geometry Shader:</p>
<pre><code>#version 460 core
layout (lines_adjacency) in;
layout (triangle_strip, max_vertices = 4) out;

in VS_OUT
{
    vec2 position;
    vec3 color;
} gs_in[4];

// tl, tr, bl, br
out GS_OUT
{
    flat vec2 pos[4];
    flat vec3 rgb[4];
} gs_out;

void main() {
    for (int i = 0; i &lt; 4; i++)
    {
        for (int j = 0; j &lt; 4; j++)
        {
            gs_out.pos[j] = gs_in[j].position;
            gs_out.rgb[j] = gs_in[j].color;
        }
        gl_Position = gl_in[i].gl_Position;
        EmitVertex();
    }
    EndPrimitive();
}
</code></pre>
<p>Fragment Shader:</p>
<pre><code>#version 460 core

precision highp float;

// tl, tr, bl, br
in GS_OUT
{
    flat vec2 pos[4];
    flat vec3 rgb[4];
} fs_in;

out vec4 fragColor;

void main(void)
{    
    fragColor = vec4(fs_in.rgb[0], 1.0);
}
</code></pre>

CC BY-SA 4.0
2023-11-27T10:20:34.850Z
I don't think gs_in should have the size of the input. Try changing it to gs_in[] instead of gs_in[4].
Reynolds
CC BY-SA 4.0
2023-11-27T17:35:28.463Z
@Reynolds While there might always be drivers doing weird things, it should certainly be allowed to have the size of the input, even if it doesn't need to. That should also be a compile error if it doesn't (or the size is wrong).
Christian Rau
CC BY-SA 4.0
2023-11-28T07:38:36.620Z
Have you checked if face culling is turned off? Maybe the triangle back face points towards the camera
Thomas
CC BY-SA 4.0
2023-11-28T07:44:17.077Z
In your draw call, try to exchange GL_LINE_STRIP by GL_LINE_STRIP_ADJACENCY. Because then the geometry shader loads 4 vertices. Otherwise the vertex shader output doesn't fit the geometry shader input
Thomas
CC BY-SA 4.0
2023-11-28T07:49:54.347Z
Check out https://www.khronos.org/opengl/wiki/Geometry_Shader chapter "Primitive in/out specification"
Thomas
CC BY-SA 4.0
2023-11-28T19:00:20.043Z
@Thomas bit late to respond, but yeah, seems like the issue is that I should be passing "GL_LINE_STRIP_ADJACENCY" to the GlDrawArrays() call; thank you everyone for your inputs
TFamIdoing
<glsl><geometry-shader>
Geometry Shader Not Working
TFamIdoing
# Geometry Shader Not Working

(Asked by: username_0 on 2023-11-26)

So I seem to have some trouble getting a geometry shader working with "glDrawArrays(GL\_LINE\_STRIP, 0, 4);". When I omit the geometry shader and make some minor variable changes, the vertex and fragment shader outputs the line strips properly, but adding the geometry shader somehow doesn't output anything (there doesn't seem to be any compile issues).

I have also tried modifying the geometry shader to be a passthrough shader, and even that fails to output anything.

Code attached below. Intention of the pipeline is to interpolate 4 colors across corners of a quad given as 4 vertices, so geometry shader is for coalescing data. Note that "pos" in "GS\_OUT" in the fragment shader is unused right now because code has been heavily modified after testing.

Vertex Shader:

```
#version 460 core
in vec2 in_Position;
in vec3 in_Color;

out VS_OUT
{
    vec2 position;
    vec3 color;
} vs_out;

void main(void)
{
    vs_out.position = in_Position;
    vs_out.color = in_Color;
    gl_Position = vec4(in_Position, 0.0, 1.0);
}

```

Geometry Shader:

```
#version 460 core
layout (lines_adjacency) in;
layout (triangle_strip, max_vertices = 4) out;

in VS_OUT
{
    vec2 position;
    vec3 color;
} gs_in[4];

// tl, tr, bl, br
out GS_OUT
{
    flat vec2 pos[4];
    flat vec3 rgb[4];
} gs_out;

void main() {
    for (int i = 0; i < 4; i++)
    {
        for (int j = 0; j < 4; j++)
        {
            gs_out.pos[j] = gs_in[j].position;
            gs_out.rgb[j] = gs_in[j].color;
        }
        gl_Position = gl_in[i].gl_Position;
        EmitVertex();
    }
    EndPrimitive();
}

```

Fragment Shader:

```
#version 460 core

precision highp float;

// tl, tr, bl, br
in GS_OUT
{
    flat vec2 pos[4];
    flat vec3 rgb[4];
} fs_in;

out vec4 fragColor;

void main(void)
{    
    fragColor = vec4(fs_in.rgb[0], 1.0);
}

```

**Tags:** glsl, geometry-shader

> **Comments:**
> **username_1**: I don't think gs_in should have the size of the input. Try changing it to gs_in[] instead of gs_in[4].  
> **username_2**: @username_1 While there might always be drivers doing weird things, it should certainly be allowed to have the size of the input, even if it doesn't need to. That should also be a compile error if it doesn't (or the size is wrong).  
> **username_3**: Have you checked if face culling is turned off? Maybe the triangle back face points towards the camera  
> **username_3**: In your draw call, try to exchange GL_LINE_STRIP by GL_LINE_STRIP_ADJACENCY. Because then the geometry shader loads 4 vertices. Otherwise the vertex shader output doesn't fit the geometry shader input  
> **username_3**: Check out https://www.khronos.org/opengl/wiki/Geometry_Shader chapter "Primitive in/out specification"  
> **username_0**: @username_3 bit late to respond, but yeah, seems like the issue is that I should be passing "GL_LINE_STRIP_ADJACENCY" to the GlDrawArrays() call; thank you everyone for your inputs  

---

## 2 answers

### Answer by username_0 on 2023-11-28. Score: 2 | Accepted answer

So as @username_3 mentioned, the issue seems to be the fact that I was passing "GL\_LINE\_STRIP" instead of "GL\_LINE\_STRIP\_ADJACENCY" to the glDrawArrays() call. Apparently, "GL\_LINE\_STRIP\_ADJACENCY is needed when there is a geometry shader involved ("https://www.khronos.org/opengl/wiki/Primitive#Adjacency\_primitives").

Edit: Originally I meant to use "GL\_LINES\_ADJACENCY" and somehow got mixed up with "GL\_LINE\_STRIP". Don't code at 5am.

> **Comments:**
> **username_3**: "Apparently, "GL_LINE_STRIP_ADJACENCY is needed when there is a geometry shader involved" that's not 100% correct... You need the ADJACENCY because your GS wants to operate on 4 input vertices. When only working on 2 input vertices within the GS you can simply use GL_LINE_STRIP  

---

### Answer by username_4 on 2023-11-28. Score: -1

The geometry shader should look something like this: the fragment shader should be changed to match.

```
#version 460 core
layout (lines_adjacency) in; // converting lines to triangles?
layout (triangle_strip, max_vertices = 4) out;

in VS_OUT
{
    vec2 position;
    vec3 color;
} gs_in[];

// tl, tr, bl, br
out GS_OUT
{
    // vec2 pos; the fragment shader isn't using it so why output it?
    vec3 rgb;  
} gs_out;

void main() {
    for (int i = 0; i < 4; i++)
    {
        //gs_out.pos = gs_in.position; -- don't output it if it isn't being used

        gs_out.rgb = gs_in[i].color;
        gl_Position = gl_in[i].gl_Position;
        EmitVertex();
    }
    EndPrimitive();
}

```

> **Comments:**
> **username_2**: Can you add some more explanation why this would solve the OP's problem and what issues with his shader it actually fixes? Because right now I can't really see how this is related to his issues (and "use this code instead" doesn't exactly help with that). The output might have been superflous in his example, but that's not an error (and any reasonable shader compiler would do what you did internally anyway). Also changing the output from an array to a single variable changes his entire algorithm. How does that help?  

---

