Given that QUADS is not in GL core (lets not moan on weather or not that is a good or bad idea ), looking at the geometry shader, the following is a possibility (for strips this does not make sense).
You declare in the geometry shader how many points it consumes per run.
Right now we have one of:
layout (points) in;
layout (lines) in;
layout (triangles) in;
layout (triangles_adjacency) in;
layout (lines_adjacency) in;
which from a the isolated point of view of the geometry shader just specifies how many points it consumes. Indeed, using GL_POINTS, GL_LINES, GL_LINES_ADJACENCY, GL_TRIANGLES, GL_TRIANGLES_ADJANCENY allows one to specify to GL to use 1,2,4,3 or 6 (respectively) from the vertex shader (I am not addressing any of the STRIP ones).
To simulate QUADS, one could feed in GL_LINES_ADJACENCY.
But why stop there (outside of the hardware not being able to): introduce an enumeration (set) saying in a generic way how many vertices the geometry shader consumes when calling glDrawJazz:
glDrawJazz( GL_GS_POLYGONi, ...)
and in the geometry shader:
layout (point_array_size=i) in; //Geometry shader input array(s) are then of length i each.
Note that GL_GS_POLYGON1 would give same behavior as GL_POINTS, GL_GS_POLYGON2 as GL_LINES, etc.
Gonna need a lot of #defines…
I’ve considered asking for geometry shader support of a QUAD, but with GL4 tessellation shaders taking patches of arbitrary vertices, I figured it would be unlikely. For some applications it would be preferable to have a geometry shader rather than a tessellation shader, and the GL4 hardware requirement makes tessellation shaders less appealing.
However, I’d be very happy with a geometry shader that took up to a programmer-specified maximum number of vertices, and reported the current primitive’s number of vertices via a GLSL builtin like gl_InputPrimVertices. It would allow for hardware-accelerated, simple tessellation of polygons (since modelers don’t always produce triangle-only models, especially during development of the model). I’m guessing since this feature doesn’t exist that it’s not possible to implement with GL3 hardware.
I’ve considered asking for geometry shader support of a QUAD
You can get QUAD by saying the input of a geometry shader is GL_LINES_ADJACENCY (admittedly looking at the code would be a what the heck moment). Though geometry shader did not come to GL until 3.2, I have a suspicion that QUAD was taken since it could be done via GL_LINES_ADJACENCY… though nothing then about QUAD_STRIP
Yes, it’s not quite as semantically nice but it’d work. The main reason I abandoned my quads request is because a lot of the model test cases I was seeing for our application were mixed triangle/quad polygon soups with the odd 5 or 6 size polygon. So I had to roll my own primitive info attribute array to handle things like the single pass wire-over-shaded algorithm.
You can get QUAD by saying the input of a geometry shader is GL_LINES_ADJACENCY (admittedly looking at the code would be a what the heck moment).
Except for the overhead of using a geometry shader. Which for a lot of D3D10-era hardware, is significant.