Author Topic: upside-down textures in OpenGL (Read 27956 times)

Laurent · « **Reply #15 on:** June 01, 2009, 05:36:12 pm »

Ok, so I'm obviously wrong (which I expected)

The thing is that (0, 0) maps to the first pixel of the array you pass to glTexImage2D ; if it's the top-left corner of the image then (0, 0) will map to the top-left corner, same for the bottom-left corner. So this is not a matter of what pixel (0, 0) maps to, it's more a matter of convention to follow.

The conclusion is that I could easily change my convention for SFML, everything would still work. But then not only OpenGL will be affected, it's the whole interface of sf::Image that will follow the new convention ; do users expect the pixel at (0, 0) to be the bottom-left one? Isn't it too dangerous to adopt the OpenGL's convention?

Tabasco · « **Reply #16 on:** June 01, 2009, 05:42:45 pm »

I'm content to just flip the sf::Image myself. I would say that if anything needs done in SFML it would be to provide a convenience function like Image->Flip or simply provide a comment in the OpenGL example describing the issue. (Maybe both?)

vpoqol5 · « **Reply #17 on:** June 03, 2009, 11:33:53 am »

The most effective thing would be to create separate inherited sf::Image class like, sf::GLimage with changed function(s), but since that really isn't needed, you could rather provide argument option in existing function like GL_TEXTURE to put in Load...Image or wherever, default to be none, or new function like CreateGLTexture which won't be private, I would go for an argument, since you won't have to recreate texture
anyway, this should be simple and understandable, so now we wait

Laurent · « **Reply #18 on:** June 03, 2009, 11:57:14 am »

Well, if I ever implement something to work around that, it would rather be a Image::Flip() function

But I wonder if bottom-left corner is really always the standard. For example, I guess it is not the case for multi-API engines using both DirectX and OpenGL, as DirectX is using top-left.

Tabasco · « **Reply #19 on:** June 03, 2009, 03:06:58 pm »

Nobody has suggested that it's always the standard, only that it's the standard in OpenGL.
My guess would be that multi-API engines simply store the texture based on the standard for what API they're using. In addition to DirectX using top-left origin for UV's, the texture is probably not stored upside-down, so the UV's and textures you would get from modeling software would work either way.

Meltra Bour · « **Reply #20 on:** August 10, 2009, 10:25:41 am »

I just ran in to this texture problem as well ... Images are not the only problem, fonts seem to have the same problem ... loading ttf files puts them upside down it seems the whole of sfml follows left-top as standard ... witch is fun ... I like to confuse people so

Good thing that I don't need collision detection on text ...

Code: [Select]


glRotatef(180.0, 1.0, 0.0, 0.0);    // Silly sfml font ... flip it up side down

any way a bump, giving people a option to flip textures and fonts around would be appreciated. one vote for sf::Image::flip() and sf::Font::flip()

and euh I have no clue about standards but the way I learned it for opengl has always been bottom-left.

Laurent · « **Reply #21 on:** August 10, 2009, 10:38:36 am »

This issue is really annoying. Trust me, I'd love to follow the OpenGL rules, that would make some parts of my internal code cleaner. But OpenGL is the one that doesn't follow the "standards". It rather follows the "natural" direction of Y axis, which is unfortunately not the same used in computer graphics in general (at least in our context).

Everything else involved in SFML has its 0 natively mapped to the top: window position, pixels in images files, ... If I change the Y axis direction then I'll get more people confused because it no longer matches these other conventions.

But like I already said, OpenGL doesn't enforce a direction on the Y axis. I've always worked with 0 on top in OpenGL and I never got any problem. This is mostly in your mind

Just use SFML's convention rather than trying to make me change it.

_seb_ · « **Reply #22 on:** August 10, 2009, 11:19:00 am »

For information:
OpenGL origin is at the lower left but texture origin is at upper left.
See http://www.opengl.org/resources/features/KilgardTechniques/oglpitfall/
Item 12 OpenGL's Lower Left Origin

l0calh05t · « **Reply #23 on:** August 10, 2009, 01:15:08 pm »

Quote from: "Laurent"

This issue is really annoying. Trust me, I'd love to follow the OpenGL rules, that would make some parts of my internal code cleaner. But OpenGL is the one that doesn't follow the "standards". It rather follows the "natural" direction of Y axis, which is unfortunately not the same used in computer graphics in general (at least in our context).

OpenGL doesn't follow the standards?!? It uses proper mathematical convention, which is 0,0 -> bottom left (and right handed coordinate system for 3D).

Quote

Everything else involved in SFML has its 0 natively mapped to the top: window position, pixels in images files, ... If I change the Y axis direction then I'll get more people confused because it no longer matches these other conventions.

