Please help! I am trying to render a textured quad.
For the life of me, it retains black with a textured phong shader. In fact, when I use a phong shader, it stays black, even though its the same phong shader that renders all the models around said dastardly quad.

I'm hoping the code is quite explanatory so I'm just gonna walk through it and someone with a sharper eye than I can hunt for glory. Beware, there is a LOT of code - just looked and I feel bad.. however I do have to explain a couple of classes, FreeImage, and how it all works. I have quite a big project now.. it just doesn't yet do a lot because I don't have any textures. Just some 30-second -to-load .objs that are blue, and almost shiny.

I digress, the 'textured' quad gets made with the line below, which calls CreateQuad inline. It's gonna have some picture of some wood or something on it. It sits at 5,5,0 world space, and is 5x5 units in area.

m_HUD is of type GLMesh. GLMesh::Create in short creates a VAO from that GeometryData, a Shader from those filenames, and holds a material - which contains uniforms I may want to set for the model; colour, gl texture id, texture name, etc. It has the Render method.

So, GLMesh::PreRender sets uniforms by talking to its GLShader, and it works like this: If the material says I'm textured, if it contains a texture ID for a diffuse map -- then I have a KdID, I set it. It also sets camera matrices. bOk is bOk, whether I use a texture or no, so the "1" is getting sent to map_kd in the shader.

So that explains how the quad gets made and how it gets rendered, using texture unit or colour, the other data that it requires etc to exist in GL land. I'm pretty sure everything's good except setting the texture / sampler (I've said little of textures, I know).

I got FreeImage. It gives me bits, and I copy them, and keep them locally, then I let GL copy them and GL gives me a texture unit.

It gets convoluted though - as I said, I keep the texture locally and don't free them bits after I give them to OpenGL, because I want to play later - so I have a class for a texture, that lets me access those bits from FreeImage with GetPixel, SetPixel, Fill, etc, as if it were a 2D array. This I feel would be a handy thing to make heightmaps with, among other things.

So FreeImage gives me bits, FreeImage is disguised as ImageFactory.

The bits go to a GLBitmap Constructor ( .. bmp->GetPixel(x, y) ), along with width, height, and whether the bits need shuffling or not when they get copied.

The GLBitmap goes to a GLTexture, which takes the width and height and the bits and does the OpenGL stuff in GLTexture::Load.

Cream::GLTexture Cream::LoadTexture(std::string path)

{

ImageFactory* factory = ImageFactory::Create();

unsigned int width(0), height(0);

bool bShuffle(false);

BYTE* bits = factory->Load( path, width, height, bShuffle );

GLBitmap* bitmap = new GLBitmap( width, height, bShuffle, bits );

GLTexture texture(GL_TEXTURE_2D, GL_RGBA);

texture.SetParam(GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);

texture.SetParam(GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);

texture.SetParam(GL_TEXTURE_MIN_FILTER, GL_LINEAR);

texture.SetParam(GL_TEXTURE_MAG_FILTER, GL_LINEAR);

texture.Load( bitmap );

return texture;

}

Okay, so here's the constructor for GLBitmap - a Pixel is 4 bytes, a BYTE is an unsigned char. You knew that. So we cast the bits to Pixels and we know we have w * h of them. This could be a place where things have gone wrong though.

So where's my error.. Well I suspect a couple of things. I have a debug callback set, would it inform me of anything obvious?

- the glActiveTexture(GLTEXTURE0+n) calls - they're wrong - the wrong place, too often, wrong texture unit ?
- not sending the right value through to the sampler in the shader*, and no map is being sampled.. linked to above?
- the bits were mangled or the pointer lost by the time OpenGL gets to them in GLTexture::Load

As I say, the coloured phong shader and the textured phong shader are identical except for swapping a vec4 uniform for a sampler and a vec2 attribute, and getting the colour by sampling the texture.

Everything renders fine except the textured-not-coloured stuff.

Please find my error(s), I'll be around to let you know how much you helped! It was a long post.. apologies! A lot of code..

Thank you so, so much in advance! There's a lot I want to do with textures that I can't yet!

In fact, here's a screenshot of a mildly shiny blue cube, a white floor-grid, and a square black hole. I kid, it's that quad.

Screenshots up. See the cube and the black quad? I can render that quad using that cube's shader and get a nice yellow on it. I simply set material->isTextured to false and give the other shader names in the GLMesh constructor way at the top. And set a colour on the material.

Okay.. the generic colured shader gives me yellow, the phong shader on the quad makes it black, same phong shader as the cube.. curiouser and curiouser..!

Could you explain what "Everything renders fine except the textured-not-coloured stuff." means? maybe a screenshot?

If I use texture shader, black. If coloured shader, fine. I say 'stuff' because I think the issue with the texturing resides in the texture stuff.. GLTexture, GLBitmap, or setting the texture / binding it. glGenTextures gives me a texture id, even when I was giving it nothing cos I had been calling FreeImage_Unload too early.. 80% sure that those are the right bytes going on the card. Lol.

So do any of your models/shaders have a textured model? Are you sending the uniform to the shader? What does your shader look like?
Does the quad have normal? Can you at least strip your shader down to texture2D(diffuse, texCoord))...... don't know if its a lighting problem/attribute problem, uniform problem, bad texture problem..
Why don't you verify glUseProgram(0) and binding the texture shows up on your quad wihtout using a shader.

