Texture

A texture is an OpenGL Object that contains one or more images that all have the same image format. A texture can be used in two ways. It can be the source of a texture access from a Shader, or it can be used as a render target.

Theory

For the purpose of this discussion, an image is defined as a single array of pixels of a certain dimensionality (1D, 2D, or 3D), with a particular size, and in a specific format.

A texture is a container of one or more images. But textures do not store arbitrary images; a texture has specific constraints on the images it can contain. There are three defining characteristics of a texture, each of the defining part of those constraints: the texture type, texture size, and the image format used for images in the texture. The texture type defines the arrangement of images within the texture. The size defines the size of the images in the texture. And the image format defines the format that all of these images share.

There are a number of different types of textures. These are:

GL_TEXTURE_1D: Images in this texture all are 1-dimensional. They have width, but no height or depth.

GL_TEXTURE_2D: Images in this texture all are 2-dimensional. They have width and height, but no depth.

GL_TEXTURE_3D: Images in this texture all are 3-dimensional. They have width, height, and depth.

GL_TEXTURE_RECTANGLE: The image in this texture (only one image. No mipmapping) is 2-dimensional. Texture coordinates used for these textures are not normalized.

GL_TEXTURE_CUBE_MAP: There are exactly 6 distinct sets of 2D images, all of the same size. They act as 6 faces of a cube.

GL_TEXTURE_1D_ARRAY: Images in this texture all are 1-dimensional. However, it contains multiple sets of 1-dimensional images, all within one texture. The array length is part of the texture's size.

GL_TEXTURE_2D_ARRAY: Images in this texture all are 2-dimensional. However, it contains multiple sets of 2-dimensional images, all within one texture. The array length is part of the texture's size.

GL_TEXTURE_CUBE_MAP_ARRAY: Images in this texture are all cube maps. It contains multiple sets of cube maps, all within one texture. The array length * 6 (number of cube faces) is part of the texture size.

GL_TEXTURE_2D_MULTISAMPLE: The image in this texture (only one image. No mipmapping) is 2-dimensional. Each pixel in these images contains multiple samples instead of just one value.

Texture sizes have a limit based on the GL implementation. For 1D and 2D textures (and any texture types that use similar dimensionality, like cubemaps) the max size of either dimension is GL_MAX_TEXTURE_SIZE. For array textures, the maximum array length is GL_MAX_ARRAY_TEXTURE_LAYERS. For 3D textures, no dimension can be greater than GL_MAX_3D_TEXTURE_SIZE in size.

Within these limits, the size of a texture can be any value. It is advised however, that you stick to powers-of-two for texture sizes, unless you have a significant need to use arbitrary sizes.

Mip maps

When a texture is directly applied to a surface, how many pixels of that texture (commonly called "texels") are used depends on the angle at which that surface is rendered. A texture mapped to a plane that is almost edge-on with the camera will only use a fraction of the pixels of the texture. Similarly, looking directly down on the texture from far away will show fewer texels than an up-close version.

The problem is with animation. When you slowly zoom out on a texture, you start to see aliasing artifacts appear. These are caused by sampling fewer than all of the texels; the choice of which texels are sampled changes between different frames of the animation. Even with linear filtering (see below), artifacts will appear as the camera zooms out.

To solve this problem, we employ mip maps. These are pre-shrunk versions of the full-sized image. Each mipmap is half the size of the previous one in the chain, using the largest dimension of the image . So a 64x16 2D texture can have 6 mip-maps: 32x8, 16x4, 8x2, 4x1, 2x1, and 1x1. OpenGL does not require that the entire mipmap chain is complete; you can specify what range of mipmaps in a texture are available.

Some texture types have multiple independent sets of mipmaps. Each face of a cubemap has its own set of mipmaps, as does each entry in an array texture. However, the texture as a whole only has one setting for which mipmaps are present. So if the texture is set up such that only the top 4 levels of mipmaps present, you must have them for all mipmap chains in the texture.

