PDA

View Full Version : exact byte format for textures



question2
06-02-2015, 03:15 PM
Hi all,

When I try to provide RGB(A) data for a texture, I am running up against some bizarre problems. For instance, recently I did an experiment where one texture was 100% red, the next 100% green and a third 100% blue, assuming the usual B-G-R-A byte order. These appeared on screen as blue, red, and brown.

The triangles that are using my texture don't currently have a color but when I do set it, it seems to help. That is odd because I thought that for instance a 24-bpp texture is opaque.

Can anyone point me to a definitive source that is not another terrible tutorial that leaves out 90% of what I need to know, which explains that exact, precise, unequivocal byte order for RGBA data?

For instance: byte 0: blue 0..255
byte 1: green 0..255
byte 2: red 0..255
byte 3: alpha 0=transparent
etc.

There are so many GL_RGB* variants that it's confusing.

For 24-bit data I'm trying this:

glTexImage2D (GL_TEXTURE_2D, 0, GL_RGB, _textureWidth, _textureHeight, 0, GL_RGB, GL_UNSIGNED_BYTE, _pixels);

For 32-bit data I'm trying this:

glTexImage2D (GL_TEXTURE_2D, 0, GL_RGBA8, _textureWidth, _textureHeight, 0, GL_RGBA, GL_UNSIGNED_BYTE, _pixels);

My data are byte-based and unsigned, so 0..255 for each of red, green and blue.

Thanks for any help.

GClements
06-02-2015, 04:18 PM
When I try to provide RGB(A) data for a texture, I am running up against some bizarre problems. For instance, recently I did an experiment where one texture was 100% red, the next 100% green and a third 100% blue, assuming the usual B-G-R-A byte order.
If format is GL_RGBA, then the components are in the order R,G,B,A. If format is GL_BGRA, then the components are in the order B,G,R,A.

One thing to often catches out novice OpenGL programmers is that the unpacking parameters (see glPixelStore (https://www.opengl.org/sdk/docs/man4/html/glPixelStore.xhtml)) have GL_UNPACK_ALIGNMENT set to 4 by default. So if you're using 3 components (RGB or BGR) and the texture width isn't a multiple of 4, you need to either add padding bytes between rows or explicitly change the unpack alignment to 1.



The triangles that are using my texture don't currently have a color but when I do set it, it seems to help. That is odd because I thought that for instance a 24-bpp texture is opaque.

It is.

But the the texture colours are multiplied by the interpolated vertex colours (assuming glTexEnv(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE), which is the default setting). This isn't related to alpha.


Can anyone point me to a definitive source
The definitive source is the OpenGL specification (https://www.opengl.org/registry/).

question2
06-02-2015, 06:41 PM
But the the texture colours are multiplied by the interpolated vertex colours (assuming glTexEnv(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE), which is the default setting). This isn't related to alpha. .

I'm confused as to why that would be the default setting, since all the examples of ever seen of textures depict the texture being shown verbatim without any modifications.
I can understand modulating the brightness as a surface turns away from The light source, what does it mean to modulate colors with colors?
Also how could modulation cause a red pixel to become green and a green pixel to become blue.

Alfonse Reinheart
06-02-2015, 07:01 PM
I'm confused as to why that would be the default setting, since all the examples of ever seen of textures depict the texture being shown verbatim without any modifications.
I can understand modulating the brightness as a surface turns away from The light source, what does it mean to modulate colors with colors?

You just gave us an example of texture colors being modulated. The result of lighting computations is a "color", which is multiplied into the texture color. You're simply bypassing lighting computations by passing a color directly, but the math is the same either way.


Also how could modulation cause a red pixel to become green and a green pixel to become blue.

We have not yet verified that what you think ought to be a red pixel actually is a red pixel yet.

question2
06-02-2015, 11:40 PM
We have not yet verified that what you think ought to be a red pixel actually is a red pixel yet.

What do you need to verify that?

GClements
06-03-2015, 05:57 AM
I'm confused as to why that would be the default setting, since all the examples of ever seen of textures depict the texture being shown verbatim without any modifications.
I can understand modulating the brightness as a surface turns away from The light source, what does it mean to modulate colors with colors?
Each component (red, green, blue) of the texture component is multiplied by the corresponding component of the interpolated vertex colour.

"Modulating with brightness" is just the case where the red, green, and blue components are identical (i.e. a shade of grey).


Also how could modulation cause a red pixel to become green and a green pixel to become blue.
It can't. If you're getting that, it's probably because either you're providing B,G,R data where R,G,B is expected, or the data is misaligned.

question2
06-03-2015, 08:30 AM
It can't. If you're getting that, it's probably because either you're providing B,G,R data where R,G,B is expected, or the data is misaligned.

This is a strange bug. First, yes I do need to use BGR. Second, I'm using maybe 50 textures and I'm finding that they are shifted. So if I say rectangle 4 is red and 5 is blue and 6 is green, actually 4 will be blue and 5 wlll be green and 6 with be whatever 7 was going to be.

After experimenting some more, I found that I was making multiple bind calls with the same correct texture id. But I was doing the bind after the glTexImage2D, so I was loading the pixels for the previous texture. Thanks for your help.