Question

I’m trying to figure out how to do texture mapping using GLSL version 4.10. I’m pretty new to GLSL and was happy to get a triangle rendering today with colors fading based on sin(time) using shaders. Now I’m interested in using shaders with a single texture.

A lot of tutorials and even Stack Overflow answers suggest using gl_MultiTexCoord0. However, this has been deprecated since GLSL 1.30 and the latest version is now 4.20. My graphics card doesn’t support 4.20 which is why I’m trying to use 4.10.

I know I’m generating and binding my texture appropriately, and I have proper vertex coordinates and texture coordinates because my heightmap rendered perfectly when I was using the fixed-function pipeline, and it renders fine with color rather than the texture.

Here are my GLSL shaders and some of my C++ draw code:

---heightmap.vert (GLSL)---

in vec3 position;
in vec2 texcoord;

out vec2 p_texcoord;

uniform mat4 projection;
uniform mat4 modelview;

void main(void)
{
    gl_Position = projection * modelview * vec4(position, 1.0);
    p_texcoord = texcoord;
}


---heightmap.frag (GLSL)---

in vec2 p_texcoord;

out vec4 color;

uniform sampler2D texture;

void main(void)
{
    color = texture2D(texture, p_texcoord);
}


---Heightmap::Draw() (C++)---

// Bind Shader
// Bind VBO + IBO
// Enable Vertex and Texcoord client state

glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D, textureId);

// glVertexPointer(...)
// glTexCoordPointer(...)

glUniform4fv(projLoc, projection);
glUniform4fv(modelviewLoc, modelview);
glUniform1i(textureId, 0);

// glDrawElements(...)

// glDisable/unbind everything

The thing that I am also suspicious about are whether I have to pass the texture coord stuff to the fragment shader as a varying since I’m not touching it in the vertex shader. Also, I have no idea how it’s going to get the interpolated texcoords from that. It seems like it’s just going to get 0.f or 1.f, not the interpolated coordinate. I don’t know enough about shaders to understand how that works. If somebody could enlighten me I would be thrilled!

Edit 1:

@Bahbar: So sorry, that was a typo. I’m typing code on one machine while reading it off another. Like I said, it all worked with the fixed function pipeline. Although glEnableClientState and gl[Vertex|TexCoord]Pointer are deprecated, they should still work with shaders, no? glVertexPointer rather than glVertexAttribPointer worked with colors rather than textures. Also, I am using glBindAttribLocation (position to 0 and texcoord to 1).

The reason I am still using glVertexPointer is I am trying to un-deprecate one thing at a time.

Answer 1

glBindTexture takes a texture object as a second parameter.

// Enable Vertex and Texcoord client state

I assume you meant the generic vertex attributes ? Where are your position and texcoord attributes set up ? To do that, you need some calls to glEnableVertexAttrib, and glVertexAttribPointer instead of glEnableClientState and glVertex/TexCoordPointer (all those are deprecated in the same way that gl_MultiTexCoord is in glsl).

And of course, to figure out where the attributes are bound, you need to either call glGetAttribLocation to figure out where the GL chose to put the attrib, or define it yourself with glBindAttribLocation (before linking the program).

Edit to add, following your addition:

Well, 0 might end up pulling data from glVertexPointer (for reasons you should not rely on. attrib 0 is special and most IHVs make it work just like Vertex), but 1 very likely won’t be pulling data from glTexCoord.

In theory, there is no overlap between the generic attributes (like your texcoord, that gets its data from glVertexAttribPointer(1,XXX), 1 here being your chosen location), and the built-in attributes (like gl_MultiTexCoord[0] that gets its data from glTexCoordPointer).

Now, nvidia is known to not follow the spec, and indeed aliases attributes (this comes from the Cg model, as far as I know), and will go so far as saying to use a specific attribute location for glTexCoord (the Cg spec suggests it uses location 8 for TexCoord0 – and location 1 is the attribute blendweight – see table 39, p242), but really you should just bite the bullet and switch your TexCoordPointer to VertexAttribPointer calls.