A '''texture''' is an [[OpenGL Objects|OpenGL Object]] that contains one or more images that all have the same [[Image Formats|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.

A '''texture''' is an [[OpenGL Objects|OpenGL Object]] that contains one or more images that all have the same [[Image Formats|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 ==

== 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), in a specific [[Image Formats|format]].

+

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 [[Image Formats|format]].

−

There are three defining characteristics of a texture: 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.

+

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:

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.

+

* {{enum|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.

+

* {{enum|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.

+

* {{enum|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.

+

* {{enum|[[Rectangle Texture|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_BUFFER: The image in this texture (only one image. No mipmapping) is 1-dimensional. The storage for this data comes from a [[Buffer Objects|Buffer Object]].

+

* {{enum|[[Texture Buffer|GL_TEXTURE_BUFFER]]}}: The image in this texture (only one image. No mipmapping) is 1-dimensional. The storage for this data comes from a [[Buffer Objects|Buffer Object]].

−

* 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.

+

* {{enum|[[Cubemap Texture|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.

+

* {{enum|[[Array Texture|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 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.

+

* {{enum|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_2D_MULTISAMPLE: Images in this texture all are 2-dimensional. Each pixel in these images contains multiple samples instead of just one value.

+

* {{enum|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.

* {{enum|[[Multisample Texture|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.

+

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 {{enum|GL_MAX_TEXTURE_SIZE}}. For array textures, the maximum array length is {{enum|GL_MAX_ARRAY_TEXTURE_LAYERS}}. For 3D textures, no dimension can be greater than {{enum|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.

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.

Line 31:

Line 34:

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.

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 5 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.

+

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.

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.

Line 45:

Line 48:

== Texture Objects ==

== Texture Objects ==

−

Textures in OpenGL are [[OpenGL Objects]], and they follow the standard conventions of such. So they have the standard <code>glGenTextures</code>, <code>glBindTexture</code>, as you would expect.

+

[[File:Anatomy_of_a_Texture.png|frame|alt=Anatomy of a Texture|Diagram of the contents of a texture object]]

−

−

The ''target'' parameter of <code>glBindTexture</code> 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 should 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 <code>glTexImage*</code> 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).

−

These functions are defined as follows:

+

Textures in OpenGL are [[OpenGL Objects]], and they follow the standard conventions of such. So they have the standard {{apifunc|glGenTextures}}, {{apifunc|glBindTexture}}, as you would expect.

The ''target'' parameter of {{apifunc|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 {{enum|GL_TEXTURE_1D}}, then you ''must'' continue to bind it as such.

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.

+

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

−

The ''target'' value specifies what target will have this operation performed on it. Certain targets are not allowed under certain functions. <code>glTexImage3D</code> can only be used with GL_TEXTURE_3D and GL_TEXTURE_2D_ARRAY targets. <code>glTexImage2D</code> 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). <code>glTexImage1D</code> can only be used with GL_TEXTURE_1D.

+

== Storage ==

+

{{main|Texture Storage}}

−

The two multisample <code>glTexImage*</code> 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.

+

Texture objects come in three parts: storage, sampling parameters, and texture parameters. There are ''numerous'' functions to create a texture's storage; so many that the article needs its own page to describe them all.

−

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

+

== Parameters ==

−

−

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.

−

−

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]].

−

−

=== Texture Parameters ===

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

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''.

+

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

−

=== Mipmap range ===

+

In the anatomy of a texture object image above, it shows three pieces of data: [[Texture Storage]], texture parameters, and [[Sampler Object#Sampling parameters|sampling parameters]]. It's important to understand that both of the last two kinds of data are set by the ''same functions'' for textures. Certain parameters are about the texture itself, and some are about sampling from them.

−

The texture parameters GL_TEXTURE_BASE_LEVEL and GL_TEXTURE_MAX_LEVEL (integer values) define the closed mipmap range of 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.

+

This section will describe the texture parameters only.

−

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.

+

=== Mipmap range ===

−

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

+

The parameters {{enum|GL_TEXTURE_BASE_LEVEL}} and {{enum|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 {{enum|GL_TEXTURE_BASE_LEVEL}} and nothing can cause the sampling of mipmaps greater than {{enum|GL_TEXTURE_MAX_LEVEL}}. This even filters into [[GLSL]]; the texture size functions will retrieve the size of {{enum|GL_TEXTURE_BASE_LEVEL}}, rather than the size of mipmap level 0.

−

=== Automatic mipmap generation ===

+

Note that [[Texture Storage#Immutable storage|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.

−

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 <code>glTexImage*</code> 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.

+

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.

−

Then, call this function:

+

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.

−

void glGenerateMipmap( GLenum ''target'' );

+

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

−

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.

+

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

+

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

+

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

+

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

+

* {{enum|GL_ZERO}}: The value for this component is always 0.

+

* {{enum|GL_ONE}}: The value for this component is always 1.

−

=== Texture image modification ===

+

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

−

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

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.

+

A texture with a depth image format is normally considered a depth component texture. This means that non-depth comparison access will return a single floating-point value (as depth components are either normalized integers or floats). Depth textures in this way can be considered a special form of single-channel floating-point color textures.

−

=== Compressed textures ===

+

However, if the texture uses a [[Image_Format#Depth_stencil_formats|packed depth/stencil image format]], it is possible to access the stencil component ''instead'' of the depth component. This is controlled by the parameter {{enum|GL_DEPTH_STENCIL_TEXTURE_MODE}}.

−

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.

+

When the parameter is set to {{enum|GL_DEPTH_COMPONENT}}, then accessing it from the shader will access the depth component as a single float, as normal. But when the parameter is set to {{enum|GL_STENCIL_COMPONENT}}, the shader can access the stencil component.

−

To perform such an operation, you must use the following functions:

+

This parameter changes the very nature of the texture access. The stencil component is an ''unsigned integer'' value, so you must use an unsigned integer sampler when accessing it. When accessing the stencil component of a 2D depth/stencil texture, you must use {{code|usampler2D}}.

{{note|Though this parameter affects sampling, it is not a ''sampling parameter''. As such, you cannot bind the same texture object to two image units and use two different samplers to fetch the depth and stencil components. However, you ''can'' create a [[Texture_Storage#Texture_views|view of the texture]] (both that and this are GL 4.3 features), and set different texture parameters into the different views. One view for the depth, one view for the stencil.}}

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

+

== Sampling parameters ==

+

{{main|Sampler Object#Sampling parameters}}

−

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.

+

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

−

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 <code>glCompressedTexSubImage</code> formats on a texture that doesn't use a non-generic compressed format.

+

These parameter are shared with [[Sampler Object]]s, in that both texture objects and sampler objects have them.

−

−

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 ==

== Texture image units ==

−

Binding textures 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.

+

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 <code>glBindTexture</code> 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 <code>glBindTexture</code> call binds the texture to depends on the current active texture image unit. This value is set by calling:

−

−

void glActiveTexture( GLenum ''texture'' );

−

−

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.'' This is a corner case in the spec and implementations may not implement it properly. It is safer to simply let each sampler have its own texture image unit.}}

−

−

The <code>glActiveTexture</code> function will affect the functioning of any function that takes a texture ''target'' as a parameter.

−

−

== Texture sampling ==

−

−

Sampling is the process of fetching a value from a texture at a given position. [[GLSL Samplers|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.

+

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

−

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.

+

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 {{enum|GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS}}.

−

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.

+

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

−

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.

+

void {{apifunc|glActiveTexture}}( GLenum {{param|texture}} );

−

The OpenGL minification settings for these are as follows:

+

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

−

{| class="wikitable" border="1"

+

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 Sampler|GLSL]], this depends on the type of sampler that uses this texture image unit.

−

|-

−

! 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.

+

{{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.}}

−

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 {{apifunc|glActiveTexture}} function defines the texture image unit that any function that takes a texture ''target'' as a parameter uses.

−

−

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 behavior; it is governed by the extension GL_EXT_texture_filter_anisotropic. However, this extension is available [[Ubiquitous Extensions|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.

−

−

=== Comparison mode ===

−

−

=== 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.

* GL_CLAMP_TO_EDGE: the texture coordinate is clamped to the [0, 1] range.

−

* GL_CLAMP_TO_BORDER: the texture coordinate is clamped to the [0, 1] range, but the edge texels are blended with a constant border color.

== GLSL binding ==

== GLSL binding ==

Line 258:

Line 163:

=== Samplers ===

=== Samplers ===

−

{{main|GLSL Samplers}}

+

{{main|Sampler (GLSL)}}

−

A ''sampler'' in [[GLSL]] is a special uniform variable. 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.

+

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.

Samplers are used with GLSL texture access functions.

−

=== Programs and textures ===

+

[[Sampler_(GLSL)#Binding_textures_to_samplers|The process of using textures with program samplers]] involves 2 halves. Texture objects are not directly associated with or attached to program objects. 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.

−

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 [[GLSL Uniforms|uniform]] value for the program samplers. For each sampler uniform, set its uniform value to an integer on the range [0, {{enum|GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS}}). When the time comes to use the program directly, simply use {{apifunc|glActiveTexture}} and {{apifunc|glBindTexture}} to bind the textures of interest to these image units.

−

So the first step is to set the [[GLSL Uniforms|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 <code>glActiveTexture</code> and <code>glBindTexture</code> 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 {{code|sampler1D}} will look to the {{enum|GL_TEXTURE_1D}} binding in the image unit it is set in.

−

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

+

If a [[Sampler Object]] is bound to the same texture image unit as a texture, then the sampler object's [[Sampler Object#Sampling parameters|parameters]] will ''replace'' the sampling parameters from that texture object.

−

== Rendet targets ==

+

=== Images ===

+

{{main|Image Load Store}}

+

+

Images within a texture can be used for arbitrary image load/store operations. Image uniforms in GLSL are associated with images in a similar way as for samplers, as described above.

+

+

== Render targets ==

{{main|Framebuffer Objects}}

{{main|Framebuffer Objects}}

−

Through the use of a framebuffer object, individual images within a texture can be the destination for rendering.

+

Through the use of a framebuffer object, individual images within a texture can be the destination for rendering. [[GLSL_Type#Images|Image uniforms]] are associated with an image unit (different from a ''texture'' image unit). Images are bound to image units with {{apifunc|glBindImageTexture}}.

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.

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.

Storage

Texture objects come in three parts: storage, sampling parameters, and texture parameters. There are numerous functions to create a texture's storage; so many that the article needs its own page to describe them all.

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 parameter pname​ in the texture bound to target​.

In the anatomy of a texture object image above, it shows three pieces of data: Texture Storage, texture parameters, and sampling parameters. It's important to understand that both of the last two kinds of data are set by the same functions for textures. Certain parameters are about the texture itself, and some are about sampling from them.

This section will describe the texture parameters only.

Mipmap range

The 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.

Note that 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.

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:

Stencil texturing

A texture with a depth image format is normally considered a depth component texture. This means that non-depth comparison access will return a single floating-point value (as depth components are either normalized integers or floats). Depth textures in this way can be considered a special form of single-channel floating-point color textures.

However, if the texture uses a packed depth/stencil image format, it is possible to access the stencil component instead of the depth component. This is controlled by the parameter GL_DEPTH_STENCIL_TEXTURE_MODE.

When the parameter is set to GL_DEPTH_COMPONENT, then accessing it from the shader will access the depth component as a single float, as normal. But when the parameter is set to GL_STENCIL_COMPONENT, the shader can access the stencil component.

This parameter changes the very nature of the texture access. The stencil component is an unsigned integer value, so you must use an unsigned integer sampler when accessing it. When accessing the stencil component of a 2D depth/stencil texture, you must use usampler2D​.

Note: Though this parameter affects sampling, it is not a sampling parameter. As such, you cannot bind the same texture object to two image units and use two different samplers to fetch the depth and stencil components. However, you can create a view of the texture (both that and this are GL 4.3 features), and set different texture parameters into the different views. One view for the depth, one view for the stencil.

Sampling parameters

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 parameters that affect this as well.

These parameter are shared with Sampler Objects, in that both texture objects and sampler objects have them.

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.

GLSL binding

Programs are one of the two users of textures. In order to use textures with a program, the program itself must use certain syntax to expose texture binding points.

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.

The process of using textures with program samplers involves 2 halves. Texture objects are not directly associated with or attached to program objects. 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.

If a Sampler Object is bound to the same texture image unit as a texture, then the sampler object's parameters will replace the sampling parameters from that texture object.

Render targets

Through the use of a framebuffer object, individual images within a texture can be the destination for rendering. Image uniforms are associated with an image unit (different from a texture image unit). Images are bound to image units with glBindImageTexture​.