When sampling a texture (see below), the implementation will automatically select which mipmap to use based on the viewing angle, size of texture, and various other factors.

When using texture sizes that are not powers of two, the half-size of lower mipmaps is rounded down. So a 63x63 texture has as its next lowest mipmap level 31x31. And so on.

The base level of a mipmap chain is the largest one. It is also the one that defines the full size of the texture. OpenGL numbers this mipmap level as 0; the next largest mipmap level is 1, and so on.

The base level of a texture does not have to be loaded. As long as you specify the range of mipmaps correctly, you can leave out any mipmap levels you want.

Texture Objects

The target parameter of glBindTexture​ corresponds to the texture's type. So when you use a freshly generated texture name, the first bind helps define the type of the texture. It is not legal to bind an object to a different target than the one it was previously bound with. So if you generate a texture and bind it as GL_TEXTURE_1D, then you must continue to bind it as such.

As with any other kind of OpenGL object, it is legal to bind multiple objects to different targets. So you can have a GL_TEXTURE_1D bound while a GL_TEXTURE_2D_ARRAY is bound.

Binding a fresh object is all that is needed to give it a type. But to give it a size and format, we must call one of the glTexImage* functions. This will allocate storage for a particular mipmap level of the texture. To allocate all of the mipmap levels of a texture, you can call the appropriate function in a loop, from base level 0 to the the maximum mipmap level (defined by the largest dimension of the texture).

The level parameter defines what mipmap level is being allocated in this function call. The width, height, and depth are specific to this particular mipmap level. For 1D array textures, the height means "number of entries in the array". The same goes for 2D array textures and the depth value.

The target value specifies what target will have this operation performed on it. Certain targets are not allowed under certain functions. glTexImage3D can only be used with GL_TEXTURE_3D, GL_TEXTURE_2D_ARRAY, and GL_TEXTURE_CUBE_MAP_ARRAY targets. glTexImage2D can only be used with GL_TEXTURE_2D, GL_TEXTURE_1D_ARRAY, GL_TEXTURE_RECTANGLE, and the 6 GL_TEXTURE_CUBE_MAP* faces (of the form GL_TEXTURE_CUBE_MAP_POSITIVE/NEGATIVE_X/Y/Z). glTexImage1D can only be used with GL_TEXTURE_1D.

The two glTexImage*Multisample functions can only be used with GL_TEXTURE_2D_MULTISAMPLE, and GL_TEXTURE_2D_MULTISAMPLE_ARRAY, with the array version for the 3D version. These functions set the sample count in addition to the internal format and size of the texture.

The internalformat value is the format of the texture. Take care with this value when allocating mipmaps: this parameter must be the same for each of the subsequent calls.

The border parameter is for old, deprecated functionality. Any value other than 0 is an error.

The format, type, and data parameters are used for performing a Pixel Transfer operation. This allows one to create a texture and fill it with some data in one call. However, since you can only give it data for one mipmap, this is not as useful as expected. As with any pixel transfer operation, Pixel Buffer Objects can be used to feed OpenGL the data.

You do not need to fill in the texture's data in the same call that you create it in. If data is NULL, no pixel transfer will be done, and the texture's data is undefined. You should make sure to fill in the texture's data at some point in the future.

Note: Even if data is NULL, the format and type fields must be legal fields, or the entire call will fail with a GL_INVALID_ENUMerror.

The multisample versions of these functions do not offer pixel transfer. This is because the image data of multisample textures cannot be updated from client data. It can only be filled in as a render target, and it can only be sourced as a texture from GLSL.

Immutable texture storage

