PDA

View Full Version : Different number inputs to a geometry shader



kRogue
03-03-2011, 05:56 AM
Given that QUADS is not in GL core (lets not moan on weather or not that is a good or bad idea :D ), 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).

Some notes:
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.

mhagain
03-03-2011, 06:49 AM
Gonna need a lot of #defines... ;)

malexander
03-03-2011, 11:25 AM
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.

kRogue
03-03-2011, 03:24 PM
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 :(

malexander
03-03-2011, 05:15 PM
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.

Alfonse Reinheart
03-03-2011, 06:12 PM
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.