cyrille henry wrote:
Matthias Neuenhofer a écrit :
did you recompile Gem after my yesterday commit?
yes but with change void glsl_program:: outtypeMess(GLuint outtype) { m_geoOutType=outtype; if(m_program && glProgramParameteriEXT) {
glProgramParameteriEXT(m_program,GL_GEOMETRY_OUTPUT_TYPE_EXT,m_geoOutType);
} was before GL_GEOMETRY_INPUT_TYPE_EXT
yep, your right, there is another typo here. i corrected it. it is strange it was working with this typo. now that i corrected it, nothing changed...
that's because (i think) you cannot really change the in/output geometry once a program is linked (at least it doesn't seem to do much). when the program get's re/linked, glProgParamiEXT gets called with the correct GL_GEOMETRY_... so that's why it should work anyhow (once the m_geoOutType/m_geoInType typos are fixed ...)
anyhow, i checked in a more-typo-fixed version.
so sending [draw foo( to the square will draw the square with GL_POLYGON... sending draw QUAD_STRIP will draw the square with GL_QUADS. sending draw Line / line_loop / LINE_STRIP will use gl_line_loop draw TRIANGLE_STRIP will use gl_triangle, you have to send draw strip in order to have triangle strip. etc. so the drawing mode and there comments in my initial patch was right. changing them result in unexpected behaviour.
we should check a (generic) way to automatically find out which drawing mode should be used. it will definitely become a usability problem, if people have to read the Gem-sources to know which geometry type they are allowed to use in the geometry shaders. also the use of GL_LINE_STRIP vs "fill" is rather ... arbitrary.
mfgasdr IOhannes