Texture not rendering

OpenGL Development
#1

EDIT:

Ok, so I fixed my texture not showing (really stupid mistake that even I could find) but there’s one more issue. Here’s my code for drawing my custom cursor


		glPushMatrix();
			glTranslatef(x, y, 0);
			glColor3f(1.0f, 1.0f, 1.0f);
			glBegin(GL_TRIANGLES);
				glVertex2f(0, 0);
				glVertex2f(14, 16);
				glVertex2f(2, 18);
			glEnd();
		glPopMatrix();

but no matter what color I set, it’s always black. Any idea why that might be?

EDIT AGAIN: Apparently when I call glDisable(GL_TEXTURE_2D) before I draw the cursor, it shows up in color. Do I really have to keep calling glEnable and glDisable for GL_TEXTURE_2D to draw my cursor, or is there a better way?

| Nathan

#2

Supply texture coordinates?

#3

I think you are posting this in response to my original post.

My current problem is stated above.

| Nathan

#4

This wouldn’t happen if you didn’t keep editing your original post.

If you have solved your problem and have another one, either open a new thread or post a new message on this one, this will make things far more organized and other people’s messages (like theagentd) will actually make sense.

Don’t you think it’s a bit selfish of yours to just delete/edit the old question and not share the solution with other people?
We are here to share knowledge, we’re not a helpdesk.

#5

I’m sorry.

My original question was a very stupid mistake that I fixed almost immediately. I didn’t think that it needed to stay, since odds are no one will make that mistake.

| Nathan

#6

In reply to your new question, yes you do need to disable GL_TEXTURE_2D after you’re done.

#7

To expand on this, you only need to disable/enable texturing when you want to change the state. i.e. If you are drawing a textured triangle, and then you want to draw a non-textured triangle, you will need to enable/disable texturing. A better solution would be to supply your desired “non-textured” triangle with a white pixel (i.e. a 1x1 section of your sprite sheet) which you them modulate with glColor4f. That way you don’t need to disable texturing, nor do you need to bind a new texture. In fact, you can include the cursor and the rest of your sprites within the same glBegin/glEnd (or vertex array / VBO).

#8

If you call glColorXX(), all following glVertexXX() calls will get that color. If you call glTexCoordXX(), all following glVertexXX() calls will get that texture coordinate. If a texture is bound and GL_TEXTURE_2D is enabled it will sample the same texture coordinates for the whole triangle unless texture coordinates are given per vertex. Most likely your texture just happens to be black at that point.

You can disable texturing by either calling glDisable(GL_TEXTURE_2D); or glBindTexture(GL_TEXTURE_2D, 0);

#9

where glBindTexture(GL_TEXTURE_2D, 0); is much faster, right?

#10

I don’t know, it probably depends on the drivers.

EDIT: Or use shaders, you can just ignore the texture in that case.

#11

How to do that?

#12

Using shaders is completely different from immediate mode. If you plan to use shaders (which you should) then you’ll probably want to learn from the very beginning (e.g. using the arcsynthesis tutorials).

Also, regarding the following:

glBindTexture(GL_TEXTURE_2D, 0);

The above doesn’t disable texturing, it only binds the default texture. There doesn’t seem to be anything in the spec that guarantees the default texture to be white or opaque. I’d say it would be better to disable textures via glDisable(GL_TEXTURE_2D) rather than binding the default texture.

Another solution is to keep textures enabled and specify (with texcoords) a 1x1 white pixel from your sprite sheet. This allows you to push your seemingly “non-textured” sprites in the same “batch” (VBO/vertex array/glBegin) and doesn’t require binding a new texture or changing the texture state.

#13

The thing is, I tried it out. Using glBindTexture(…, 0) instead of glDisable(GL_TEXTURE_2D); is MUCH faster.
I just didn’t got, how to render textures completly without glBindTexture? Or do you mean the glActiveTexture stuff with that?

#14

“MUCH FASTER” is a relative term. :smiley: It’s sampling texture data per vertex, which it might not need to if texturing is disabled; therefore maybe it would be “MUCH FASTER” in a different benchmark. Also, it may lead you to issues depending on how the driver implements the default texture. It usually works, and lots of people do it, but that doesn’t mean it’s necessarily the safest/best practice. :slight_smile:

If you want efficiency, use a 1x1 white pixel like I suggested. This has nothing to do with glActiveTexture; it’s just a matter of specifying a 1x1 opaque white pixel in your texture atlas using glTexCoord2f. That way you can push all of your sprites into the same VBO regardless of whether you want them textured or “not textured” (i.e. solid color).