1. What?
2. Yes. All the lighting colours vectors, a bunch of matrices, and the texture unit all go to the shader no problem. The GLMesh looks at the material in SetMaterial(), checking for a gl tex id or texture path, and loads texture via a factory (Freeimage) if it needs to. In GLMesh::Render, GLMesh::PreRenderlooks at the material it holds and sets a colour if there is no texture ids - PreRender sets uniforms. See the code in the original post.

3. Look like? There is a basic coloured pass thru shader, a phong coloured shader, and a phong textured shader. In the screenshot in the original post, the phong coloured is the cube on the right, the coloured pass thru is the XYZ and the grid, and the textured quad shader is the black quad in the middle.

I rendered the quad with the pass thru shader, uniform colour as yellow, and it was yellow. I use the textured phong shader or the coloured phong shader, and the quad is black. Verr strange.

As shown in the code in the original post, the quad has four vertices and four normals, each normal is z positive.

The phong colour and phong texture shader are identical except the change from a uniform vec4 colour to a in vec2 uv and a uniform sampler2D tex.

Seriously for chewing through that first post and it was just the texture coordinates.. I'm glad though, that it was a noob error and not down to the whole mechanism of materials, geometry, vaos n shaders, and those texture classes.. there's some saving face in that, I think.

I'll let you in on a secret: I changed my phong shader fragment shader to just set fragColour as what it sampled, no lighting calcs.. something may be wrong with my normals or the phong code.. another thread, coming soon *facepalm*.

Thank you again! So was my texture' backwards' or 'inside out' or what?

From the original post you seem to have specified the quad verts as botRight -> botLeft -> topLeft -> topRight, but the quad texcoords were

topLeft -> topRight -> botRight -> botLeft so the order didnt match.

This is exactly my problem! I've been doing some testing with my 3 shaders.

- The basic coloured one always works on models and on the quad.
- The coloured phong shader on models works (does it..?) - the models appear blue and shiny, like the cube there. But it doesn't work on my quad - until
- The textured phong shader works on the quad - when I set all the normals to (0.0, 0.0 -1.0) - so does the coloured phong shader.

I haven't tried a texture on a mesh.. though obviously I want to. So my quad is wound all wrong! And my texturing stuff works.

So what order is the most used or correct way to wind a quad? I'm always worrying about triangles recently.

I would imagine it should be top right, bottom right, top left, bottom left? Or do you do them counter/clockwise, like a tri, - something like bottom right, top right, top left, bottom left? I'm guessing this is important for rendering meshes that are quads?

Using your texture coordinates, and making x0 negative and x1 positive, y0 negative and y1 positive (that was poor mistake I admit), and setting my normals to -Z, I get this with the textured phong shader. Is my Quad wound the wrong way?

Attached Thumbnails

Winding and texture coord order is important for everything, I use CCW = front, but it doesnt matter you just have to make sure its consistent with your cull winding.

If your vertex winding is not what you intended then your triangles will have their front faces culled when backface culling is enabled. You see this in poorly created models that have missing triangles when view from the outside, its because the winding on all the triangle is not consistent

If your texture coordinates dont fall where they should your texture might be distored, flipped horzontally or vertically. With textures like rocks with no obvious up/down left/right it can make it difficult to notice these problems. Make a basic texture for testing. Say with a capital L on the left of the image, colored red, T at top for top another color, Bottom, Right, etc. Give it a 1 pixel border, place a circle dead center. This will help you notice flips, stretches, and tiling better. Use a white background so you can notice any strange color changes.

Im not sure if what Im seeing is wrong, because If have no way to gauge if that texture looks wrong or not, Its features dont say right or wrong.