It is possible to allocate storage for a texture in an immutable way, such that once the storage is allocated, it cannot later be altered. The contents of the storage can be altered with various functions (like the glTexSubImage*​ calls, but not the storage itself. The size of the texture and the mipmap pyramid will be fixed.

Calling glTexImage*​ (or glCopyTexImage*​) on that particular texture object will result in an error, as will calling glTexStorage*​ on it.

The levels​ parameter defines the number of mipmaps to allocate. The levels​ value must specify a valid number of mipmap levels; if you try to create levels below the minimum 1 pixel in size, a GL_INVALID_OPERATION error results.

Storage for Buffer Textures come from buffer objects, and as such, they cannot be immutable.

Texture view creation

A view of a texture is a texture object which references the storage within another texture. Both texture objects share the same storage, but have different parameters (see below), and may only reference some of the mipmaps and layers in the other texture storage. So changing the texel data stored in one will affect the other, but changing the filtering mode will not.

When creating a view texture, the original source texture object must have immutable storage. All view textures are themselves immutable, so you can use a view texture to create another view texture. Therefore, the source texture must be a previously created view or a texture who's storage was created with one of the glTexStorage*​ functions as defined above.

texture​ is the view texture object name that will be created. target​ is the type of texture that will be created (if texture​ was previously bound to the context, target​ must match the type it was bound as). origtexture​ is the texture to create a view from, and as previously explained, it must have immutable storage. The new texture is given an Image Format from the internalformat​ parameter.

The new texture can select portions of the storage from the original texture. The portion selected is defined by the minlevel​, numlevels​, minlayer​, and numlayers​ parameters. minlevel​ is the mipmap level in the original texture that will become the base level of the new texture. numlevels​ defines the number of mipmap levels. starting from minlevel​, to be referenced by the new view texture.

minlayer​ defines the array layer or cubemap face to start with. numlayers​ defines the number of layers, starting from {param|minlayer}} to be referenced by the new view texture.

The target​ and internalformat​ can differ from the equivalent target and internal format of the original texture. See the documentation for the glTextureView function for specific details. The table for S3TC formats is available on the S3TC page.

View textures can be created from other view textures.

Texture Parameters

Texture objects have parameters. These parameters control many aspects of how the texture functions.

These function set the parameter values param or params for the particular texture parameter pname in the texture bound to target.

Mipmap range

The texture parameters GL_TEXTURE_BASE_LEVEL and GL_TEXTURE_MAX_LEVEL (integer values) define the closed range of the mipmaps that are to be considered available with this texture. Nothing can cause the sampling of mipmaps smaller than GL_TEXTURE_BASE_LEVEL and nothing can cause the sampling of mipmaps greater than GL_TEXTURE_MAX_LEVEL. This even filters into GLSL; the texture size functions will retrieve the size of GL_TEXTURE_BASE_LEVEL, rather than the size of mipmap level 0.

There is another pair of texture parameters, GL_TEXTURE_MAX_LOD and GL_TEXTURE_MIN_LOD (floating-point values). These do something similar: they clamp the value that computes which mipmap should be sampled from in a texture. However it does not cover everything; that is not the purpose of these parameters. So if your intent is to guarantee that you can never sample any other mipmap levels, what you want are the BASE_LEVEL and MAX_LEVEL, not the LODs here.

Remember: these parameters work for the entire texture. So all cubemap faces must have the same mipmaps defined, as must all array textures.

Note that immutable storage textures (or views created from immutable storage textures) will already have these values set to the mipmap range of the storage. You can set them to be smaller, but it is an error to go outside of the available mipmap range for the immutable storage.

Automatic mipmap generation

It is often useful to auto-generate a mipmap set from just the base mipmap level in the previously defined range. How exactly the implementation does filtering for mipmap generation is implementation-dependent. You do not have to call the glTexImage* functions to allocate storage for the mipmaps to be generated; OpenGL will handle that detail for you.

Before you can generate mipmaps, you must set the base mipmap level as above. And you must actually put data in that level. If you are generating mipmaps for cubemaps, you must have put data into all 6 faces of the cubemap.

This will cause the texture bound to target to have its mipmap levels below the base level auto-generated. The base level and max level range is observed; the base level will not change, and all levels below it will be generated, down to the max level. Any mipmap levels defined outside of the base/max range will not be changed.

Texture image modification

It is often useful to modify a texture after it is specified. If you wish to pass it data from the CPU, calling the glTexImage* is a very heavyweight operation. If you only want to update a subsection of the texture, those functions will not help.

