I was having a lot of trouble using glVertexAttrib4f to set the vertex color in my shader, and I traced it down to it being due to the shader linker assigning attribute 0 to my vcolor attribute. There seem to be several problems related with vertex attribute 0: The api test in get_current_attrib() is gles2 only, not gl3 as well (this may be a misunderstanding on my part). There are no api tests in VertexAttrib4fARB and friends (at least check for for GLES2, please) Most importantly: the shader linker is assigning attribute 0. Interestingly, attribute 0 works perfectly well if an array is used on it. I noticed the problem because when my vcolor attribute was assigned 0, it was never set and thus everything was rendered black. vertex shader --8<-- uniform mat4 mvp_mat; attribute vec4 vertex; attribute vec4 vcolor; varying vec4 color; varying vec2 st; void main (void) { gl_Position = mvp_mat * vec4 (vertex.xy, 0.0, 1.0); st = vertex.zw; color = vcolor; } --8<-- fragment shader --8<-- uniform sampler2D texture; uniform sampler2D palette; varying vec4 color; varying vec2 st; void main (void) { float pix; pix = texture2D (texture, st).r; if (pix == 1.0) discard; gl_FragColor = texture2D (palette, vec2 (pix, 0.5)) * color; } --8<-- full source can be had from git://git.quakeforge.net/gitroot/quake/quakeforge glsl branch. However, this has the workaround for the problem (vertex and vcolor declaration order swapped in the vertex shader)
I forgot to mention that the glsl using programs are qw-client-glslx and nq-glslx.
(In reply to comment #0) > I was having a lot of trouble using glVertexAttrib4f to set the vertex color in > my shader, and I traced it down to it being due to the shader linker assigning > attribute 0 to my vcolor attribute. This is completely valid. Your shader does not use gl_Vertex, and I'm assuming you don't call glBindAttribLocation to set some other attribute as slot 0. There is no requirement, explicit or implied, that attributes be assigned in the order in which they appear in the shader. As you've noticed, relying on that may break on some implementations. :) > There seem to be several problems related with vertex attribute 0: > The api test in get_current_attrib() is gles2 only, not gl3 as well (this may > be a misunderstanding on my part). I don't think there's any need for change here. I'm pretty sure that attribute 0 was still "special" in 3.0. I don't think that was changed until 3.1, but I'll have to double check. > There are no api tests in VertexAttrib4fARB and friends (at least check for for > GLES2, please) For GLES2, these functions get routed through _es_VertexAttrib4f, etc., and I believe those do the right thing. > Most importantly: the shader linker is assigning attribute 0. > Interestingly, attribute 0 works perfectly well if an array is used on it. > > I noticed the problem because when my vcolor attribute was assigned 0, it was > never set and thus everything was rendered black. > > vertex shader > --8<-- > uniform mat4 mvp_mat; > attribute vec4 vertex; > attribute vec4 vcolor; > > varying vec4 color; > varying vec2 st; > > void > main (void) > { > gl_Position = mvp_mat * vec4 (vertex.xy, 0.0, 1.0); > st = vertex.zw; > color = vcolor; > } > --8<-- > > fragment shader > --8<-- > uniform sampler2D texture; > uniform sampler2D palette; > varying vec4 color; > varying vec2 st; > > void > main (void) > { > float pix; > > pix = texture2D (texture, st).r; > if (pix == 1.0) > discard; > gl_FragColor = texture2D (palette, vec2 (pix, 0.5)) * color; > } > --8<-- > > full source can be had from git://git.quakeforge.net/gitroot/quake/quakeforge > glsl branch. However, this has the workaround for the problem (vertex and > vcolor declaration order swapped in the vertex shader)
I had the same problem as Bill with the disabled array for attribute 0. I debugged a bit into it and saw a potential problem in src/mesa/vbo/vbo_exec_array.c: In recalculate_input_bindings(), the last line of case VP_ARB is inputs[VERT_ATTRIB_GENERIC0] = inputs[0]; If the attrib array is disabled, inputs[0] resolves to &vbo->currval[VBO_ATTRIB_POS], instead of (at least in my expectation) currval[VBO_ATTRIB_GENERIC0].
This is probably fixed with commit fe2f5cfdc7439cbe481d4bea393b46395967a8a3. Please retest if possible. Re-open if you still have an issue.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.