?GL_MAX_TEXTURE_SIZE, and ?GL_MAX_3D_TEXTURE_SIZE are not really descriptive enough. It has to report the largest square texture image that can be accommodated with mipmaps and borders, but a long skinny texture, or a texture without mipmaps and borders, may easily fit in texture memory. The proxy targets allow the user to more accurately query whether the GL can accommodate a texture of a given configuration. If the texture cannot be accommodated, the texture state variables, which may be queried with gl:getTexLevelParameter , are set to 0. If the texture can be accommodated, the texture state values will be set as they would be set for a non-proxy target.
Pname specifies the texture parameter whose value or values will be returned.
The accepted parameter names are as follows:
?GL_TEXTURE_WIDTH: Params returns a single value, the width of the texture image. This value includes the border of the texture image. The initial value is 0.
?GL_TEXTURE_HEIGHT: Params returns a single value, the height of the texture image. This value includes the border of the texture image. The initial value is 0.
?GL_TEXTURE_DEPTH: Params returns a single value, the depth of the texture image. This value includes the border of the texture image. The initial value is 0.
?GL_TEXTURE_INTERNAL_FORMAT: Params returns a single value, the internal format of the texture image.
?GL_TEXTURE_RED_TYPE,
?GL_TEXTURE_GREEN_TYPE,
?GL_TEXTURE_BLUE_TYPE,
?GL_TEXTURE_ALPHA_TYPE,
?GL_TEXTURE_DEPTH_TYPE: The data type used to store the component. The types ?GL_NONE , ?GL_SIGNED_NORMALIZED, ?GL_UNSIGNED_NORMALIZED, ?GL_FLOAT, ?GL_INT , and ?GL_UNSIGNED_INT may be returned to indicate signed normalized fixed-point, unsigned normalized fixed-point, floating-point, integer unnormalized, and unsigned integer unnormalized components, respectively.
?GL_TEXTURE_RED_SIZE,
?GL_TEXTURE_GREEN_SIZE,
?GL_TEXTURE_BLUE_SIZE,
?GL_TEXTURE_ALPHA_SIZE,
?GL_TEXTURE_DEPTH_SIZE: The internal storage resolution of an individual component. The resolution chosen by the GL will be a close match for the resolution requested by the user with the component argument of gl:texImage1D/8 , gl:texImage2D/9 , gl:texImage3D/10 , gl:copyTexImage1D/7 , and gl:copyTexImage2D/8 . The initial value is 0.
?GL_TEXTURE_COMPRESSED: Params returns a single boolean value indicating if the texture image is stored in a compressed internal format. The initiali value is ?GL_FALSE .
?GL_TEXTURE_COMPRESSED_IMAGE_SIZE: Params returns a single integer value, the number of unsigned bytes of the compressed texture image that would be returned from gl:getCompressedTexImage/3 .
See external documentation.
getTexLevelParameteriv(Target, Level, Pname) -> {integer()}
texImage1D(Target, Level, InternalFormat, Width, Border, Format, Type, Pixels) -> ok
Types
Specify a one-dimensional texture image
Texturing maps a portion of a specified texture image onto each graphical primitive for which texturing is enabled. To enable and disable one-dimensional texturing, call gl:enable/1 and gl:enable/1 with argument ?GL_TEXTURE_1D.
Texture images are defined with gl:texImage1D. The arguments describe the parameters of the texture image, such as width, width of the border, level-of-detail number (see gl:texParameterf/3 ), and the internal resolution and format used to store the image. The last three arguments describe how the image is represented in memory.
If Target is ?GL_PROXY_TEXTURE_1D, no data is read from Data , but all of the texture image state is recalculated, checked for consistency, and checked against the implementation's capabilities. If the implementation cannot handle a texture of the requested texture size, it sets all of the image state to 0, but does not generate an error (see gl:getError/0 ). To query for an entire mipmap array, use an image array level greater than or equal to 1.
If Target is ?GL_TEXTURE_1D, data is read from Data as a sequence of signed or unsigned bytes, shorts, or longs, or single-precision floating-point values, depending on Type . These values are grouped into sets of one, two, three, or four values, depending on Format , to form elements. Each data byte is treated as eight 1-bit elements, with bit ordering determined by ?GL_UNPACK_LSB_FIRST (see gl:pixelStoref/2 ).
If a non-zero named buffer object is bound to the ?GL_PIXEL_UNPACK_BUFFER target (see gl:bindBuffer/2 ) while a texture image is specified, Data is treated as a byte offset into the buffer object's data store.
The first element corresponds to the left end of the texture array. Subsequent elements progress left-to-right through the remaining texels in the texture array. The final element corresponds to the right end of the texture array.
Format determines the composition of each element in Data . It can assume one of these symbolic values:
?GL_RED: Each element is a single red component. The GL converts it to floating point and assembles it into an RGBA element by attaching 0 for green and blue, and 1 for alpha. Each component is then multiplied by the signed scale factor ?GL_c_SCALE, added to the signed bias ?GL_c_BIAS, and clamped to the range [0,1].
?GL_RG: Each element is a single red/green double The GL converts it to floating point and assembles it into an RGBA element by attaching 0 for blue, and 1 for alpha. Each component is then multiplied by the signed scale factor ?GL_c_SCALE, added to the signed bias ?GL_c_BIAS, and clamped to the range [0,1].
?GL_RGB
?GL_BGR: Each element is an RGB triple. The GL converts it to floating point and assembles it into an RGBA element by attaching 1 for alpha. Each component is then multiplied by the signed scale factor ?GL_c_SCALE, added to the signed bias ?GL_c_BIAS, and clamped to the range [0,1].
?GL_RGBA
?GL_BGRA: Each element contains all four components. Each component is multiplied by the signed scale factor ?GL_c_SCALE, added to the signed bias ?GL_c_BIAS, and clamped to the range [0,1].
?GL_DEPTH_COMPONENT: Each element is a single depth value. The GL converts it to floating point, multiplies by the signed scale factor ?GL_DEPTH_SCALE, adds the signed bias ?GL_DEPTH_BIAS, and clamps to the range [0,1].
If an application wants to store the texture at a certain resolution or in a certain format, it can request the resolution and format with InternalFormat . The GL will choose an internal representation that closely approximates that requested by InternalFormat , but it may not match exactly. (The representations specified by ?GL_RED, ?GL_RG , ?GL_RGB and ?GL_RGBA must match exactly.)
InternalFormat may be one of the base internal formats shown in Table 1, below
InternalFormat may also be one of the sized internal formats shown in Table 2, below
Finally, InternalFormat may also be one of the generic or compressed compressed texture formats shown in Table 3 below
If the InternalFormat parameter is one of the generic compressed formats, ?GL_COMPRESSED_RED , ?GL_COMPRESSED_RG, ?GL_COMPRESSED_RGB, or ?GL_COMPRESSED_RGBA, the GL will replace the internal format with the symbolic constant for a specific internal format and compress the texture before storage. If no corresponding internal format is available, or the GL can not compress that image for any reason, the internal format is instead replaced with a corresponding base internal format.
If the InternalFormat parameter is ?GL_SRGB, ?GL_SRGB8, ?GL_SRGB_ALPHA or ?GL_SRGB8_ALPHA8, the texture is treated as if the red, green, or blue components are encoded in the sRGB color space. Any alpha component is left unchanged. The conversion from the sRGB encoded component c s to a linear component c l is:
c l={ c s/12.92if c s≤ 0.04045( c s+0.055/1.055) 2.4if c s> 0.04045
Assume c s is the sRGB component in the range [0,1].
Use the ?GL_PROXY_TEXTURE_1D target to try out a resolution and format. The implementation will update and recompute its best match for the requested storage resolution and format. To then query this state, call gl:getTexLevelParameterfv/3 . If the texture cannot be accommodated, texture state is set to 0.
A one-component texture image uses only the red component of the RGBA color from Data . A two-component image uses the R and A values. A three-component image uses the R, G, and B values. A four-component image uses all of the RGBA components.
Image-based shadowing can be enabled by comparing texture r coordinates to depth texture values to generate a boolean result. See gl:texParameterf/3 for details on texture comparison.
See external documentation.
texImage2D(Target, Level, InternalFormat, Width, Height, Border, Format, Type, Pixels) -> ok
Types
Specify a two-dimensional texture image
Texturing allows elements of an image array to be read by shaders.
To define texture images, call gl:texImage2D. The arguments describe the parameters of the texture image, such as height, width, width of the border, level-of-detail number (see gl:texParameterf/3 ), and number of color components provided. The last three arguments describe how the image is represented in memory.
If Target is ?GL_PROXY_TEXTURE_2D, ?GL_PROXY_TEXTURE_1D_ARRAY, ?GL_PROXY_TEXTURE_CUBE_MAP , or ?GL_PROXY_TEXTURE_RECTANGLE, no data is read from Data , but all of the texture image state is recalculated, checked for consistency, and checked against the implementation's capabilities. If the implementation cannot handle a texture of the requested texture size, it sets all of the image state to 0, but does not generate an error (see gl:getError/0 ). To query for an entire mipmap array, use an image array level greater than or equal to 1.
If Target is ?GL_TEXTURE_2D, ?GL_TEXTURE_RECTANGLE or one of the ?GL_TEXTURE_CUBE_MAP targets, data is read from Data as a sequence of signed or unsigned bytes, shorts, or longs, or single-precision floating-point values, depending on Type . These values are grouped into sets of one, two, three, or four values, depending on Format , to form elements. Each data byte is treated as eight 1-bit elements, with bit ordering determined by ?GL_UNPACK_LSB_FIRST (see gl:pixelStoref/2 ).
If Target is ?GL_TEXTURE_1D_ARRAY, data is interpreted as an array of one-dimensional images.
If a non-zero named buffer object is bound to the ?GL_PIXEL_UNPACK_BUFFER target (see gl:bindBuffer/2 ) while a texture image is specified, Data is treated as a byte offset into the buffer object's data store.
The first element corresponds to the lower left corner of the texture image. Subsequent elements progress left-to-right through the remaining texels in the lowest row of the texture image, and then in successively higher rows of the texture image. The final element corresponds to the upper right corner of the texture image.
Format determines the composition of each element in Data . It can assume one of these symbolic values:
?GL_RED: Each element is a single red component. The GL converts it to floating point and assembles it into an RGBA element by attaching 0 for green and blue, and 1 for alpha. Each component is then multiplied by the signed scale factor ?GL_c_SCALE, added to the signed bias ?GL_c_BIAS, and clamped to the range [0,1].
?GL_RG: Each element is a red/green double. The GL converts it to floating point and assembles it into an RGBA element by attaching 0 for blue, and 1 for alpha. Each component is then multiplied by the signed scale factor ?GL_c_SCALE, added to the signed bias ?GL_c_BIAS, and clamped to the range [0,1].
?GL_RGB
?GL_BGR: Each element is an RGB triple. The GL converts it to floating point and assembles it into an RGBA element by attaching 1 for alpha. Each component is then multiplied by the signed scale factor ?GL_c_SCALE, added to the signed bias ?GL_c_BIAS, and clamped to the range [0,1].
?GL_RGBA
?GL_BGRA: Each element contains all four components. Each component is multiplied by the signed scale factor ?GL_c_SCALE, added to the signed bias ?GL_c_BIAS, and clamped to the range [0,1].
?GL_DEPTH_COMPONENT: Each element is a single depth value. The GL converts it to floating point, multiplies by the signed scale factor ?GL_DEPTH_SCALE, adds the signed bias ?GL_DEPTH_BIAS, and clamps to the range [0,1].
?GL_DEPTH_STENCIL: Each element is a pair of depth and stencil values. The depth component of the pair is interpreted as in ?GL_DEPTH_COMPONENT. The stencil component is interpreted based on specified the depth + stencil internal format.
If an application wants to store the texture at a certain resolution or in a certain format, it can request the resolution and format with InternalFormat . The GL will choose an internal representation that closely approximates that requested by InternalFormat , but it may not match exactly. (The representations specified by ?GL_RED, ?GL_RG , ?GL_RGB, and ?GL_RGBA must match exactly.)
InternalFormat may be one of the base internal formats shown in Table 1, below
InternalFormat may also be one of the sized internal formats shown in Table 2, below
Finally, InternalFormat may also be one of the generic or compressed compressed texture formats shown in Table 3 below
If the InternalFormat parameter is one of the generic compressed formats, ?GL_COMPRESSED_RED , ?GL_COMPRESSED_RG, ?GL_COMPRESSED_RGB, or ?GL_COMPRESSED_RGBA, the GL will replace the internal format with the symbolic constant for a specific internal format and compress the texture before storage. If no corresponding internal format is available, or the GL can not compress that image for any reason, the internal format is instead replaced with a corresponding base internal format.
If the InternalFormat parameter is ?GL_SRGB, ?GL_SRGB8, ?GL_SRGB_ALPHA , or ?GL_SRGB8_ALPHA8, the texture is treated as if the red, green, or blue components are encoded in the sRGB color space. Any alpha component is left unchanged. The conversion from the sRGB encoded component c s to a linear component c l is:
c l={ c s/12.92if c s≤ 0.04045( c s+0.055/1.055) 2.4if c s> 0.04045
Assume c s is the sRGB component in the range [0,1].
Use the ?GL_PROXY_TEXTURE_2D, ?GL_PROXY_TEXTURE_1D_ARRAY, ?GL_PROXY_TEXTURE_RECTANGLE , or ?GL_PROXY_TEXTURE_CUBE_MAP target to try out a resolution and format. The implementation will update and recompute its best match for the requested storage resolution and format. To then query this state, call gl:getTexLevelParameterfv/3 . If the texture cannot be accommodated, texture state is set to 0.
A one-component texture image uses only the red component of the RGBA color extracted from Data . A two-component image uses the R and G values. A three-component image uses the R, G, and B values. A four-component image uses all of the RGBA components.
Image-based shadowing can be enabled by comparing texture r coordinates to depth texture values to generate a boolean result. See gl:texParameterf/3 for details on texture comparison.
See external documentation.
getTexImage(Target, Level, Format, Type, Pixels) -> ok
Return a texture image
gl:getTexImage returns a texture image into Img . Target specifies whether the desired texture image is one specified by gl:texImage1D/8 (?GL_TEXTURE_1D ), gl:texImage2D/9 (?GL_TEXTURE_1D_ARRAY, ?GL_TEXTURE_RECTANGLE, ?GL_TEXTURE_2D or any of ?GL_TEXTURE_CUBE_MAP_*), or gl:texImage3D/10 (?GL_TEXTURE_2D_ARRAY , ?GL_TEXTURE_3D). Level specifies the level-of-detail number of the desired image. Format and Type specify the format and type of the desired image array. See the reference page for gl:texImage1D/8 for a description of the acceptable values for the Format and Type parameters, respectively.
If a non-zero named buffer object is bound to the ?GL_PIXEL_PACK_BUFFER target (see gl:bindBuffer/2 ) while a texture image is requested, Img is treated as a byte offset into the buffer object's data store.
To understand the operation of gl:getTexImage, consider the selected internal four-component texture image to be an RGBA color buffer the size of the image. The semantics of gl:getTexImage are then identical to those of gl:readPixels/7 , with the exception that no pixel transfer operations are performed, when called with the same Format and Type , with x and y set to 0, width set to the width of the texture image and height set to 1 for 1D images, or to the height of the texture image for 2D images.
If the selected texture image does not contain four components, the following mappings are applied. Single-component textures are treated as RGBA buffers with red set to the single-component value, green set to 0, blue set to 0, and alpha set to 1. Two-component textures are treated as RGBA buffers with red set to the value of component zero, alpha set to the value of component one, and green and blue set to 0. Finally, three-component textures are treated as RGBA buffers with red set to component zero, green set to component one, blue set to component two, and alpha set to 1.
To determine the required size of Img , use gl:getTexLevelParameterfv/3 to determine the dimensions of the internal texture image, then scale the required number of pixels by the storage required for each pixel, based on Format and Type . Be sure to take the pixel storage parameters into account, especially ?GL_PACK_ALIGNMENT .
See external documentation.
Types
Generate texture names
gl:genTextures returns N texture names in Textures . There is no guarantee that the names form a contiguous set of integers; however, it is guaranteed that none of the returned names was in use immediately before the call to gl:genTextures.
The generated textures have no dimensionality; they assume the dimensionality of the texture target to which they are first bound (see gl:bindTexture/2 ).
Texture names returned by a call to gl:genTextures are not returned by subsequent calls, unless they are first deleted with gl:deleteTextures/1 .
See external documentation.
deleteTextures(Textures) -> ok
Types
Delete named textures
gl:deleteTextures deletes N textures named by the elements of the array Textures . After a texture is deleted, it has no contents or dimensionality, and its name is free for reuse (for example by gl:genTextures/1 ). If a texture that is currently bound is deleted, the binding reverts to 0 (the default texture).
gl:deleteTextures silently ignores 0's and names that do not correspond to existing textures.
See external documentation.
bindTexture(Target, Texture) -> ok
Bind a named texture to a texturing target
gl:bindTexture lets you create or use a named texture. Calling gl:bindTexture with Target set to ?GL_TEXTURE_1D, ?GL_TEXTURE_2D, ?GL_TEXTURE_3D , or ?GL_TEXTURE_1D_ARRAY, ?GL_TEXTURE_2D_ARRAY, ?GL_TEXTURE_RECTANGLE , ?GL_TEXTURE_CUBE_MAP, ?GL_TEXTURE_2D_MULTISAMPLE or ?GL_TEXTURE_2D_MULTISAMPLE_ARRAY and Texture set to the name of the new texture binds the texture name to the target. When a texture is bound to a target, the previous binding for that target is automatically broken.
Texture names are unsigned integers. The value zero is reserved to represent the default texture for each texture target. Texture names and the corresponding texture contents are local to the shared object space of the current GL rendering context; two rendering contexts share texture names only if they explicitly enable sharing between contexts through the appropriate GL windows interfaces functions.
You must use gl:genTextures/1 to generate a set of new texture names.
 The state of a one-dimensional texture immediately after it is first bound is equivalent to the state of the default ?GL_TEXTURE_1D at GL initialization, and similarly for the other texture types.
While a texture is bound, GL operations on the target to which it is bound affect the bound texture, and queries of the target to which it is bound return state from the bound texture. In effect, the texture targets become aliases for the textures currently bound to them, and the texture name zero refers to the default textures that were bound to them at initialization.
A texture binding created with gl:bindTexture remains active until a different texture is bound to the same target, or until the bound texture is deleted with gl:deleteTextures/1 .
Once created, a named texture may be re-bound to its same original target as often as needed. It is usually much faster to use gl:bindTexture to bind an existing named texture to one of the texture targets than it is to reload the texture image using gl:texImage1D/8 , gl:texImage2D/9 , gl:texImage3D/10 or another similar function.
See external documentation.
prioritizeTextures(Textures, Priorities) -> ok
Set texture residence priority
gl:prioritizeTextures assigns the N texture priorities given in Priorities to the N textures named in Textures .
The GL establishes a working set of textures that are resident in texture memory. These textures may be bound to a texture target much more efficiently than textures that are not resident. By specifying a priority for each texture, gl:prioritizeTextures allows applications to guide the GL implementation in determining which textures should be resident.
The priorities given in Priorities are clamped to the range [0 1] before they are assigned. 0 indicates the lowest priority; textures with priority 0 are least likely to be resident. 1 indicates the highest priority; textures with priority 1 are most likely to be resident. However, textures are not guaranteed to be resident until they are used.
gl:prioritizeTextures silently ignores attempts to prioritize texture 0 or any texture name that does not correspond to an existing texture.
gl:prioritizeTextures does not require that any of the textures named by Textures be bound to a texture target. gl:texParameterf/3 may also be used to set a texture's priority, but only if the texture is currently bound. This is the only way to set the priority of a default texture.
See external documentation.
areTexturesResident(Textures) -> {0 | 1, Residences::[0 | 1]}
Types
Determine if textures are loaded in texture memory
GL establishes a working set of textures that are resident in texture memory. These textures can be bound to a texture target much more efficiently than textures that are not resident.
gl:areTexturesResident queries the texture residence status of the N textures named by the elements of Textures . If all the named textures are resident, gl:areTexturesResident returns ?GL_TRUE, and the contents of Residences are undisturbed. If not all the named textures are resident, gl:areTexturesResident returns ?GL_FALSE, and detailed status is returned in the N elements of Residences . If an element of Residences is ?GL_TRUE, then the texture named by the corresponding element of Textures is resident.
The residence status of a single bound texture may also be queried by calling gl:getTexParameterfv/2 with the target argument set to the target to which the texture is bound, and the pname argument set to ?GL_TEXTURE_RESIDENT. This is the only way that the residence status of a default texture can be queried.
See external documentation.
Types
Determine if a name corresponds to a texture
gl:isTexture returns ?GL_TRUE if Texture is currently the name of a texture. If Texture is zero, or is a non-zero value that is not currently the name of a texture, or if an error occurs, gl:isTexture returns ?GL_FALSE.
A name returned by gl:genTextures/1 , but not yet associated with a texture by calling gl:bindTexture/2 , is not the name of a texture.
See external documentation.
texSubImage1D(Target, Level, Xoffset, Width, Format, Type, Pixels) -> ok
Types
texSubImage2D(Target, Level, Xoffset, Yoffset, Width, Height, Format, Type, Pixels) -> ok
Types
copyTexImage1D(Target, Level, Internalformat, X, Y, Width, Border) -> ok
Types
Copy pixels into a 1D texture image
gl:copyTexImage1D defines a one-dimensional texture image with pixels from the current ?GL_READ_BUFFER.
The screen-aligned pixel row with left corner at (x y) and with a length of width+2(border) defines the texture array at the mipmap level specified by Level . Internalformat specifies the internal format of the texture array.
The pixels in the row are processed exactly as if gl:readPixels/7 had been called, but the process stops just before final conversion. At this point all pixel component values are clamped to the range [0 1] and then converted to the texture's internal format for storage in the texel array.
Pixel ordering is such that lower x screen coordinates correspond to lower texture coordinates.
If any of the pixels within the specified row of the current ?GL_READ_BUFFER are outside the window associated with the current rendering context, then the values obtained for those pixels are undefined.
gl:copyTexImage1D defines a one-dimensional texture image with pixels from the current ?GL_READ_BUFFER.
When Internalformat is one of the sRGB types, the GL does not automatically convert the source pixels to the sRGB color space. In this case, the gl:pixelMap function can be used to accomplish the conversion.
See external documentation.
copyTexImage2D(Target, Level, Internalformat, X, Y, Width, Height, Border) -> ok
Types
Copy pixels into a 2D texture image
gl:copyTexImage2D defines a two-dimensional texture image, or cube-map texture image with pixels from the current ?GL_READ_BUFFER.
The screen-aligned pixel rectangle with lower left corner at ( X , Y ) and with a width of width+2(border) and a height of height+2(border) defines the texture array at the mipmap level specified by Level . Internalformat specifies the internal format of the texture array.
The pixels in the rectangle are processed exactly as if gl:readPixels/7 had been called, but the process stops just before final conversion. At this point all pixel component values are clamped to the range [0 1] and then converted to the texture's internal format for storage in the texel array.
Pixel ordering is such that lower x and y screen coordinates correspond to lower s and t texture coordinates.
If any of the pixels within the specified rectangle of the current ?GL_READ_BUFFER are outside the window associated with the current rendering context, then the values obtained for those pixels are undefined.
When Internalformat is one of the sRGB types, the GL does not automatically convert the source pixels to the sRGB color space. In this case, the gl:pixelMap function can be used to accomplish the conversion.
See external documentation.
copyTexSubImage1D(Target, Level, Xoffset, X, Y, Width) -> ok
Types
Copy a one-dimensional texture subimage
gl:copyTexSubImage1D replaces a portion of a one-dimensional texture image with pixels from the current ?GL_READ_BUFFER (rather than from main memory, as is the case for gl:texSubImage1D/7 ).
The screen-aligned pixel row with left corner at ( X , Y ), and with length Width replaces the portion of the texture array with x indices Xoffset through xoffset +width-1, inclusive. The destination in the texture array may not include any texels outside the texture array as it was originally specified.
The pixels in the row are processed exactly as if gl:readPixels/7 had been called, but the process stops just before final conversion. At this point, all pixel component values are clamped to the range [0 1] and then converted to the texture's internal format for storage in the texel array.
It is not an error to specify a subtexture with zero width, but such a specification has no effect. If any of the pixels within the specified row of the current ?GL_READ_BUFFER are outside the read window associated with the current rendering context, then the values obtained for those pixels are undefined.
No change is made to the internalformat, width, or border parameters of the specified texture array or to texel values outside the specified subregion.
See external documentation.
copyTexSubImage2D(Target, Level, Xoffset, Yoffset, X, Y, Width, Height) -> ok
Types
Copy a two-dimensional texture subimage
gl:copyTexSubImage2D replaces a rectangular portion of a two-dimensional texture image or cube-map texture image with pixels from the current ?GL_READ_BUFFER (rather than from main memory, as is the case for gl:texSubImage1D/7 ).
The screen-aligned pixel rectangle with lower left corner at (x y) and with width Width and height Height replaces the portion of the texture array with x indices Xoffset through xoffset+width-1, inclusive, and y indices Yoffset through yoffset+height -1, inclusive, at the mipmap level specified by Level .
The pixels in the rectangle are processed exactly as if gl:readPixels/7 had been called, but the process stops just before final conversion. At this point, all pixel component values are clamped to the range [0 1] and then converted to the texture's internal format for storage in the texel array.
The destination rectangle in the texture array may not include any texels outside the texture array as it was originally specified. It is not an error to specify a subtexture with zero width or height, but such a specification has no effect.
If any of the pixels within the specified rectangle of the current ?GL_READ_BUFFER are outside the read window associated with the current rendering context, then the values obtained for those pixels are undefined.
No change is made to the internalformat, width, height, or border parameters of the specified texture array or to texel values outside the specified subregion.
See external documentation.
map1d(Target, U1, U2, Stride, Order, Points) -> ok
Types
map1f(Target, U1, U2, Stride, Order, Points) -> ok
Types
map2d(Target, U1, U2, Ustride, Uorder, V1, V2, Vstride, Vorder, Points) -> ok
Types
map2f(Target, U1, U2, Ustride, Uorder, V1, V2, Vstride, Vorder, Points) -> ok
Types
getMapdv(Target, Query, V) -> ok
Return evaluator parameters
gl:map1d/6 and gl:map1d/6 define evaluators. gl:getMap returns evaluator parameters. Target chooses a map, Query selects a specific parameter, and V points to storage where the values will be returned.
The acceptable values for the Target parameter are described in the gl:map1d/6 and gl:map1d/6 reference pages.
Query can assume the following values:
?GL_COEFF: V returns the control points for the evaluator function. One-dimensional evaluators return order control points, and two-dimensional evaluators return uorder×vorder control points. Each control point consists of one, two, three, or four integer, single-precision floating-point, or double-precision floating-point values, depending on the type of the evaluator. The GL returns two-dimensional control points in row-major order, incrementing the uorder index quickly and the vorder index after each row. Integer values, when requested, are computed by rounding the internal floating-point values to the nearest integer values.
?GL_ORDER: V returns the order of the evaluator function. One-dimensional evaluators return a single value, order. The initial value is 1. Two-dimensional evaluators return two values, uorder and vorder. The initial value is 1,1.
?GL_DOMAIN: V returns the linear u and v mapping parameters. One-dimensional evaluators return two values, u1 and u2, as specified by gl:map1d/6 . Two-dimensional evaluators return four values ( u1, u2, v1, and v2) as specified by gl:map1d/6 . Integer values, when requested, are computed by rounding the internal floating-point values to the nearest integer values.
See external documentation.
getMapfv(Target, Query, V) -> ok
See getMapdv/3
getMapiv(Target, Query, V) -> ok
See getMapdv/3
Types
Evaluate enabled one- and two-dimensional maps
gl:evalCoord1 evaluates enabled one-dimensional maps at argument U . gl:evalCoord2 does the same for two-dimensional maps using two domain values, U and V . To define a map, call gl:map1d/6 and gl:map1d/6 ; to enable and disable it, call gl:enable/1 and gl:enable/1 .
When one of the gl:evalCoord commands is issued, all currently enabled maps of the indicated dimension are evaluated. Then, for each enabled map, it is as if the corresponding GL command had been issued with the computed value. That is, if ?GL_MAP1_INDEX or ?GL_MAP2_INDEX is enabled, a gl:indexd/1 command is simulated. If ?GL_MAP1_COLOR_4 or ?GL_MAP2_COLOR_4 is enabled, a gl:color3b/3 command is simulated. If ?GL_MAP1_NORMAL or ?GL_MAP2_NORMAL is enabled, a normal vector is produced, and if any of ?GL_MAP1_TEXTURE_COORD_1, ?GL_MAP1_TEXTURE_COORD_2 , ?GL_MAP1_TEXTURE_COORD_3, ?GL_MAP1_TEXTURE_COORD_4, ?GL_MAP2_TEXTURE_COORD_1 , ?GL_MAP2_TEXTURE_COORD_2, ?GL_MAP2_TEXTURE_COORD_3, or ?GL_MAP2_TEXTURE_COORD_4 is enabled, then an appropriate gl:texCoord1d/1 command is simulated.
For color, color index, normal, and texture coordinates the GL uses evaluated values instead of current values for those evaluations that are enabled, and current values otherwise, However, the evaluated values do not update the current values. Thus, if gl:vertex2d/2 commands are interspersed with gl:evalCoord commands, the color, normal, and texture coordinates associated with the gl:vertex2d/2 commands are not affected by the values generated by the gl:evalCoord commands, but only by the most recent gl:color3b/3 , gl:indexd/1 , gl:normal3b/3 , and gl:texCoord1d/1 commands.
No commands are issued for maps that are not enabled. If more than one texture evaluation is enabled for a particular dimension (for example, ?GL_MAP2_TEXTURE_COORD_1 and ?GL_MAP2_TEXTURE_COORD_2 ), then only the evaluation of the map that produces the larger number of coordinates (in this case, ?GL_MAP2_TEXTURE_COORD_2) is carried out. ?GL_MAP1_VERTEX_4 overrides ?GL_MAP1_VERTEX_3, and ?GL_MAP2_VERTEX_4 overrides ?GL_MAP2_VERTEX_3 , in the same manner. If neither a three- nor a four-component vertex map is enabled for the specified dimension, the gl:evalCoord command is ignored.
If you have enabled automatic normal generation, by calling gl:enable/1 with argument ?GL_AUTO_NORMAL, gl:evalCoord2 generates surface normals analytically, regardless of the contents or enabling of the ?GL_MAP2_NORMAL map. Let
m=((∂ p)/(∂ u))×((∂ p)/(∂ v))
Then the generated normal n is n=m/(||m||)
If automatic normal generation is disabled, the corresponding normal map ?GL_MAP2_NORMAL , if enabled, is used to produce a normal. If neither automatic normal generation nor a normal map is enabled, no normal is generated for gl:evalCoord2 commands.
See external documentation.
Types
See evalCoord1d/1
Types
Equivalent to evalCoord1d(U).
Types
Equivalent to evalCoord1f(U).
Types
See evalCoord1d/1
Types
See evalCoord1d/1
Types
Equivalent to evalCoord2d(U, V).
Types
Equivalent to evalCoord2f(U, V).
Types
Define a one- or two-dimensional mesh
gl:mapGrid and gl:evalMesh1/3 are used together to efficiently generate and evaluate a series of evenly-spaced map domain values. gl:evalMesh1/3 steps through the integer domain of a one- or two-dimensional grid, whose range is the domain of the evaluation maps specified by gl:map1d/6 and gl:map1d/6 .
gl:mapGrid1 and gl:mapGrid2 specify the linear grid mappings between the i (or i and j) integer grid coordinates, to the u (or u and v) floating-point evaluation map coordinates. See gl:map1d/6 and gl:map1d/6 for details of how u and v coordinates are evaluated.
gl:mapGrid1 specifies a single linear mapping such that integer grid coordinate 0 maps exactly to U1 , and integer grid coordinate Un maps exactly to U2 . All other integer grid coordinates i are mapped so that
u=i(u2-u1)/un+u1
gl:mapGrid2 specifies two such linear mappings. One maps integer grid coordinate i=0 exactly to U1 , and integer grid coordinate i=un exactly to U2 . The other maps integer grid coordinate j=0 exactly to V1 , and integer grid coordinate j=vn exactly to V2 . Other integer grid coordinates i and j are mapped such that
u=i(u2-u1)/un+u1
v=j(v2-v1)/vn+v1
The mappings specified by gl:mapGrid are used identically by gl:evalMesh1/3 and gl:evalPoint1/1 .
See external documentation.
Types
See mapGrid1d/3
mapGrid2d(Un, U1, U2, Vn, V1, V2) -> ok
Types
See mapGrid1d/3
mapGrid2f(Un, U1, U2, Vn, V1, V2) -> ok
Types
See mapGrid1d/3
Types
Generate and evaluate a single point in a mesh
gl:mapGrid1d/3 and gl:evalMesh1/3 are used in tandem to efficiently generate and evaluate a series of evenly spaced map domain values. gl:evalPoint can be used to evaluate a single grid point in the same gridspace that is traversed by gl:evalMesh1/3 . Calling gl:evalPoint1 is equivalent to calling glEvalCoord1( i.Δ u+u 1 ); where Δ u=(u 2-u 1)/n
and n, u 1, and u 2 are the arguments to the most recent gl:mapGrid1d/3 command. The one absolute numeric requirement is that if i=n, then the value computed from i.Δ u+u 1 is exactly u 2.
In the two-dimensional case, gl:evalPoint2, let
Δ u=(u 2-u 1)/n
Δ v=(v 2-v 1)/m
where n, u 1, u 2, m, v 1, and v 2 are the arguments to the most recent gl:mapGrid1d/3 command. Then the gl:evalPoint2 command is equivalent to calling glEvalCoord2( i. Δ u+u 1, j.Δ v+v 1 ); The only absolute numeric requirements are that if i=n, then the value computed from i.Δ u+u 1 is exactly u 2, and if j=m, then the value computed from j.Δ v+v 1 is exactly v 2.
See external documentation.
Types
See evalPoint1/1
Compute a one- or two-dimensional grid of points or lines
gl:mapGrid1d/3 and gl:evalMesh are used in tandem to efficiently generate and evaluate a series of evenly-spaced map domain values. gl:evalMesh steps through the integer domain of a one- or two-dimensional grid, whose range is the domain of the evaluation maps specified by gl:map1d/6 and gl:map1d/6 . Mode determines whether the resulting vertices are connected as points, lines, or filled polygons.
In the one-dimensional case, gl:evalMesh1, the mesh is generated as if the following code fragment were executed:
glBegin( Type ); for ( i = I1 ; i <= I2 ; i += 1 ) glEvalCoord1( i.Δ u+u 1 ); glEnd(); where
Δ u=(u 2-u 1)/n
and n, u 1, and u 2 are the arguments to the most recent gl:mapGrid1d/3 command. type is ?GL_POINTS if Mode is ?GL_POINT, or ?GL_LINES if Mode is ?GL_LINE.
The one absolute numeric requirement is that if i=n, then the value computed from i.Δ u+u 1 is exactly u 2.
In the two-dimensional case, gl:evalMesh2, let .cp Δ u=(u 2-u 1)/n
Δ v=(v 2-v 1)/m
where n, u 1, u 2, m, v 1, and v 2 are the arguments to the most recent gl:mapGrid1d/3 command. Then, if Mode is ?GL_FILL, the gl:evalMesh2 command is equivalent to:
for ( j = J1 ; j < J2 ; j += 1 ) { glBegin( GL_QUAD_STRIP ); for ( i = I1 ; i <= I2 ; i += 1 ) { glEvalCoord2( i.Δ u+u 1, j.Δ v+v 1 ); glEvalCoord2( i.Δ u+u 1,(j+1).Δ v+v 1 ); } glEnd(); }
If Mode is ?GL_LINE, then a call to gl:evalMesh2 is equivalent to:
for ( j = J1 ; j <= J2 ; j += 1 ) { glBegin( GL_LINE_STRIP ); for ( i = I1 ; i <= I2 ; i += 1 ) glEvalCoord2( i.Δ u+u 1, j.Δ v+v 1 ); glEnd(); } for ( i = I1 ; i <= I2 ; i += 1 ) { glBegin( GL_LINE_STRIP ); for ( j = J1 ; j <= J1 ; j += 1 ) glEvalCoord2( i.Δ u+u 1, j. Δ v+v 1 ); glEnd(); }
And finally, if Mode is ?GL_POINT, then a call to gl:evalMesh2 is equivalent to:
glBegin( GL_POINTS ); for ( j = J1 ; j <= J2 ; j += 1 ) for ( i = I1 ; i <= I2 ; i += 1 ) glEvalCoord2( i.Δ u+u 1, j.Δ v+v 1 ); glEnd();
In all three cases, the only absolute numeric requirements are that if i=n, then the value computed from i.Δ u+u 1 is exactly u 2, and if j=m, then the value computed from j.Δ v+v 1 is exactly v 2.
See external documentation.
evalMesh2(Mode, I1, I2, J1, J2) -> ok
See evalMesh1/3
Specify fog parameters
Fog is initially disabled. While enabled, fog affects rasterized geometry, bitmaps, and pixel blocks, but not buffer clear operations. To enable and disable fog, call gl:enable/1 and gl:enable/1 with argument ?GL_FOG.
gl:fog assigns the value or values in Params to the fog parameter specified by Pname . The following values are accepted for Pname :
?GL_FOG_MODE: Params is a single integer or floating-point value that specifies the equation to be used to compute the fog blend factor, f. Three symbolic constants are accepted: ?GL_LINEAR, ?GL_EXP, and ?GL_EXP2. The equations corresponding to these symbolic constants are defined below. The initial fog mode is ?GL_EXP.
?GL_FOG_DENSITY: Params is a single integer or floating-point value that specifies density, the fog density used in both exponential fog equations. Only nonnegative densities are accepted. The initial fog density is 1.
?GL_FOG_START: Params is a single integer or floating-point value that specifies start, the near distance used in the linear fog equation. The initial near distance is 0.
?GL_FOG_END: Params is a single integer or floating-point value that specifies end, the far distance used in the linear fog equation. The initial far distance is 1.
?GL_FOG_INDEX: Params is a single integer or floating-point value that specifies i f, the fog color index. The initial fog index is 0.
?GL_FOG_COLOR: Params contains four integer or floating-point values that specify C f, the fog color. Integer values are mapped linearly such that the most positive representable value maps to 1.0, and the most negative representable value maps to -1.0. Floating-point values are mapped directly. After conversion, all color components are clamped to the range [0 1]. The initial fog color is (0, 0, 0, 0).
?GL_FOG_COORD_SRC: Params contains either of the following symbolic constants: ?GL_FOG_COORD or ?GL_FRAGMENT_DEPTH. ?GL_FOG_COORD specifies that the current fog coordinate should be used as distance value in the fog color computation. ?GL_FRAGMENT_DEPTH specifies that the current fragment depth should be used as distance value in the fog computation.
Fog blends a fog color with each rasterized pixel fragment's post-texturing color using a blending factor f. Factor f is computed in one of three ways, depending on the fog mode. Let c be either the distance in eye coordinate from the origin (in the case that the ?GL_FOG_COORD_SRC is ?GL_FRAGMENT_DEPTH) or the current fog coordinate (in the case that ?GL_FOG_COORD_SRC is ?GL_FOG_COORD). The equation for ?GL_LINEAR fog is f=(end-c)/(end-start)
The equation for ?GL_EXP fog is f=e(-(density. c))
The equation for ?GL_EXP2 fog is f=e(-(density. c)) 2
Regardless of the fog mode, f is clamped to the range [0 1] after it is computed. Then, if the GL is in RGBA color mode, the fragment's red, green, and blue colors, represented by C r, are replaced by
(C r)"=f×C r+(1-f)×C f
Fog does not affect a fragment's alpha component.
In color index mode, the fragment's color index i r is replaced by
(i r)"=i r+(1-f)×i f
See external documentation.
See fogf/2
See fogf/2
See fogf/2
feedbackBuffer(Size, Type, Buffer) -> ok
Controls feedback mode
The gl:feedbackBuffer function controls feedback. Feedback, like selection, is a GL mode. The mode is selected by calling gl:renderMode/1 with ?GL_FEEDBACK. When the GL is in feedback mode, no pixels are produced by rasterization. Instead, information about primitives that would have been rasterized is fed back to the application using the GL.
gl:feedbackBuffer has three arguments: Buffer is a pointer to an array of floating-point values into which feedback information is placed. Size indicates the size of the array. Type is a symbolic constant describing the information that is fed back for each vertex. gl:feedbackBuffer must be issued before feedback mode is enabled (by calling gl:renderMode/1 with argument ?GL_FEEDBACK). Setting ?GL_FEEDBACK without establishing the feedback buffer, or calling gl:feedbackBuffer while the GL is in feedback mode, is an error.
When gl:renderMode/1 is called while in feedback mode, it returns the number of entries placed in the feedback array and resets the feedback array pointer to the base of the feedback buffer. The returned value never exceeds Size . If the feedback data required more room than was available in Buffer , gl:renderMode/1 returns a negative value. To take the GL out of feedback mode, call gl:renderMode/1 with a parameter value other than ?GL_FEEDBACK.
While in feedback mode, each primitive, bitmap, or pixel rectangle that would be rasterized generates a block of values that are copied into the feedback array. If doing so would cause the number of entries to exceed the maximum, the block is partially written so as to fill the array (if there is any room left at all), and an overflow flag is set. Each block begins with a code indicating the primitive type, followed by values that describe the primitive's vertices and associated data. Entries are also written for bitmaps and pixel rectangles. Feedback occurs after polygon culling and gl:polygonMode/2 interpretation of polygons has taken place, so polygons that are culled are not returned in the feedback buffer. It can also occur after polygons with more than three edges are broken up into triangles, if the GL implementation renders polygons by performing this decomposition.
The gl:passThrough/1 command can be used to insert a marker into the feedback buffer. See gl:passThrough/1 .
Following is the grammar for the blocks of values written into the feedback buffer. Each primitive is indicated with a unique identifying value followed by some number of vertices. Polygon entries include an integer value indicating how many vertices follow. A vertex is fed back as some number of floating-point values, as determined by Type . Colors are fed back as four values in RGBA mode and one value in color index mode.
feedbackList ← feedbackItem feedbackList | feedbackItem
feedbackItem ← point | lineSegment | polygon | bitmap | pixelRectangle | passThru
point ←?GL_POINT_TOKEN vertex
lineSegment ←?GL_LINE_TOKEN vertex vertex | ?GL_LINE_RESET_TOKEN vertex vertex
polygon ←?GL_POLYGON_TOKEN n polySpec
polySpec ← polySpec vertex | vertex vertex vertex
bitmap ←?GL_BITMAP_TOKEN vertex
pixelRectangle ←?GL_DRAW_PIXEL_TOKEN vertex | ?GL_COPY_PIXEL_TOKEN vertex
passThru ←?GL_PASS_THROUGH_TOKEN value
vertex ← 2d | 3d | 3dColor | 3dColorTexture | 4dColorTexture
2d ← value value
3d ← value value value
3dColor ← value value value color
3dColorTexture ← value value value color tex
4dColorTexture ← value value value value color tex
color ← rgba | index
rgba ← value value value value
index ← value
tex ← value value value value
value is a floating-point number, and n is a floating-point integer giving the number of vertices in the polygon. ?GL_POINT_TOKEN, ?GL_LINE_TOKEN, ?GL_LINE_RESET_TOKEN , ?GL_POLYGON_TOKEN, ?GL_BITMAP_TOKEN, ?GL_DRAW_PIXEL_TOKEN, ?GL_COPY_PIXEL_TOKEN and ?GL_PASS_THROUGH_TOKEN are symbolic floating-point constants. ?GL_LINE_RESET_TOKEN is returned whenever the line stipple pattern is reset. The data returned as a vertex depends on the feedback Type .
The following table gives the correspondence between Type and the number of values per vertex. k is 1 in color index mode and 4 in RGBA mode.
TypeCoordinatesColor TextureTotal Number of Values?GL_2Dx, y 2
?GL_3D x, y, z 3
?GL_3D_COLOR x, y, z k 3+k
?GL_3D_COLOR_TEXTURE x, y, z k 4 7+k
?GL_4D_COLOR_TEXTUREx, y, z, w k 4 8+k
Feedback vertex coordinates are in window coordinates, except w, which is in clip coordinates. Feedback colors are lighted, if lighting is enabled. Feedback texture coordinates are generated, if texture coordinate generation is enabled. They are always transformed by the texture matrix.
See external documentation.
Types
Place a marker in the feedback buffer
Feedback is a GL render mode. The mode is selected by calling gl:renderMode/1 with ?GL_FEEDBACK. When the GL is in feedback mode, no pixels are produced by rasterization. Instead, information about primitives that would have been rasterized is fed back to the application using the GL. See the gl:feedbackBuffer/3 reference page for a description of the feedback buffer and the values in it.
gl:passThrough inserts a user-defined marker in the feedback buffer when it is executed in feedback mode. Token is returned as if it were a primitive; it is indicated with its own unique identifying value: ?GL_PASS_THROUGH_TOKEN. The order of gl:passThrough commands with respect to the specification of graphics primitives is maintained.
See external documentation.
selectBuffer(Size, Buffer) -> ok
Establish a buffer for selection mode values
gl:selectBuffer has two arguments: Buffer is a pointer to an array of unsigned integers, and Size indicates the size of the array. Buffer returns values from the name stack (see gl:initNames/0 , gl:loadName/1 , gl:pushName/1 ) when the rendering mode is ?GL_SELECT (see gl:renderMode/1 ). gl:selectBuffer must be issued before selection mode is enabled, and it must not be issued while the rendering mode is ?GL_SELECT.
A programmer can use selection to determine which primitives are drawn into some region of a window. The region is defined by the current modelview and perspective matrices.
In selection mode, no pixel fragments are produced from rasterization. Instead, if a primitive or a raster position intersects the clipping volume defined by the viewing frustum and the user-defined clipping planes, this primitive causes a selection hit. (With polygons, no hit occurs if the polygon is culled.) When a change is made to the name stack, or when gl:renderMode/1 is called, a hit record is copied to Buffer if any hits have occurred since the last such event (name stack change or gl:renderMode/1 call). The hit record consists of the number of names in the name stack at the time of the event, followed by the minimum and maximum depth values of all vertices that hit since the previous event, followed by the name stack contents, bottom name first.
Depth values (which are in the range [0,1]) are multiplied by 2 32-1, before being placed in the hit record.
An internal index into Buffer is reset to 0 whenever selection mode is entered. Each time a hit record is copied into Buffer , the index is incremented to point to the cell just past the end of the block of names(emthat is, to the next available cell If the hit record is larger than the number of remaining locations in Buffer , as much data as can fit is copied, and the overflow flag is set. If the name stack is empty when a hit record is copied, that record consists of 0 followed by the minimum and maximum depth values.
To exit selection mode, call gl:renderMode/1 with an argument other than ?GL_SELECT . Whenever gl:renderMode/1 is called while the render mode is ?GL_SELECT, it returns the number of hit records copied to Buffer , resets the overflow flag and the selection buffer pointer, and initializes the name stack to be empty. If the overflow bit was set when gl:renderMode/1 was called, a negative hit record count is returned.
See external documentation.
Initialize the name stack
The name stack is used during selection mode to allow sets of rendering commands to be uniquely identified. It consists of an ordered set of unsigned integers. gl:initNames causes the name stack to be initialized to its default empty state.
The name stack is always empty while the render mode is not ?GL_SELECT. Calls to gl:initNames while the render mode is not ?GL_SELECT are ignored.
See external documentation.
Types
Load a name onto the name stack
The name stack is used during selection mode to allow sets of rendering commands to be uniquely identified. It consists of an ordered set of unsigned integers and is initially empty.
gl:loadName causes Name to replace the value on the top of the name stack.
The name stack is always empty while the render mode is not ?GL_SELECT. Calls to gl:loadName while the render mode is not ?GL_SELECT are ignored.
See external documentation.
Types
Push and pop the name stack
The name stack is used during selection mode to allow sets of rendering commands to be uniquely identified. It consists of an ordered set of unsigned integers and is initially empty.
gl:pushName causes Name to be pushed onto the name stack. gl:pushName/1 pops one name off the top of the stack.
The maximum name stack depth is implementation-dependent; call ?GL_MAX_NAME_STACK_DEPTH to find out the value for a particular implementation. It is an error to push a name onto a full stack or to pop a name off an empty stack. It is also an error to manipulate the name stack between the execution of gl:'begin'/1 and the corresponding execution of gl:'begin'/1 . In any of these cases, the error flag is set and no other change is made to GL state.
The name stack is always empty while the render mode is not ?GL_SELECT. Calls to gl:pushName or gl:pushName/1 while the render mode is not ?GL_SELECT are ignored.
See external documentation.
See pushName/1
blendColor(Red, Green, Blue, Alpha) -> ok
Set the blend color
The ?GL_BLEND_COLOR may be used to calculate the source and destination blending factors. The color components are clamped to the range [0 1] before being stored. See gl:blendFunc/2 for a complete description of the blending operations. Initially the ?GL_BLEND_COLOR is set to (0, 0, 0, 0).
See external documentation.
Types
Specify the equation used for both the RGB blend equation and the Alpha blend equation
The blend equations determine how a new pixel (the ''source'' color) is combined with a pixel already in the framebuffer (the ''destination'' color). This function sets both the RGB blend equation and the alpha blend equation to a single equation. gl:blendEquationi specifies the blend equation for a single draw buffer whereas gl:blendEquation sets the blend equation for all draw buffers.
These equations use the source and destination blend factors specified by either gl:blendFunc/2 or gl:blendFuncSeparate/4 . See gl:blendFunc/2 or gl:blendFuncSeparate/4 for a description of the various blend factors.
In the equations that follow, source and destination color components are referred to as (R s G s B s A s) and (R d G d B d A d), respectively. The result color is referred to as (R r G r B r A r). The source and destination blend factors are denoted (s R s G s B s A) and (d R d G d B d A), respectively. For these equations all color components are understood to have values in the range [0 1].

The ?GL_MIN and ?GL_MAX equations are useful for applications that analyze image data (image thresholding against a constant color, for example). The ?GL_FUNC_ADD equation is useful for antialiasing and transparency, among other things.
Initially, both the RGB blend equation and the alpha blend equation are set to ?GL_FUNC_ADD .
See external documentation.
drawRangeElements(Mode, Start, End, Count, Type, Indices) -> ok
Render primitives from array data
gl:drawRangeElements is a restricted form of gl:drawElements/4 . Mode , Start , End , and Count match the corresponding arguments to gl:drawElements/4 , with the additional constraint that all values in the arrays Count must lie between Start and End , inclusive.
Implementations denote recommended maximum amounts of vertex and index data, which may be queried by calling gl:getBooleanv/1 with argument ?GL_MAX_ELEMENTS_VERTICES and ?GL_MAX_ELEMENTS_INDICES . If end-start+1 is greater than the value of ?GL_MAX_ELEMENTS_VERTICES, or if Count is greater than the value of ?GL_MAX_ELEMENTS_INDICES, then the call may operate at reduced performance. There is no requirement that all vertices in the range [start end] be referenced. However, the implementation may partially process unused vertices, reducing performance from what could be achieved with an optimal index set.
When gl:drawRangeElements is called, it uses Count sequential elements from an enabled array, starting at Start to construct a sequence of geometric primitives. Mode specifies what kind of primitives are constructed, and how the array elements construct these primitives. If more than one array is enabled, each is used.
Vertex attributes that are modified by gl:drawRangeElements have an unspecified value after gl:drawRangeElements returns. Attributes that aren't modified maintain their previous values.
See external documentation.
texImage3D(Target, Level, InternalFormat, Width, Height, Depth, Border, Format, Type, Pixels) -> ok
Types
Specify a three-dimensional texture image
Texturing maps a portion of a specified texture image onto each graphical primitive for which texturing is enabled. To enable and disable three-dimensional texturing, call gl:enable/1 and gl:enable/1 with argument ?GL_TEXTURE_3D.
To define texture images, call gl:texImage3D. The arguments describe the parameters of the texture image, such as height, width, depth, width of the border, level-of-detail number (see gl:texParameterf/3 ), and number of color components provided. The last three arguments describe how the image is represented in memory.
If Target is ?GL_PROXY_TEXTURE_3D, no data is read from Data , but all of the texture image state is recalculated, checked for consistency, and checked against the implementation's capabilities. If the implementation cannot handle a texture of the requested texture size, it sets all of the image state to 0, but does not generate an error (see gl:getError/0 ). To query for an entire mipmap array, use an image array level greater than or equal to 1.
If Target is ?GL_TEXTURE_3D, data is read from Data as a sequence of signed or unsigned bytes, shorts, or longs, or single-precision floating-point values, depending on Type . These values are grouped into sets of one, two, three, or four values, depending on Format , to form elements. Each data byte is treated as eight 1-bit elements, with bit ordering determined by ?GL_UNPACK_LSB_FIRST (see gl:pixelStoref/2 ).
If a non-zero named buffer object is bound to the ?GL_PIXEL_UNPACK_BUFFER target (see gl:bindBuffer/2 ) while a texture image is specified, Data is treated as a byte offset into the buffer object's data store.
The first element corresponds to the lower left corner of the texture image. Subsequent elements progress left-to-right through the remaining texels in the lowest row of the texture image, and then in successively higher rows of the texture image. The final element corresponds to the upper right corner of the texture image.
Format determines the composition of each element in Data . It can assume one of these symbolic values:
?GL_RED: Each element is a single red component. The GL converts it to floating point and assembles it into an RGBA element by attaching 0 for green and blue, and 1 for alpha. Each component is then multiplied by the signed scale factor ?GL_c_SCALE, added to the signed bias ?GL_c_BIAS, and clamped to the range [0,1].
?GL_RG: Each element is a red and green pair. The GL converts each to floating point and assembles it into an RGBA element by attaching 0 for blue, and 1 for alpha. Each component is then multiplied by the signed scale factor ?GL_c_SCALE, added to the signed bias ?GL_c_BIAS, and clamped to the range [0,1].
?GL_RGB
?GL_BGR: Each element is an RGB triple. The GL converts it to floating point and assembles it into an RGBA element by attaching 1 for alpha. Each component is then multiplied by the signed scale factor ?GL_c_SCALE, added to the signed bias ?GL_c_BIAS, and clamped to the range [0,1].
?GL_RGBA
?GL_BGRA: Each element contains all four components. Each component is multiplied by the signed scale factor ?GL_c_SCALE, added to the signed bias ?GL_c_BIAS, and clamped to the range [0,1].
If an application wants to store the texture at a certain resolution or in a certain format, it can request the resolution and format with InternalFormat . The GL will choose an internal representation that closely approximates that requested by InternalFormat , but it may not match exactly. (The representations specified by ?GL_RED, ?GL_RG , ?GL_RGB, and ?GL_RGBA must match exactly.)
InternalFormat may be one of the base internal formats shown in Table 1, below
InternalFormat may also be one of the sized internal formats shown in Table 2, below
Finally, InternalFormat may also be one of the generic or compressed compressed texture formats shown in Table 3 below
If the InternalFormat parameter is one of the generic compressed formats, ?GL_COMPRESSED_RED , ?GL_COMPRESSED_RG, ?GL_COMPRESSED_RGB, or ?GL_COMPRESSED_RGBA, the GL will replace the internal format with the symbolic constant for a specific internal format and compress the texture before storage. If no corresponding internal format is available, or the GL can not compress that image for any reason, the internal format is instead replaced with a corresponding base internal format.
If the InternalFormat parameter is ?GL_SRGB, ?GL_SRGB8, ?GL_SRGB_ALPHA , or ?GL_SRGB8_ALPHA8, the texture is treated as if the red, green, blue, or luminance components are encoded in the sRGB color space. Any alpha component is left unchanged. The conversion from the sRGB encoded component c s to a linear component c l is:
c l={ c s/12.92if c s≤ 0.04045( c s+0.055/1.055) 2.4if c s> 0.04045
Assume c s is the sRGB component in the range [0,1].
Use the ?GL_PROXY_TEXTURE_3D target to try out a resolution and format. The implementation will update and recompute its best match for the requested storage resolution and format. To then query this state, call gl:getTexLevelParameterfv/3 . If the texture cannot be accommodated, texture state is set to 0.
A one-component texture image uses only the red component of the RGBA color extracted from Data . A two-component image uses the R and A values. A three-component image uses the R, G, and B values. A four-component image uses all of the RGBA components.
See external documentation.
texSubImage3D(Target, Level, Xoffset, Yoffset, Zoffset, Width, Height, Depth, Format, Type, Pixels) -> ok
Types
copyTexSubImage3D(Target, Level, Xoffset, Yoffset, Zoffset, X, Y, Width, Height) -> ok
Types
Copy a three-dimensional texture subimage
gl:copyTexSubImage3D replaces a rectangular portion of a three-dimensional texture image with pixels from the current ?GL_READ_BUFFER (rather than from main memory, as is the case for gl:texSubImage1D/7 ).
The screen-aligned pixel rectangle with lower left corner at ( X , Y ) and with width Width and height Height replaces the portion of the texture array with x indices Xoffset through xoffset+width-1, inclusive, and y indices Yoffset through yoffset+height-1, inclusive, at z index Zoffset and at the mipmap level specified by Level .
The pixels in the rectangle are processed exactly as if gl:readPixels/7 had been called, but the process stops just before final conversion. At this point, all pixel component values are clamped to the range [0 1] and then converted to the texture's internal format for storage in the texel array.
The destination rectangle in the texture array may not include any texels outside the texture array as it was originally specified. It is not an error to specify a subtexture with zero width or height, but such a specification has no effect.
If any of the pixels within the specified rectangle of the current ?GL_READ_BUFFER are outside the read window associated with the current rendering context, then the values obtained for those pixels are undefined.
No change is made to the internalformat, width, height, depth, or border parameters of the specified texture array or to texel values outside the specified subregion.
See external documentation.
colorTable(Target, Internalformat, Width, Format, Type, Table) -> ok
Define a color lookup table
gl:colorTable may be used in two ways: to test the actual size and color resolution of a lookup table given a particular set of parameters, or to load the contents of a color lookup table. Use the targets ?GL_PROXY_* for the first case and the other targets for the second case.
If a non-zero named buffer object is bound to the ?GL_PIXEL_UNPACK_BUFFER target (see gl:bindBuffer/2 ) while a color table is specified, Data is treated as a byte offset into the buffer object's data store.
If Target is ?GL_COLOR_TABLE, ?GL_POST_CONVOLUTION_COLOR_TABLE, or ?GL_POST_COLOR_MATRIX_COLOR_TABLE , gl:colorTable builds a color lookup table from an array of pixels. The pixel array specified by Width , Format , Type , and Data is extracted from memory and processed just as if gl:drawPixels/5 were called, but processing stops after the final expansion to RGBA is completed.
The four scale parameters and the four bias parameters that are defined for the table are then used to scale and bias the R, G, B, and A components of each pixel. (Use gl:colorTableParameter to set these scale and bias parameters.)
Next, the R, G, B, and A values are clamped to the range [0 1]. Each pixel is then converted to the internal format specified by Internalformat . This conversion simply maps the component values of the pixel (R, G, B, and A) to the values included in the internal format (red, green, blue, alpha, luminance, and intensity). The mapping is as follows:
Internal FormatRedGreen BlueAlphaLuminanceIntensity?GL_ALPHA A
?GL_LUMINANCE R
?GL_LUMINANCE_ALPHA A R
?GL_INTENSITY R
?GL_RGB R G B
?GL_RGBA R G B A
Finally, the red, green, blue, alpha, luminance, and/or intensity components of the resulting pixels are stored in the color table. They form a one-dimensional table with indices in the range [0 width-1].
If Target is ?GL_PROXY_*, gl:colorTable recomputes and stores the values of the proxy color table's state variables ?GL_COLOR_TABLE_FORMAT, ?GL_COLOR_TABLE_WIDTH , ?GL_COLOR_TABLE_RED_SIZE, ?GL_COLOR_TABLE_GREEN_SIZE, ?GL_COLOR_TABLE_BLUE_SIZE , ?GL_COLOR_TABLE_ALPHA_SIZE, ?GL_COLOR_TABLE_LUMINANCE_SIZE, and ?GL_COLOR_TABLE_INTENSITY_SIZE . There is no effect on the image or state of any actual color table. If the specified color table is too large to be supported, then all the proxy state variables listed above are set to zero. Otherwise, the color table could be supported by gl:colorTable using the corresponding non-proxy target, and the proxy state variables are set as if that target were being defined.
The proxy state variables can be retrieved by calling gl:getColorTableParameterfv/2 with a target of ?GL_PROXY_*. This allows the application to decide if a particular gl:colorTable command would succeed, and to determine what the resulting color table attributes would be.
If a color table is enabled, and its width is non-zero, then its contents are used to replace a subset of the components of each RGBA pixel group, based on the internal format of the table.
Each pixel group has color components (R, G, B, A) that are in the range [0.0 1.0]. The color components are rescaled to the size of the color lookup table to form an index. Then a subset of the components based on the internal format of the table are replaced by the table entry selected by that index. If the color components and contents of the table are represented as follows:
RepresentationMeaningr Table index computed from R
g Table index computed from G
b Table index computed from B
a Table index computed from A
L[i] Luminance value at table index i
I[i] Intensity value at table index i
R[i] Red value at table index i
G[i] Green value at table index i
B[i] Blue value at table index i
A[i] Alpha value at table index i
then the result of color table lookup is as follows:
Resulting Texture ComponentsTable Internal Format RGBA
?GL_ALPHARGBA[a]
?GL_LUMINANCEL[r]L[g]L[b]At
?GL_LUMINANCE_ALPHA L[r]L[g]L[b]A[a]
?GL_INTENSITY I[r]I[g]I[b]I[a]
?GL_RGBR[r] G[g]B[b]A
?GL_RGBAR[r] G[g]B[b]A[a]
When ?GL_COLOR_TABLE is enabled, the colors resulting from the pixel map operation (if it is enabled) are mapped by the color lookup table before being passed to the convolution operation. The colors resulting from the convolution operation are modified by the post convolution color lookup table when ?GL_POST_CONVOLUTION_COLOR_TABLE is enabled. These modified colors are then sent to the color matrix operation. Finally, if ?GL_POST_COLOR_MATRIX_COLOR_TABLE is enabled, the colors resulting from the color matrix operation are mapped by the post color matrix color lookup table before being used by the histogram operation.
See external documentation.
colorTableParameterfv(Target, Pname, Params) -> ok
Set color lookup table parameters
gl:colorTableParameter is used to specify the scale factors and bias terms applied to color components when they are loaded into a color table. Target indicates which color table the scale and bias terms apply to; it must be set to ?GL_COLOR_TABLE, ?GL_POST_CONVOLUTION_COLOR_TABLE , or ?GL_POST_COLOR_MATRIX_COLOR_TABLE.
Pname must be ?GL_COLOR_TABLE_SCALE to set the scale factors. In this case, Params points to an array of four values, which are the scale factors for red, green, blue, and alpha, in that order.
Pname must be ?GL_COLOR_TABLE_BIAS to set the bias terms. In this case, Params points to an array of four values, which are the bias terms for red, green, blue, and alpha, in that order.
The color tables themselves are specified by calling gl:colorTable/6 .
See external documentation.
colorTableParameteriv(Target, Pname, Params) -> ok
copyColorTable(Target, Internalformat, X, Y, Width) -> ok
Copy pixels into a color table
gl:copyColorTable loads a color table with pixels from the current ?GL_READ_BUFFER (rather than from main memory, as is the case for gl:colorTable/6 ).
The screen-aligned pixel rectangle with lower-left corner at ( X , Y ) having width Width and height 1 is loaded into the color table. If any pixels within this region are outside the window that is associated with the GL context, the values obtained for those pixels are undefined.
The pixels in the rectangle are processed just as if gl:readPixels/7 were called, with Internalformat set to RGBA, but processing stops after the final conversion to RGBA.
The four scale parameters and the four bias parameters that are defined for the table are then used to scale and bias the R, G, B, and A components of each pixel. The scale and bias parameters are set by calling gl:colorTableParameterfv/3 .
Next, the R, G, B, and A values are clamped to the range [0 1]. Each pixel is then converted to the internal format specified by Internalformat . This conversion simply maps the component values of the pixel (R, G, B, and A) to the values included in the internal format (red, green, blue, alpha, luminance, and intensity). The mapping is as follows:
Internal FormatRedGreen BlueAlphaLuminanceIntensity?GL_ALPHA A
?GL_LUMINANCE R
?GL_LUMINANCE_ALPHA A R
?GL_INTENSITY R
?GL_RGB R G B
?GL_RGBA R G B A
Finally, the red, green, blue, alpha, luminance, and/or intensity components of the resulting pixels are stored in the color table. They form a one-dimensional table with indices in the range [0 width-1].
See external documentation.
getColorTable(Target, Format, Type, Table) -> ok
Retrieve contents of a color lookup table
gl:getColorTable returns in Table the contents of the color table specified by Target . No pixel transfer operations are performed, but pixel storage modes that are applicable to gl:readPixels/7 are performed.
If a non-zero named buffer object is bound to the ?GL_PIXEL_PACK_BUFFER target (see gl:bindBuffer/2 ) while a histogram table is requested, Table is treated as a byte offset into the buffer object's data store.
Color components that are requested in the specified Format , but which are not included in the internal format of the color lookup table, are returned as zero. The assignments of internal color components to the components requested by Format are
Internal ComponentResulting ComponentRed Red
Green Green
Blue Blue
Alpha Alpha
Luminance Red
Intensity Red
See external documentation.
getColorTableParameterfv(Target, Pname) -> {float(), float(), float(), float()}
Get color lookup table parameters
Returns parameters specific to color table Target .
When Pname is set to ?GL_COLOR_TABLE_SCALE or ?GL_COLOR_TABLE_BIAS, gl:getColorTableParameter returns the color table scale or bias parameters for the table specified by Target . For these queries, Target must be set to ?GL_COLOR_TABLE , ?GL_POST_CONVOLUTION_COLOR_TABLE, or ?GL_POST_COLOR_MATRIX_COLOR_TABLE and Params points to an array of four elements, which receive the scale or bias factors for red, green, blue, and alpha, in that order.
gl:getColorTableParameter can also be used to retrieve the format and size parameters for a color table. For these queries, set Target to either the color table target or the proxy color table target. The format and size parameters are set by gl:colorTable/6 .
The following table lists the format and size parameters that may be queried. For each symbolic constant listed below for Pname , Params must point to an array of the given length and receive the values indicated.
ParameterNMeaning?GL_COLOR_TABLE_FORMAT 1 Internal format (e.g., ?GL_RGBA)
?GL_COLOR_TABLE_WIDTH 1 Number of elements in table
?GL_COLOR_TABLE_RED_SIZE 1 Size of red component, in bits
?GL_COLOR_TABLE_GREEN_SIZE 1 Size of green component
?GL_COLOR_TABLE_BLUE_SIZE 1 Size of blue component
?GL_COLOR_TABLE_ALPHA_SIZE 1 Size of alpha component
?GL_COLOR_TABLE_LUMINANCE_SIZE 1 Size of luminance component
?GL_COLOR_TABLE_INTENSITY_SIZE 1 Size of intensity component
See external documentation.
getColorTableParameteriv(Target, Pname) -> {integer(), integer(), integer(), integer()}
colorSubTable(Target, Start, Count, Format, Type, Data) -> ok
Respecify a portion of a color table
gl:colorSubTable is used to respecify a contiguous portion of a color table previously defined using gl:colorTable/6 . The pixels referenced by Data replace the portion of the existing table from indices Start to start+count-1, inclusive. This region may not include any entries outside the range of the color table as it was originally specified. It is not an error to specify a subtexture with width of 0, but such a specification has no effect.
If a non-zero named buffer object is bound to the ?GL_PIXEL_UNPACK_BUFFER target (see gl:bindBuffer/2 ) while a portion of a color table is respecified, Data is treated as a byte offset into the buffer object's data store.
See external documentation.
copyColorSubTable(Target, Start, X, Y, Width) -> ok
Respecify a portion of a color table
gl:copyColorSubTable is used to respecify a contiguous portion of a color table previously defined using gl:colorTable/6 . The pixels copied from the framebuffer replace the portion of the existing table from indices Start to start+x-1, inclusive. This region may not include any entries outside the range of the color table, as was originally specified. It is not an error to specify a subtexture with width of 0, but such a specification has no effect.
See external documentation.
convolutionFilter1D(Target, Internalformat, Width, Format, Type, Image) -> ok
Define a one-dimensional convolution filter
gl:convolutionFilter1D builds a one-dimensional convolution filter kernel from an array of pixels.
The pixel array specified by Width , Format , Type , and Data is extracted from memory and processed just as if gl:drawPixels/5 were called, but processing stops after the final expansion to RGBA is completed.
If a non-zero named buffer object is bound to the ?GL_PIXEL_UNPACK_BUFFER target (see gl:bindBuffer/2 ) while a convolution filter is specified, Data is treated as a byte offset into the buffer object's data store.
The R, G, B, and A components of each pixel are next scaled by the four 1D ?GL_CONVOLUTION_FILTER_SCALE parameters and biased by the four 1D ?GL_CONVOLUTION_FILTER_BIAS parameters. (The scale and bias parameters are set by gl:convolutionParameterf/3 using the ?GL_CONVOLUTION_1D target and the names ?GL_CONVOLUTION_FILTER_SCALE and ?GL_CONVOLUTION_FILTER_BIAS . The parameters themselves are vectors of four values that are applied to red, green, blue, and alpha, in that order.) The R, G, B, and A values are not clamped to [0,1] at any time during this process.
Each pixel is then converted to the internal format specified by Internalformat . This conversion simply maps the component values of the pixel (R, G, B, and A) to the values included in the internal format (red, green, blue, alpha, luminance, and intensity). The mapping is as follows:
Internal FormatRedGreen BlueAlphaLuminanceIntensity?GL_ALPHA A
?GL_LUMINANCE R
?GL_LUMINANCE_ALPHA A R
?GL_INTENSITY R
?GL_RGB R G B
?GL_RGBA R G B A
The red, green, blue, alpha, luminance, and/or intensity components of the resulting pixels are stored in floating-point rather than integer format. They form a one-dimensional filter kernel image indexed with coordinate i such that i starts at 0 and increases from left to right. Kernel location i is derived from the ith pixel, counting from 0.
Note that after a convolution is performed, the resulting color components are also scaled by their corresponding ?GL_POST_CONVOLUTION_c_SCALE parameters and biased by their corresponding ?GL_POST_CONVOLUTION_c_BIAS parameters (where c takes on the values RED, GREEN, BLUE, and ALPHA). These parameters are set by gl:pixelTransferf/2 .
See external documentation.
convolutionFilter2D(Target, Internalformat, Width, Height, Format, Type, Image) -> ok
Types
Define a two-dimensional convolution filter
gl:convolutionFilter2D builds a two-dimensional convolution filter kernel from an array of pixels.
The pixel array specified by Width , Height , Format , Type , and Data is extracted from memory and processed just as if gl:drawPixels/5 were called, but processing stops after the final expansion to RGBA is completed.
If a non-zero named buffer object is bound to the ?GL_PIXEL_UNPACK_BUFFER target (see gl:bindBuffer/2 ) while a convolution filter is specified, Data is treated as a byte offset into the buffer object's data store.
The R, G, B, and A components of each pixel are next scaled by the four 2D ?GL_CONVOLUTION_FILTER_SCALE parameters and biased by the four 2D ?GL_CONVOLUTION_FILTER_BIAS parameters. (The scale and bias parameters are set by gl:convolutionParameterf/3 using the ?GL_CONVOLUTION_2D target and the names ?GL_CONVOLUTION_FILTER_SCALE and ?GL_CONVOLUTION_FILTER_BIAS . The parameters themselves are vectors of four values that are applied to red, green, blue, and alpha, in that order.) The R, G, B, and A values are not clamped to [0,1] at any time during this process.
Each pixel is then converted to the internal format specified by Internalformat . This conversion simply maps the component values of the pixel (R, G, B, and A) to the values included in the internal format (red, green, blue, alpha, luminance, and intensity). The mapping is as follows:
Internal FormatRedGreen BlueAlphaLuminanceIntensity?GL_ALPHA A
?GL_LUMINANCE R
?GL_LUMINANCE_ALPHA A R
?GL_INTENSITY R
?GL_RGB R G B
?GL_RGBA R G B A
The red, green, blue, alpha, luminance, and/or intensity components of the resulting pixels are stored in floating-point rather than integer format. They form a two-dimensional filter kernel image indexed with coordinates i and j such that i starts at zero and increases from left to right, and j starts at zero and increases from bottom to top. Kernel location i,j is derived from the Nth pixel, where N is i+j* Width .
Note that after a convolution is performed, the resulting color components are also scaled by their corresponding ?GL_POST_CONVOLUTION_c_SCALE parameters and biased by their corresponding ?GL_POST_CONVOLUTION_c_BIAS parameters (where c takes on the values RED, GREEN, BLUE, and ALPHA). These parameters are set by gl:pixelTransferf/2 .
See external documentation.
convolutionParameterf(Target, Pname, Params) -> ok
Set convolution parameters
gl:convolutionParameter sets the value of a convolution parameter.
Target selects the convolution filter to be affected: ?GL_CONVOLUTION_1D, ?GL_CONVOLUTION_2D , or ?GL_SEPARABLE_2D for the 1D, 2D, or separable 2D filter, respectively.
Pname selects the parameter to be changed. ?GL_CONVOLUTION_FILTER_SCALE and ?GL_CONVOLUTION_FILTER_BIAS affect the definition of the convolution filter kernel; see gl:convolutionFilter1D/6 , gl:convolutionFilter2D/7 , and gl:separableFilter2D/8 for details. In these cases, Params v is an array of four values to be applied to red, green, blue, and alpha values, respectively. The initial value for ?GL_CONVOLUTION_FILTER_SCALE is (1, 1, 1, 1), and the initial value for ?GL_CONVOLUTION_FILTER_BIAS is (0, 0, 0, 0).
A Pname value of ?GL_CONVOLUTION_BORDER_MODE controls the convolution border mode. The accepted modes are:
?GL_REDUCE: The image resulting from convolution is smaller than the source image. If the filter width is Wf and height is Hf, and the source image width is Ws and height is Hs, then the convolved image width will be Ws-Wf+1 and height will be Hs-Hf +1. (If this reduction would generate an image with zero or negative width and/or height, the output is simply null, with no error generated.) The coordinates of the image resulting from convolution are zero through Ws-Wf in width and zero through Hs-Hf in height.
?GL_CONSTANT_BORDER: The image resulting from convolution is the same size as the source image, and processed as if the source image were surrounded by pixels with their color specified by the ?GL_CONVOLUTION_BORDER_COLOR.
?GL_REPLICATE_BORDER: The image resulting from convolution is the same size as the source image, and processed as if the outermost pixel on the border of the source image were replicated.
See external documentation.
convolutionParameterfv(Target::enum(), Pname::enum(), Params) -> ok
Types
Equivalent to convolutionParameterf(Target, Pname, Params).
convolutionParameteri(Target, Pname, Params) -> ok
convolutionParameteriv(Target::enum(), Pname::enum(), Params) -> ok
Types
Equivalent to convolutionParameteri(Target, Pname, Params).
copyConvolutionFilter1D(Target, Internalformat, X, Y, Width) -> ok
Copy pixels into a one-dimensional convolution filter
gl:copyConvolutionFilter1D defines a one-dimensional convolution filter kernel with pixels from the current ?GL_READ_BUFFER (rather than from main memory, as is the case for gl:convolutionFilter1D/6 ).
The screen-aligned pixel rectangle with lower-left corner at ( X , Y ), width Width and height 1 is used to define the convolution filter. If any pixels within this region are outside the window that is associated with the GL context, the values obtained for those pixels are undefined.
The pixels in the rectangle are processed exactly as if gl:readPixels/7 had been called with format set to RGBA, but the process stops just before final conversion. The R, G, B, and A components of each pixel are next scaled by the four 1D ?GL_CONVOLUTION_FILTER_SCALE parameters and biased by the four 1D ?GL_CONVOLUTION_FILTER_BIAS parameters. (The scale and bias parameters are set by gl:convolutionParameterf/3 using the ?GL_CONVOLUTION_1D target and the names ?GL_CONVOLUTION_FILTER_SCALE and ?GL_CONVOLUTION_FILTER_BIAS . The parameters themselves are vectors of four values that are applied to red, green, blue, and alpha, in that order.) The R, G, B, and A values are not clamped to [0,1] at any time during this process.
Each pixel is then converted to the internal format specified by Internalformat . This conversion simply maps the component values of the pixel (R, G, B, and A) to the values included in the internal format (red, green, blue, alpha, luminance, and intensity). The mapping is as follows:
Internal FormatRedGreen BlueAlphaLuminanceIntensity?GL_ALPHA A
?GL_LUMINANCE R
?GL_LUMINANCE_ALPHA A R
?GL_INTENSITY R
?GL_RGB R G B
?GL_RGBA R G B A
The red, green, blue, alpha, luminance, and/or intensity components of the resulting pixels are stored in floating-point rather than integer format.
Pixel ordering is such that lower x screen coordinates correspond to lower i filter image coordinates.
Note that after a convolution is performed, the resulting color components are also scaled by their corresponding ?GL_POST_CONVOLUTION_c_SCALE parameters and biased by their corresponding ?GL_POST_CONVOLUTION_c_BIAS parameters (where c takes on the values RED, GREEN, BLUE, and ALPHA). These parameters are set by gl:pixelTransferf/2 .
See external documentation.
copyConvolutionFilter2D(Target, Internalformat, X, Y, Width, Height) -> ok
Types
Copy pixels into a two-dimensional convolution filter
gl:copyConvolutionFilter2D defines a two-dimensional convolution filter kernel with pixels from the current ?GL_READ_BUFFER (rather than from main memory, as is the case for gl:convolutionFilter2D/7 ).
The screen-aligned pixel rectangle with lower-left corner at ( X , Y ), width Width and height Height is used to define the convolution filter. If any pixels within this region are outside the window that is associated with the GL context, the values obtained for those pixels are undefined.
The pixels in the rectangle are processed exactly as if gl:readPixels/7 had been called with format set to RGBA, but the process stops just before final conversion. The R, G, B, and A components of each pixel are next scaled by the four 2D ?GL_CONVOLUTION_FILTER_SCALE parameters and biased by the four 2D ?GL_CONVOLUTION_FILTER_BIAS parameters. (The scale and bias parameters are set by gl:convolutionParameterf/3 using the ?GL_CONVOLUTION_2D target and the names ?GL_CONVOLUTION_FILTER_SCALE and ?GL_CONVOLUTION_FILTER_BIAS . The parameters themselves are vectors of four values that are applied to red, green, blue, and alpha, in that order.) The R, G, B, and A values are not clamped to [0,1] at any time during this process.
Each pixel is then converted to the internal format specified by Internalformat . This conversion simply maps the component values of the pixel (R, G, B, and A) to the values included in the internal format (red, green, blue, alpha, luminance, and intensity). The mapping is as follows:
Internal FormatRedGreen BlueAlphaLuminanceIntensity?GL_ALPHA A
?GL_LUMINANCE R
?GL_LUMINANCE_ALPHA A R
?GL_INTENSITY R
?GL_RGB R G B
?GL_RGBA R G B A
The red, green, blue, alpha, luminance, and/or intensity components of the resulting pixels are stored in floating-point rather than integer format.
Pixel ordering is such that lower x screen coordinates correspond to lower i filter image coordinates, and lower y screen coordinates correspond to lower j filter image coordinates.
Note that after a convolution is performed, the resulting color components are also scaled by their corresponding ?GL_POST_CONVOLUTION_c_SCALE parameters and biased by their corresponding ?GL_POST_CONVOLUTION_c_BIAS parameters (where c takes on the values RED, GREEN, BLUE, and ALPHA). These parameters are set by gl:pixelTransferf/2 .
See external documentation.
getConvolutionFilter(Target, Format, Type, Image) -> ok
Get current 1D or 2D convolution filter kernel
gl:getConvolutionFilter returns the current 1D or 2D convolution filter kernel as an image. The one- or two-dimensional image is placed in Image according to the specifications in Format and Type . No pixel transfer operations are performed on this image, but the relevant pixel storage modes are applied.
If a non-zero named buffer object is bound to the ?GL_PIXEL_PACK_BUFFER target (see gl:bindBuffer/2 ) while a convolution filter is requested, Image is treated as a byte offset into the buffer object's data store.
Color components that are present in Format but not included in the internal format of the filter are returned as zero. The assignments of internal color components to the components of Format are as follows.
Internal Component Resulting ComponentRed Red
Green Green
Blue Blue
Alpha Alpha
Luminance Red
Intensity Red
See external documentation.
getConvolutionParameterfv(Target, Pname) -> {float(), float(), float(), float()}
Get convolution parameters
gl:getConvolutionParameter retrieves convolution parameters. Target determines which convolution filter is queried. Pname determines which parameter is returned:
?GL_CONVOLUTION_BORDER_MODE: The convolution border mode. See gl:convolutionParameterf/3 for a list of border modes.
?GL_CONVOLUTION_BORDER_COLOR: The current convolution border color. Params must be a pointer to an array of four elements, which will receive the red, green, blue, and alpha border colors.
?GL_CONVOLUTION_FILTER_SCALE: The current filter scale factors. Params must be a pointer to an array of four elements, which will receive the red, green, blue, and alpha filter scale factors in that order.
?GL_CONVOLUTION_FILTER_BIAS: The current filter bias factors. Params must be a pointer to an array of four elements, which will receive the red, green, blue, and alpha filter bias terms in that order.
?GL_CONVOLUTION_FORMAT: The current internal format. See gl:convolutionFilter1D/6 , gl:convolutionFilter2D/7 , and gl:separableFilter2D/8 for lists of allowable formats.
?GL_CONVOLUTION_WIDTH: The current filter image width.
?GL_CONVOLUTION_HEIGHT: The current filter image height.
?GL_MAX_CONVOLUTION_WIDTH: The maximum acceptable filter image width.
?GL_MAX_CONVOLUTION_HEIGHT: The maximum acceptable filter image height.
See external documentation.
getConvolutionParameteriv(Target, Pname) -> {integer(), integer(), integer(), integer()}
separableFilter2D(Target, Internalformat, Width, Height, Format, Type, Row, Column) -> ok
Types
Define a separable two-dimensional convolution filter
gl:separableFilter2D builds a two-dimensional separable convolution filter kernel from two arrays of pixels.
The pixel arrays specified by ( Width , Format , Type , Row ) and ( Height , Format , Type , Column ) are processed just as if they had been passed to gl:drawPixels/5 , but processing stops after the final expansion to RGBA is completed.
If a non-zero named buffer object is bound to the ?GL_PIXEL_UNPACK_BUFFER target (see gl:bindBuffer/2 ) while a convolution filter is specified, Row and Column are treated as byte offsets into the buffer object's data store.
Next, the R, G, B, and A components of all pixels in both arrays are scaled by the four separable 2D ?GL_CONVOLUTION_FILTER_SCALE parameters and biased by the four separable 2D ?GL_CONVOLUTION_FILTER_BIAS parameters. (The scale and bias parameters are set by gl:convolutionParameterf/3 using the ?GL_SEPARABLE_2D target and the names ?GL_CONVOLUTION_FILTER_SCALE and ?GL_CONVOLUTION_FILTER_BIAS. The parameters themselves are vectors of four values that are applied to red, green, blue, and alpha, in that order.) The R, G, B, and A values are not clamped to [0,1] at any time during this process.
Each pixel is then converted to the internal format specified by Internalformat . This conversion simply maps the component values of the pixel (R, G, B, and A) to the values included in the internal format (red, green, blue, alpha, luminance, and intensity). The mapping is as follows:
Internal FormatRed GreenBlueAlphaLuminance Intensity?GL_LUMINANCE R
?GL_LUMINANCE_ALPHA A R
?GL_INTENSITY R
?GL_RGB R G B
?GL_RGBA R G B A
The red, green, blue, alpha, luminance, and/or intensity components of the resulting pixels are stored in floating-point rather than integer format. They form two one-dimensional filter kernel images. The row image is indexed by coordinate i starting at zero and increasing from left to right. Each location in the row image is derived from element i of Row . The column image is indexed by coordinate j starting at zero and increasing from bottom to top. Each location in the column image is derived from element j of Column .
Note that after a convolution is performed, the resulting color components are also scaled by their corresponding ?GL_POST_CONVOLUTION_c_SCALE parameters and biased by their corresponding ?GL_POST_CONVOLUTION_c_BIAS parameters (where c takes on the values RED, GREEN, BLUE, and ALPHA). These parameters are set by gl:pixelTransferf/2 .
See external documentation.
getHistogram(Target, Reset, Format, Type, Values) -> ok
Get histogram table
gl:getHistogram returns the current histogram table as a one-dimensional image with the same width as the histogram. No pixel transfer operations are performed on this image, but pixel storage modes that are applicable to 1D images are honored.
If a non-zero named buffer object is bound to the ?GL_PIXEL_PACK_BUFFER target (see gl:bindBuffer/2 ) while a histogram table is requested, Values is treated as a byte offset into the buffer object's data store.
Color components that are requested in the specified Format , but which are not included in the internal format of the histogram, are returned as zero. The assignments of internal color components to the components requested by Format are:
Internal ComponentResulting ComponentRed Red
Green Green
Blue Blue
Alpha Alpha
Luminance Red
See external documentation.
getHistogramParameterfv(Target, Pname) -> {float()}
Get histogram parameters
gl:getHistogramParameter is used to query parameter values for the current histogram or for a proxy. The histogram state information may be queried by calling gl:getHistogramParameter with a Target of ?GL_HISTOGRAM (to obtain information for the current histogram table) or ?GL_PROXY_HISTOGRAM (to obtain information from the most recent proxy request) and one of the following values for the Pname argument:
ParameterDescription?GL_HISTOGRAM_WIDTH Histogram table width
?GL_HISTOGRAM_FORMAT Internal format
?GL_HISTOGRAM_RED_SIZE Red component counter size, in bits
?GL_HISTOGRAM_GREEN_SIZE Green component counter size, in bits
?GL_HISTOGRAM_BLUE_SIZE Blue component counter size, in bits
?GL_HISTOGRAM_ALPHA_SIZE Alpha component counter size, in bits
?GL_HISTOGRAM_LUMINANCE_SIZE Luminance component counter size, in bits
?GL_HISTOGRAM_SINK Value of the sink parameter
See external documentation.
getHistogramParameteriv(Target, Pname) -> {integer()}
getMinmax(Target, Reset, Format, Types, Values) -> ok
Get minimum and maximum pixel values
gl:getMinmax returns the accumulated minimum and maximum pixel values (computed on a per-component basis) in a one-dimensional image of width 2. The first set of return values are the minima, and the second set of return values are the maxima. The format of the return values is determined by Format , and their type is determined by Types .
If a non-zero named buffer object is bound to the ?GL_PIXEL_PACK_BUFFER target (see gl:bindBuffer/2 ) while minimum and maximum pixel values are requested, Values is treated as a byte offset into the buffer object's data store.
No pixel transfer operations are performed on the return values, but pixel storage modes that are applicable to one-dimensional images are performed. Color components that are requested in the specified Format , but that are not included in the internal format of the minmax table, are returned as zero. The assignment of internal color components to the components requested by Format are as follows:
Internal ComponentResulting ComponentRed Red
Green Green
Blue Blue
Alpha Alpha
Luminance Red
If Reset is ?GL_TRUE, the minmax table entries corresponding to the return values are reset to their initial values. Minimum and maximum values that are not returned are not modified, even if Reset is ?GL_TRUE.
See external documentation.
getMinmaxParameterfv(Target, Pname) -> {float()}
Get minmax parameters
gl:getMinmaxParameter retrieves parameters for the current minmax table by setting Pname to one of the following values:
ParameterDescription?GL_MINMAX_FORMAT Internal format of minmax table
?GL_MINMAX_SINK Value of the sink parameter
See external documentation.
getMinmaxParameteriv(Target, Pname) -> {integer()}
histogram(Target, Width, Internalformat, Sink) -> ok
Define histogram table
When ?GL_HISTOGRAM is enabled, RGBA color components are converted to histogram table indices by clamping to the range [0,1], multiplying by the width of the histogram table, and rounding to the nearest integer. The table entries selected by the RGBA indices are then incremented. (If the internal format of the histogram table includes luminance, then the index derived from the R color component determines the luminance table entry to be incremented.) If a histogram table entry is incremented beyond its maximum value, then its value becomes undefined. (This is not an error.)
Histogramming is performed only for RGBA pixels (though these may be specified originally as color indices and converted to RGBA by index table lookup). Histogramming is enabled with gl:enable/1 and disabled with gl:enable/1 .
When Target is ?GL_HISTOGRAM, gl:histogram redefines the current histogram table to have Width entries of the format specified by Internalformat . The entries are indexed 0 through width-1, and all entries are initialized to zero. The values in the previous histogram table, if any, are lost. If Sink is ?GL_TRUE , then pixels are discarded after histogramming; no further processing of the pixels takes place, and no drawing, texture loading, or pixel readback will result.
When Target is ?GL_PROXY_HISTOGRAM, gl:histogram computes all state information as if the histogram table were to be redefined, but does not actually define the new table. If the requested histogram table is too large to be supported, then the state information will be set to zero. This provides a way to determine if a histogram table with the given parameters can be supported.
See external documentation.
minmax(Target, Internalformat, Sink) -> ok
Define minmax table
When ?GL_MINMAX is enabled, the RGBA components of incoming pixels are compared to the minimum and maximum values for each component, which are stored in the two-element minmax table. (The first element stores the minima, and the second element stores the maxima.) If a pixel component is greater than the corresponding component in the maximum element, then the maximum element is updated with the pixel component value. If a pixel component is less than the corresponding component in the minimum element, then the minimum element is updated with the pixel component value. (In both cases, if the internal format of the minmax table includes luminance, then the R color component of incoming pixels is used for comparison.) The contents of the minmax table may be retrieved at a later time by calling gl:getMinmax/5 . The minmax operation is enabled or disabled by calling gl:enable/1 or gl:enable/1 , respectively, with an argument of ?GL_MINMAX .
gl:minmax redefines the current minmax table to have entries of the format specified by Internalformat . The maximum element is initialized with the smallest possible component values, and the minimum element is initialized with the largest possible component values. The values in the previous minmax table, if any, are lost. If Sink is ?GL_TRUE , then pixels are discarded after minmax; no further processing of the pixels takes place, and no drawing, texture loading, or pixel readback will result.
See external documentation.
Types
Reset histogram table entries to zero
gl:resetHistogram resets all the elements of the current histogram table to zero.
See external documentation.
Types
Reset minmax table entries to initial values
gl:resetMinmax resets the elements of the current minmax table to their initial values: the maximum element receives the minimum possible component values, and the minimum element receives the maximum possible component values.
See external documentation.
Types
Select active texture unit
gl:activeTexture selects which texture unit subsequent texture state calls will affect. The number of texture units an implementation supports is implementation dependent, but must be at least 80.
See external documentation.
sampleCoverage(Value, Invert) -> ok
Specify multisample coverage parameters
Multisampling samples a pixel multiple times at various implementation-dependent subpixel locations to generate antialiasing effects. Multisampling transparently antialiases points, lines, polygons, and images if it is enabled.
Value is used in constructing a temporary mask used in determining which samples will be used in resolving the final fragment color. This mask is bitwise-anded with the coverage mask generated from the multisampling computation. If the Invert flag is set, the temporary mask is inverted (all bits flipped) and then the bitwise-and is computed.
If an implementation does not have any multisample buffers available, or multisampling is disabled, rasterization occurs with only a single sample computing a pixel's final RGB color.
Provided an implementation supports multisample buffers, and multisampling is enabled, then a pixel's final color is generated by combining several samples per pixel. Each sample contains color, depth, and stencil information, allowing those operations to be performed on each sample.
See external documentation.
compressedTexImage3D(Target, Level, Internalformat, Width, Height, Depth, Border, ImageSize, Data) -> ok
Types
Specify a three-dimensional texture image in a compressed format
Texturing allows elements of an image array to be read by shaders.
gl:compressedTexImage3D loads a previously defined, and retrieved, compressed three-dimensional texture image if Target is ?GL_TEXTURE_3D (see gl:texImage3D/10 ).
If Target is ?GL_TEXTURE_2D_ARRAY, Data is treated as an array of compressed 2D textures.
If Target is ?GL_PROXY_TEXTURE_3D or ?GL_PROXY_TEXTURE_2D_ARRAY, no data is read from Data , but all of the texture image state is recalculated, checked for consistency, and checked against the implementation's capabilities. If the implementation cannot handle a texture of the requested texture size, it sets all of the image state to 0, but does not generate an error (see gl:getError/0 ). To query for an entire mipmap array, use an image array level greater than or equal to 1.
Internalformat must be a known compressed image format (such as ?GL_RGTC) or an extension-specified compressed-texture format. When a texture is loaded with gl:texImage2D/9 using a generic compressed texture format (e.g., ?GL_COMPRESSED_RGB), the GL selects from one of its extensions supporting compressed textures. In order to load the compressed texture image using gl:compressedTexImage3D, query the compressed texture image's size and format using gl:getTexLevelParameterfv/3 .
If a non-zero named buffer object is bound to the ?GL_PIXEL_UNPACK_BUFFER target (see gl:bindBuffer/2 ) while a texture image is specified, Data is treated as a byte offset into the buffer object's data store.
If the compressed data are arranged into fixed-size blocks of texels, the pixel storage modes can be used to select a sub-rectangle from a larger containing rectangle. These pixel storage modes operate in the same way as they do for gl:texImage1D/8 . In the following description, denote by b s, b w, b h, and b d, the values of pixel storage modes ?GL_UNPACK_COMPRESSED_BLOCK_SIZE, ?GL_UNPACK_COMPRESSED_BLOCK_WIDTH, ?GL_UNPACK_COMPRESSED_BLOCK_HEIGHT , and ?GL_UNPACK_COMPRESSED_BLOCK_DEPTH, respectively. b s is the compressed block size in bytes; b w, b h, and b d are the compressed block width, height, and depth in pixels.
By default the pixel storage modes ?GL_UNPACK_ROW_LENGTH, ?GL_UNPACK_SKIP_ROWS , ?GL_UNPACK_SKIP_PIXELS, ?GL_UNPACK_IMAGE_HEIGHT and ?GL_UNPACK_SKIP_IMAGES are ignored for compressed images. To enable ?GL_UNPACK_SKIP_PIXELS and ?GL_UNPACK_ROW_LENGTH , b s and b w must both be non-zero. To also enable ?GL_UNPACK_SKIP_ROWS and ?GL_UNPACK_IMAGE_HEIGHT , b h must be non-zero. To also enable ?GL_UNPACK_SKIP_IMAGES, b d must be non-zero. All parameters must be consistent with the compressed format to produce the desired results.
When selecting a sub-rectangle from a compressed image: the value of ?GL_UNPACK_SKIP_PIXELS must be a multiple of b w;the value of ?GL_UNPACK_SKIP_ROWS must be a multiple of b w;the value of ?GL_UNPACK_SKIP_IMAGES must be a multiple of b w.
ImageSize must be equal to:
b s×|width b/w|×|height b/h|×|depth b/d|
See external documentation.
compressedTexImage2D(Target, Level, Internalformat, Width, Height, Border, ImageSize, Data) -> ok
Types
Specify a two-dimensional texture image in a compressed format
Texturing allows elements of an image array to be read by shaders.
gl:compressedTexImage2D loads a previously defined, and retrieved, compressed two-dimensional texture image if Target is ?GL_TEXTURE_2D, or one of the cube map faces such as ?GL_TEXTURE_CUBE_MAP_POSITIVE_X. (see gl:texImage2D/9 ).
If Target is ?GL_TEXTURE_1D_ARRAY, Data is treated as an array of compressed 1D textures.
If Target is ?GL_PROXY_TEXTURE_2D, ?GL_PROXY_TEXTURE_1D_ARRAY or ?GL_PROXY_CUBE_MAP , no data is read from Data , but all of the texture image state is recalculated, checked for consistency, and checked against the implementation's capabilities. If the implementation cannot handle a texture of the requested texture size, it sets all of the image state to 0, but does not generate an error (see gl:getError/0 ). To query for an entire mipmap array, use an image array level greater than or equal to 1.
Internalformat must be a known compressed image format (such as ?GL_RGTC) or an extension-specified compressed-texture format. When a texture is loaded with gl:texImage2D/9 using a generic compressed texture format (e.g., ?GL_COMPRESSED_RGB), the GL selects from one of its extensions supporting compressed textures. In order to load the compressed texture image using gl:compressedTexImage2D, query the compressed texture image's size and format using gl:getTexLevelParameterfv/3 .
If a non-zero named buffer object is bound to the ?GL_PIXEL_UNPACK_BUFFER target (see gl:bindBuffer/2 ) while a texture image is specified, Data is treated as a byte offset into the buffer object's data store.
If the compressed data are arranged into fixed-size blocks of texels, the pixel storage modes can be used to select a sub-rectangle from a larger containing rectangle. These pixel storage modes operate in the same way as they do for gl:texImage2D/9 . In the following description, denote by b s, b w, b h, and b d, the values of pixel storage modes ?GL_UNPACK_COMPRESSED_BLOCK_SIZE, ?GL_UNPACK_COMPRESSED_BLOCK_WIDTH, ?GL_UNPACK_COMPRESSED_BLOCK_HEIGHT , and ?GL_UNPACK_COMPRESSED_BLOCK_DEPTH, respectively. b s is the compressed block size in bytes; b w, b h, and b d are the compressed block width, height, and depth in pixels.
By default the pixel storage modes ?GL_UNPACK_ROW_LENGTH, ?GL_UNPACK_SKIP_ROWS , ?GL_UNPACK_SKIP_PIXELS, ?GL_UNPACK_IMAGE_HEIGHT and ?GL_UNPACK_SKIP_IMAGES are ignored for compressed images. To enable ?GL_UNPACK_SKIP_PIXELS and ?GL_UNPACK_ROW_LENGTH , b s and b w must both be non-zero. To also enable ?GL_UNPACK_SKIP_ROWS and ?GL_UNPACK_IMAGE_HEIGHT , b h must be non-zero. To also enable ?GL_UNPACK_SKIP_IMAGES, b d must be non-zero. All parameters must be consistent with the compressed format to produce the desired results.
When selecting a sub-rectangle from a compressed image: the value of ?GL_UNPACK_SKIP_PIXELS must be a multiple of b w;the value of ?GL_UNPACK_SKIP_ROWS must be a multiple of b w.
ImageSize must be equal to:
b s×|width b/w|×|height b/h|
See external documentation.
compressedTexImage1D(Target, Level, Internalformat, Width, Border, ImageSize, Data) -> ok
Types
Specify a one-dimensional texture image in a compressed format
Texturing allows elements of an image array to be read by shaders.
gl:compressedTexImage1D loads a previously defined, and retrieved, compressed one-dimensional texture image if Target is ?GL_TEXTURE_1D (see gl:texImage1D/8 ).
If Target is ?GL_PROXY_TEXTURE_1D, no data is read from Data , but all of the texture image state is recalculated, checked for consistency, and checked against the implementation's capabilities. If the implementation cannot handle a texture of the requested texture size, it sets all of the image state to 0, but does not generate an error (see gl:getError/0 ). To query for an entire mipmap array, use an image array level greater than or equal to 1.
Internalformat must be an extension-specified compressed-texture format. When a texture is loaded with gl:texImage1D/8 using a generic compressed texture format (e.g., ?GL_COMPRESSED_RGB) the GL selects from one of its extensions supporting compressed textures. In order to load the compressed texture image using gl:compressedTexImage1D , query the compressed texture image's size and format using gl:getTexLevelParameterfv/3 .
If a non-zero named buffer object is bound to the ?GL_PIXEL_UNPACK_BUFFER target (see gl:bindBuffer/2 ) while a texture image is specified, Data is treated as a byte offset into the buffer object's data store.
If the compressed data are arranged into fixed-size blocks of texels, the pixel storage modes can be used to select a sub-rectangle from a larger containing rectangle. These pixel storage modes operate in the same way as they do for gl:texImage1D/8 . In the following description, denote by b s, b w, b h, and b d, the values of pixel storage modes ?GL_UNPACK_COMPRESSED_BLOCK_SIZE, ?GL_UNPACK_COMPRESSED_BLOCK_WIDTH, ?GL_UNPACK_COMPRESSED_BLOCK_HEIGHT , and ?GL_UNPACK_COMPRESSED_BLOCK_DEPTH, respectively. b s is the compressed block size in bytes; b w, b h, and b d are the compressed block width, height, and depth in pixels.
By default the pixel storage modes ?GL_UNPACK_ROW_LENGTH, ?GL_UNPACK_SKIP_ROWS , ?GL_UNPACK_SKIP_PIXELS, ?GL_UNPACK_IMAGE_HEIGHT and ?GL_UNPACK_SKIP_IMAGES are ignored for compressed images. To enable ?GL_UNPACK_SKIP_PIXELS and ?GL_UNPACK_ROW_LENGTH , b s and b w must both be non-zero. To also enable ?GL_UNPACK_SKIP_ROWS and ?GL_UNPACK_IMAGE_HEIGHT , b h must be non-zero. To also enable ?GL_UNPACK_SKIP_IMAGES, b d must be non-zero. All parameters must be consistent with the compressed format to produce the desired results.
When selecting a sub-rectangle from a compressed image: the value of ?GL_UNPACK_SKIP_PIXELS must be a multiple of b w;
ImageSize must be equal to:
b s×|width b/w|
See external documentation.
compressedTexSubImage3D(Target, Level, Xoffset, Yoffset, Zoffset, Width, Height, Depth, Format, ImageSize, Data) -> ok
Types
Specify a three-dimensional texture subimage in a compressed format
Texturing allows elements of an image array to be read by shaders.
gl:compressedTexSubImage3D redefines a contiguous subregion of an existing three-dimensional texture image. The texels referenced by Data replace the portion of the existing texture array with x indices Xoffset and xoffset+width-1, and the y indices Yoffset and yoffset+height-1, and the z indices Zoffset and zoffset+depth-1, inclusive. This region may not include any texels outside the range of the texture array as it was originally specified. It is not an error to specify a subtexture with width of 0, but such a specification has no effect.
Internalformat must be a known compressed image format (such as ?GL_RGTC) or an extension-specified compressed-texture format. The Format of the compressed texture image is selected by the GL implementation that compressed it (see gl:texImage3D/10 ) and should be queried at the time the texture was compressed with gl:getTexLevelParameterfv/3 .
If a non-zero named buffer object is bound to the ?GL_PIXEL_UNPACK_BUFFER target (see gl:bindBuffer/2 ) while a texture image is specified, Data is treated as a byte offset into the buffer object's data store.
See external documentation.
compressedTexSubImage2D(Target, Level, Xoffset, Yoffset, Width, Height, Format, ImageSize, Data) -> ok
Types
Specify a two-dimensional texture subimage in a compressed format
Texturing allows elements of an image array to be read by shaders.
gl:compressedTexSubImage2D redefines a contiguous subregion of an existing two-dimensional texture image. The texels referenced by Data replace the portion of the existing texture array with x indices Xoffset and xoffset+width-1, and the y indices Yoffset and yoffset+height-1, inclusive. This region may not include any texels outside the range of the texture array as it was originally specified. It is not an error to specify a subtexture with width of 0, but such a specification has no effect.
Internalformat must be a known compressed image format (such as ?GL_RGTC) or an extension-specified compressed-texture format. The Format of the compressed texture image is selected by the GL implementation that compressed it (see gl:texImage2D/9 ) and should be queried at the time the texture was compressed with gl:getTexLevelParameterfv/3 .
If a non-zero named buffer object is bound to the ?GL_PIXEL_UNPACK_BUFFER target (see gl:bindBuffer/2 ) while a texture image is specified, Data is treated as a byte offset into the buffer object's data store.
See external documentation.
compressedTexSubImage1D(Target, Level, Xoffset, Width, Format, ImageSize, Data) -> ok
Types
Specify a one-dimensional texture subimage in a compressed format
Texturing allows elements of an image array to be read by shaders.
gl:compressedTexSubImage1D redefines a contiguous subregion of an existing one-dimensional texture image. The texels referenced by Data replace the portion of the existing texture array with x indices Xoffset and xoffset+width-1, inclusive. This region may not include any texels outside the range of the texture array as it was originally specified. It is not an error to specify a subtexture with width of 0, but such a specification has no effect.
Internalformat must be a known compressed image format (such as ?GL_RGTC) or an extension-specified compressed-texture format. The Format of the compressed texture image is selected by the GL implementation that compressed it (see gl:texImage1D/8 ), and should be queried at the time the texture was compressed with gl:getTexLevelParameterfv/3 .
If a non-zero named buffer object is bound to the ?GL_PIXEL_UNPACK_BUFFER target (see gl:bindBuffer/2 ) while a texture image is specified, Data is treated as a byte offset into the buffer object's data store.
See external documentation.
getCompressedTexImage(Target, Lod, Img) -> ok
Return a compressed texture image
gl:getCompressedTexImage returns the compressed texture image associated with Target and Lod into Img . Img should be an array of ?GL_TEXTURE_COMPRESSED_IMAGE_SIZE bytes. Target specifies whether the desired texture image was one specified by gl:texImage1D/8 (?GL_TEXTURE_1D), gl:texImage2D/9 (?GL_TEXTURE_2D or any of ?GL_TEXTURE_CUBE_MAP_* ), or gl:texImage3D/10 (?GL_TEXTURE_3D). Lod specifies the level-of-detail number of the desired image.
If a non-zero named buffer object is bound to the ?GL_PIXEL_PACK_BUFFER target (see gl:bindBuffer/2 ) while a texture image is requested, Img is treated as a byte offset into the buffer object's data store.
To minimize errors, first verify that the texture is compressed by calling gl:getTexLevelParameterfv/3 with argument ?GL_TEXTURE_COMPRESSED. If the texture is compressed, then determine the amount of memory required to store the compressed texture by calling gl:getTexLevelParameterfv/3 with argument ?GL_TEXTURE_COMPRESSED_IMAGE_SIZE. Finally, retrieve the internal format of the texture by calling gl:getTexLevelParameterfv/3 with argument ?GL_TEXTURE_INTERNAL_FORMAT . To store the texture for later use, associate the internal format and size with the retrieved texture image. These data can be used by the respective texture or subtexture loading routine used for loading Target textures.
See external documentation.
clientActiveTexture(Texture) -> ok
Types
Select active texture unit
gl:clientActiveTexture selects the vertex array client state parameters to be modified by gl:texCoordPointer/4 , and enabled or disabled with gl:enableClientState/1 or gl:enableClientState/1 , respectively, when called with a parameter of ?GL_TEXTURE_COORD_ARRAY .
See external documentation.
multiTexCoord1d(Target, S) -> ok
Set the current texture coordinates
gl:multiTexCoord specifies texture coordinates in one, two, three, or four dimensions. gl:multiTexCoord1 sets the current texture coordinates to (s 0 0 1); a call to gl:multiTexCoord2 sets them to (s t 0 1). Similarly, gl:multiTexCoord3 specifies the texture coordinates as (s t r 1), and gl:multiTexCoord4 defines all four components explicitly as (s t r q).
The current texture coordinates are part of the data that is associated with each vertex and with the current raster position. Initially, the values for (s t r q) are (0 0 0 1).
See external documentation.
multiTexCoord1dv(Target::enum(), V) -> ok
Types
Equivalent to multiTexCoord1d(Target, S).
multiTexCoord1f(Target, S) -> ok
multiTexCoord1fv(Target::enum(), V) -> ok
Types
Equivalent to multiTexCoord1f(Target, S).
multiTexCoord1i(Target, S) -> ok
multiTexCoord1iv(Target::enum(), V) -> ok
Types
Equivalent to multiTexCoord1i(Target, S).
multiTexCoord1s(Target, S) -> ok
multiTexCoord1sv(Target::enum(), V) -> ok
Types
Equivalent to multiTexCoord1s(Target, S).
multiTexCoord2d(Target, S, T) -> ok
multiTexCoord2dv(Target::enum(), V) -> ok
Types
Equivalent to multiTexCoord2d(Target, S, T).
multiTexCoord2f(Target, S, T) -> ok
multiTexCoord2fv(Target::enum(), V) -> ok
Types
Equivalent to multiTexCoord2f(Target, S, T).
multiTexCoord2i(Target, S, T) -> ok
multiTexCoord2iv(Target::enum(), V) -> ok
Types
Equivalent to multiTexCoord2i(Target, S, T).
multiTexCoord2s(Target, S, T) -> ok
multiTexCoord2sv(Target::enum(), V) -> ok
Types
Equivalent to multiTexCoord2s(Target, S, T).
multiTexCoord3d(Target, S, T, R) -> ok
multiTexCoord3dv(Target::enum(), V) -> ok
Types
Equivalent to multiTexCoord3d(Target, S, T, R).
multiTexCoord3f(Target, S, T, R) -> ok
multiTexCoord3fv(Target::enum(), V) -> ok
Types
Equivalent to multiTexCoord3f(Target, S, T, R).
multiTexCoord3i(Target, S, T, R) -> ok
multiTexCoord3iv(Target::enum(), V) -> ok
Types
Equivalent to multiTexCoord3i(Target, S, T, R).
multiTexCoord3s(Target, S, T, R) -> ok
multiTexCoord3sv(Target::enum(), V) -> ok
Types
Equivalent to multiTexCoord3s(Target, S, T, R).
multiTexCoord4d(Target, S, T, R, Q) -> ok
multiTexCoord4dv(Target::enum(), V) -> ok
Types
Equivalent to multiTexCoord4d(Target, S, T, R, Q).
multiTexCoord4f(Target, S, T, R, Q) -> ok
multiTexCoord4fv(Target::enum(), V) -> ok
Types
Equivalent to multiTexCoord4f(Target, S, T, R, Q).
multiTexCoord4i(Target, S, T, R, Q) -> ok
multiTexCoord4iv(Target::enum(), V) -> ok
Types
Equivalent to multiTexCoord4i(Target, S, T, R, Q).
multiTexCoord4s(Target, S, T, R, Q) -> ok
multiTexCoord4sv(Target::enum(), V) -> ok
Types
Equivalent to multiTexCoord4s(Target, S, T, R, Q).
Types
Replace the current matrix with the specified row-major ordered matrix
gl:loadTransposeMatrix replaces the current matrix with the one whose elements are specified by M . The current matrix is the projection matrix, modelview matrix, or texture matrix, depending on the current matrix mode (see gl:matrixMode/1 ).
The current matrix, M, defines a transformation of coordinates. For instance, assume M refers to the modelview matrix. If v=(v[0] v[1] v[2] v[3]) is the set of object coordinates of a vertex, and M points to an array of 16 single- or double-precision floating-point values m={m[0] m[1] ... m[15]}, then the modelview transformation M(v) does the following:
M(v)=(m[0] m[1] m[2] m[3] m[4] m[5] m[6] m[7] m[8] m[9] m[10] m[11] m[12] m[13] m[14] m[15])×(v[0] v[1] v[2] v[3])
Projection and texture transformations are similarly defined.
Calling gl:loadTransposeMatrix with matrix M is identical in operation to gl:loadMatrixd/1 with M T, where T represents the transpose.
See external documentation.
Types
Types
Multiply the current matrix with the specified row-major ordered matrix
gl:multTransposeMatrix multiplies the current matrix with the one specified using M , and replaces the current matrix with the product.
The current matrix is determined by the current matrix mode (see gl:matrixMode/1 ). It is either the projection matrix, modelview matrix, or the texture matrix.
See external documentation.
Types
blendFuncSeparate(SfactorRGB, DfactorRGB, SfactorAlpha, DfactorAlpha) -> ok
Specify pixel arithmetic for RGB and alpha components separately
Pixels can be drawn using a function that blends the incoming (source) RGBA values with the RGBA values that are already in the frame buffer (the destination values). Blending is initially disabled. Use gl:enable/1 and gl:enable/1 with argument ?GL_BLEND to enable and disable blending.
gl:blendFuncSeparate defines the operation of blending for all draw buffers when it is enabled. gl:blendFuncSeparatei defines the operation of blending for a single draw buffer specified by Buf when enabled for that draw buffer. SrcRGB specifies which method is used to scale the source RGB-color components. DstRGB specifies which method is used to scale the destination RGB-color components. Likewise, SrcAlpha specifies which method is used to scale the source alpha color component, and DstAlpha specifies which method is used to scale the destination alpha component. The possible methods are described in the following table. Each method defines four scale factors, one each for red, green, blue, and alpha.
In the table and in subsequent equations, first source, second source and destination color components are referred to as (R s0 G s0 B s0 A s0), (R s1 G s1 B s1 A s1), and (R d G d B d A d), respectively. The color specified by gl:blendColor/4 is referred to as (R c G c B c A c). They are understood to have integer values between 0 and (k R k G k B k A), where
k c=2(m c)-1
and (m R m G m B m A) is the number of red, green, blue, and alpha bitplanes.
Source and destination scale factors are referred to as (s R s G s B s A) and (d R d G d B d A). All scale factors have range [0 1].
 However, a blend factor that should be equal to 1 is guaranteed not to modify its multiplicand, and a blend factor equal to 0 reduces its multiplicand to 0. For example, when SrcRGB is ?GL_SRC_ALPHA , DstRGB is ?GL_ONE_MINUS_SRC_ALPHA, and A s is equal to k A, the equations reduce to simple replacement:
R d=R s G d=G s B d=B s A d=A s
See external documentation.
multiDrawArrays(Mode, First, Count) -> ok
Render multiple sets of primitives from array data
gl:multiDrawArrays specifies multiple sets of geometric primitives with very few subroutine calls. Instead of calling a GL procedure to pass each individual vertex, normal, texture coordinate, edge flag, or color, you can prespecify separate arrays of vertices, normals, and colors and use them to construct a sequence of primitives with a single call to gl:multiDrawArrays.
gl:multiDrawArrays behaves identically to gl:drawArrays/3 except that Primcount separate ranges of elements are specified instead.
When gl:multiDrawArrays is called, it uses Count sequential elements from each enabled array to construct a sequence of geometric primitives, beginning with element First . Mode specifies what kind of primitives are constructed, and how the array elements construct those primitives.
Vertex attributes that are modified by gl:multiDrawArrays have an unspecified value after gl:multiDrawArrays returns. Attributes that aren't modified remain well defined.
See external documentation.
pointParameterf(Pname, Param) -> ok
Specify point parameters
The following values are accepted for Pname :
?GL_POINT_FADE_THRESHOLD_SIZE: Params is a single floating-point value that specifies the threshold value to which point sizes are clamped if they exceed the specified value. The default value is 1.0.
?GL_POINT_SPRITE_COORD_ORIGIN: Params is a single enum specifying the point sprite texture coordinate origin, either ?GL_LOWER_LEFT or ?GL_UPPER_LEFT. The default value is ?GL_UPPER_LEFT.
See external documentation.
pointParameterfv(Pname, Params) -> ok
pointParameteri(Pname, Param) -> ok
pointParameteriv(Pname, Params) -> ok
Types
Set the current fog coordinates
gl:fogCoord specifies the fog coordinate that is associated with each vertex and the current raster position. The value specified is interpolated and used in computing the fog color (see gl:fogf/2 ).
See external documentation.
Types
Equivalent to fogCoordf(Coord).
Types
See fogCoordf/1
Types
Equivalent to fogCoordd(Coord).
fogCoordPointer(Type, Stride, Pointer) -> ok
Define an array of fog coordinates
gl:fogCoordPointer specifies the location and data format of an array of fog coordinates to use when rendering. Type specifies the data type of each fog coordinate, and Stride specifies the byte stride from one fog coordinate to the next, allowing vertices and attributes to be packed into a single array or stored in separate arrays.
If a non-zero named buffer object is bound to the ?GL_ARRAY_BUFFER target (see gl:bindBuffer/2 ) while a fog coordinate array is specified, Pointer is treated as a byte offset into the buffer object's data store. Also, the buffer object binding (?GL_ARRAY_BUFFER_BINDING ) is saved as fog coordinate vertex array client-side state (?GL_FOG_COORD_ARRAY_BUFFER_BINDING ).
When a fog coordinate array is specified, Type , Stride , and Pointer are saved as client-side state, in addition to the current vertex array buffer object binding.
To enable and disable the fog coordinate array, call gl:enableClientState/1 and gl:enableClientState/1 with the argument ?GL_FOG_COORD_ARRAY. If enabled, the fog coordinate array is used when gl:drawArrays/3 , gl:multiDrawArrays/3 , gl:drawElements/4 , see glMultiDrawElements , gl:drawRangeElements/6 , or gl:arrayElement/1 is called.
See external documentation.
secondaryColor3b(Red, Green, Blue) -> ok
Types
Set the current secondary color
The GL stores both a primary four-valued RGBA color and a secondary four-valued RGBA color (where alpha is always set to 0.0) that is associated with every vertex.
The secondary color is interpolated and applied to each fragment during rasterization when ?GL_COLOR_SUM is enabled. When lighting is enabled, and ?GL_SEPARATE_SPECULAR_COLOR is specified, the value of the secondary color is assigned the value computed from the specular term of the lighting computation. Both the primary and secondary current colors are applied to each fragment, regardless of the state of ?GL_COLOR_SUM, under such conditions. When ?GL_SEPARATE_SPECULAR_COLOR is specified, the value returned from querying the current secondary color is undefined.
gl:secondaryColor3b, gl:secondaryColor3s, and gl:secondaryColor3i take three signed byte, short, or long integers as arguments. When v is appended to the name, the color commands can take a pointer to an array of such values.
Color values are stored in floating-point format, with unspecified mantissa and exponent sizes. Unsigned integer color components, when specified, are linearly mapped to floating-point values such that the largest representable value maps to 1.0 (full intensity), and 0 maps to 0.0 (zero intensity). Signed integer color components, when specified, are linearly mapped to floating-point values such that the most positive representable value maps to 1.0, and the most negative representable value maps to -1.0. (Note that this mapping does not convert 0 precisely to 0.0). Floating-point values are mapped directly.
Neither floating-point nor signed integer values are clamped to the range [0 1] before the current color is updated. However, color components are clamped to this range before they are interpolated or written into a color buffer.
See external documentation.
Types
Equivalent to secondaryColor3b(Red, Green, Blue).
secondaryColor3d(Red, Green, Blue) -> ok
Types
Types
Equivalent to secondaryColor3d(Red, Green, Blue).
secondaryColor3f(Red, Green, Blue) -> ok
Types
Types
Equivalent to secondaryColor3f(Red, Green, Blue).
secondaryColor3i(Red, Green, Blue) -> ok
Types
Types
Equivalent to secondaryColor3i(Red, Green, Blue).
secondaryColor3s(Red, Green, Blue) -> ok
Types
Types
Equivalent to secondaryColor3s(Red, Green, Blue).
secondaryColor3ub(Red, Green, Blue) -> ok
Types
Types
Equivalent to secondaryColor3ub(Red, Green, Blue).
secondaryColor3ui(Red, Green, Blue) -> ok
Types
Types
Equivalent to secondaryColor3ui(Red, Green, Blue).
secondaryColor3us(Red, Green, Blue) -> ok
Types
Types
Equivalent to secondaryColor3us(Red, Green, Blue).
secondaryColorPointer(Size, Type, Stride, Pointer) -> ok
Define an array of secondary colors
gl:secondaryColorPointer specifies the location and data format of an array of color components to use when rendering. Size specifies the number of components per color, and must be 3. Type specifies the data type of each color component, and Stride specifies the byte stride from one color to the next, allowing vertices and attributes to be packed into a single array or stored in separate arrays.