These functions are used to modify image data without reallocating it.

These functions update a specific region of the given texture and mipmap level with new data. The xoffset, yoffset, zoffset, width, height, and depth define the region to be updated. The format, type, and data functions operate as for any Pixel Transfer operation.

Compressed textures

Standard Pixel Transfer operations can convert pixel data into compressed formats for you. These algorithms tend to be optimized for speed rather than image quality. Therefore, it is often desirable to pre-compress image data offline and upload it as compressed image data. A normal pixel transfer operation cannot handle this.

The glCompressedTexImage functions work very much like the glTexImage functions. They respecify a mipmap layer completely. The glCompressedTexSubImage functions work like the glTexSubImage, updating only the image data.

The target, level, xoffset, yoffset, zoffset, width, height, depth, and border fields function exactly as they did in the earlier functions. imageSize is the length of the byte array data. Since the format of the compressed image data must match the specific format of the texture, the implementation can deduce what this data means from the pointer and size alone.

The internalformat parameter must refer to a specific compressed format. The generic formats cannot be used here. And it is an error to call any of the glCompressedTexSubImage formats on a texture that doesn't use a non-generic compressed format.

Though this is not technically a pixel transfer operations, a buffer bound to GL_UNPACK_BUFFER can still be used in place of a client memory pointer.

Texture image units

Binding textures for use in OpenGL is a little weird. There are two reasons to bind a texture object to the context: to change values in the object and to render something with it.

Changing the texture's stored state can be done with the above simple glBindTexture​ call. However, actually rendering with a texture is a bit more complicated.

A texture can be bound to one or more locations. These locations are called texture image units. OpenGL contexts have a maximum number of texture image units, queriable from the constant GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS.

What image unit a glBindTexture​ call binds the texture to depends on the current active texture image unit. This value is set by calling:

The value of texture​ is GL_TEXTURE0 + i, where i is a number on the half-open range [0, GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS). This will cause the texture image unit i to be the current active image unit.

Each texture image unit supports bindings to all targets. So a 2D texture and an array texture can be bound to the same image unit, or different 2D texture can be bound in two different image units without affecting each other. So which texture gets used when rendering? In GLSL, this depends on the type of sampler that uses this texture image unit.

Note: This sounds suspiciously like you can use the same texture image unit for different samplers, as long as they have different texture types. Do not do this. The spec explicitly disallows it; if two different GLSL samplers have different texture types, but are associated with the same texture image unit, then rendering will fail. Give each sampler a different texture image unit.

The glActiveTexture​ function defines the texture image unit that any function that takes a texture target as a parameter uses.

Texture sampling

Sampling is the process of fetching a value from a texture at a given position. GLSL controls much of the process of sampling, but there are many texture parameters that affect this as well.

Normalized texture coordinates

Locations in a texture are usually abstracted via the use of normalized texture coordinates. These are floating-point values where 0 means one edge of the texture and 1 means the opposite edge of the texture. This abstracts away the size of the texture, allowing different textures with different sizes to be used.

Filtering

Filtering is the process of accessing a particular sample from a texture. There are two cases for filtering: minification and magnification. Magnification means that the area of the fragment in texture space is smaller than a texel, and minification means that the area of the fragment in texture space is larger than a texel. Filtering for these two cases can be set independently.

The magnification filter is controlled by the GL_TEXTURE_MAG_FILTER texture parameter. This value can be GL_LINEAR or GL_NEAREST. If GL_NEAREST is used, then the implementation will select the texel nearest the texture coordinate; this is commonly called "point sampling"). If GL_LINEAR is used, the implementation will perform a weighted linear blend between the nearest adjacent samples.

The minification filter is controlled by the GL_TEXTURE_MIN_FILTER texture parameter. To understand these values better, it is important to discuss what the particular options are.