But like I already said, OpenGL doesn't enforce a direction on the Y axis. I've always worked with 0 on top in OpenGL and I never got any problem. This is mostly in your mind
Just use SFML's convention rather than trying to make me change it.

OpenGL convention is having the texture origin in the bottom left, so the way it is now, is extremely impractical/confusing for all the GL users.

One temporary solution would be to push a -1 scale in y direction onto the OGL texture matrix stack... (of course only for fixed function, not shaders & OGL3)

Laurent · « **Reply #24 on:** August 10, 2009, 01:41:51 pm »

Quote

OpenGL doesn't follow the standards?!? It uses proper mathematical convention, which is 0,0 -> bottom left (and right handed coordinate system for 3D).

I just said it doesn't follow the 2D computer graphics standards. Proper mathematical convention is fine, but I think it's inappropriate in this context, where everything else uses a top-left origin.

As SFML is dealing with more stuff related to 2D computer graphics (GUI, images, ...) than OpenGL, it can't be based on the same convention. I had to choose the more widely used.

Quote

OpenGL convention is having the texture origin in the bottom left, so the way it is now, is extremely impractical/confusing for all the GL users.

I know... I just want you to think more globally, not just with OpenGL in mind. Would you like window.SetPosition(0, 0) to put your window at the bottom-left corner of your desktop? Or image.GetPixel(0, 0) to be the bottom-left pixel of your image?

Quote

One temporary solution would be to push a -1 scale in y direction onto the OGL texture matrix stack...

I think that it would mess up many other things.

l0calh05t · « **Reply #25 on:** August 10, 2009, 03:49:05 pm »

Quote from: "Laurent"

I just said it doesn't follow the 2D computer graphics standards. Proper mathematical convention is fine, but I think it's inappropriate in this context, where everything else uses a top-left origin.

If you are using 2D graphics, you are probably using SFML-Graphics, but if you are using 3D graphics, and therefore directly using textures this is inappropriate. Furthermore this change would be hidden to users of SFML-Graphics... (Or are images ever used directly without sprites?)

Quote

As SFML is dealing with more stuff related to 2D computer graphics (GUI, images, ...) than OpenGL, it can't be based on the same convention. I had to choose the more widely used.

I know... I just want you to think more globally, not just with OpenGL in mind. Would you like window.SetPosition(0, 0) to put your window at the bottom-left corner of your desktop? Or image.GetPixel(0, 0) to be the bottom-left pixel of your image?

Actually, yes, I would like that! :wink:

Quote

I think that it would mess up many other things.

Depends on where it is done. But it isn't a proper solution anyways... just a quick, hacky fix for fixed-function GL

Laurent · « **Reply #26 on:** August 10, 2009, 03:56:05 pm »

Quote

If you are using 2D graphics, you are probably using SFML-Graphics, but if you are using 3D graphics, and therefore directly using textures this is inappropriate.

If you're using 3D and textures then you're not using SFML. Except for loading images, but every image loading library loads the pixels with the origin at the top-left corner anyway.

l0calh05t · « **Reply #27 on:** August 10, 2009, 04:41:18 pm »

Quote from: "Laurent"

If you're using 3D and textures then you're not using SFML. Except for loading images, but every image loading library loads the pixels with the origin at the top-left corner anyway.

So... if I'm using SFML-Window, SFML-Audio and SFML-Network, but not SFML-Graphics, I'm not using SFML?

(Font [not String] and Image are the only parts of SFML-Graphics I'm still using, but they'll probably be removed at some point...)

EDIT:
About no libs which load with a pixel origin at the bottom left.... try SOIL with SOIL_FLAG_INVERT_Y. And DevIL also supports it via ilOriginFunc

Laurent · « **Reply #28 on:** August 10, 2009, 05:06:55 pm »

Quote

So... if I'm using SFML-Window, SFML-Audio and SFML-Network, but not SFML-Graphics, I'm not using SFML?

I just meant "you're not using SFML for 3D and textures" -- because that's what you were talking about

Quote

About no libs which load with a pixel origin at the bottom left.... try SOIL with SOIL_FLAG_INVERT_Y. And DevIL also supports it via ilOriginFunc

Ok, most of the OpenGL-oriented image libraries provide an option for flipping the image. I admit that SFML could do it as well -- but here we're just talking about a helper function, not a new default behaviour.

Anyway, if you want quick results you shouldn't wait for me, you'd better implement your own FlipPixels function

l0calh05t · « **Reply #29 on:** August 10, 2009, 06:16:03 pm »

Quote from: "Laurent"

Anyway, if you want quick results you shouldn't wait for me, you'd better implement your own FlipPixels function

I never really considered it a problem... using SOIL directly gives me a lot more options anyways... It was a bit confusing though as I wrote my own text renderer (based on sf::Font using VBOs)