Texture

___To Be Continued...


[State]

[ Conception ]
...
    URL:http://alfonse.bitbucket.org/oldtut/Texturing/Tutorial%2014.html

A texture is an object that contains one or more arrays of data, with all of the arrays having some dimensionality. The storage for a texture is owned by OpenGL and the GPU, much like they own the storage for buffer objects. Textures can be accessed in a shader, which fetches data from the texture at a specific location within the texture's arrays. 

The arrays within a texture are called images; this is a legacy term, but it is what they are called. Textures have a texture type; this defines characteristics of the texture as a whole, like the number of dimensions of the images and a few other special things.

...
___
___glTexImage*D()
___
Tutorial's URL: http://alfonse.bitbucket.org/oldtut/Texturing/Tutorial%2014.html (source)

Parameters Explanation: What and Why

• Texture Objects
• Pixel Transfer and Formats
• Textures in Shaders
• Texture Sampling
• Texture Binding
• Sampler Objecs
• Texture Resolution

    ***  Tutorial

All we need to do is to send texture data to server/GPU, and then 

tell OpenGL in which format we stored them.  

Function for sending data to GPU is glTexImage2D(). 

    Parameters in order are:

• target - in our case it is GL_TEXTURE_2D 

• texture LOD - Level Of Detail - we set this to zero - this parameter is used for defining mipmaps. The base level (full resolution) is 0. All subsequent levels (1/4 of the texture size, 1/16 of the texture size...) are higher, i.e. 1, 2 and so on. But we don't have to do it manually (even though we can, and we don't even have to define ALL mipmap levels if we don't want to, OpenGL doesn't require that), there is luckily a function for mipmap generation (soon we'll get into that). 

• internal format - specification says it's number of components per pixel, but it doesn't accept numbers, but constants like GL_RGBand so on (see spec). And even though we use BGR as format, we put here GL_RGB anyway, because this parameter doesn't accept GL_BGR, it really only informs about the number of components per texel. I don't find this very intuitive, but it's probably because of some backwards compatibility. 

• width - Texture width 

• height - Texture height 

• border - width of border - in older OpenGL specifications you could create a border around texture (it's really useless), in new 3.3 specification (and also in future specifications, like 4.2 in time of writing this tutorial), this parameter MUST be zero 

• format - Format in which we specify data, GL_BGR in this case 

• type - data type of single value, we use unsigned bytes, and thus GL_UNSIGNED_BYTE as data type 

• data - finally a pointer to the data

___

___ Texture ID

___

URL: http://www.mbsoftworks.sk/index.php?page=tutorials&series=1&tutorial=9 (Tut source)

Textures in OpenGL are used similarly as other OpenGL objects - first we must tell OpenGL to generate textures, and then it provides us a texture name (ID), with which we can address the texture.

Very important thing about textures is, that their dimensions MUST be powers of 2.

/**
 **
 ***********
...:comment
          NPOT Texture

An NPOT Texture is a texture whose dimensions are not powers of 2 (Non-Power-Of-Two). In earlier hardware, there was a requirement that the dimensions of a texture were a power of two in size. NPOT textures are textures that are not restricted to powers of two.

...:
[URL]
     https://www.talisman.org/opengl-1.1/Reference/glTexImage2D.html
     http://pyopengl.sourceforge.net/documentation/manual-3.0/glTexImage2D.html
   
     [ internalFormat ]

•           Specifies the number of color components in the texture.

    [ format ]  

•           Specifies the format of the pixel data.

 ************
 **
 **/

FreeImage doesn't store our images in RGB format, on Windows, it's actually BGR, and this thing should be platform-dependant as far as I know. But this is no problem, when sending data to GPU, we'll just tell it that they're in BGR format. And now we really are ready to upload data to GPU... or we are? Yes, but a little word about texture filters should be said.

After a brief explanation of texture filters, we can proceed with its creation. All we need to do is to send texture data to GPU, and then tell OpenGL in which format we stored them. Function for sending data to GPU is glTexImage2D. It's parameters (in order) are:

1. target - in our case it is GL_TEXTURE_2D
2. texture LOD - Level Of Detail - we set this to zero - this parameter is used for defining mipmaps. The base level (full resolution) is 0. All subsequent levels (1/4 of the texture size, 1/16 of the texture size...) are higher, i.e. 1, 2 and so on. But we don't have to do it manually (even though we can, and we don't even have to define ALL mipmap levels if we don't want to, OpenGL doesn't require that), there is luckily a function for mipmap generation (soon we'll get into that).
3. internal format - specification says it's number of components per pixel, but it doesn't accept numbers, but constants like GL_RGB and so on (see spec). And even though we use BGR as format, we put here GL_RGB anyway, because this parameter doesn't accept GL_BGR, it really only informs about the number of components per texel. I don't find this very intuitive, but it's probably because of some backwards compatibility.
4. width - Texture width
5. height - Texture height
6. border - width of border - in older OpenGL specifications you could create a border around texture (it's really useless), in new 3.3 specification (and also in future specifications, like 4.2 in time of writing this tutorial), this parameter MUST be zero
7. format - Format in which we specify data, GL_BGR in this case
8. type - data type of single value, we use unsigned bytes, and thus GL_UNSIGNED_BYTE as data type
9. data - finally a pointer to the data

 [ so what's the difference between internal format and format ; ( ]
___
___

___