When doing minification, you can choose to use mipmapping or not. Using mipmapping means selecting between multiple mipmaps based on the angle and size of the texture relative to the screen. Whether you use mipmapping or not, you can still select between linear blending of the particular layer or nearest. And if you do use mipmapping, you can choose to either select a single mipmap to sample from, or you can sample the two adjacent mipmaps and linearly blend the resulting values to get the final result.

The OpenGL minification settings for these are as follows:

Param Setting

Linear within mip-level

Has mipmapping

Linear between mip-levels

GL_NEAREST

No

No

GL_LINEAR

Yes

No

GL_NEAREST_MIPMAP_NEAREST

No

Yes

No

GL_LINEAR_MIPMAP_NEAREST

Yes

Yes

No

GL_NEAREST_MIPMAP_LINEAR

No

Yes

Yes

GL_LINEAR_MIPMAP_LINEAR

Yes

Yes

Yes

A note on terminology. This discussion has refrained from using the common filtering terms "bilinear" and "trilinear." This is for a good reason; these terms are often misunderstood and do not carry over to all texture types.

Take the term "bilinear". This term is used because it refers to linear filtering in 2 axes: horizontally and vertically in a 2D texture. A monolinear would be filtering in one axis, and thus trilinear is filtering in 3 axes.

The problem is that what constitutes "bilinear" depends on the texture type. Or specifically, its dimensionality. Setting GL_TEXTURE_MAG_FILTER and MIN_FILTERs to GL_LINEAR will create monolinear filtering in a 1D texture, bilinear filtering in a 2D texture, and trilinear in a 3D texture. In all cases, it is simply doing a linear filter between the nearest samples; some texture types simply have more nearest samples than others.

Unfortunately, what most people think of as "trilinear" is not linear filtering of a 3D texture, but what in OpenGL terms is GL_LINEAR mag filter and GL_LINEAR_MIPMAP_LINEAR in the min filter in a 2D texture. That is, it is bilinear filtering of each appropriate mipmap level, and doing a third linear filter between the adjacent mipmap levels. Hence the term "trilinear".

This is easily confused with what is just GL_LINEAR for 3D textures. That is why OpenGL and this discussion does not use these terms.

Anisotropic filtering

Note: This is not core functionality; it is governed by the extension GL_EXT_texture_filter_anisotropic. However, this extension is available virtually everywhere.

Anisotropic filtering is an advanced filtering technique that takes more than one sample point and blends them together. Exactly how this is done is implementation-dependent, but the control is a specific value: the maximum number of samples that can be taken of the texture. More samples may slow down performance, but increase image quality. Then again, it may not, depending on the angle you're looking at the surface. Implementations only take extra samples when needed.

To use anisotropic filtering, set the GL_TEXTURE_MAX_ANISOTROPY_EXT parameter. This parameter is floating-point, and can be set between 1.0f and an implementation-defined maximum anisotropy (queried with GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT). Any value greater than 1.0f counts as a use of anisotropic filtering.

Anisotropic filtering is not a replacement for mipmaps or mipmap filtering. For best results, combine a anisotropic filtering with a GL_LINEAR_MIPMAP_LINEAR minification filter.

Sampling results

The result for sampling from a texture with a color image format is a 4-dimensional value. For floating-point and normalized integer image formats, the return value is a vec4. For signed integral image formats, the return value is a ivec4 and for unsigned integrals, it is a uvec4.

The four values are filled in from the texture. Not all image formats provide all four values. Any values not provided by the texture are filled with zeros, except for the last component (alpha), which is a 1.

Swizzle mask

While GLSL shaders are perfectly capable of reordering the vec4 value returned by a texture function, it is often more convenient to control the ordering of the values from code. This is done through swizzle parameters.

Texture objects (and only texture objects. Not sampler objects) can have swizzling parameters. This only works for textures with color image formats. Each of the four output components, RGBA, can be set to come from a particular color channel.

To set the output for a component, you would set the GL_TEXTURE_SWIZZLE_C texture parameter, where C is R, G, B, or A. These parameters can be set to the following values:

GL_RED: The value for this component comes from the red channel of the image. All color formats have at least a red channel.

GL_GREEN: The value for this component comes from the green channel of the image, or 0 if it has no green channel.

GL_BLUE: The value for this component comes from the blue channel of the image, or 0 if it has no blue channel.

GL_ALPHA: The value for this component comes from the alpha channel of the image, or 1 if it has no alpha channel.

GL_ZERO: The value for this component is always 0.

GL_ONE: The value for this component is always 1.

You can also use the GL_TEXTURE_SWIZZLE_RGBA parameter to set all four at once. This one takes an array of four values. For example:

This will effectively map the red channel in the image to the alpha channel when the shader accesses it.

Comparison mode

Depth textures, textures that have a depth component image format, can be sampled in one of two ways. They can be sampled as a normal texture, which simply retrieves the depth value (with filtering applied). This will return a single floating-point value, not a vec4. Swizzling does not work on depth textures.

They can also be fetched in comparison mode. This means that sampling from the texture requires a value to compare to those pulled from the texture; this value is called the reference value. The result of the comparison depends on the comparison function set in the texture. If the function succeeds, the resulting value is 1.0f; if it fails, it is 0.0f.

When linear filtering is used, the actual returned value is implementation-defined. However, the value will be on the range [0, 1] and will be proportional to the number of neighboring texels that pass the comparison based on the single given value.

If the texture is a normalized integer depth format, then the reference value is clamped to [0, 1], to match the values from the texture. Otherwise, the value is not clamped.

Using this mode requires two special settings. First, the sampler used in GLSL must be a shadow sampler. Second, the texture used in that sampler must have activated depth comparison mode. Attempting to use a texture without comparison with a shadow sampler, or vice-versa, will result in an error upon rendering.

To set the texture to comparison mode, set the GL_TEXTURE_COMPARE_MODE texture parameter to GL_COMPARE_REF_TO_TEXTURE with glTexParameteri​. The comparison function to use when comparing the reference to the texture is set with the GL_TEXTURE_COMPARE_FUNC texture parameter. Acceptable values are GL_NEVER (always fails), GL_ALWAYS (always succeeds), GL_LESS, GL_LEQUAL, GL_EQUAL, GL_NOT_EQUAL, GL_GEQUAL, and GL_GREATER. The comparison works as follows:

ref OPERATOR texture

Where ref is the reference value given to the texture lookup function by GLSL, and texture is the value fetched from the texture. So GL_LESS will be true if the reference value is strictly less than the value pulled from the texture.

Edge value sampling

Normalized texture coordinates are not limited to values between 0.0 and 1.0. They can be any floating-point number. When a texture coordinate is not within the [0, 1] range, a heuristic must be employed to decide what the color value will be.

Each dimension of a texture can have a different heuristic. These are set by setting the texture parameters GL_TEXTURE_WRAP_S, GL_TEXTURE_WRAP_T, and GL_TEXTURE_WRAP_R, where S, T, and R are the first 3 texture coordinates in order. The possible heuristics are:

GL_REPEAT: the texture coordinate wraps around the texture. So a texture coordinate of -0.2 becomes the equivalent of 0.8.

GLSL binding

Samplers

A sampler in GLSL is a uniform variable that represents an accessible texture. It cannot be set from within a program; it can only be set by the user of the program. Sampler types correspond to OpenGL texture types.

Samplers are used with GLSL texture access functions.

Programs and textures

The process of using textures with a program involves 2 halves. Texture objects are not directly associated with or attached to programs. Instead, program samplers reference texture image unit indices. And whatever textures are bound to those image units at the time of rendering are used by the program.

So the first step is to set the uniform value for the program samplers. For each sampler uniform, set its uniform value to an integer on the range [0, GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS). When the time comes to use the program directly, simply use glActiveTexture and glBindTexture to bind the textures of interest to these image units.

The textures bound to the image unit set in the sampler uniforms must match the sampler's type. So a sampler1D will look to the GL_TEXTURE_1D binding in the image unit it is set in.