MSDN specifies (link) that when using triangleadj type of input to the GS, it should provide me with 6 vertices in specific order: 1st vertex of the triangle processed, vertex of an adjacent triangle, 2nd vertex of the triangle processed, another vertex of an adjacent triangle and so on... So if I wanted to create a pass-through shader (i.e. output the same triangle I got on input and nothing else) I should return vertices 0, 2 and 4. Is that correct?

Well, apparently it isn't because I did just that and when I ran my app the vertices were flickering (like changing positions/disappearing/showing again or sth like that). But when I instead output vertices 0, 1 and 2 the app rendered the mesh correctly.

I could provide some code but it seems like the problem is in the input vertices order, not the code itself.

So what order do input vertices to the GS come in?

  • \$\begingroup\$ In which order do the vertex/index buffer specify the vertices? The GS most likely receives them in that same order. So if the order is wrong in the vertex/index buffer it would be wrong in the GS as well. (Assuming that tessellation is not being used.) \$\endgroup\$ Commented Jul 10, 2014 at 1:05
  • \$\begingroup\$ There are functions in DirectXMesh on CodePlex that will generate adjacency for a triangle mesh and then let you create an IB suitable for use with GS with adjacency. \$\endgroup\$ Commented Jul 10, 2014 at 1:17
  • \$\begingroup\$ Also check your primitive topology; if you're not using one of the topology types with adjacency this might happen. \$\endgroup\$ Commented Apr 6, 2015 at 22:04

1 Answer 1


Probably you are giving the vertices in the wrong order like you said. Anyway returning the vertices 0,2,4 will give you the correct triangle.

I think the problem is that your input vertices are not given in the right winding direction. Swapping 2 vertices in a triangle will reverse the normal vector of that triangle resulting in a invisble triangle (it will be removed using back-face culling).

If there's a way to test what values are returned from the shader that could help. Because debugging numbers using feedback from visual flickering is not that easy =D.

Edit: You need to isolate the problem, why do you think the shader is problem in the first place? Just give 6 vertices to the shader and check if the shader recieves all the coordinates in the order you would expect. Then check if vertex 0, 2 and 4 would give the requested triangle. If all that is correct, I think the problem is not in the shader. You might give the wrong vertices to the shader, or the problem is located when you use the coordiantes the shader returned...

  • \$\begingroup\$ I have front/back face culling turned off, so it's not that. As for debugging - I can debug the shader but I'm not sure what exactly I should be looking for. \$\endgroup\$
    – NPS
    Commented Feb 9, 2014 at 19:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .