OpenGL texture loading issue

Question

This is a very vague problem, so please feel free to clarify anything about this project.

I'm working on a very large application, and recently a very perplexing bug has cropped up regarding the texturing. Some of the textures that we are loading are being loaded - I've stepped through the code, and it runs - but all OpenGL renders for those textures is a weird Pink/White striped texture.

What would you suggest to even begin debugging this situation?

• The project is multithreaded, but a mutex makes sure all OpenGL calls are not interrupted by anything else.
• Some textures are being loaded, some are not. They're all loaded in the exact same way.
• I've made sure that all textures exist
• The "pink/white" textures are definitely loaded in memory - they become visible shortly after I load any other texture into OpenGL.

I'm perplexed, and have no idea what else can be wrong. Is there an OpenGL command that can be called after glTexImage that would force the texture to become useable?

Edit: It's not about the commands failing, it's mainly a timing issue. The pink/white textures show up for a while, until more textures are loaded. It's almost as if the textures are queued up, and the queue just pauses at some time.

Next Edit: I got the glIntercept log working correctly, and this is what it outputted (before the entire program crashed)

http://freetexthost.com/1kdkksabdg

Next Edit: I know for a fact the textures are loaded in OpenGL memory, but for some reason they're not rendering in the program themselves.

Answer 1

Check the size and compression of those images you use as textures. i think opengl texture size has to be a power of 2 ...

Answer 2

If your texture is colored incorrectly most likely you're loading the wrong order of RGB. Make sure in your glTexImage2D you're using the right enums for your image format. Make sure the number of components is correct and that you're getting the order of your RGB pixels in the format argument right.

Although probably not related to your textures showing up wrong, OpenGL doesn't support multithreaded draws so make sure you're not doing any drawing work on a different thread than the one that owns the context.

Edit: Do you have a reference renderer so you can verify the image pixels are being loaded as expected? I would strongly recommend writing a small routine to load then immediately save the pixels to a file so you can be sure that you're getting the right texture results.

Answer 3

When you say:

The project is multithreaded, but a mutex makes sure all OpenGL calls are not interrupted by anything else.

This doesn't sound like strong enough protection to me: remember that OpenGL is a state machine with a large amount of internal state. You need to make sure the OpenGL state is what you expect it to be when you are making your calls, and that certain sequences of calls don't get interrupted with by calls from other threads.

I'm no expert on OpenGL thread-safety, but this seems to me where your problem might lie.

Answer 4

Check your texture coordinates. If they are set wrong, you can see just one or two texels mapped to entire primitives. Remember, OpenGL is a state machine. Check if you're changing the texture coordinate state at the wrong time. You may be setting the texture coordinates at a later point in your code, then when you get back to redrawing these elements the state is acceptable for mapping your texture to the code.

If it is merely a timing issue where the texture loading OpenGL calls aren't executed in time, and your threading code is correct, try adding a call to glFlush() after loading the textures. glFlush() causes all pending OpenGL commands to execute.

Answer 5

You can't load a texture in a thread and use it in other different thread because you will see a beautiful white texture. To do this possible you must load the OpenGL context in between differents threads before use any OpenGL function.

Answer 6

If you are using GLIntercept to check your code, ensure to enable: ThreadChecking = True; in the gliConfig.ini file.

Viewing the log it seems that quite a few OpenGL calls are being main outside the main context.