#15
  1. Actually you can’t even say that performance went from ~100 frames to ~300+, because I didn’t specify my hardware: GTX 550Ti, etc… even then, I would have to specify what I was rendering excactly: I used GL_NEAREST filtering, rendering ~ 1000 sprites, where there are ~20 different sprite images, packed into 2 sprite sheets. Then I would need to specify what programs were running, and even then I didn’t specify what other things the game was doing (updating positions, calculating collisions, physics, lighting etc.).

So I just said “MUCH faster”. :smiley:
Or lets say, it was about twice as fast?

  1. yup I understood.
    I was only kind of confused about what theagentd said:

what does he mean by “ignore the texture”?
Does he mean, there won’t be any texture-binding? I have only seen that in NV_bindless_texture.
Does he mean, you were able to just don’t make gl_FragColor (or whatever you use in OGL3+) be dependent on the texture (“texture2D(…);”)?

This should clear it up :slight_smile:

#16

[quote]what does he mean by “ignore the texture”?
[/quote]
If you are using shaders, you control which attributes (color, texture, vertex normals, etc) to pass to the shader. The shader decides how to color the fragment, so it doesn’t need to sample from any textures. There is no concept of “enabling” or “disabling” texturing.

For example, here is a fragment shader that “ignores the texture coordinates” and instead simply returns the color attribute.

#version 120

varying vec4 Color;
varying vec2 TexCoord;

void main(void) {
	gl_FragColor = Color;
}

Newer GLSL versions would define the attributes like so, and use a custom gl_FragOut.

layout(location=1) in vec4 Color;
layout(location=2) in vec4 TexCoord;
#17

Binding texture 0 does indeed bind the default texture, and I can’t find anything in the 1.0 spec that says what the texture unit is initialized to. The texture object extension just implies that the default texture is initialized by the driver, but doesn’t say anything about what it’s initialized to. I suspect it’s just a courtesy that if you didn’t supply the texture unit any data, that it acts as if texturing wasn’t enabled, but that a segfault would also be equally valid behavior.

I can’t imagine they’d change the behavior now (TONS of things rely on binding texture 0) but did they ever clarify initialization in later revisions of the spec?

#18

I couldn’t find anything in the spec, but posts like this suggests drivers may implement it differently.

In theory the default texture (id = 0) should act like any other texture – e.g. you could manipulate it with glTexImage2D. The only difference is that it can’t be deleted.

[quote]In addition to the default textures TEXTURE_1D, TEXTURE_2D, and TEXTURE_3D_EXT, it is possible to create named 1, 2, and 3-dimensional texture objects. The name space for texture objects is the unsigned integers, with zero reserved by the GL.
[/quote]
http://www.opengl.org/registry/specs/EXT/texture_object.txt

For the curious: “named” textures were introduced with glGenTextures() and glBindTexture() in 1.1. Before that, as I understand it, you would only have a single texture unit (aka the “default texture”) to play with. The “default texture” was left in tact for backwards compatibility with OpenGL 1.0.

However, since users almost never rely on the default texture these days (instead we tend to create a new texture), drivers may not implement texture 0 exactly as you’d expect. IMO the safest solution is to not touch the default texture. :slight_smile:

#19

If you are using shaders, you control which attributes (color, texture, vertex normals, etc) to pass to the shader. The shader decides how to color the fragment, so it doesn’t need to sample from any textures. There is no concept of “enabling” or “disabling” texturing.

For example, here is a fragment shader that “ignores the texture coordinates” and instead simply returns the color attribute.

#version 120

varying vec4 Color;
varying vec2 TexCoord;

void main(void) {
	gl_FragColor = Color;
}

[/quote]
In this case, the varying TexCoord will be optimized away, so there’s not need to have it in the first place. It won’t even be found if you query the varying location for it.

Concering the default texture:
It’s kind of irrelevant for OGL3 since you can just choose not to sample the texture in the shader, but it’s still possible to sample the default texture. In my experience, this has always returned (1, 1, 1, 1) = white meaning it’s a no-op. I’ve always just enabled GL_TEXTURE_2D at initialization and bound the default texture when I needed untextured surfaces. In a real game though you very rarely need untextured surfaces.

EDIT: Assuming the spec is consistent (lol): When using Framebuffer Objects (FBOs), the default FBO 0 refers to the screen framebuffer and is obviously perfectly valid.

#20

If you are using shaders, you control which attributes (color, texture, vertex normals, etc) to pass to the shader. The shader decides how to color the fragment, so it doesn’t need to sample from any textures. There is no concept of “enabling” or “disabling” texturing.

For example, here is a fragment shader that “ignores the texture coordinates” and instead simply returns the color attribute.

#version 120

varying vec4 Color;
varying vec2 TexCoord;

void main(void) {
	gl_FragColor = Color;
}

Newer GLSL versions would define the attributes like so, and use a custom gl_FragOut.

layout(location=1) in vec4 Color;
layout(location=2) in vec4 TexCoord;

[/quote]
yes. Just what I wanted to say with: