Jump to content
  • Advertisement
Sign in to follow this  
cppcdr

OpenGL Textures are inverted?

This topic is 4513 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I was wondering why all my textures are inverted... I load them then render them, but the texture looks like it has been flipped vertically... Is there a setting in OpenGL that I have to set to fix this problem?

Share this post


Link to post
Share on other sites
Advertisement
Many image formats are stored top-down, but OpenGL stores textures bottom-up; this can result in 'flipped' textures if you don't adjust for it. You can correct this by flipping the texture vertically on load, or by flipping the second element of your texture coordinates (i.e. 't' or 'v').

Share this post


Link to post
Share on other sites
OpenGL does not "store" images "bottom up".

OpenGL, and DirectX, address image data with the first loaded bytes as lower-valued V coordinates. Thus, the first byte has V = 0 and the last byte has V = 1.0 (somewhat simplified).

If your image loader hands data to OpenGL in a format other than what your modeler assumes (some modelers assume first byte is top, others assume first byte is bottom) then you'll get a vertical flip.

Also, most TGA and BMP loaders return the bottommost scanline as the first data; most PNG and JPG loaders return the topmost scanline as the first data. Something to be aware of.

If you want to fix this up in texture coordinates, instead of handing proper data to OpenGL in the first place, then you can scale the Y coordinate of the texture coordinate matrix:


glMatrixMode(GL_TEXTURE);
glScalef(1,-1,1);


Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
OpenGL does not "store" images "bottom up".
*sigh* I suppose I left myself open to that :-| I'm a stickler for accuracy about certain things also, so I suppose I should expect to be called on my somewhat lazy answer.

So let me try again. OpenGL functions that deal with pixel or texel data generally accept a pointer to a contiguous block of memory containing the rows of the image in sequence. It could be said that a vertical texture coordinate of 0 will be associated with the first row in this block of memory, while a value of 1 will be associated with the last row in this block of memory.

Although 'up' and 'down' don't always have a well defined meaning in this context, when working with images (such as in Photoshop or a texture editor), we usually associate a definite top and bottom with the image we're viewing. Although there are many different image formats, my understanding is that it is common to assocate the first row in the block of memory containing the image data with the top rather than the bottom of the image (a quick google check seems to confirm that this is the case for .jpg at least).

References on OpenGL texture mapping often presents the texture coordinate system like this:
0,1------------1,1
| |
| |
| |
| |
0,0------------1,0
Which, I think, leads people to orient their texture coordinate system this way with respect to the screen (say, for sprites, or walls in an FPS). Naively applying these texture coordinates to textures loaded from, say, .jpg images, will result in textures that appear to be upside-down.

One can of course simply change the texture coordinates to reflect this, but flipping the image is also an option.

So you are right; my answer was lazy and not well thought out. OpenGL does not 'store' the textures 'bottom-up', but simply associates a vertical texture coordinate of 0 with the first row. All I really meant by the 'bottom up' comment was that following the naive approach described above can have the perceived effect of 'flipping' the textures from the expected orientation.

I hope that will make up for the poor quality of my previous response. Also, although I consider myself proficient in OpenGL, I'm not an expert, so I suppose there could be further inaccuracies (be they minor or major) in the above explanation.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!