gl
MODULE
MODULE SUMMARY
DESCRIPTION
DATA TYPES
- clamp() = float()
-
0.0..1.0
- enum() = non_neg_integer()
-
See wx/include/gl.hrl
- matrix() = {float(), float(), float(), float(), float(), float(), float(), float(), float(), float(), float(), float(), float(), float(), float(), float()}
- mem() = binary() | tuple()
-
Memory block
- offset() = non_neg_integer()
-
Offset in memory block
EXPORTS
Types:
Specify the clear value for the color index buffers
gl:clearIndex specifies the index used by gl:clear/1 to clear the color index buffers. C is not clamped. Rather, C is converted to a fixed-point value with unspecified precision to the right of the binary point. The integer part of this value is then masked with 2 m-1, where m is the number of bits in a color index stored in the frame buffer.
See external documentation.
clearColor(Red, Green, Blue, Alpha) -> ok
Types:
Specify clear values for the color buffers
gl:clearColor specifies the red, green, blue, and alpha values used by gl:clear/1 to clear the color buffers. Values specified by gl:clearColor are clamped to the range [0 1].
See external documentation.
Types:
Clear buffers to preset values
gl:clear sets the bitplane area of the window to values previously selected by gl:clearColor , gl:clearDepth, and gl:clearStencil. Multiple color buffers can be cleared simultaneously by selecting more than one buffer at a time using gl:drawBuffer/1 .
The pixel ownership test, the scissor test, dithering, and the buffer writemasks affect the operation of gl:clear. The scissor box bounds the cleared region. Alpha function, blend function, logical operation, stenciling, texture mapping, and depth-buffering are ignored by gl:clear.
gl:clear takes a single argument that is the bitwise OR of several values indicating which buffer is to be cleared.
The values are as follows:
?GL_COLOR_BUFFER_BIT: Indicates the buffers currently enabled for color writing.
?GL_DEPTH_BUFFER_BIT: Indicates the depth buffer.
?GL_STENCIL_BUFFER_BIT: Indicates the stencil buffer.
The value to which each buffer is cleared depends on the setting of the clear value for that buffer.
See external documentation.
Types:
Control the writing of individual bits in the color index buffers
gl:indexMask controls the writing of individual bits in the color index buffers. The least significant n bits of Mask , where n is the number of bits in a color index buffer, specify a mask. Where a 1 (one) appears in the mask, it's possible to write to the corresponding bit in the color index buffer (or buffers). Where a 0 (zero) appears, the corresponding bit is write-protected.
This mask is used only in color index mode, and it affects only the buffers currently selected for writing (see gl:drawBuffer/1 ). Initially, all bits are enabled for writing.
See external documentation.
colorMask(Red, Green, Blue, Alpha) -> ok
Types:
Enable and disable writing of frame buffer color components
gl:colorMask and gl:colorMaski specify whether the individual color components in the frame buffer can or cannot be written. gl:colorMaski sets the mask for a specific draw buffer, whereas gl:colorMask sets the mask for all draw buffers. If Red is ?GL_FALSE, for example, no change is made to the red component of any pixel in any of the color buffers, regardless of the drawing operation attempted.
Changes to individual bits of components cannot be controlled. Rather, changes are either enabled or disabled for entire color components.
See external documentation.
Types:
Specify the alpha test function
The alpha test discards fragments depending on the outcome of a comparison between an incoming fragment's alpha value and a constant reference value. gl:alphaFunc specifies the reference value and the comparison function. The comparison is performed only if alpha testing is enabled. By default, it is not enabled. (See gl:enable/1 and gl:enable/1 of ?GL_ALPHA_TEST.)
Func and Ref specify the conditions under which the pixel is drawn. The incoming alpha value is compared to Ref using the function specified by Func . If the value passes the comparison, the incoming fragment is drawn if it also passes subsequent stencil and depth buffer tests. If the value fails the comparison, no change is made to the frame buffer at that pixel location. The comparison functions are as follows:
?GL_NEVER: Never passes.
?GL_LESS: Passes if the incoming alpha value is less than the reference value.
?GL_EQUAL: Passes if the incoming alpha value is equal to the reference value.
?GL_LEQUAL: Passes if the incoming alpha value is less than or equal to the reference value.
?GL_GREATER: Passes if the incoming alpha value is greater than the reference value.
?GL_NOTEQUAL: Passes if the incoming alpha value is not equal to the reference value.
?GL_GEQUAL: Passes if the incoming alpha value is greater than or equal to the reference value.
?GL_ALWAYS: Always passes (initial value).
gl:alphaFunc operates on all pixel write operations, including those resulting from the scan conversion of points, lines, polygons, and bitmaps, and from pixel draw and copy operations. gl:alphaFunc does not affect screen clear operations.
See external documentation.
blendFunc(Sfactor, Dfactor) -> ok
Types:
Specify pixel arithmetic
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:blendFunc defines the operation of blending for all draw buffers when it is enabled. gl:blendFunci defines the operation of blending for a single draw buffer specified by Buf when enabled for that draw buffer. Sfactor specifies which method is used to scale the source color components. Dfactor specifies which method is used to scale the destination color components. Both parameters must be one of the following symbolic constants: ?GL_ZERO, ?GL_ONE, ?GL_SRC_COLOR, ?GL_ONE_MINUS_SRC_COLOR , ?GL_DST_COLOR, ?GL_ONE_MINUS_DST_COLOR, ?GL_SRC_ALPHA, ?GL_ONE_MINUS_SRC_ALPHA , ?GL_DST_ALPHA, ?GL_ONE_MINUS_DST_ALPHA, ?GL_CONSTANT_COLOR, ?GL_ONE_MINUS_CONSTANT_COLOR , ?GL_CONSTANT_ALPHA, ?GL_ONE_MINUS_CONSTANT_ALPHA, ?GL_SRC_ALPHA_SATURATE , ?GL_SRC1_COLOR, ?GL_ONE_MINUS_SRC1_COLOR, ?GL_SRC1_ALPHA, and ?GL_ONE_MINUS_SRC1_ALPHA . 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). The scale factors described in the table, denoted (f R f G f B f A), represent either source or destination factors. All scale factors have range [0 1].
Parameter(f R f G f B f A)?GL_ZERO (0 0 0 0)
?GL_ONE(1 1 1 1)
?GL_SRC_COLOR (R s0 k/R G s0 k/G B s0 k/B A s0 k/A)
?GL_ONE_MINUS_SRC_COLOR(1 1 1 1)-(R s0 k/R G s0 k/G B s0 k/B A s0 k/A)
?GL_DST_COLOR (R d k/R G d k/G B d k/B A d k/A)
?GL_ONE_MINUS_DST_COLOR(1 1 1 1)-(R d k/R G d k/G B d k/B A d k/A)
?GL_SRC_ALPHA (A s0 k/A A s0 k/A A s0 k/A A s0 k/A)
?GL_ONE_MINUS_SRC_ALPHA(1 1 1 1)-(A s0 k/A A s0 k/A A s0 k/A A s0 k/A)
?GL_DST_ALPHA (A d k/A A d k/A A d k/A A d k/A)
?GL_ONE_MINUS_DST_ALPHA(1 1 1 1)-(A d k/A A d k/A A d k/A A d k/A)
?GL_CONSTANT_COLOR (R c G c B c A c)
?GL_ONE_MINUS_CONSTANT_COLOR(1 1 1 1)-(R c G c B c A c)
?GL_CONSTANT_ALPHA(A c A c A c A c)
?GL_ONE_MINUS_CONSTANT_ALPHA (1 1 1 1)-(A c A c A c A c)
?GL_SRC_ALPHA_SATURATE(i i i 1)
?GL_SRC1_COLOR (R s1 k/R G s1 k/G B s1 k/B A s1 k/A)
?GL_ONE_MINUS_SRC1_COLOR(1 1 1 1)-(R s1 k/R G s1 k/G B s1 k/B A s1 k/A)
?GL_SRC1_ALPHA (A s1 k/A A s1 k/A A s1 k/A A s1 k/A)
?GL_ONE_MINUS_SRC1_ALPHA(1 1 1 1)-(A s1 k/A A s1 k/A A s1 k/A A s1 k/A)
In the table,
i=min(A s k A-A d) k/A
To determine the blended RGBA values of a pixel, the system uses the following equations:
R d=min(k R R s s R+R d d R) G d=min(k G G s s G+G d d G) B d=min(k B B s s B+B d d B) A d=min(k A A s s A+A d d A)
Despite the apparent precision of the above equations, blending arithmetic is not exactly specified, because blending operates with imprecise integer color values. 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 Sfactor is ?GL_SRC_ALPHA , Dfactor 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.
Types:
Specify a logical pixel operation for rendering
gl:logicOp specifies a logical operation that, when enabled, is applied between the incoming RGBA color and the RGBA color at the corresponding location in the frame buffer. To enable or disable the logical operation, call gl:enable/1 and gl:enable/1 using the symbolic constant ?GL_COLOR_LOGIC_OP. The initial value is disabled.
OpcodeResulting Operation?GL_CLEAR 0
?GL_SET 1
?GL_COPY s
?GL_COPY_INVERTED ~s
?GL_NOOP d
?GL_INVERT ~d
?GL_AND s & d
?GL_NAND ~(s & d)
?GL_OR s | d
?GL_NOR ~(s | d)
?GL_XOR s ^ d
?GL_EQUIV ~(s ^ d)
?GL_AND_REVERSE s & ~d
?GL_AND_INVERTED ~s & d
?GL_OR_REVERSE s | ~d
?GL_OR_INVERTED ~s | d
Opcode is a symbolic constant chosen from the list above. In the explanation of the logical operations, s represents the incoming color and d represents the color in the frame buffer. Standard C-language operators are used. As these bitwise operators suggest, the logical operation is applied independently to each bit pair of the source and destination colors.
See external documentation.
Types:
Specify whether front- or back-facing facets can be culled
gl:cullFace specifies whether front- or back-facing facets are culled (as specified by mode) when facet culling is enabled. Facet culling is initially disabled. To enable and disable facet culling, call the gl:enable/1 and gl:enable/1 commands with the argument ?GL_CULL_FACE. Facets include triangles, quadrilaterals, polygons, and rectangles.
gl:frontFace/1 specifies which of the clockwise and counterclockwise facets are front-facing and back-facing. See gl:frontFace/1 .
See external documentation.
Types:
Define front- and back-facing polygons
In a scene composed entirely of opaque closed surfaces, back-facing polygons are never visible. Eliminating these invisible polygons has the obvious benefit of speeding up the rendering of the image. To enable and disable elimination of back-facing polygons, call gl:enable/1 and gl:enable/1 with argument ?GL_CULL_FACE.
The projection of a polygon to window coordinates is said to have clockwise winding if an imaginary object following the path from its first vertex, its second vertex, and so on, to its last vertex, and finally back to its first vertex, moves in a clockwise direction about the interior of the polygon. The polygon's winding is said to be counterclockwise if the imaginary object following the same path moves in a counterclockwise direction about the interior of the polygon. gl:frontFace specifies whether polygons with clockwise winding in window coordinates, or counterclockwise winding in window coordinates, are taken to be front-facing. Passing ?GL_CCW to Mode selects counterclockwise polygons as front-facing; ?GL_CW selects clockwise polygons as front-facing. By default, counterclockwise polygons are taken to be front-facing.
See external documentation.
Types:
Specify the diameter of rasterized points
gl:pointSize specifies the rasterized diameter of points. If point size mode is disabled (see gl:enable/1 with parameter ?GL_PROGRAM_POINT_SIZE), this value will be used to rasterize points. Otherwise, the value written to the shading language built-in variable gl_PointSize will be used.
See external documentation.
Types:
Specify the width of rasterized lines
gl:lineWidth specifies the rasterized width of both aliased and antialiased lines. Using a line width other than 1 has different effects, depending on whether line antialiasing is enabled. To enable and disable line antialiasing, call gl:enable/1 and gl:enable/1 with argument ?GL_LINE_SMOOTH. Line antialiasing is initially disabled.
If line antialiasing is disabled, the actual width is determined by rounding the supplied width to the nearest integer. (If the rounding results in the value 0, it is as if the line width were 1.) If |Δ x|>=|Δ y|, i pixels are filled in each column that is rasterized, where i is the rounded value of Width . Otherwise, i pixels are filled in each row that is rasterized.
If antialiasing is enabled, line rasterization produces a fragment for each pixel square that intersects the region lying within the rectangle having width equal to the current line width, length equal to the actual length of the line, and centered on the mathematical line segment. The coverage value for each fragment is the window coordinate area of the intersection of the rectangular region with the corresponding pixel square. This value is saved and used in the final rasterization step.
Not all widths can be supported when line antialiasing is enabled. If an unsupported width is requested, the nearest supported width is used. Only width 1 is guaranteed to be supported; others depend on the implementation. Likewise, there is a range for aliased line widths as well. To query the range of supported widths and the size difference between supported widths within the range, call gl:getBooleanv/1 with arguments ?GL_ALIASED_LINE_WIDTH_RANGE , ?GL_SMOOTH_LINE_WIDTH_RANGE, and ?GL_SMOOTH_LINE_WIDTH_GRANULARITY.
See external documentation.
lineStipple(Factor, Pattern) -> ok
Types:
Specify the line stipple pattern
Line stippling masks out certain fragments produced by rasterization; those fragments will not be drawn. The masking is achieved by using three parameters: the 16-bit line stipple pattern Pattern , the repeat count Factor , and an integer stipple counter s.
Counter s is reset to 0 whenever gl:'begin'/1 is called and before each line segment of a gl:'begin'/1 (?GL_LINES)/ gl:'begin'/1 sequence is generated. It is incremented after each fragment of a unit width aliased line segment is generated or after each i fragments of an i width line segment are generated. The i fragments associated with count s are masked out if
Pattern bit (s/factor)% 16
is 0, otherwise these fragments are sent to the frame buffer. Bit zero of Pattern is the least significant bit.
Antialiased lines are treated as a sequence of 1×width rectangles for purposes of stippling. Whether rectangle s is rasterized or not depends on the fragment rule described for aliased lines, counting rectangles rather than groups of fragments.
To enable and disable line stippling, call gl:enable/1 and gl:enable/1 with argument ?GL_LINE_STIPPLE. When enabled, the line stipple pattern is applied as described above. When disabled, it is as if the pattern were all 1's. Initially, line stippling is disabled.
See external documentation.
Types:
Select a polygon rasterization mode
gl:polygonMode controls the interpretation of polygons for rasterization. Face describes which polygons Mode applies to: both front and back-facing polygons (?GL_FRONT_AND_BACK ). The polygon mode affects only the final rasterization of polygons. In particular, a polygon's vertices are lit and the polygon is clipped and possibly culled before these modes are applied.
Three modes are defined and can be specified in Mode :
?GL_POINT: Polygon vertices that are marked as the start of a boundary edge are drawn as points. Point attributes such as ?GL_POINT_SIZE and ?GL_POINT_SMOOTH control the rasterization of the points. Polygon rasterization attributes other than ?GL_POLYGON_MODE have no effect.
?GL_LINE: Boundary edges of the polygon are drawn as line segments. Line attributes such as ?GL_LINE_WIDTH and ?GL_LINE_SMOOTH control the rasterization of the lines. Polygon rasterization attributes other than ?GL_POLYGON_MODE have no effect.
?GL_FILL: The interior of the polygon is filled. Polygon attributes such as ?GL_POLYGON_SMOOTH control the rasterization of the polygon.
See external documentation.
polygonOffset(Factor, Units) -> ok
Types:
Set the scale and units used to calculate depth values
When ?GL_POLYGON_OFFSET_FILL, ?GL_POLYGON_OFFSET_LINE, or ?GL_POLYGON_OFFSET_POINT is enabled, each fragment's depth value will be offset after it is interpolated from the depth values of the appropriate vertices. The value of the offset is factor×DZ+r×units, where DZ is a measurement of the change in depth relative to the screen area of the polygon, and r is the smallest value that is guaranteed to produce a resolvable offset for a given implementation. The offset is added before the depth test is performed and before the value is written into the depth buffer.
gl:polygonOffset is useful for rendering hidden-line images, for applying decals to surfaces, and for rendering solids with highlighted edges.
See external documentation.
Types:
Set the polygon stippling pattern
Polygon stippling, like line stippling (see gl:lineStipple/2 ), masks out certain fragments produced by rasterization, creating a pattern. Stippling is independent of polygon antialiasing.
Pattern is a pointer to a 32×32 stipple pattern that is stored in memory just like the pixel data supplied to a gl:drawPixels/5 call with height and width both equal to 32, a pixel format of ?GL_COLOR_INDEX, and data type of ?GL_BITMAP . That is, the stipple pattern is represented as a 32×32 array of 1-bit color indices packed in unsigned bytes. gl:pixelStoref/2 parameters like ?GL_UNPACK_SWAP_BYTES and ?GL_UNPACK_LSB_FIRST affect the assembling of the bits into a stipple pattern. Pixel transfer operations (shift, offset, pixel map) are not applied to the stipple image, however.
If a non-zero named buffer object is bound to the ?GL_PIXEL_UNPACK_BUFFER target (see gl:bindBuffer/2 ) while a stipple pattern is specified, Pattern is treated as a byte offset into the buffer object's data store.
To enable and disable polygon stippling, call gl:enable/1 and gl:enable/1 with argument ?GL_POLYGON_STIPPLE. Polygon stippling is initially disabled. If it's enabled, a rasterized polygon fragment with window coordinates x w and y w is sent to the next stage of the GL if and only if the ( x w% 32)th bit in the ( y w% 32)th row of the stipple pattern is 1 (one). When polygon stippling is disabled, it is as if the stipple pattern consists of all 1's.
See external documentation.
getPolygonStipple() -> binary()
Return the polygon stipple pattern
gl:getPolygonStipple returns to Pattern a 32×32 polygon stipple pattern. The pattern is packed into memory as if gl:readPixels/7 with both height and width of 32, type of ?GL_BITMAP, and format of ?GL_COLOR_INDEX were called, and the stipple pattern were stored in an internal 32×32 color index buffer. Unlike gl:readPixels/7 , however, pixel transfer operations (shift, offset, pixel map) are not applied to the returned stipple image.
If a non-zero named buffer object is bound to the ?GL_PIXEL_PACK_BUFFER target (see gl:bindBuffer/2 ) while a polygon stipple pattern is requested, Pattern is treated as a byte offset into the buffer object's data store.
See external documentation.
Types:
Flag edges as either boundary or nonboundary
Each vertex of a polygon, separate triangle, or separate quadrilateral specified between a gl:'begin'/1 / gl:'begin'/1 pair is marked as the start of either a boundary or nonboundary edge. If the current edge flag is true when the vertex is specified, the vertex is marked as the start of a boundary edge. Otherwise, the vertex is marked as the start of a nonboundary edge. gl:edgeFlag sets the edge flag bit to ?GL_TRUE if Flag is ?GL_TRUE and to ?GL_FALSE otherwise.
The vertices of connected triangles and connected quadrilaterals are always marked as boundary, regardless of the value of the edge flag.
Boundary and nonboundary edge flags on vertices are significant only if ?GL_POLYGON_MODE is set to ?GL_POINT or ?GL_LINE. See gl:polygonMode/2 .
See external documentation.
Types:
Equivalent to edgeFlag(Flag).
scissor(X, Y, Width, Height) -> ok
Types:
Define the scissor box
gl:scissor defines a rectangle, called the scissor box, in window coordinates. The first two arguments, X and Y , specify the lower left corner of the box. Width and Height specify the width and height of the box.
To enable and disable the scissor test, call gl:enable/1 and gl:enable/1 with argument ?GL_SCISSOR_TEST. The test is initially disabled. While the test is enabled, only pixels that lie within the scissor box can be modified by drawing commands. Window coordinates have integer values at the shared corners of frame buffer pixels. glScissor(0,0,1,1) allows modification of only the lower left pixel in the window, and glScissor(0,0,0,0) doesn't allow modification of any pixels in the window.
When the scissor test is disabled, it is as though the scissor box includes the entire window.
See external documentation.
clipPlane(Plane, Equation) -> ok
Types:
Specify a plane against which all geometry is clipped
Geometry is always clipped against the boundaries of a six-plane frustum in x, y , and z. gl:clipPlane allows the specification of additional planes, not necessarily perpendicular to the x, y, or z axis, against which all geometry is clipped. To determine the maximum number of additional clipping planes, call gl:getBooleanv/1 with argument ?GL_MAX_CLIP_PLANES. All implementations support at least six such clipping planes. Because the resulting clipping region is the intersection of the defined half-spaces, it is always convex.
gl:clipPlane specifies a half-space using a four-component plane equation. When gl:clipPlane is called, Equation is transformed by the inverse of the modelview matrix and stored in the resulting eye coordinates. Subsequent changes to the modelview matrix have no effect on the stored plane-equation components. If the dot product of the eye coordinates of a vertex with the stored plane equation components is positive or zero, the vertex is in with respect to that clipping plane. Otherwise, it is out.
To enable and disable clipping planes, call gl:enable/1 and gl:enable/1 with the argument ?GL_CLIP_PLANEi, where i is the plane number.
All clipping planes are initially defined as (0, 0, 0, 0) in eye coordinates and are disabled.
See external documentation.
getClipPlane(Plane) -> {float(), float(), float(), float()}
Types:
Return the coefficients of the specified clipping plane
gl:getClipPlane returns in Equation the four coefficients of the plane equation for Plane .
See external documentation.
Types:
Specify which color buffers are to be drawn into
When colors are written to the frame buffer, they are written into the color buffers specified by gl:drawBuffer. The specifications are as follows:
?GL_NONE: No color buffers are written.
?GL_FRONT_LEFT: Only the front left color buffer is written.
?GL_FRONT_RIGHT: Only the front right color buffer is written.
?GL_BACK_LEFT: Only the back left color buffer is written.
?GL_BACK_RIGHT: Only the back right color buffer is written.
?GL_FRONT: Only the front left and front right color buffers are written. If there is no front right color buffer, only the front left color buffer is written.
?GL_BACK: Only the back left and back right color buffers are written. If there is no back right color buffer, only the back left color buffer is written.
?GL_LEFT: Only the front left and back left color buffers are written. If there is no back left color buffer, only the front left color buffer is written.
?GL_RIGHT: Only the front right and back right color buffers are written. If there is no back right color buffer, only the front right color buffer is written.
?GL_FRONT_AND_BACK: All the front and back color buffers (front left, front right, back left, back right) are written. If there are no back color buffers, only the front left and front right color buffers are written. If there are no right color buffers, only the front left and back left color buffers are written. If there are no right or back color buffers, only the front left color buffer is written.
If more than one color buffer is selected for drawing, then blending or logical operations are computed and applied independently for each color buffer and can produce different results in each buffer.
Monoscopic contexts include only left buffers, and stereoscopic contexts include both left and right buffers. Likewise, single-buffered contexts include only front buffers, and double-buffered contexts include both front and back buffers. The context is selected at GL initialization.
See external documentation.
Types:
Select a color buffer source for pixels
gl:readBuffer specifies a color buffer as the source for subsequent gl:readPixels/7 , gl:copyTexImage1D/7 , gl:copyTexImage2D/8 , gl:copyTexSubImage1D/6 , gl:copyTexSubImage2D/8 , and gl:copyTexSubImage3D/9 commands. Mode accepts one of twelve or more predefined values. In a fully configured system, ?GL_FRONT, ?GL_LEFT, and ?GL_FRONT_LEFT all name the front left buffer, ?GL_FRONT_RIGHT and ?GL_RIGHT name the front right buffer, and ?GL_BACK_LEFT and ?GL_BACK name the back left buffer. Further more, the constants ?GL_COLOR_ATTACHMENTi may be used to indicate the ith color attachment where i ranges from zero to the value of ?GL_MAX_COLOR_ATTACHMENTS minus one.
Nonstereo double-buffered configurations have only a front left and a back left buffer. Single-buffered configurations have a front left and a front right buffer if stereo, and only a front left buffer if nonstereo. It is an error to specify a nonexistent buffer to gl:readBuffer .
Mode is initially ?GL_FRONT in single-buffered configurations and ?GL_BACK in double-buffered configurations.
See external documentation.
Types:
Enable or disable server-side GL capabilities
gl:enable and gl:enable/1 enable and disable various capabilities. Use gl:isEnabled/1 or gl:getBooleanv/1 to determine the current setting of any capability. The initial value for each capability with the exception of ?GL_DITHER and ?GL_MULTISAMPLE is ?GL_FALSE. The initial value for ?GL_DITHER and ?GL_MULTISAMPLE is ?GL_TRUE.
Both gl:enable and gl:enable/1 take a single argument, Cap , which can assume one of the following values:
Some of the GL's capabilities are indexed. gl:enablei and gl:disablei enable and disable indexed capabilities.
?GL_BLEND: If enabled, blend the computed fragment color values with the values in the color buffers. See gl:blendFunc/2 .
?GL_CLIP_DISTANCEi: If enabled, clip geometry against user-defined half space i.
?GL_COLOR_LOGIC_OP: If enabled, apply the currently selected logical operation to the computed fragment color and color buffer values. See gl:logicOp/1 .
?GL_CULL_FACE: If enabled, cull polygons based on their winding in window coordinates. See gl:cullFace/1 .
?GL_DEPTH_CLAMP: If enabled, the -w c≤ z c≤ w c plane equation is ignored by view volume clipping (effectively, there is no near or far plane clipping). See gl:depthRange/2 .
?GL_DEPTH_TEST: If enabled, do depth comparisons and update the depth buffer. Note that even if the depth buffer exists and the depth mask is non-zero, the depth buffer is not updated if the depth test is disabled. See gl:depthFunc/1 and gl:depthRange/2 .
?GL_DITHER: If enabled, dither color components or indices before they are written to the color buffer.
?GL_FRAMEBUFFER_SRGB: If enabled and the value of ?GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING for the framebuffer attachment corresponding to the destination buffer is ?GL_SRGB, the R, G, and B destination color values (after conversion from fixed-point to floating-point) are considered to be encoded for the sRGB color space and hence are linearized prior to their use in blending.
?GL_LINE_SMOOTH: If enabled, draw lines with correct filtering. Otherwise, draw aliased lines. See gl:lineWidth/1 .
?GL_MULTISAMPLE: If enabled, use multiple fragment samples in computing the final color of a pixel. See gl:sampleCoverage/2 .
?GL_POLYGON_OFFSET_FILL: If enabled, and if the polygon is rendered in ?GL_FILL mode, an offset is added to depth values of a polygon's fragments before the depth comparison is performed. See gl:polygonOffset/2 .
?GL_POLYGON_OFFSET_LINE: If enabled, and if the polygon is rendered in ?GL_LINE mode, an offset is added to depth values of a polygon's fragments before the depth comparison is performed. See gl:polygonOffset/2 .
?GL_POLYGON_OFFSET_POINT: If enabled, an offset is added to depth values of a polygon's fragments before the depth comparison is performed, if the polygon is rendered in ?GL_POINT mode. See gl:polygonOffset/2 .
?GL_POLYGON_SMOOTH: If enabled, draw polygons with proper filtering. Otherwise, draw aliased polygons. For correct antialiased polygons, an alpha buffer is needed and the polygons must be sorted front to back.
?GL_PRIMITIVE_RESTART: Enables primitive restarting. If enabled, any one of the draw commands which transfers a set of generic attribute array elements to the GL will restart the primitive when the index of the vertex is equal to the primitive restart index. See gl:primitiveRestartIndex/1 .
?GL_SAMPLE_ALPHA_TO_COVERAGE: If enabled, compute a temporary coverage value where each bit is determined by the alpha value at the corresponding sample location. The temporary coverage value is then ANDed with the fragment coverage value.
?GL_SAMPLE_ALPHA_TO_ONE: If enabled, each sample alpha value is replaced by the maximum representable alpha value.
?GL_SAMPLE_COVERAGE: If enabled, the fragment's coverage is ANDed with the temporary coverage value. If ?GL_SAMPLE_COVERAGE_INVERT is set to ?GL_TRUE, invert the coverage value. See gl:sampleCoverage/2 .
?GL_SAMPLE_SHADING: If enabled, the active fragment shader is run once for each covered sample, or at fraction of this rate as determined by the current value of ?GL_MIN_SAMPLE_SHADING_VALUE . See gl:minSampleShading/1 .
?GL_SAMPLE_MASK: If enabled, the sample coverage mask generated for a fragment during rasterization will be ANDed with the value of ?GL_SAMPLE_MASK_VALUE before shading occurs. See gl:sampleMaski/2 .
?GL_SCISSOR_TEST: If enabled, discard fragments that are outside the scissor rectangle. See gl:scissor/4 .
?GL_STENCIL_TEST: If enabled, do stencil testing and update the stencil buffer. See gl:stencilFunc/3 and gl:stencilOp/3 .
?GL_TEXTURE_CUBE_MAP_SEAMLESS: If enabled, cubemap textures are sampled such that when linearly sampling from the border between two adjacent faces, texels from both faces are used to generate the final sample value. When disabled, texels from only a single face are used to construct the final sample value.
?GL_PROGRAM_POINT_SIZE: If enabled and a vertex or geometry shader is active, then the derived point size is taken from the (potentially clipped) shader builtin ?gl_PointSize and clamped to the implementation-dependent point size range.
See external documentation.
Types:
See enable/1
Types:
Test whether a capability is enabled
gl:isEnabled returns ?GL_TRUE if Cap is an enabled capability and returns ?GL_FALSE otherwise. Boolean states that are indexed may be tested with gl:isEnabledi . For gl:isEnabledi, Index specifies the index of the capability to test. Index must be between zero and the count of indexed capabilities for Cap . Initially all capabilities except ?GL_DITHER are disabled; ?GL_DITHER is initially enabled.
The following capabilities are accepted for Cap :
Constant See?GL_BLEND gl:blendFunc/2 , gl:logicOp/1
?GL_CLIP_DISTANCEi gl:enable/1
?GL_COLOR_LOGIC_OP gl:logicOp/1
?GL_CULL_FACE gl:cullFace/1
?GL_DEPTH_CLAMP gl:enable/1
?GL_DEPTH_TEST gl:depthFunc/1 , gl:depthRange/2
?GL_DITHER gl:enable/1
?GL_FRAMEBUFFER_SRGB gl:enable/1
?GL_LINE_SMOOTH gl:lineWidth/1
?GL_MULTISAMPLE gl:sampleCoverage/2
?GL_POLYGON_SMOOTH gl:polygonMode/2
?GL_POLYGON_OFFSET_FILL gl:polygonOffset/2
?GL_POLYGON_OFFSET_LINE gl:polygonOffset/2
?GL_POLYGON_OFFSET_POINT gl:polygonOffset/2
?GL_PROGRAM_POINT_SIZE gl:enable/1
?GL_PRIMITIVE_RESTART gl:enable/1 , gl:primitiveRestartIndex/1
?GL_SAMPLE_ALPHA_TO_COVERAGE gl:sampleCoverage/2
?GL_SAMPLE_ALPHA_TO_ONE gl:sampleCoverage/2
?GL_SAMPLE_COVERAGE gl:sampleCoverage/2
?GL_SAMPLE_MASK gl:enable/1
?GL_SCISSOR_TEST gl:scissor/4
?GL_STENCIL_TEST gl:stencilFunc/3 , gl:stencilOp/3
?GL_TEXTURE_CUBEMAP_SEAMLESS gl:enable/1
See external documentation.
Types:
Enable or disable client-side capability
gl:enableClientState and gl:enableClientState/1 enable or disable individual client-side capabilities. By default, all client-side capabilities are disabled. Both gl:enableClientState and gl:enableClientState/1 take a single argument, Cap , which can assume one of the following values:
?GL_COLOR_ARRAY: If enabled, the color array is enabled for writing and used during rendering when gl:arrayElement/1 , gl:drawArrays/3 , gl:drawElements/4 , gl:drawRangeElements/6 gl:multiDrawArrays/3 , or see glMultiDrawElements is called. See gl:colorPointer/4 .
?GL_EDGE_FLAG_ARRAY: If enabled, the edge flag array is enabled for writing and used during rendering when gl:arrayElement/1 , gl:drawArrays/3 , gl:drawElements/4 , gl:drawRangeElements/6 gl:multiDrawArrays/3 , or see glMultiDrawElements is called. See gl:edgeFlagPointer/2 .
?GL_FOG_COORD_ARRAY: If enabled, the fog coordinate array is enabled for writing and used during rendering when gl:arrayElement/1 , gl:drawArrays/3 , gl:drawElements/4 , gl:drawRangeElements/6 gl:multiDrawArrays/3 , or see glMultiDrawElements is called. See gl:fogCoordPointer/3 .
?GL_INDEX_ARRAY: If enabled, the index array is enabled for writing and used during rendering when gl:arrayElement/1 , gl:drawArrays/3 , gl:drawElements/4 , gl:drawRangeElements/6 gl:multiDrawArrays/3 , or see glMultiDrawElements is called. See gl:indexPointer/3 .
?GL_NORMAL_ARRAY: If enabled, the normal array is enabled for writing and used during rendering when gl:arrayElement/1 , gl:drawArrays/3 , gl:drawElements/4 , gl:drawRangeElements/6 gl:multiDrawArrays/3 , or see glMultiDrawElements is called. See gl:normalPointer/3 .
?GL_SECONDARY_COLOR_ARRAY: If enabled, the secondary color array is enabled for writing and used during rendering when gl:arrayElement/1 , gl:drawArrays/3 , gl:drawElements/4 , gl:drawRangeElements/6 gl:multiDrawArrays/3 , or see glMultiDrawElements is called. See gl:colorPointer/4 .
?GL_TEXTURE_COORD_ARRAY: If enabled, the texture coordinate array is enabled for writing and used during rendering when gl:arrayElement/1 , gl:drawArrays/3 , gl:drawElements/4 , gl:drawRangeElements/6 gl:multiDrawArrays/3 , or see glMultiDrawElements is called. See gl:texCoordPointer/4 .
?GL_VERTEX_ARRAY: If enabled, the vertex array is enabled for writing and used during rendering when gl:arrayElement/1 , gl:drawArrays/3 , gl:drawElements/4 , gl:drawRangeElements/6 gl:multiDrawArrays/3 , or see glMultiDrawElements is called. See gl:vertexPointer/4 .
See external documentation.
Types:
Types:
Return the value or values of a selected parameter
These four commands return values for simple state variables in GL. Pname is a symbolic constant indicating the state variable to be returned, and Params is a pointer to an array of the indicated type in which to place the returned data.
Type conversion is performed if Params has a different type than the state variable value being requested. If gl:getBooleanv is called, a floating-point (or integer) value is converted to ?GL_FALSE if and only if it is 0.0 (or 0). Otherwise, it is converted to ?GL_TRUE. If gl:getIntegerv is called, boolean values are returned as ?GL_TRUE or ?GL_FALSE, and most floating-point values are rounded to the nearest integer value. Floating-point colors and normals, however, are returned with a linear mapping that maps 1.0 to the most positive representable integer value and -1.0 to the most negative representable integer value. If gl:getFloatv or gl:getDoublev is called, boolean values are returned as ?GL_TRUE or ?GL_FALSE, and integer values are converted to floating-point values.
The following symbolic constants are accepted by Pname :
?GL_ACTIVE_TEXTURE: Params returns a single value indicating the active multitexture unit. The initial value is ?GL_TEXTURE0. See gl:activeTexture/1 .
?GL_ALIASED_LINE_WIDTH_RANGE: Params returns a pair of values indicating the range of widths supported for aliased lines. See gl:lineWidth/1 .
?GL_ARRAY_BUFFER_BINDING: Params returns a single value, the name of the buffer object currently bound to the target ?GL_ARRAY_BUFFER. If no buffer object is bound to this target, 0 is returned. The initial value is 0. See gl:bindBuffer/2 .
?GL_BLEND: Params returns a single boolean value indicating whether blending is enabled. The initial value is ?GL_FALSE. See gl:blendFunc/2 .
?GL_BLEND_COLOR: Params returns four values, the red, green, blue, and alpha values which are the components of the blend color. See gl:blendColor/4 .
?GL_BLEND_DST_ALPHA: Params returns one value, the symbolic constant identifying the alpha destination blend function. The initial value is ?GL_ZERO. See gl:blendFunc/2 and gl:blendFuncSeparate/4 .
?GL_BLEND_DST_RGB: Params returns one value, the symbolic constant identifying the RGB destination blend function. The initial value is ?GL_ZERO. See gl:blendFunc/2 and gl:blendFuncSeparate/4 .
?GL_BLEND_EQUATION_RGB: Params returns one value, a symbolic constant indicating whether the RGB blend equation is ?GL_FUNC_ADD, ?GL_FUNC_SUBTRACT, ?GL_FUNC_REVERSE_SUBTRACT , ?GL_MIN or ?GL_MAX. See gl:blendEquationSeparate/2 .
?GL_BLEND_EQUATION_ALPHA: Params returns one value, a symbolic constant indicating whether the Alpha blend equation is ?GL_FUNC_ADD, ?GL_FUNC_SUBTRACT , ?GL_FUNC_REVERSE_SUBTRACT, ?GL_MIN or ?GL_MAX. See gl:blendEquationSeparate/2 .
?GL_BLEND_SRC_ALPHA: Params returns one value, the symbolic constant identifying the alpha source blend function. The initial value is ?GL_ONE. See gl:blendFunc/2 and gl:blendFuncSeparate/4 .
?GL_BLEND_SRC_RGB: Params returns one value, the symbolic constant identifying the RGB source blend function. The initial value is ?GL_ONE. See gl:blendFunc/2 and gl:blendFuncSeparate/4 .
?GL_COLOR_CLEAR_VALUE: Params returns four values: the red, green, blue, and alpha values used to clear the color buffers. Integer values, if requested, are linearly mapped from the internal floating-point representation such that 1.0 returns the most positive representable integer value, and -1.0 returns the most negative representable integer value. The initial value is (0, 0, 0, 0). See gl:clearColor/4 .
?GL_COLOR_LOGIC_OP: Params returns a single boolean value indicating whether a fragment's RGBA color values are merged into the framebuffer using a logical operation. The initial value is ?GL_FALSE. See gl:logicOp/1 .
?GL_COLOR_WRITEMASK: Params returns four boolean values: the red, green, blue, and alpha write enables for the color buffers. The initial value is (?GL_TRUE, ?GL_TRUE, ?GL_TRUE, ?GL_TRUE). See gl:colorMask/4 .
?GL_COMPRESSED_TEXTURE_FORMATS: Params returns a list of symbolic constants of length ?GL_NUM_COMPRESSED_TEXTURE_FORMATS indicating which compressed texture formats are available. See gl:compressedTexImage2D/8 .
?GL_CONTEXT_FLAGS: Params returns one value, the flags with which the context was created (such as debugging functionality).
?GL_CULL_FACE: Params returns a single boolean value indicating whether polygon culling is enabled. The initial value is ?GL_FALSE. See gl:cullFace/1 .
?GL_CURRENT_PROGRAM: Params returns one value, the name of the program object that is currently active, or 0 if no program object is active. See gl:useProgram/1 .
?GL_DEPTH_CLEAR_VALUE: Params returns one value, the value that is used to clear the depth buffer. Integer values, if requested, are linearly mapped from the internal floating-point representation such that 1.0 returns the most positive representable integer value, and -1.0 returns the most negative representable integer value. The initial value is 1. See gl:clearDepth/1 .
?GL_DEPTH_FUNC: Params returns one value, the symbolic constant that indicates the depth comparison function. The initial value is ?GL_LESS. See gl:depthFunc/1 .
?GL_DEPTH_RANGE: Params returns two values: the near and far mapping limits for the depth buffer. Integer values, if requested, are linearly mapped from the internal floating-point representation such that 1.0 returns the most positive representable integer value, and -1.0 returns the most negative representable integer value. The initial value is (0, 1). See gl:depthRange/2 .
?GL_DEPTH_TEST: Params returns a single boolean value indicating whether depth testing of fragments is enabled. The initial value is ?GL_FALSE. See gl:depthFunc/1 and gl:depthRange/2 .
?GL_DEPTH_WRITEMASK: Params returns a single boolean value indicating if the depth buffer is enabled for writing. The initial value is ?GL_TRUE. See gl:depthMask/1 .
?GL_DITHER: Params returns a single boolean value indicating whether dithering of fragment colors and indices is enabled. The initial value is ?GL_TRUE.
?GL_DOUBLEBUFFER: Params returns a single boolean value indicating whether double buffering is supported.
?GL_DRAW_BUFFER: Params returns one value, a symbolic constant indicating which buffers are being drawn to. See gl:drawBuffer/1 . The initial value is ?GL_BACK if there are back buffers, otherwise it is ?GL_FRONT.
?GL_DRAW_BUFFERi: Params returns one value, a symbolic constant indicating which buffers are being drawn to by the corresponding output color. See gl:drawBuffers/1 . The initial value of ?GL_DRAW_BUFFER0 is ?GL_BACK if there are back buffers, otherwise it is ?GL_FRONT. The initial values of draw buffers for all other output colors is ?GL_NONE.
?GL_DRAW_FRAMEBUFFER_BINDING: Params returns one value, the name of the framebuffer object currently bound to the ?GL_DRAW_FRAMEBUFFER target. If the default framebuffer is bound, this value will be zero. The initial value is zero. See gl:bindFramebuffer/2 .
?GL_READ_FRAMEBUFFER_BINDING: Params returns one value, the name of the framebuffer object currently bound to the ?GL_READ_FRAMEBUFFER target. If the default framebuffer is bound, this value will be zero. The initial value is zero. See gl:bindFramebuffer/2 .
?GL_ELEMENT_ARRAY_BUFFER_BINDING: Params returns a single value, the name of the buffer object currently bound to the target ?GL_ELEMENT_ARRAY_BUFFER. If no buffer object is bound to this target, 0 is returned. The initial value is 0. See gl:bindBuffer/2 .
?GL_FRAGMENT_SHADER_DERIVATIVE_HINT: Params returns one value, a symbolic constant indicating the mode of the derivative accuracy hint for fragment shaders. The initial value is ?GL_DONT_CARE. See gl:hint/2 .
?GL_IMPLEMENTATION_COLOR_READ_FORMAT: Params returns a single GLenum value indicating the implementation's preferred pixel data format. See gl:readPixels/7 .
?GL_IMPLEMENTATION_COLOR_READ_TYPE: Params returns a single GLenum value indicating the implementation's preferred pixel data type. See gl:readPixels/7 .
?GL_LINE_SMOOTH: Params returns a single boolean value indicating whether antialiasing of lines is enabled. The initial value is ?GL_FALSE. See gl:lineWidth/1 .
?GL_LINE_SMOOTH_HINT: Params returns one value, a symbolic constant indicating the mode of the line antialiasing hint. The initial value is ?GL_DONT_CARE. See gl:hint/2 .
?GL_LINE_WIDTH: Params returns one value, the line width as specified with gl:lineWidth/1 . The initial value is 1.
?GL_LAYER_PROVOKING_VERTEX: Params returns one value, the implementation dependent specifc vertex of a primitive that is used to select the rendering layer. If the value returned is equivalent to ?GL_PROVOKING_VERTEX, then the vertex selection follows the convention specified by gl:provokingVertex/1 . If the value returned is equivalent to ?GL_FIRST_VERTEX_CONVENTION, then the selection is always taken from the first vertex in the primitive. If the value returned is equivalent to ?GL_LAST_VERTEX_CONVENTION , then the selection is always taken from the last vertex in the primitive. If the value returned is equivalent to ?GL_UNDEFINED_VERTEX, then the selection is not guaranteed to be taken from any specific vertex in the primitive.
?GL_LINE_WIDTH_GRANULARITY: Params returns one value, the width difference between adjacent supported widths for antialiased lines. See gl:lineWidth/1 .
?GL_LINE_WIDTH_RANGE: Params returns two values: the smallest and largest supported widths for antialiased lines. See gl:lineWidth/1 .
?GL_LOGIC_OP_MODE: Params returns one value, a symbolic constant indicating the selected logic operation mode. The initial value is ?GL_COPY. See gl:logicOp/1 .
?GL_MAJOR_VERSION: Params returns one value, the major version number of the OpenGL API supported by the current context.
?GL_MAX_3D_TEXTURE_SIZE: Params returns one value, a rough estimate of the largest 3D texture that the GL can handle. The value must be at least 64. Use ?GL_PROXY_TEXTURE_3D to determine if a texture is too large. See gl:texImage3D/10 .
?GL_MAX_ARRAY_TEXTURE_LAYERS: Params returns one value. The value indicates the maximum number of layers allowed in an array texture, and must be at least 256. See gl:texImage2D/9 .
?GL_MAX_CLIP_DISTANCES: Params returns one value, the maximum number of application-defined clipping distances. The value must be at least 8.
?GL_MAX_COLOR_TEXTURE_SAMPLES: Params returns one value, the maximum number of samples in a color multisample texture.
?GL_MAX_COMBINED_ATOMIC_COUNTERS: Params returns a single value, the maximum number of atomic counters available to all active shaders.
?GL_MAX_COMBINED_FRAGMENT_UNIFORM_COMPONENTS: Params returns one value, the number of words for fragment shader uniform variables in all uniform blocks (including default). The value must be at least 1. See gl:uniform1f/2 .
?GL_MAX_COMBINED_GEOMETRY_UNIFORM_COMPONENTS: Params returns one value, the number of words for geometry shader uniform variables in all uniform blocks (including default). The value must be at least 1. See gl:uniform1f/2 .
?GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS: Params returns one value, the maximum supported texture image units that can be used to access texture maps from the vertex shader and the fragment processor combined. If both the vertex shader and the fragment processing stage access the same texture image unit, then that counts as using two texture image units against this limit. The value must be at least 48. See gl:activeTexture/1 .
?GL_MAX_COMBINED_UNIFORM_BLOCKS: Params returns one value, the maximum number of uniform blocks per program. The value must be at least 36. See gl:uniformBlockBinding/3 .
?GL_MAX_COMBINED_VERTEX_UNIFORM_COMPONENTS: Params returns one value, the number of words for vertex shader uniform variables in all uniform blocks (including default). The value must be at least 1. See gl:uniform1f/2 .
?GL_MAX_CUBE_MAP_TEXTURE_SIZE: Params returns one value. The value gives a rough estimate of the largest cube-map texture that the GL can handle. The value must be at least 1024. Use ?GL_PROXY_TEXTURE_CUBE_MAP to determine if a texture is too large. See gl:texImage2D/9 .
?GL_MAX_DEPTH_TEXTURE_SAMPLES: Params returns one value, the maximum number of samples in a multisample depth or depth-stencil texture.
?GL_MAX_DRAW_BUFFERS: Params returns one value, the maximum number of simultaneous outputs that may be written in a fragment shader. The value must be at least 8. See gl:drawBuffers/1 .
?GL_MAX_DUALSOURCE_DRAW_BUFFERS: Params returns one value, the maximum number of active draw buffers when using dual-source blending. The value must be at least 1. See gl:blendFunc/2 and gl:blendFuncSeparate/4 .
?GL_MAX_ELEMENTS_INDICES: Params returns one value, the recommended maximum number of vertex array indices. See gl:drawRangeElements/6 .
?GL_MAX_ELEMENTS_VERTICES: Params returns one value, the recommended maximum number of vertex array vertices. See gl:drawRangeElements/6 .
?GL_MAX_FRAGMENT_ATOMIC_COUNTERS: Params returns a single value, the maximum number of atomic counters available to fragment shaders.
?GL_MAX_FRAGMENT_INPUT_COMPONENTS: Params returns one value, the maximum number of components of the inputs read by the fragment shader, which must be at least 128.
?GL_MAX_FRAGMENT_UNIFORM_COMPONENTS: Params returns one value, the maximum number of individual floating-point, integer, or boolean values that can be held in uniform variable storage for a fragment shader. The value must be at least 1024. See gl:uniform1f/2 .
?GL_MAX_FRAGMENT_UNIFORM_VECTORS: Params returns one value, the maximum number of individual 4-vectors of floating-point, integer, or boolean values that can be held in uniform variable storage for a fragment shader. The value is equal to the value of ?GL_MAX_FRAGMENT_UNIFORM_COMPONENTS divided by 4 and must be at least 256. See gl:uniform1f/2 .
?GL_MAX_FRAGMENT_UNIFORM_BLOCKS: Params returns one value, the maximum number of uniform blocks per fragment shader. The value must be at least 12. See gl:uniformBlockBinding/3 .
?GL_MAX_GEOMETRY_ATOMIC_COUNTERS: Params returns a single value, the maximum number of atomic counters available to geometry shaders.
?GL_MAX_GEOMETRY_INPUT_COMPONENTS: Params returns one value, the maximum number of components of inputs read by a geometry shader, which must be at least 64.
?GL_MAX_GEOMETRY_OUTPUT_COMPONENTS: Params returns one value, the maximum number of components of outputs written by a geometry shader, which must be at least 128.
?GL_MAX_GEOMETRY_TEXTURE_IMAGE_UNITS: Params returns one value, the maximum supported texture image units that can be used to access texture maps from the geometry shader. The value must be at least 16. See gl:activeTexture/1 .
?GL_MAX_GEOMETRY_UNIFORM_BLOCKS: Params returns one value, the maximum number of uniform blocks per geometry shader. The value must be at least 12. See gl:uniformBlockBinding/3 .
?GL_MAX_GEOMETRY_UNIFORM_COMPONENTS: Params returns one value, the maximum number of individual floating-point, integer, or boolean values that can be held in uniform variable storage for a geometry shader. The value must be at least 1024. See gl:uniform1f/2 .
?GL_MAX_INTEGER_SAMPLES: Params returns one value, the maximum number of samples supported in integer format multisample buffers.
?GL_MIN_MAP_BUFFER_ALIGNMENT: Params returns one value, the minimum alignment in basic machine units of pointers returned fromsee glMapBuffer and see glMapBufferRange . This value must be a power of two and must be at least 64.
?GL_MAX_PROGRAM_TEXEL_OFFSET: Params returns one value, the maximum texel offset allowed in a texture lookup, which must be at least 7.
?GL_MIN_PROGRAM_TEXEL_OFFSET: Params returns one value, the minimum texel offset allowed in a texture lookup, which must be at most -8.
?GL_MAX_RECTANGLE_TEXTURE_SIZE: Params returns one value. The value gives a rough estimate of the largest rectangular texture that the GL can handle. The value must be at least 1024. Use ?GL_PROXY_RECTANGLE_TEXTURE to determine if a texture is too large. See gl:texImage2D/9 .
?GL_MAX_RENDERBUFFER_SIZE: Params returns one value. The value indicates the maximum supported size for renderbuffers. See gl:framebufferRenderbuffer/4 .
?GL_MAX_SAMPLE_MASK_WORDS: Params returns one value, the maximum number of sample mask words.
?GL_MAX_SERVER_WAIT_TIMEOUT: Params returns one value, the maximum gl:waitSync/3 timeout interval.
?GL_MAX_TESS_CONTROL_ATOMIC_COUNTERS: Params returns a single value, the maximum number of atomic counters available to tessellation control shaders.
?GL_MAX_TESS_EVALUATION_ATOMIC_COUNTERS: Params returns a single value, the maximum number of atomic counters available to tessellation evaluation shaders.
?GL_MAX_TEXTURE_BUFFER_SIZE: Params returns one value. The value gives the maximum number of texels allowed in the texel array of a texture buffer object. Value must be at least 65536.
?GL_MAX_TEXTURE_IMAGE_UNITS: Params returns one value, the maximum supported texture image units that can be used to access texture maps from the fragment shader. The value must be at least 16. See gl:activeTexture/1 .
?GL_MAX_TEXTURE_LOD_BIAS: Params returns one value, the maximum, absolute value of the texture level-of-detail bias. The value must be at least 2.0.
?GL_MAX_TEXTURE_SIZE: Params returns one value. The value gives a rough estimate of the largest texture that the GL can handle. The value must be at least 1024. Use a proxy texture target such as ?GL_PROXY_TEXTURE_1D or ?GL_PROXY_TEXTURE_2D to determine if a texture is too large. See gl:texImage1D/8 and gl:texImage2D/9 .
?GL_MAX_UNIFORM_BUFFER_BINDINGS: Params returns one value, the maximum number of uniform buffer binding points on the context, which must be at least 36.
?GL_MAX_UNIFORM_BLOCK_SIZE: Params returns one value, the maximum size in basic machine units of a uniform block, which must be at least 16384.
?GL_MAX_VARYING_COMPONENTS: Params returns one value, the number components for varying variables, which must be at least 60.
?GL_MAX_VARYING_VECTORS: Params returns one value, the number 4-vectors for varying variables, which is equal to the value of ?GL_MAX_VARYING_COMPONENTS and must be at least 15.
?GL_MAX_VARYING_FLOATS: Params returns one value, the maximum number of interpolators available for processing varying variables used by vertex and fragment shaders. This value represents the number of individual floating-point values that can be interpolated; varying variables declared as vectors, matrices, and arrays will all consume multiple interpolators. The value must be at least 32.
?GL_MAX_VERTEX_ATOMIC_COUNTERS: Params returns a single value, the maximum number of atomic counters available to vertex shaders.
?GL_MAX_VERTEX_ATTRIBS: Params returns one value, the maximum number of 4-component generic vertex attributes accessible to a vertex shader. The value must be at least 16. See gl:vertexAttrib1d/2 .
?GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS: Params returns one value, the maximum supported texture image units that can be used to access texture maps from the vertex shader. The value may be at least 16. See gl:activeTexture/1 .
?GL_MAX_VERTEX_UNIFORM_COMPONENTS: Params returns one value, the maximum number of individual floating-point, integer, or boolean values that can be held in uniform variable storage for a vertex shader. The value must be at least 1024. See gl:uniform1f/2 .
?GL_MAX_VERTEX_UNIFORM_VECTORS: Params returns one value, the maximum number of 4-vectors that may be held in uniform variable storage for the vertex shader. The value of ?GL_MAX_VERTEX_UNIFORM_VECTORS is equal to the value of ?GL_MAX_VERTEX_UNIFORM_COMPONENTS and must be at least 256.
?GL_MAX_VERTEX_OUTPUT_COMPONENTS: Params returns one value, the maximum number of components of output written by a vertex shader, which must be at least 64.
?GL_MAX_VERTEX_UNIFORM_BLOCKS: Params returns one value, the maximum number of uniform blocks per vertex shader. The value must be at least 12. See gl:uniformBlockBinding/3 .
?GL_MAX_VIEWPORT_DIMS: Params returns two values: the maximum supported width and height of the viewport. These must be at least as large as the visible dimensions of the display being rendered to. See gl:viewport/4 .
?GL_MAX_VIEWPORTS: Params returns one value, the maximum number of simultaneous viewports that are supported. The value must be at least 16. See gl:viewportIndexedf/5 .
?GL_MINOR_VERSION: Params returns one value, the minor version number of the OpenGL API supported by the current context.
?GL_NUM_COMPRESSED_TEXTURE_FORMATS: Params returns a single integer value indicating the number of available compressed texture formats. The minimum value is 4. See gl:compressedTexImage2D/8 .
?GL_NUM_EXTENSIONS: Params returns one value, the number of extensions supported by the GL implementation for the current context. See gl:getString/1 .
?GL_NUM_PROGRAM_BINARY_FORMATS: Params returns one value, the number of program binary formats supported by the implementation.
?GL_NUM_SHADER_BINARY_FORMATS: Params returns one value, the number of binary shader formats supported by the implementation. If this value is greater than zero, then the implementation supports loading binary shaders. If it is zero, then the loading of binary shaders by the implementation is not supported.
?GL_PACK_ALIGNMENT: Params returns one value, the byte alignment used for writing pixel data to memory. The initial value is 4. See gl:pixelStoref/2 .
?GL_PACK_IMAGE_HEIGHT: Params returns one value, the image height used for writing pixel data to memory. The initial value is 0. See gl:pixelStoref/2 .
?GL_PACK_LSB_FIRST: Params returns a single boolean value indicating whether single-bit pixels being written to memory are written first to the least significant bit of each unsigned byte. The initial value is ?GL_FALSE. See gl:pixelStoref/2 .
?GL_PACK_ROW_LENGTH: Params returns one value, the row length used for writing pixel data to memory. The initial value is 0. See gl:pixelStoref/2 .
?GL_PACK_SKIP_IMAGES: Params returns one value, the number of pixel images skipped before the first pixel is written into memory. The initial value is 0. See gl:pixelStoref/2 .
?GL_PACK_SKIP_PIXELS: Params returns one value, the number of pixel locations skipped before the first pixel is written into memory. The initial value is 0. See gl:pixelStoref/2 .
?GL_PACK_SKIP_ROWS: Params returns one value, the number of rows of pixel locations skipped before the first pixel is written into memory. The initial value is 0. See gl:pixelStoref/2 .
?GL_PACK_SWAP_BYTES: Params returns a single boolean value indicating whether the bytes of two-byte and four-byte pixel indices and components are swapped before being written to memory. The initial value is ?GL_FALSE. See gl:pixelStoref/2 .
?GL_PIXEL_PACK_BUFFER_BINDING: Params returns a single value, the name of the buffer object currently bound to the target ?GL_PIXEL_PACK_BUFFER. If no buffer object is bound to this target, 0 is returned. The initial value is 0. See gl:bindBuffer/2 .
?GL_PIXEL_UNPACK_BUFFER_BINDING: Params returns a single value, the name of the buffer object currently bound to the target ?GL_PIXEL_UNPACK_BUFFER. If no buffer object is bound to this target, 0 is returned. The initial value is 0. See gl:bindBuffer/2 .
?GL_POINT_FADE_THRESHOLD_SIZE: Params returns one value, the point size threshold for determining the point size. See gl:pointParameterf/2 .
?GL_PRIMITIVE_RESTART_INDEX: Params returns one value, the current primitive restart index. The initial value is 0. See gl:primitiveRestartIndex/1 .
?GL_PROGRAM_BINARY_FORMATS: Params an array of ?GL_NUM_PROGRAM_BINARY_FORMATS values, indicating the proram binary formats supported by the implementation.
?GL_PROGRAM_PIPELINE_BINDING: Params a single value, the name of the currently bound program pipeline object, or zero if no program pipeline object is bound. See gl:bindProgramPipeline/1 .
?GL_PROVOKING_VERTEX: Params returns one value, the currently selected provoking vertex convention. The initial value is ?GL_LAST_VERTEX_CONVENTION. See gl:provokingVertex/1 .
?GL_POINT_SIZE: Params returns one value, the point size as specified by gl:pointSize/1 . The initial value is 1.
?GL_POINT_SIZE_GRANULARITY: Params returns one value, the size difference between adjacent supported sizes for antialiased points. See gl:pointSize/1 .
?GL_POINT_SIZE_RANGE: Params returns two values: the smallest and largest supported sizes for antialiased points. The smallest size must be at most 1, and the largest size must be at least 1. See gl:pointSize/1 .
?GL_POLYGON_OFFSET_FACTOR: Params returns one value, the scaling factor used to determine the variable offset that is added to the depth value of each fragment generated when a polygon is rasterized. The initial value is 0. See gl:polygonOffset/2 .
?GL_POLYGON_OFFSET_UNITS: Params returns one value. This value is multiplied by an implementation-specific value and then added to the depth value of each fragment generated when a polygon is rasterized. The initial value is 0. See gl:polygonOffset/2 .
?GL_POLYGON_OFFSET_FILL: Params returns a single boolean value indicating whether polygon offset is enabled for polygons in fill mode. The initial value is ?GL_FALSE . See gl:polygonOffset/2 .
?GL_POLYGON_OFFSET_LINE: Params returns a single boolean value indicating whether polygon offset is enabled for polygons in line mode. The initial value is ?GL_FALSE . See gl:polygonOffset/2 .
?GL_POLYGON_OFFSET_POINT: Params returns a single boolean value indicating whether polygon offset is enabled for polygons in point mode. The initial value is ?GL_FALSE . See gl:polygonOffset/2 .
?GL_POLYGON_SMOOTH: Params returns a single boolean value indicating whether antialiasing of polygons is enabled. The initial value is ?GL_FALSE. See gl:polygonMode/2 .
?GL_POLYGON_SMOOTH_HINT: Params returns one value, a symbolic constant indicating the mode of the polygon antialiasing hint. The initial value is ?GL_DONT_CARE. See gl:hint/2 .
?GL_READ_BUFFER: Params returns one value, a symbolic constant indicating which color buffer is selected for reading. The initial value is ?GL_BACK if there is a back buffer, otherwise it is ?GL_FRONT. See gl:readPixels/7 .
?GL_RENDERBUFFER_BINDING: Params returns a single value, the name of the renderbuffer object currently bound to the target ?GL_RENDERBUFFER. If no renderbuffer object is bound to this target, 0 is returned. The initial value is 0. See gl:bindRenderbuffer/2 .
?GL_SAMPLE_BUFFERS: Params returns a single integer value indicating the number of sample buffers associated with the framebuffer. See gl:sampleCoverage/2 .
?GL_SAMPLE_COVERAGE_VALUE: Params returns a single positive floating-point value indicating the current sample coverage value. See gl:sampleCoverage/2 .
?GL_SAMPLE_COVERAGE_INVERT: Params returns a single boolean value indicating if the temporary coverage value should be inverted. See gl:sampleCoverage/2 .
?GL_SAMPLER_BINDING: Params returns a single value, the name of the sampler object currently bound to the active texture unit. The initial value is 0. See gl:bindSampler/2 .
?GL_SAMPLES: Params returns a single integer value indicating the coverage mask size. See gl:sampleCoverage/2 .
?GL_SCISSOR_BOX: Params returns four values: the x and y window coordinates of the scissor box, followed by its width and height. Initially the x and y window coordinates are both 0 and the width and height are set to the size of the window. See gl:scissor/4 .
?GL_SCISSOR_TEST: Params returns a single boolean value indicating whether scissoring is enabled. The initial value is ?GL_FALSE. See gl:scissor/4 .
?GL_SHADER_COMPILER: Params returns a single boolean value indicating whether an online shader compiler is present in the implementation. All desktop OpenGL implementations must support online shader compilations, and therefore the value of ?GL_SHADER_COMPILER will always be ?GL_TRUE.
?GL_SMOOTH_LINE_WIDTH_RANGE: Params returns a pair of values indicating the range of widths supported for smooth (antialiased) lines. See gl:lineWidth/1 .
?GL_SMOOTH_LINE_WIDTH_GRANULARITY: Params returns a single value indicating the level of quantization applied to smooth line width parameters.
?GL_STENCIL_BACK_FAIL: Params returns one value, a symbolic constant indicating what action is taken for back-facing polygons when the stencil test fails. The initial value is ?GL_KEEP. See gl:stencilOpSeparate/4 .
?GL_STENCIL_BACK_FUNC: Params returns one value, a symbolic constant indicating what function is used for back-facing polygons to compare the stencil reference value with the stencil buffer value. The initial value is ?GL_ALWAYS. See gl:stencilFuncSeparate/4 .
?GL_STENCIL_BACK_PASS_DEPTH_FAIL: Params returns one value, a symbolic constant indicating what action is taken for back-facing polygons when the stencil test passes, but the depth test fails. The initial value is ?GL_KEEP. See gl:stencilOpSeparate/4 .
?GL_STENCIL_BACK_PASS_DEPTH_PASS: Params returns one value, a symbolic constant indicating what action is taken for back-facing polygons when the stencil test passes and the depth test passes. The initial value is ?GL_KEEP. See gl:stencilOpSeparate/4 .
?GL_STENCIL_BACK_REF: Params returns one value, the reference value that is compared with the contents of the stencil buffer for back-facing polygons. The initial value is 0. See gl:stencilFuncSeparate/4 .
?GL_STENCIL_BACK_VALUE_MASK: Params returns one value, the mask that is used for back-facing polygons to mask both the stencil reference value and the stencil buffer value before they are compared. The initial value is all 1's. See gl:stencilFuncSeparate/4 .
?GL_STENCIL_BACK_WRITEMASK: Params returns one value, the mask that controls writing of the stencil bitplanes for back-facing polygons. The initial value is all 1's. See gl:stencilMaskSeparate/2 .
?GL_STENCIL_CLEAR_VALUE: Params returns one value, the index to which the stencil bitplanes are cleared. The initial value is 0. See gl:clearStencil/1 .
?GL_STENCIL_FAIL: Params returns one value, a symbolic constant indicating what action is taken when the stencil test fails. The initial value is ?GL_KEEP. See gl:stencilOp/3 . This stencil state only affects non-polygons and front-facing polygons. Back-facing polygons use separate stencil state. See gl:stencilOpSeparate/4 .
?GL_STENCIL_FUNC: Params returns one value, a symbolic constant indicating what function is used to compare the stencil reference value with the stencil buffer value. The initial value is ?GL_ALWAYS. See gl:stencilFunc/3 . This stencil state only affects non-polygons and front-facing polygons. Back-facing polygons use separate stencil state. See gl:stencilFuncSeparate/4 .
?GL_STENCIL_PASS_DEPTH_FAIL: Params returns one value, a symbolic constant indicating what action is taken when the stencil test passes, but the depth test fails. The initial value is ?GL_KEEP. See gl:stencilOp/3 . This stencil state only affects non-polygons and front-facing polygons. Back-facing polygons use separate stencil state. See gl:stencilOpSeparate/4 .
?GL_STENCIL_PASS_DEPTH_PASS: Params returns one value, a symbolic constant indicating what action is taken when the stencil test passes and the depth test passes. The initial value is ?GL_KEEP. See gl:stencilOp/3 . This stencil state only affects non-polygons and front-facing polygons. Back-facing polygons use separate stencil state. See gl:stencilOpSeparate/4 .
?GL_STENCIL_REF: Params returns one value, the reference value that is compared with the contents of the stencil buffer. The initial value is 0. See gl:stencilFunc/3 . This stencil state only affects non-polygons and front-facing polygons. Back-facing polygons use separate stencil state. See gl:stencilFuncSeparate/4 .
?GL_STENCIL_TEST: Params returns a single boolean value indicating whether stencil testing of fragments is enabled. The initial value is ?GL_FALSE. See gl:stencilFunc/3 and gl:stencilOp/3 .
?GL_STENCIL_VALUE_MASK: Params returns one value, the mask that is used to mask both the stencil reference value and the stencil buffer value before they are compared. The initial value is all 1's. See gl:stencilFunc/3 . This stencil state only affects non-polygons and front-facing polygons. Back-facing polygons use separate stencil state. See gl:stencilFuncSeparate/4 .
?GL_STENCIL_WRITEMASK: Params returns one value, the mask that controls writing of the stencil bitplanes. The initial value is all 1's. See gl:stencilMask/1 . This stencil state only affects non-polygons and front-facing polygons. Back-facing polygons use separate stencil state. See gl:stencilMaskSeparate/2 .
?GL_STEREO: Params returns a single boolean value indicating whether stereo buffers (left and right) are supported.
?GL_SUBPIXEL_BITS: Params returns one value, an estimate of the number of bits of subpixel resolution that are used to position rasterized geometry in window coordinates. The value must be at least 4.
?GL_TEXTURE_BINDING_1D: Params returns a single value, the name of the texture currently bound to the target ?GL_TEXTURE_1D. The initial value is 0. See gl:bindTexture/2 .
?GL_TEXTURE_BINDING_1D_ARRAY: Params returns a single value, the name of the texture currently bound to the target ?GL_TEXTURE_1D_ARRAY. The initial value is 0. See gl:bindTexture/2 .
?GL_TEXTURE_BINDING_2D: Params returns a single value, the name of the texture currently bound to the target ?GL_TEXTURE_2D. The initial value is 0. See gl:bindTexture/2 .
?GL_TEXTURE_BINDING_2D_ARRAY: Params returns a single value, the name of the texture currently bound to the target ?GL_TEXTURE_2D_ARRAY. The initial value is 0. See gl:bindTexture/2 .
?GL_TEXTURE_BINDING_2D_MULTISAMPLE: Params returns a single value, the name of the texture currently bound to the target ?GL_TEXTURE_2D_MULTISAMPLE. The initial value is 0. See gl:bindTexture/2 .
?GL_TEXTURE_BINDING_2D_MULTISAMPLE_ARRAY: Params returns a single value, the name of the texture currently bound to the target ?GL_TEXTURE_2D_MULTISAMPLE_ARRAY . The initial value is 0. See gl:bindTexture/2 .
?GL_TEXTURE_BINDING_3D: Params returns a single value, the name of the texture currently bound to the target ?GL_TEXTURE_3D. The initial value is 0. See gl:bindTexture/2 .
?GL_TEXTURE_BINDING_BUFFER: Params returns a single value, the name of the texture currently bound to the target ?GL_TEXTURE_BUFFER. The initial value is 0. See gl:bindTexture/2 .
?GL_TEXTURE_BINDING_CUBE_MAP: Params returns a single value, the name of the texture currently bound to the target ?GL_TEXTURE_CUBE_MAP. The initial value is 0. See gl:bindTexture/2 .
?GL_TEXTURE_BINDING_RECTANGLE: Params returns a single value, the name of the texture currently bound to the target ?GL_TEXTURE_RECTANGLE. The initial value is 0. See gl:bindTexture/2 .
?GL_TEXTURE_COMPRESSION_HINT: Params returns a single value indicating the mode of the texture compression hint. The initial value is ?GL_DONT_CARE.
?GL_TEXTURE_BUFFER_BINDING: Params returns a single value, the name of the texture buffer object currently bound. The initial value is 0. See gl:bindBuffer/2 .
?GL_TIMESTAMP: Params returns a single value, the 64-bit value of the current GL time. See gl:queryCounter/2 .
?GL_TRANSFORM_FEEDBACK_BUFFER_BINDING: When used with non-indexed variants of gl:get (such as gl:getIntegerv), Params returns a single value, the name of the buffer object currently bound to the target ?GL_TRANSFORM_FEEDBACK_BUFFER. If no buffer object is bound to this target, 0 is returned. When used with indexed variants of gl:get (such as gl:getIntegeri_v), Params returns a single value, the name of the buffer object bound to the indexed transform feedback attribute stream. The initial value is 0 for all targets. See gl:bindBuffer/2 , gl:bindBufferBase/3 , and gl:bindBufferRange/5 .
?GL_TRANSFORM_FEEDBACK_BUFFER_START: When used with indexed variants of gl:get (such as gl:getInteger64i_v), Params returns a single value, the start offset of the binding range for each transform feedback attribute stream. The initial value is 0 for all streams. See gl:bindBufferRange/5 .
?GL_TRANSFORM_FEEDBACK_BUFFER_SIZE: When used with indexed variants of gl:get (such as gl:getInteger64i_v), Params returns a single value, the size of the binding range for each transform feedback attribute stream. The initial value is 0 for all streams. See gl:bindBufferRange/5 .
?GL_UNIFORM_BUFFER_BINDING: When used with non-indexed variants of gl:get (such as gl:getIntegerv), Params returns a single value, the name of the buffer object currently bound to the target ?GL_UNIFORM_BUFFER. If no buffer object is bound to this target, 0 is returned. When used with indexed variants of gl:get (such as gl:getIntegeri_v), Params returns a single value, the name of the buffer object bound to the indexed uniform buffer binding point. The initial value is 0 for all targets. See gl:bindBuffer/2 , gl:bindBufferBase/3 , and gl:bindBufferRange/5 .
?GL_UNIFORM_BUFFER_OFFSET_ALIGNMENT: Params returns a single value, the minimum required alignment for uniform buffer sizes and offset. The initial value is 1. See gl:uniformBlockBinding/3 .
?GL_UNIFORM_BUFFER_SIZE: When used with indexed variants of gl:get (such as gl:getInteger64i_v), Params returns a single value, the size of the binding range for each indexed uniform buffer binding. The initial value is 0 for all bindings. See gl:bindBufferRange/5 .
?GL_UNIFORM_BUFFER_START: When used with indexed variants of gl:get (such as gl:getInteger64i_v), Params returns a single value, the start offset of the binding range for each indexed uniform buffer binding. The initial value is 0 for all bindings. See gl:bindBufferRange/5 .
?GL_UNPACK_ALIGNMENT: Params returns one value, the byte alignment used for reading pixel data from memory. The initial value is 4. See gl:pixelStoref/2 .
?GL_UNPACK_IMAGE_HEIGHT: Params returns one value, the image height used for reading pixel data from memory. The initial is 0. See gl:pixelStoref/2 .
?GL_UNPACK_LSB_FIRST: Params returns a single boolean value indicating whether single-bit pixels being read from memory are read first from the least significant bit of each unsigned byte. The initial value is ?GL_FALSE. See gl:pixelStoref/2 .
?GL_UNPACK_ROW_LENGTH: Params returns one value, the row length used for reading pixel data from memory. The initial value is 0. See gl:pixelStoref/2 .
?GL_UNPACK_SKIP_IMAGES: Params returns one value, the number of pixel images skipped before the first pixel is read from memory. The initial value is 0. See gl:pixelStoref/2 .
?GL_UNPACK_SKIP_PIXELS: Params returns one value, the number of pixel locations skipped before the first pixel is read from memory. The initial value is 0. See gl:pixelStoref/2 .
?GL_UNPACK_SKIP_ROWS: Params returns one value, the number of rows of pixel locations skipped before the first pixel is read from memory. The initial value is 0. See gl:pixelStoref/2 .
?GL_UNPACK_SWAP_BYTES: Params returns a single boolean value indicating whether the bytes of two-byte and four-byte pixel indices and components are swapped after being read from memory. The initial value is ?GL_FALSE. See gl:pixelStoref/2 .
?GL_VERTEX_PROGRAM_POINT_SIZE: Params returns a single boolean value indicating whether vertex program point size mode is enabled. If enabled, and a vertex shader is active, then the point size is taken from the shader built-in gl_PointSize. If disabled, and a vertex shader is active, then the point size is taken from the point state as specified by gl:pointSize/1 . The initial value is ?GL_FALSE.
?GL_VIEWPORT: When used with non-indexed variants of gl:get (such as gl:getIntegerv ), Params returns four values: the x and y window coordinates of the viewport, followed by its width and height. Initially the x and y window coordinates are both set to 0, and the width and height are set to the width and height of the window into which the GL will do its rendering. See gl:viewport/4 . When used with indexed variants of gl:get (such as gl:getIntegeri_v), Params returns four values: the x and y window coordinates of the indexed viewport, followed by its width and height. Initially the x and y window coordinates are both set to 0, and the width and height are set to the width and height of the window into which the GL will do its rendering. See gl:viewportIndexedf/5 .
?GL_VIEWPORT_BOUNDS_RANGE: Params returns two values, the minimum and maximum viewport bounds range. The minimum range should be at least [-32768, 32767].
?GL_VIEWPORT_INDEX_PROVOKING_VERTEX: Params returns one value, the implementation dependent specifc vertex of a primitive that is used to select the viewport index. If the value returned is equivalent to ?GL_PROVOKING_VERTEX, then the vertex selection follows the convention specified by gl:provokingVertex/1 . If the value returned is equivalent to ?GL_FIRST_VERTEX_CONVENTION, then the selection is always taken from the first vertex in the primitive. If the value returned is equivalent to ?GL_LAST_VERTEX_CONVENTION , then the selection is always taken from the last vertex in the primitive. If the value returned is equivalent to ?GL_UNDEFINED_VERTEX, then the selection is not guaranteed to be taken from any specific vertex in the primitive.
?GL_VIEWPORT_SUBPIXEL_BITS: Params returns a single value, the number of bits of sub-pixel precision which the GL uses to interpret the floating point viewport bounds. The minimum value is 0.
Many of the boolean parameters can also be queried more easily using gl:isEnabled/1 .
See external documentation.
getDoublev(Pname) -> [float()]
Types:
See getBooleanv/1
Types:
See getBooleanv/1
getIntegerv(Pname) -> [integer()]
Types:
See getBooleanv/1
Types:
Push and pop the server attribute stack
gl:pushAttrib takes one argument, a mask that indicates which groups of state variables to save on the attribute stack. Symbolic constants are used to set bits in the mask. Mask is typically constructed by specifying the bitwise-or of several of these constants together. The special mask ?GL_ALL_ATTRIB_BITS can be used to save all stackable states.
The symbolic mask constants and their associated GL state are as follows (the second column lists which attributes are saved):
?GL_ACCUM_BUFFER_BIT Accumulation buffer clear value?GL_COLOR_BUFFER_BIT?GL_ALPHA_TEST enable bit
Alpha test function and reference value
?GL_BLEND enable bit
Blending source and destination functions
Constant blend color
Blending equation
?GL_DITHER enable bit
?GL_DRAW_BUFFER setting
?GL_COLOR_LOGIC_OP enable bit
?GL_INDEX_LOGIC_OP enable bit
Logic op function
Color mode and index mode clear values
Color mode and index mode writemasks
?GL_CURRENT_BIT Current RGBA color
Current color index
Current normal vector
Current texture coordinates
Current raster position
?GL_CURRENT_RASTER_POSITION_VALID flag
RGBA color associated with current raster position
Color index associated with current raster position
Texture coordinates associated with current raster position
?GL_EDGE_FLAG flag
?GL_DEPTH_BUFFER_BIT?GL_DEPTH_TEST enable bit
Depth buffer test function
Depth buffer clear value
?GL_DEPTH_WRITEMASK enable bit
?GL_ENABLE_BIT?GL_ALPHA_TEST flag
?GL_AUTO_NORMAL flag
?GL_BLEND flag
Enable bits for the user-definable clipping planes
?GL_COLOR_MATERIAL
?GL_CULL_FACE flag
?GL_DEPTH_TEST flag
?GL_DITHER flag
?GL_FOG flag
?GL_LIGHT i where ?0 <= i < ?GL_MAX_LIGHTS
?GL_LIGHTING flag
?GL_LINE_SMOOTH flag
?GL_LINE_STIPPLE flag
?GL_COLOR_LOGIC_OP flag
?GL_INDEX_LOGIC_OP flag
?GL_MAP1_x where x is a map type
?GL_MAP2_ x where x is a map type
?GL_MULTISAMPLE flag
?GL_NORMALIZE flag
?GL_POINT_SMOOTH flag
?GL_POLYGON_OFFSET_LINE flag
?GL_POLYGON_OFFSET_FILL flag
?GL_POLYGON_OFFSET_POINT flag
?GL_POLYGON_SMOOTH flag
?GL_POLYGON_STIPPLE flag
?GL_SAMPLE_ALPHA_TO_COVERAGE flag
?GL_SAMPLE_ALPHA_TO_ONE flag
?GL_SAMPLE_COVERAGE flag
?GL_SCISSOR_TEST flag
?GL_STENCIL_TEST flag
?GL_TEXTURE_1D flag
?GL_TEXTURE_2D flag
?GL_TEXTURE_3D flag
Flags ?GL_TEXTURE_GEN_x where x is S, T, R, or Q
?GL_EVAL_BIT?GL_MAP1_x enable bits, where x is a map type
?GL_MAP2_x enable bits, where x is a map type
1D grid endpoints and divisions
2D grid endpoints and divisions
?GL_AUTO_NORMAL enable bit
?GL_FOG_BIT?GL_FOG enable bit
Fog color
Fog density
Linear fog start
Linear fog end
Fog index
?GL_FOG_MODE value
?GL_HINT_BIT?GL_PERSPECTIVE_CORRECTION_HINT setting
?GL_POINT_SMOOTH_HINT setting
?GL_LINE_SMOOTH_HINT setting
?GL_POLYGON_SMOOTH_HINT setting
?GL_FOG_HINT setting
?GL_GENERATE_MIPMAP_HINT setting
?GL_TEXTURE_COMPRESSION_HINT setting
?GL_LIGHTING_BIT?GL_COLOR_MATERIAL enable bit
?GL_COLOR_MATERIAL_FACE value
Color material parameters that are tracking the current color
Ambient scene color
?GL_LIGHT_MODEL_LOCAL_VIEWER value
?GL_LIGHT_MODEL_TWO_SIDE setting
?GL_LIGHTING enable bit
Enable bit for each light
Ambient, diffuse, and specular intensity for each light
Direction, position, exponent, and cutoff angle for each light
Constant, linear, and quadratic attenuation factors for each light
Ambient, diffuse, specular, and emissive color for each material
Ambient, diffuse, and specular color indices for each material
Specular exponent for each material
?GL_SHADE_MODEL setting
?GL_LINE_BIT?GL_LINE_SMOOTH flag
?GL_LINE_STIPPLE enable bit
Line stipple pattern and repeat counter
Line width
?GL_LIST_BIT ?GL_LIST_BASE setting
?GL_MULTISAMPLE_BIT ?GL_MULTISAMPLE flag
?GL_SAMPLE_ALPHA_TO_COVERAGE flag
?GL_SAMPLE_ALPHA_TO_ONE flag
?GL_SAMPLE_COVERAGE flag
?GL_SAMPLE_COVERAGE_VALUE value
?GL_SAMPLE_COVERAGE_INVERT value
?GL_PIXEL_MODE_BIT?GL_RED_BIAS and ?GL_RED_SCALE settings
?GL_GREEN_BIAS and ?GL_GREEN_SCALE values
?GL_BLUE_BIAS and ?GL_BLUE_SCALE
?GL_ALPHA_BIAS and ?GL_ALPHA_SCALE
?GL_DEPTH_BIAS and ?GL_DEPTH_SCALE
?GL_INDEX_OFFSET and ?GL_INDEX_SHIFT values
?GL_MAP_COLOR and ?GL_MAP_STENCIL flags
?GL_ZOOM_X and ?GL_ZOOM_Y factors
?GL_READ_BUFFER setting
?GL_POINT_BIT?GL_POINT_SMOOTH flag
Point size
?GL_POLYGON_BIT?GL_CULL_FACE enable bit
?GL_CULL_FACE_MODE value
?GL_FRONT_FACE indicator
?GL_POLYGON_MODE setting
?GL_POLYGON_SMOOTH flag
?GL_POLYGON_STIPPLE enable bit
?GL_POLYGON_OFFSET_FILL flag
?GL_POLYGON_OFFSET_LINE flag
?GL_POLYGON_OFFSET_POINT flag
?GL_POLYGON_OFFSET_FACTOR
?GL_POLYGON_OFFSET_UNITS
?GL_POLYGON_STIPPLE_BIT Polygon stipple image
?GL_SCISSOR_BIT?GL_SCISSOR_TEST flag
Scissor box
?GL_STENCIL_BUFFER_BIT ?GL_STENCIL_TEST enable bit
Stencil function and reference value
Stencil value mask
Stencil fail, pass, and depth buffer pass actions
Stencil buffer clear value
Stencil buffer writemask
?GL_TEXTURE_BIT Enable bits for the four texture coordinates
Border color for each texture image
Minification function for each texture image
Magnification function for each texture image
Texture coordinates and wrap mode for each texture image
Color and mode for each texture environment
Enable bits ?GL_TEXTURE_GEN_x, x is S, T, R, and Q
?GL_TEXTURE_GEN_MODE setting for S, T, R, and Q
gl:texGend/3 plane equations for S, T, R, and Q
Current texture bindings (for example, ?GL_TEXTURE_BINDING_2D)
?GL_TRANSFORM_BIT Coefficients of the six clipping planes
Enable bits for the user-definable clipping planes
?GL_MATRIX_MODE value
?GL_NORMALIZE flag
?GL_RESCALE_NORMAL flag
?GL_VIEWPORT_BIT Depth range (near and far)
Viewport origin and extent
gl:pushAttrib/1 restores the values of the state variables saved with the last gl:pushAttrib command. Those not saved are left unchanged.
It is an error to push attributes onto a full stack or to pop attributes off an empty stack. In either case, the error flag is set and no other change is made to GL state.
Initially, the attribute stack is empty.
See external documentation.
See pushAttrib/1
Types:
Push and pop the client attribute stack
gl:pushClientAttrib takes one argument, a mask that indicates which groups of client-state variables to save on the client attribute stack. Symbolic constants are used to set bits in the mask. Mask is typically constructed by specifying the bitwise-or of several of these constants together. The special mask ?GL_CLIENT_ALL_ATTRIB_BITS can be used to save all stackable client state.
The symbolic mask constants and their associated GL client state are as follows (the second column lists which attributes are saved):
?GL_CLIENT_PIXEL_STORE_BIT Pixel storage modes ?GL_CLIENT_VERTEX_ARRAY_BIT Vertex arrays (and enables)
gl:pushClientAttrib/1 restores the values of the client-state variables saved with the last gl:pushClientAttrib. Those not saved are left unchanged.
It is an error to push attributes onto a full client attribute stack or to pop attributes off an empty stack. In either case, the error flag is set, and no other change is made to GL state.
Initially, the client attribute stack is empty.
See external documentation.
Types:
Set rasterization mode
gl:renderMode sets the rasterization mode. It takes one argument, Mode , which can assume one of three predefined values:
?GL_RENDER: Render mode. Primitives are rasterized, producing pixel fragments, which are written into the frame buffer. This is the normal mode and also the default mode.
?GL_SELECT: Selection mode. No pixel fragments are produced, and no change to the frame buffer contents is made. Instead, a record of the names of primitives that would have been drawn if the render mode had been ?GL_RENDER is returned in a select buffer, which must be created (see gl:selectBuffer/2 ) before selection mode is entered.
?GL_FEEDBACK: Feedback mode. No pixel fragments are produced, and no change to the frame buffer contents is made. Instead, the coordinates and attributes of vertices that would have been drawn if the render mode had been ?GL_RENDER is returned in a feedback buffer, which must be created (see gl:feedbackBuffer/3 ) before feedback mode is entered.
The return value of gl:renderMode is determined by the render mode at the time gl:renderMode is called, rather than by Mode . The values returned for the three render modes are as follows:
?GL_RENDER: 0.
?GL_SELECT: The number of hit records transferred to the select buffer.
?GL_FEEDBACK: The number of values (not vertices) transferred to the feedback buffer.
See the gl:selectBuffer/2 and gl:feedbackBuffer/3 reference pages for more details concerning selection and feedback operation.
See external documentation.
Return error information
gl:getError returns the value of the error flag. Each detectable error is assigned a numeric code and symbolic name. When an error occurs, the error flag is set to the appropriate error code value. No other errors are recorded until gl:getError is called, the error code is returned, and the flag is reset to ?GL_NO_ERROR. If a call to gl:getError returns ?GL_NO_ERROR, there has been no detectable error since the last call to gl:getError , or since the GL was initialized.
To allow for distributed implementations, there may be several error flags. If any single error flag has recorded an error, the value of that flag is returned and that flag is reset to ?GL_NO_ERROR when gl:getError is called. If more than one flag has recorded an error, gl:getError returns and clears an arbitrary error flag value. Thus, gl:getError should always be called in a loop, until it returns ?GL_NO_ERROR , if all error flags are to be reset.
Initially, all error flags are set to ?GL_NO_ERROR.
The following errors are currently defined:
?GL_NO_ERROR: No error has been recorded. The value of this symbolic constant is guaranteed to be 0.
?GL_INVALID_ENUM: An unacceptable value is specified for an enumerated argument. The offending command is ignored and has no other side effect than to set the error flag.
?GL_INVALID_VALUE: A numeric argument is out of range. The offending command is ignored and has no other side effect than to set the error flag.
?GL_INVALID_OPERATION: The specified operation is not allowed in the current state. The offending command is ignored and has no other side effect than to set the error flag.
?GL_INVALID_FRAMEBUFFER_OPERATION: The framebuffer object is not complete. The offending command is ignored and has no other side effect than to set the error flag.
?GL_OUT_OF_MEMORY: There is not enough memory left to execute the command. The state of the GL is undefined, except for the state of the error flags, after this error is recorded.
When an error flag is set, results of a GL operation are undefined only if ?GL_OUT_OF_MEMORY has occurred. In all other cases, the command generating the error is ignored and has no effect on the GL state or frame buffer contents. If the generating command returns a value, it returns 0. If gl:getError itself generates an error, it returns 0.
See external documentation.
Types:
Return a string describing the current GL connection
gl:getString returns a pointer to a static string describing some aspect of the current GL connection. Name can be one of the following:
?GL_VENDOR: Returns the company responsible for this GL implementation. This name does not change from release to release.
?GL_RENDERER: Returns the name of the renderer. This name is typically specific to a particular configuration of a hardware platform. It does not change from release to release.
?GL_VERSION: Returns a version or release number.
?GL_SHADING_LANGUAGE_VERSION: Returns a version or release number for the shading language.
gl:getStringi returns a pointer to a static string indexed by Index . Name can be one of the following:
?GL_EXTENSIONS: For gl:getStringi only, returns the extension string supported by the implementation at Index .
Strings ?GL_VENDOR and ?GL_RENDERER together uniquely specify a platform. They do not change from release to release and should be used by platform-recognition algorithms.
The ?GL_VERSION and ?GL_SHADING_LANGUAGE_VERSION strings begin with a version number. The version number uses one of these forms:
major_number.minor_numbermajor_number.minor_number.release_number
Vendor-specific information may follow the version number. Its format depends on the implementation, but a space always separates the version number and the vendor-specific information.
All strings are null-terminated.
See external documentation.
Block until all GL execution is complete
gl:finish does not return until the effects of all previously called GL commands are complete. Such effects include all changes to GL state, all changes to connection state, and all changes to the frame buffer contents.
See external documentation.
Force execution of GL commands in finite time
Different GL implementations buffer commands in several different locations, including network buffers and the graphics accelerator itself. gl:flush empties all of these buffers, causing all issued commands to be executed as quickly as they are accepted by the actual rendering engine. Though this execution may not be completed in any particular time period, it does complete in finite time.
Because any GL program might be executed over a network, or on an accelerator that buffers commands, all programs should call gl:flush whenever they count on having all of their previously issued commands completed. For example, call gl:flush before waiting for user input that depends on the generated image.
See external documentation.
Types:
Specify implementation-specific hints
Certain aspects of GL behavior, when there is room for interpretation, can be controlled with hints. A hint is specified with two arguments. Target is a symbolic constant indicating the behavior to be controlled, and Mode is another symbolic constant indicating the desired behavior. The initial value for each Target is ?GL_DONT_CARE . Mode can be one of the following:
?GL_FASTEST: The most efficient option should be chosen.
?GL_NICEST: The most correct, or highest quality, option should be chosen.
?GL_DONT_CARE: No preference.
Though the implementation aspects that can be hinted are well defined, the interpretation of the hints depends on the implementation. The hint aspects that can be specified with Target , along with suggested semantics, are as follows:
?GL_FRAGMENT_SHADER_DERIVATIVE_HINT: Indicates the accuracy of the derivative calculation for the GL shading language fragment processing built-in functions: ?dFdx , ?dFdy, and ?fwidth.
?GL_LINE_SMOOTH_HINT: Indicates the sampling quality of antialiased lines. If a larger filter function is applied, hinting ?GL_NICEST can result in more pixel fragments being generated during rasterization.
?GL_POLYGON_SMOOTH_HINT: Indicates the sampling quality of antialiased polygons. Hinting ?GL_NICEST can result in more pixel fragments being generated during rasterization, if a larger filter function is applied.
?GL_TEXTURE_COMPRESSION_HINT: Indicates the quality and performance of the compressing texture images. Hinting ?GL_FASTEST indicates that texture images should be compressed as quickly as possible, while ?GL_NICEST indicates that texture images should be compressed with as little image quality loss as possible. ?GL_NICEST should be selected if the texture is to be retrieved by gl:getCompressedTexImage/3 for reuse.
See external documentation.
Types:
Specify the clear value for the depth buffer
gl:clearDepth specifies the depth value used by gl:clear/1 to clear the depth buffer. Values specified by gl:clearDepth are clamped to the range [0 1].
See external documentation.
Types:
Specify the value used for depth buffer comparisons
gl:depthFunc specifies the function used to compare each incoming pixel depth value with the depth value present in the depth buffer. The comparison is performed only if depth testing is enabled. (See gl:enable/1 and gl:enable/1 of ?GL_DEPTH_TEST .)
Func specifies the conditions under which the pixel will be drawn. The comparison functions are as follows:
?GL_NEVER: Never passes.
?GL_LESS: Passes if the incoming depth value is less than the stored depth value.
?GL_EQUAL: Passes if the incoming depth value is equal to the stored depth value.
?GL_LEQUAL: Passes if the incoming depth value is less than or equal to the stored depth value.
?GL_GREATER: Passes if the incoming depth value is greater than the stored depth value.
?GL_NOTEQUAL: Passes if the incoming depth value is not equal to the stored depth value.
?GL_GEQUAL: Passes if the incoming depth value is greater than or equal to the stored depth value.
?GL_ALWAYS: Always passes.
The initial value of Func is ?GL_LESS. Initially, depth testing is disabled. If depth testing is disabled or if no depth buffer exists, it is as if the depth test always passes.
See external documentation.
Types:
Enable or disable writing into the depth buffer
gl:depthMask specifies whether the depth buffer is enabled for writing. If Flag is ?GL_FALSE, depth buffer writing is disabled. Otherwise, it is enabled. Initially, depth buffer writing is enabled.
See external documentation.
depthRange(Near_val, Far_val) -> ok
Types:
Specify mapping of depth values from normalized device coordinates to window coordinates
After clipping and division by w, depth coordinates range from -1 to 1, corresponding to the near and far clipping planes. gl:depthRange specifies a linear mapping of the normalized depth coordinates in this range to window depth coordinates. Regardless of the actual depth buffer implementation, window coordinate depth values are treated as though they range from 0 through 1 (like color components). Thus, the values accepted by gl:depthRange are both clamped to this range before they are accepted.
The setting of (0,1) maps the near plane to 0 and the far plane to 1. With this mapping, the depth buffer range is fully utilized.
See external documentation.
clearAccum(Red, Green, Blue, Alpha) -> ok
Types:
Specify clear values for the accumulation buffer
gl:clearAccum specifies the red, green, blue, and alpha values used by gl:clear/1 to clear the accumulation buffer.
Values specified by gl:clearAccum are clamped to the range [-1 1].
See external documentation.
Types:
Operate on the accumulation buffer
The accumulation buffer is an extended-range color buffer. Images are not rendered into it. Rather, images rendered into one of the color buffers are added to the contents of the accumulation buffer after rendering. Effects such as antialiasing (of points, lines, and polygons), motion blur, and depth of field can be created by accumulating images generated with different transformation matrices.
Each pixel in the accumulation buffer consists of red, green, blue, and alpha values. The number of bits per component in the accumulation buffer depends on the implementation. You can examine this number by calling gl:getBooleanv/1 four times, with arguments ?GL_ACCUM_RED_BITS, ?GL_ACCUM_GREEN_BITS, ?GL_ACCUM_BLUE_BITS, and ?GL_ACCUM_ALPHA_BITS . Regardless of the number of bits per component, the range of values stored by each component is [-1 1]. The accumulation buffer pixels are mapped one-to-one with frame buffer pixels.
gl:accum operates on the accumulation buffer. The first argument, Op , is a symbolic constant that selects an accumulation buffer operation. The second argument, Value , is a floating-point value to be used in that operation. Five operations are specified: ?GL_ACCUM , ?GL_LOAD, ?GL_ADD, ?GL_MULT, and ?GL_RETURN.
All accumulation buffer operations are limited to the area of the current scissor box and applied identically to the red, green, blue, and alpha components of each pixel. If a gl:accum operation results in a value outside the range [-1 1], the contents of an accumulation buffer pixel component are undefined.
The operations are as follows:
?GL_ACCUM: Obtains R, G, B, and A values from the buffer currently selected for reading (see gl:readBuffer/1 ). Each component value is divided by 2 n-1, where n is the number of bits allocated to each color component in the currently selected buffer. The result is a floating-point value in the range [0 1], which is multiplied by Value and added to the corresponding pixel component in the accumulation buffer, thereby updating the accumulation buffer.
?GL_LOAD: Similar to ?GL_ACCUM, except that the current value in the accumulation buffer is not used in the calculation of the new value. That is, the R, G, B, and A values from the currently selected buffer are divided by 2 n-1, multiplied by Value , and then stored in the corresponding accumulation buffer cell, overwriting the current value.
?GL_ADD: Adds Value to each R, G, B, and A in the accumulation buffer.
?GL_MULT: Multiplies each R, G, B, and A in the accumulation buffer by Value and returns the scaled component to its corresponding accumulation buffer location.
?GL_RETURN: Transfers accumulation buffer values to the color buffer or buffers currently selected for writing. Each R, G, B, and A component is multiplied by Value , then multiplied by 2 n-1, clamped to the range [0 2 n-1], and stored in the corresponding display buffer cell. The only fragment operations that are applied to this transfer are pixel ownership, scissor, dithering, and color writemasks.
To clear the accumulation buffer, call gl:clearAccum/4 with R, G, B, and A values to set it to, then call gl:clear/1 with the accumulation buffer enabled.
See external documentation.
Types:
Specify which matrix is the current matrix
gl:matrixMode sets the current matrix mode. Mode can assume one of four values:
?GL_MODELVIEW: Applies subsequent matrix operations to the modelview matrix stack.
?GL_PROJECTION: Applies subsequent matrix operations to the projection matrix stack.
?GL_TEXTURE: Applies subsequent matrix operations to the texture matrix stack.
?GL_COLOR: Applies subsequent matrix operations to the color matrix stack.
To find out which matrix stack is currently the target of all matrix operations, call gl:getBooleanv/1 with argument ?GL_MATRIX_MODE. The initial value is ?GL_MODELVIEW.
See external documentation.
ortho(Left, Right, Bottom, Top, Near_val, Far_val) -> ok
Types:
Multiply the current matrix with an orthographic matrix
gl:ortho describes a transformation that produces a parallel projection. The current matrix (see gl:matrixMode/1 ) is multiplied by this matrix and the result replaces the current matrix, as if gl:multMatrixd/1 were called with the following matrix as its argument:
((2/(right-left)) 0 0(t x) 0(2/(top-bottom)) 0(t y) 0 0(-2/(farVal-nearVal))(t z) 0 0 0 1)
where t x=-((right+left)/(right-left)) t y=-((top+bottom)/(top-bottom)) t z=-((farVal+nearVal)/(farVal-nearVal))
Typically, the matrix mode is ?GL_PROJECTION, and (left bottom-nearVal) and (right top-nearVal) specify the points on the near clipping plane that are mapped to the lower left and upper right corners of the window, respectively, assuming that the eye is located at (0, 0, 0). -farVal specifies the location of the far clipping plane. Both NearVal and FarVal can be either positive or negative.
Use gl:pushMatrix/0 and gl:pushMatrix/0 to save and restore the current matrix stack.
See external documentation.
frustum(Left, Right, Bottom, Top, Near_val, Far_val) -> ok
Types:
Multiply the current matrix by a perspective matrix
gl:frustum describes a perspective matrix that produces a perspective projection. The current matrix (see gl:matrixMode/1 ) is multiplied by this matrix and the result replaces the current matrix, as if gl:multMatrixd/1 were called with the following matrix as its argument:
[((2 nearVal)/(right-left)) 0 A 0 0((2 nearVal)/(top-bottom)) B 0 0 0 C D 0 0 -1 0]
A=(right+left)/(right-left)
B=(top+bottom)/(top-bottom)
C=-((farVal+nearVal)/(farVal-nearVal))
D=-((2 farVal nearVal)/(farVal-nearVal))
Typically, the matrix mode is ?GL_PROJECTION, and (left bottom-nearVal) and (right top-nearVal) specify the points on the near clipping plane that are mapped to the lower left and upper right corners of the window, assuming that the eye is located at (0, 0, 0). -farVal specifies the location of the far clipping plane. Both NearVal and FarVal must be positive.
Use gl:pushMatrix/0 and gl:pushMatrix/0 to save and restore the current matrix stack.
See external documentation.
viewport(X, Y, Width, Height) -> ok
Types:
Set the viewport
gl:viewport specifies the affine transformation of x and y from normalized device coordinates to window coordinates. Let (x nd y nd) be normalized device coordinates. Then the window coordinates (x w y w) are computed as follows:
x w=(x nd+1) (width/2)+x
y w=(y nd+1) (height/2)+y
Viewport width and height are silently clamped to a range that depends on the implementation. To query this range, call gl:getBooleanv/1 with argument ?GL_MAX_VIEWPORT_DIMS.
See external documentation.
Push and pop the current matrix stack
There is a stack of matrices for each of the matrix modes. In ?GL_MODELVIEW mode, the stack depth is at least 32. In the other modes, ?GL_COLOR, ?GL_PROJECTION , and ?GL_TEXTURE, the depth is at least 2. The current matrix in any mode is the matrix on the top of the stack for that mode.
gl:pushMatrix pushes the current matrix stack down by one, duplicating the current matrix. That is, after a gl:pushMatrix call, the matrix on top of the stack is identical to the one below it.
gl:pushMatrix/0 pops the current matrix stack, replacing the current matrix with the one below it on the stack.
Initially, each of the stacks contains one matrix, an identity matrix.
It is an error to push a full matrix stack or to pop a matrix stack that contains only a single matrix. In either case, the error flag is set and no other change is made to GL state.
See external documentation.
See pushMatrix/0
Replace the current matrix with the identity matrix
gl:loadIdentity replaces the current matrix with the identity matrix. It is semantically equivalent to calling gl:loadMatrixd/1 with the identity matrix
((1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1))
but in some cases it is more efficient.
See external documentation.
Types:
Replace the current matrix with the specified matrix
gl:loadMatrix 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[4] m[8] m[12] m[1] m[5] m[9] m[13] m[2] m[6] m[10] m[14] m[3] m[7] m[11] m[15])×(v[0] v[1] v[2] v[3])
Projection and texture transformations are similarly defined.
See external documentation.
Types:
See loadMatrixd/1
Types:
Multiply the current matrix with the specified matrix
gl:multMatrix 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:
See multMatrixd/1
Types:
Multiply the current matrix by a rotation matrix
gl:rotate produces a rotation of Angle degrees around the vector (x y z). The current matrix (see gl:matrixMode/1 ) is multiplied by a rotation matrix with the product replacing the current matrix, as if gl:multMatrixd/1 were called with the following matrix as its argument:
(x 2(1-c)+c x y(1-c)-z s x z(1-c)+y s 0 y x(1-c)+z s y 2(1-c)+c y z(1-c)-x s 0 x z(1-c)-y s y z(1-c)+x s z 2(1-c)+c 0 0 0 0 1)
Where c=cos(angle), s=sin(angle), and ||(x y z)||=1 (if not, the GL will normalize this vector).
If the matrix mode is either ?GL_MODELVIEW or ?GL_PROJECTION, all objects drawn after gl:rotate is called are rotated. Use gl:pushMatrix/0 and gl:pushMatrix/0 to save and restore the unrotated coordinate system.
See external documentation.
Types:
See rotated/4
Types:
Multiply the current matrix by a general scaling matrix
gl:scale produces a nonuniform scaling along the x, y, and z axes. The three parameters indicate the desired scale factor along each of the three axes.
The current matrix (see gl:matrixMode/1 ) is multiplied by this scale matrix, and the product replaces the current matrix as if gl:multMatrixd/1 were called with the following matrix as its argument:
(x 0 0 0 0 y 0 0 0 0 z 0 0 0 0 1)
If the matrix mode is either ?GL_MODELVIEW or ?GL_PROJECTION, all objects drawn after gl:scale is called are scaled.
Use gl:pushMatrix/0 and gl:pushMatrix/0 to save and restore the unscaled coordinate system.
See external documentation.
Types:
See scaled/3
Types:
Multiply the current matrix by a translation matrix
gl:translate produces a translation by (x y z). The current matrix (see gl:matrixMode/1 ) is multiplied by this translation matrix, with the product replacing the current matrix, as if gl:multMatrixd/1 were called with the following matrix for its argument:
(1 0 0 x 0 1 0 y 0 0 1 z 0 0 0 1)
If the matrix mode is either ?GL_MODELVIEW or ?GL_PROJECTION, all objects drawn after a call to gl:translate are translated.
Use gl:pushMatrix/0 and gl:pushMatrix/0 to save and restore the untranslated coordinate system.
See external documentation.
Types:
See translated/3
Types:
Determine if a name corresponds to a display list
gl:isList returns ?GL_TRUE if List is the name of a display list and returns ?GL_FALSE if it is not, or if an error occurs.
A name returned by gl:genLists/1 , but not yet associated with a display list by calling gl:newList/2 , is not the name of a display list.
See external documentation.
deleteLists(List, Range) -> ok
Types:
Delete a contiguous group of display lists
gl:deleteLists causes a contiguous group of display lists to be deleted. List is the name of the first display list to be deleted, and Range is the number of display lists to delete. All display lists d with list<= d<= list+range-1 are deleted.
All storage locations allocated to the specified display lists are freed, and the names are available for reuse at a later time. Names within the range that do not have an associated display list are ignored. If Range is 0, nothing happens.
See external documentation.
Types:
Generate a contiguous set of empty display lists
gl:genLists has one argument, Range . It returns an integer n such that Range contiguous empty display lists, named n, n+1, ..., n+range-1, are created. If Range is 0, if there is no group of Range contiguous names available, or if any error is generated, no display lists are generated, and 0 is returned.
See external documentation.
Types:
Create or replace a display list
Display lists are groups of GL commands that have been stored for subsequent execution. Display lists are created with gl:newList. All subsequent commands are placed in the display list, in the order issued, until gl:endList/0 is called.
gl:newList has two arguments. The first argument, List , is a positive integer that becomes the unique name for the display list. Names can be created and reserved with gl:genLists/1 and tested for uniqueness with gl:isList/1 . The second argument, Mode , is a symbolic constant that can assume one of two values:
?GL_COMPILE: Commands are merely compiled.
?GL_COMPILE_AND_EXECUTE: Commands are executed as they are compiled into the display list.
Certain commands are not compiled into the display list but are executed immediately, regardless of the display-list mode. These commands are gl:areTexturesResident/1 , gl:colorPointer/4 , gl:deleteLists/2 , gl:deleteTextures/1 , gl:enableClientState/1 , gl:edgeFlagPointer/2 , gl:enableClientState/1 , gl:feedbackBuffer/3 , gl:finish/0 , gl:flush/0 , gl:genLists/1 , gl:genTextures/1 , gl:indexPointer/3 , gl:interleavedArrays/3 , gl:isEnabled/1 , gl:isList/1 , gl:isTexture/1 , gl:normalPointer/3 , gl:pushClientAttrib/1 , gl:pixelStoref/2 , gl:pushClientAttrib/1 , gl:readPixels/7 , gl:renderMode/1 , gl:selectBuffer/2 , gl:texCoordPointer/4 , gl:vertexPointer/4 , and all of the gl:getBooleanv/1 commands.
Similarly, gl:texImage1D/8 , gl:texImage2D/9 , and gl:texImage3D/10 are executed immediately and not compiled into the display list when their first argument is ?GL_PROXY_TEXTURE_1D, ?GL_PROXY_TEXTURE_1D, or ?GL_PROXY_TEXTURE_3D , respectively.
When the ARB_imaging extension is supported, gl:histogram/4 executes immediately when its argument is ?GL_PROXY_HISTOGRAM. Similarly, gl:colorTable/6 executes immediately when its first argument is ?GL_PROXY_COLOR_TABLE, ?GL_PROXY_POST_CONVOLUTION_COLOR_TABLE , or ?GL_PROXY_POST_COLOR_MATRIX_COLOR_TABLE.
For OpenGL versions 1.3 and greater, or when the ARB_multitexture extension is supported, gl:clientActiveTexture/1 is not compiled into display lists, but executed immediately.
When gl:endList/0 is encountered, the display-list definition is completed by associating the list with the unique name List (specified in the gl:newList command). If a display list with name List already exists, it is replaced only when gl:endList/0 is called.
See external documentation.
Types:
Execute a display list
gl:callList causes the named display list to be executed. The commands saved in the display list are executed in order, just as if they were called without using a display list. If List has not been defined as a display list, gl:callList is ignored.
gl:callList can appear inside a display list. To avoid the possibility of infinite recursion resulting from display lists calling one another, a limit is placed on the nesting level of display lists during display-list execution. This limit is at least 64, and it depends on the implementation.
GL state is not saved and restored across a call to gl:callList. Thus, changes made to GL state during the execution of a display list remain after execution of the display list is completed. Use gl:pushAttrib/1 , gl:pushAttrib/1 , gl:pushMatrix/0 , and gl:pushMatrix/0 to preserve GL state across gl:callList calls.
See external documentation.
Types:
Execute a list of display lists
gl:callLists causes each display list in the list of names passed as Lists to be executed. As a result, the commands saved in each display list are executed in order, just as if they were called without using a display list. Names of display lists that have not been defined are ignored.
gl:callLists provides an efficient means for executing more than one display list. Type allows lists with various name formats to be accepted. The formats are as follows:
?GL_BYTE: Lists is treated as an array of signed bytes, each in the range -128 through 127.
?GL_UNSIGNED_BYTE: Lists is treated as an array of unsigned bytes, each in the range 0 through 255.
?GL_SHORT: Lists is treated as an array of signed two-byte integers, each in the range -32768 through 32767.
?GL_UNSIGNED_SHORT: Lists is treated as an array of unsigned two-byte integers, each in the range 0 through 65535.
?GL_INT: Lists is treated as an array of signed four-byte integers.
?GL_UNSIGNED_INT: Lists is treated as an array of unsigned four-byte integers.
?GL_FLOAT: Lists is treated as an array of four-byte floating-point values.
?GL_2_BYTES: Lists is treated as an array of unsigned bytes. Each pair of bytes specifies a single display-list name. The value of the pair is computed as 256 times the unsigned value of the first byte plus the unsigned value of the second byte.
?GL_3_BYTES: Lists is treated as an array of unsigned bytes. Each triplet of bytes specifies a single display-list name. The value of the triplet is computed as 65536 times the unsigned value of the first byte, plus 256 times the unsigned value of the second byte, plus the unsigned value of the third byte.
?GL_4_BYTES: Lists is treated as an array of unsigned bytes. Each quadruplet of bytes specifies a single display-list name. The value of the quadruplet is computed as 16777216 times the unsigned value of the first byte, plus 65536 times the unsigned value of the second byte, plus 256 times the unsigned value of the third byte, plus the unsigned value of the fourth byte.
The list of display-list names is not null-terminated. Rather, N specifies how many names are to be taken from Lists .
An additional level of indirection is made available with the gl:listBase/1 command, which specifies an unsigned offset that is added to each display-list name specified in Lists before that display list is executed.
gl:callLists can appear inside a display list. To avoid the possibility of infinite recursion resulting from display lists calling one another, a limit is placed on the nesting level of display lists during display-list execution. This limit must be at least 64, and it depends on the implementation.
GL state is not saved and restored across a call to gl:callLists. Thus, changes made to GL state during the execution of the display lists remain after execution is completed. Use gl:pushAttrib/1 , gl:pushAttrib/1 , gl:pushMatrix/0 , and gl:pushMatrix/0 to preserve GL state across gl:callLists calls.
See external documentation.
Types:
set the display-list base for
gl:callLists/1 specifies an array of offsets. Display-list names are generated by adding Base to each offset. Names that reference valid display lists are executed; the others are ignored.
See external documentation.
Types:
Delimit the vertices of a primitive or a group of like primitives
gl:'begin' and gl:'begin'/1 delimit the vertices that define a primitive or a group of like primitives. gl:'begin' accepts a single argument that specifies in which of ten ways the vertices are interpreted. Taking n as an integer count starting at one, and N as the total number of vertices specified, the interpretations are as follows:
?GL_POINTS: Treats each vertex as a single point. Vertex n defines point n. N points are drawn.
?GL_LINES: Treats each pair of vertices as an independent line segment. Vertices 2 n-1 and 2 n define line n. N/2 lines are drawn.
?GL_LINE_STRIP: Draws a connected group of line segments from the first vertex to the last. Vertices n and n+1 define line n. N-1 lines are drawn.
?GL_LINE_LOOP: Draws a connected group of line segments from the first vertex to the last, then back to the first. Vertices n and n+1 define line n. The last line, however, is defined by vertices N and 1. N lines are drawn.
?GL_TRIANGLES: Treats each triplet of vertices as an independent triangle. Vertices 3 n-2, 3 n-1, and 3 n define triangle n. N/3 triangles are drawn.
?GL_TRIANGLE_STRIP: Draws a connected group of triangles. One triangle is defined for each vertex presented after the first two vertices. For odd n, vertices n, n+1, and n+2 define triangle n. For even n, vertices n+1, n, and n+2 define triangle n. N-2 triangles are drawn.
?GL_TRIANGLE_FAN: Draws a connected group of triangles. One triangle is defined for each vertex presented after the first two vertices. Vertices 1, n+1, and n+2 define triangle n. N-2 triangles are drawn.
?GL_QUADS: Treats each group of four vertices as an independent quadrilateral. Vertices 4 n-3, 4 n-2, 4 n-1, and 4 n define quadrilateral n. N/4 quadrilaterals are drawn.
?GL_QUAD_STRIP: Draws a connected group of quadrilaterals. One quadrilateral is defined for each pair of vertices presented after the first pair. Vertices 2 n-1, 2 n, 2 n+2, and 2 n+1 define quadrilateral n. N/2-1 quadrilaterals are drawn. Note that the order in which vertices are used to construct a quadrilateral from strip data is different from that used with independent data.
?GL_POLYGON: Draws a single, convex polygon. Vertices 1 through N define this polygon.
Only a subset of GL commands can be used between gl:'begin' and gl:'begin'/1 . The commands are gl:vertex2d/2 , gl:color3b/3 , gl:secondaryColor3b/3 , gl:indexd/1 , gl:normal3b/3 , gl:fogCoordf/1 , gl:texCoord1d/1 , gl:multiTexCoord1d/2 , gl:vertexAttrib1d/2 , gl:evalCoord1d/1 , gl:evalPoint1/1 , gl:arrayElement/1 , gl:materialf/3 , and gl:edgeFlag/1 . Also, it is acceptable to use gl:callList/1 or gl:callLists/1 to execute display lists that include only the preceding commands. If any other GL command is executed between gl:'begin' and gl:'begin'/1 , the error flag is set and the command is ignored.
Regardless of the value chosen for Mode , there is no limit to the number of vertices that can be defined between gl:'begin' and gl:'begin'/1 . Lines, triangles, quadrilaterals, and polygons that are incompletely specified are not drawn. Incomplete specification results when either too few vertices are provided to specify even a single primitive or when an incorrect multiple of vertices is specified. The incomplete primitive is ignored; the rest are drawn.
The minimum specification of vertices for each primitive is as follows: 1 for a point, 2 for a line, 3 for a triangle, 4 for a quadrilateral, and 3 for a polygon. Modes that require a certain multiple of vertices are ?GL_LINES (2), ?GL_TRIANGLES (3), ?GL_QUADS (4), and ?GL_QUAD_STRIP (2).
See external documentation.
See 'begin'/1
Types:
Specify a vertex
gl:vertex commands are used within gl:'begin'/1 / gl:'begin'/1 pairs to specify point, line, and polygon vertices. The current color, normal, texture coordinates, and fog coordinate are associated with the vertex when gl:vertex is called.
When only x and y are specified, z defaults to 0 and w defaults to 1. When x, y, and z are specified, w defaults to 1.
See external documentation.
Types:
See vertex2d/2
Types:
See vertex2d/2
Types:
See vertex2d/2
Types:
See vertex2d/2
Types:
See vertex2d/2
Types:
See vertex2d/2
Types:
See vertex2d/2
Types:
See vertex2d/2
Types:
See vertex2d/2
Types:
See vertex2d/2
Types:
See vertex2d/2
Types:
Equivalent to vertex2d(X, Y).
Types:
Equivalent to vertex2f(X, Y).
Types:
Equivalent to vertex2i(X, Y).
Types:
Equivalent to vertex2s(X, Y).
Types:
Equivalent to vertex3d(X, Y, Z).
Types:
Equivalent to vertex3f(X, Y, Z).
Types:
Equivalent to vertex3i(X, Y, Z).
Types:
Equivalent to vertex3s(X, Y, Z).
Types:
Equivalent to vertex4d(X, Y, Z, W).
Types:
Equivalent to vertex4f(X, Y, Z, W).
Types:
Equivalent to vertex4i(X, Y, Z, W).
Types:
Equivalent to vertex4s(X, Y, Z, W).
Types:
Set the current normal vector
The current normal is set to the given coordinates whenever gl:normal is issued. Byte, short, or integer arguments are converted to floating-point format with a linear mapping that maps the most positive representable integer value to 1.0 and the most negative representable integer value to -1.0.
Normals specified with gl:normal need not have unit length. If ?GL_NORMALIZE is enabled, then normals of any length specified with gl:normal are normalized after transformation. If ?GL_RESCALE_NORMAL is enabled, normals are scaled by a scaling factor derived from the modelview matrix. ?GL_RESCALE_NORMAL requires that the originally specified normals were of unit length, and that the modelview matrix contain only uniform scales for proper results. To enable and disable normalization, call gl:enable/1 and gl:enable/1 with either ?GL_NORMALIZE or ?GL_RESCALE_NORMAL. Normalization is initially disabled.
See external documentation.
Types:
See normal3b/3
Types:
See normal3b/3
Types:
See normal3b/3
Types:
See normal3b/3
Types:
Equivalent to normal3b(Nx, Ny, Nz).
Types:
Equivalent to normal3d(Nx, Ny, Nz).
Types:
Equivalent to normal3f(Nx, Ny, Nz).
Types:
Equivalent to normal3i(Nx, Ny, Nz).
Types:
Equivalent to normal3s(Nx, Ny, Nz).
Types:
Set the current color index
gl:index updates the current (single-valued) color index. It takes one argument, the new value for the current color index.
The current index is stored as a floating-point value. Integer values are converted directly to floating-point values, with no special mapping. The initial value is 1.
Index values outside the representable range of the color index buffer are not clamped. However, before an index is dithered (if enabled) and written to the frame buffer, it is converted to fixed-point format. Any bits in the integer portion of the resulting fixed-point value that do not correspond to bits in the frame buffer are masked out.
See external documentation.
Types:
See indexd/1
Types:
See indexd/1
Types:
See indexd/1
Types:
See indexd/1
Types:
Equivalent to indexd(C).
Types:
Equivalent to indexf(C).
Types:
Equivalent to indexi(C).
Types:
Equivalent to indexs(C).
Types:
Equivalent to indexub(C).
color3b(Red, Green, Blue) -> ok
Types:
Set the current color
The GL stores both a current single-valued color index and a current four-valued RGBA color. gl:color sets a new four-valued RGBA color. gl:color has two major variants: gl:color3 and gl:color4. gl:color3 variants specify new red, green, and blue values explicitly and set the current alpha value to 1.0 (full intensity) implicitly. gl:color4 variants specify all four color components explicitly.
gl:color3b, gl:color4b, gl:color3s, gl:color4s, gl:color3i, and gl:color4i take three or four 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.
Current 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.
color3d(Red, Green, Blue) -> ok
Types:
See color3b/3
color3f(Red, Green, Blue) -> ok
Types:
See color3b/3
color3i(Red, Green, Blue) -> ok
Types:
See color3b/3
color3s(Red, Green, Blue) -> ok
Types:
See color3b/3
color3ub(Red, Green, Blue) -> ok
Types:
See color3b/3
color3ui(Red, Green, Blue) -> ok
Types:
See color3b/3
color3us(Red, Green, Blue) -> ok
Types:
See color3b/3
color4b(Red, Green, Blue, Alpha) -> ok
Types:
See color3b/3
color4d(Red, Green, Blue, Alpha) -> ok
Types:
See color3b/3
color4f(Red, Green, Blue, Alpha) -> ok
Types:
See color3b/3
color4i(Red, Green, Blue, Alpha) -> ok
Types:
See color3b/3
color4s(Red, Green, Blue, Alpha) -> ok
Types:
See color3b/3
color4ub(Red, Green, Blue, Alpha) -> ok
Types:
See color3b/3
color4ui(Red, Green, Blue, Alpha) -> ok
Types:
See color3b/3
color4us(Red, Green, Blue, Alpha) -> ok
Types:
See color3b/3
Types:
Equivalent to color3b(Red, Green, Blue).
Types:
Equivalent to color3d(Red, Green, Blue).
Types:
Equivalent to color3f(Red, Green, Blue).
Types:
Equivalent to color3i(Red, Green, Blue).
Types:
Equivalent to color3s(Red, Green, Blue).
Types:
Equivalent to color3ub(Red, Green, Blue).
Types:
Equivalent to color3ui(Red, Green, Blue).
Types:
Equivalent to color3us(Red, Green, Blue).
Types:
Equivalent to color4b(Red, Green, Blue, Alpha).
Types:
Equivalent to color4d(Red, Green, Blue, Alpha).
Types:
Equivalent to color4f(Red, Green, Blue, Alpha).
Types:
Equivalent to color4i(Red, Green, Blue, Alpha).
Types:
Equivalent to color4s(Red, Green, Blue, Alpha).
Types:
Equivalent to color4ub(Red, Green, Blue, Alpha).
Types:
Equivalent to color4ui(Red, Green, Blue, Alpha).
Types:
Equivalent to color4us(Red, Green, Blue, Alpha).
Types:
Set the current texture coordinates
gl:texCoord specifies texture coordinates in one, two, three, or four dimensions. gl:texCoord1 sets the current texture coordinates to (s 0 0 1); a call to gl:texCoord2 sets them to (s t 0 1). Similarly, gl:texCoord3 specifies the texture coordinates as (s t r 1), and gl:texCoord4 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 , and q are (0, 0, 0, 1).
See external documentation.
Types:
See texCoord1d/1
Types:
See texCoord1d/1
Types:
See texCoord1d/1
Types:
See texCoord1d/1
Types:
See texCoord1d/1
Types:
See texCoord1d/1
Types:
See texCoord1d/1
Types:
See texCoord1d/1
Types:
See texCoord1d/1
Types:
See texCoord1d/1
Types:
See texCoord1d/1
Types:
See texCoord1d/1
Types:
See texCoord1d/1
Types:
See texCoord1d/1
Types:
See texCoord1d/1
Types:
Equivalent to texCoord1d(S).
Types:
Equivalent to texCoord1f(S).
Types:
Equivalent to texCoord1i(S).
Types:
Equivalent to texCoord1s(S).
Types:
Equivalent to texCoord2d(S, T).
Types:
Equivalent to texCoord2f(S, T).
Types:
Equivalent to texCoord2i(S, T).
Types:
Equivalent to texCoord2s(S, T).
Types:
Equivalent to texCoord3d(S, T, R).
Types:
Equivalent to texCoord3f(S, T, R).
Types:
Equivalent to texCoord3i(S, T, R).
Types:
Equivalent to texCoord3s(S, T, R).
Types:
Equivalent to texCoord4d(S, T, R, Q).
Types:
Equivalent to texCoord4f(S, T, R, Q).
Types:
Equivalent to texCoord4i(S, T, R, Q).
Types:
Equivalent to texCoord4s(S, T, R, Q).
Types:
Specify the raster position for pixel operations
The GL maintains a 3D position in window coordinates. This position, called the raster position, is used to position pixel and bitmap write operations. It is maintained with subpixel accuracy. See gl:bitmap/7 , gl:drawPixels/5 , and gl:copyPixels/5 .
The current raster position consists of three window coordinates ( x, y, z), a clip coordinate value ( w), an eye coordinate distance, a valid bit, and associated color data and texture coordinates. The w coordinate is a clip coordinate, because w is not projected to window coordinates. gl:rasterPos4 specifies object coordinates x, y, z, and w explicitly. gl:rasterPos3 specifies object coordinate x, y, and z explicitly, while w is implicitly set to 1. gl:rasterPos2 uses the argument values for x and y while implicitly setting z and w to 0 and 1.
The object coordinates presented by gl:rasterPos are treated just like those of a gl:vertex2d/2 command: They are transformed by the current modelview and projection matrices and passed to the clipping stage. If the vertex is not culled, then it is projected and scaled to window coordinates, which become the new current raster position, and the ?GL_CURRENT_RASTER_POSITION_VALID flag is set. If the vertex is culled, then the valid bit is cleared and the current raster position and associated color and texture coordinates are undefined.
The current raster position also includes some associated color data and texture coordinates. If lighting is enabled, then ?GL_CURRENT_RASTER_COLOR (in RGBA mode) or ?GL_CURRENT_RASTER_INDEX (in color index mode) is set to the color produced by the lighting calculation (see gl:lightf/3 , gl:lightModelf/2 , and gl:shadeModel/1 ). If lighting is disabled, current color (in RGBA mode, state variable ?GL_CURRENT_COLOR) or color index (in color index mode, state variable ?GL_CURRENT_INDEX) is used to update the current raster color. ?GL_CURRENT_RASTER_SECONDARY_COLOR (in RGBA mode) is likewise updated.
Likewise, ?GL_CURRENT_RASTER_TEXTURE_COORDS is updated as a function of ?GL_CURRENT_TEXTURE_COORDS , based on the texture matrix and the texture generation functions (see gl:texGend/3 ). Finally, the distance from the origin of the eye coordinate system to the vertex as transformed by only the modelview matrix replaces ?GL_CURRENT_RASTER_DISTANCE.
Initially, the current raster position is (0, 0, 0, 1), the current raster distance is 0, the valid bit is set, the associated RGBA color is (1, 1, 1, 1), the associated color index is 1, and the associated texture coordinates are (0, 0, 0, 1). In RGBA mode, ?GL_CURRENT_RASTER_INDEX is always 1; in color index mode, the current raster RGBA color always maintains its initial value.
See external documentation.
Types:
See rasterPos2d/2
Types:
See rasterPos2d/2
Types:
See rasterPos2d/2
Types:
See rasterPos2d/2
Types:
See rasterPos2d/2
Types:
See rasterPos2d/2
Types:
See rasterPos2d/2
Types:
See rasterPos2d/2
Types:
See rasterPos2d/2
Types:
See rasterPos2d/2
Types:
See rasterPos2d/2
Types:
Equivalent to rasterPos2d(X, Y).
Types:
Equivalent to rasterPos2f(X, Y).
Types:
Equivalent to rasterPos2i(X, Y).
Types:
Equivalent to rasterPos2s(X, Y).
Types:
Equivalent to rasterPos3d(X, Y, Z).
Types:
Equivalent to rasterPos3f(X, Y, Z).
Types:
Equivalent to rasterPos3i(X, Y, Z).
Types:
Equivalent to rasterPos3s(X, Y, Z).
Types:
Equivalent to rasterPos4d(X, Y, Z, W).
Types:
Equivalent to rasterPos4f(X, Y, Z, W).
Types:
Equivalent to rasterPos4i(X, Y, Z, W).
Types:
Equivalent to rasterPos4s(X, Y, Z, W).
Types:
Draw a rectangle
gl:rect supports efficient specification of rectangles as two corner points. Each rectangle command takes four arguments, organized either as two consecutive pairs of (x y) coordinates or as two pointers to arrays, each containing an (x y) pair. The resulting rectangle is defined in the z=0 plane.
gl:rect( X1 , Y1 , X2 , Y2 ) is exactly equivalent to the following sequence: glBegin(?GL_POLYGON); glVertex2( X1 , Y1 ); glVertex2( X2 , Y1 ); glVertex2( X2 , Y2 ); glVertex2( X1 , Y2 ); glEnd(); Note that if the second vertex is above and to the right of the first vertex, the rectangle is constructed with a counterclockwise winding.
See external documentation.
Types:
See rectd/4
Types:
See rectd/4
Types:
See rectd/4
Types:
See rectd/4
Types:
See rectd/4
Types:
See rectd/4
Types:
See rectd/4
vertexPointer(Size, Type, Stride, Ptr) -> ok
Types:
Define an array of vertex data
gl:vertexPointer specifies the location and data format of an array of vertex coordinates to use when rendering. Size specifies the number of coordinates per vertex, and must be 2, 3, or 4. Type specifies the data type of each coordinate, and Stride specifies the byte stride from one vertex to the next, allowing vertices and attributes to be packed into a single array or stored in separate arrays. (Single-array storage may be more efficient on some implementations; see gl:interleavedArrays/3 .)
If a non-zero named buffer object is bound to the ?GL_ARRAY_BUFFER target (see gl:bindBuffer/2 ) while a vertex 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 vertex array client-side state (?GL_VERTEX_ARRAY_BUFFER_BINDING).
When a vertex array is specified, Size , 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 vertex array, call gl:enableClientState/1 and gl:enableClientState/1 with the argument ?GL_VERTEX_ARRAY. If enabled, the vertex array is used when gl:arrayElement/1 , gl:drawArrays/3 , gl:multiDrawArrays/3 , gl:drawElements/4 , see glMultiDrawElements , or gl:drawRangeElements/6 is called.
See external documentation.
normalPointer(Type, Stride, Ptr) -> ok
Types:
Define an array of normals
gl:normalPointer specifies the location and data format of an array of normals to use when rendering. Type specifies the data type of each normal coordinate, and Stride specifies the byte stride from one normal to the next, allowing vertices and attributes to be packed into a single array or stored in separate arrays. (Single-array storage may be more efficient on some implementations; see gl:interleavedArrays/3 .)
If a non-zero named buffer object is bound to the ?GL_ARRAY_BUFFER target (see gl:bindBuffer/2 ) while a normal 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 normal vertex array client-side state (?GL_NORMAL_ARRAY_BUFFER_BINDING ).
When a normal 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 normal array, call gl:enableClientState/1 and gl:enableClientState/1 with the argument ?GL_NORMAL_ARRAY. If enabled, the normal 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.
colorPointer(Size, Type, Stride, Ptr) -> ok
Types:
Define an array of colors
gl:colorPointer 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 or 4. 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. (Single-array storage may be more efficient on some implementations; see gl:interleavedArrays/3 .)
If a non-zero named buffer object is bound to the ?GL_ARRAY_BUFFER target (see gl:bindBuffer/2 ) while a color 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 color vertex array client-side state (?GL_COLOR_ARRAY_BUFFER_BINDING).
When a color array is specified, Size , 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 color array, call gl:enableClientState/1 and gl:enableClientState/1 with the argument ?GL_COLOR_ARRAY. If enabled, the color 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.
indexPointer(Type, Stride, Ptr) -> ok
Types:
Define an array of color indexes
gl:indexPointer specifies the location and data format of an array of color indexes to use when rendering. Type specifies the data type of each color index and Stride specifies the byte stride from one color index 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 color index 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 color index vertex array client-side state (?GL_INDEX_ARRAY_BUFFER_BINDING ).
When a color index 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 color index array, call gl:enableClientState/1 and gl:enableClientState/1 with the argument ?GL_INDEX_ARRAY. If enabled, the color index 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.
texCoordPointer(Size, Type, Stride, Ptr) -> ok
Types:
Define an array of texture coordinates
gl:texCoordPointer specifies the location and data format of an array of texture coordinates to use when rendering. Size specifies the number of coordinates per texture coordinate set, and must be 1, 2, 3, or 4. Type specifies the data type of each texture coordinate, and Stride specifies the byte stride from one texture coordinate set to the next, allowing vertices and attributes to be packed into a single array or stored in separate arrays. (Single-array storage may be more efficient on some implementations; see gl:interleavedArrays/3 .)
If a non-zero named buffer object is bound to the ?GL_ARRAY_BUFFER target (see gl:bindBuffer/2 ) while a texture 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 texture coordinate vertex array client-side state (?GL_TEXTURE_COORD_ARRAY_BUFFER_BINDING ).
When a texture coordinate array is specified, Size , Type , Stride , and Pointer are saved as client-side state, in addition to the current vertex array buffer object binding.
To enable and disable a texture coordinate array, call gl:enableClientState/1 and gl:enableClientState/1 with the argument ?GL_TEXTURE_COORD_ARRAY. If enabled, the texture coordinate array is used when gl:arrayElement/1 , gl:drawArrays/3 , gl:multiDrawArrays/3 , gl:drawElements/4 , see glMultiDrawElements, or gl:drawRangeElements/6 is called.
See external documentation.
edgeFlagPointer(Stride, Ptr) -> ok
Types:
Define an array of edge flags
gl:edgeFlagPointer specifies the location and data format of an array of boolean edge flags to use when rendering. Stride specifies the byte stride from one edge flag 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 an edge flag 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 edge flag vertex array client-side state (?GL_EDGE_FLAG_ARRAY_BUFFER_BINDING ).
When an edge flag array is specified, Stride and Pointer are saved as client-side state, in addition to the current vertex array buffer object binding.
To enable and disable the edge flag array, call gl:enableClientState/1 and gl:enableClientState/1 with the argument ?GL_EDGE_FLAG_ARRAY. If enabled, the edge flag 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.
Types:
Render a vertex using the specified vertex array element
gl:arrayElement commands are used within gl:'begin'/1 / gl:'begin'/1 pairs to specify vertex and attribute data for point, line, and polygon primitives. If ?GL_VERTEX_ARRAY is enabled when gl:arrayElement is called, a single vertex is drawn, using vertex and attribute data taken from location I of the enabled arrays. If ?GL_VERTEX_ARRAY is not enabled, no drawing occurs but the attributes corresponding to the enabled arrays are modified.
Use gl:arrayElement to construct primitives by indexing vertex data, rather than by streaming through arrays of data in first-to-last order. Because each call specifies only a single vertex, it is possible to explicitly specify per-primitive attributes such as a single normal for each triangle.
Changes made to array data between the execution of gl:'begin'/1 and the corresponding execution of gl:'begin'/1 may affect calls to gl:arrayElement that are made within the same gl:'begin'/1 / gl:'begin'/1 period in nonsequential ways. That is, a call to gl:arrayElement that precedes a change to array data may access the changed data, and a call that follows a change to array data may access original data.
See external documentation.
drawArrays(Mode, First, Count) -> ok
Types:
Render primitives from array data
gl:drawArrays specifies multiple 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:drawArrays .
When gl:drawArrays 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:drawArrays have an unspecified value after gl:drawArrays returns. Attributes that aren't modified remain well defined.
See external documentation.
drawElements(Mode, Count, Type, Indices) -> ok
Types:
Render primitives from array data
gl:drawElements specifies multiple geometric primitives with very few subroutine calls. Instead of calling a GL function to pass each individual vertex, normal, texture coordinate, edge flag, or color, you can prespecify separate arrays of vertices, normals, and so on, and use them to construct a sequence of primitives with a single call to gl:drawElements .
When gl:drawElements is called, it uses Count sequential elements from an enabled array, starting at Indices 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:drawElements have an unspecified value after gl:drawElements returns. Attributes that aren't modified maintain their previous values.
See external documentation.
interleavedArrays(Format, Stride, Pointer) -> ok
Types:
Simultaneously specify and enable several interleaved arrays
gl:interleavedArrays lets you specify and enable individual color, normal, texture and vertex arrays whose elements are part of a larger aggregate array element. For some implementations, this is more efficient than specifying the arrays separately.
If Stride is 0, the aggregate elements are stored consecutively. Otherwise, Stride bytes occur between the beginning of one aggregate array element and the beginning of the next aggregate array element.
Format serves as a key describing the extraction of individual arrays from the aggregate array. If Format contains a T, then texture coordinates are extracted from the interleaved array. If C is present, color values are extracted. If N is present, normal coordinates are extracted. Vertex coordinates are always extracted.
The digits 2, 3, and 4 denote how many values are extracted. F indicates that values are extracted as floating-point values. Colors may also be extracted as 4 unsigned bytes if 4UB follows the C. If a color is extracted as 4 unsigned bytes, the vertex array element which follows is located at the first possible floating-point aligned address.
See external documentation.
Types:
Select flat or smooth shading
GL primitives can have either flat or smooth shading. Smooth shading, the default, causes the computed colors of vertices to be interpolated as the primitive is rasterized, typically assigning different colors to each resulting pixel fragment. Flat shading selects the computed color of just one vertex and assigns it to all the pixel fragments generated by rasterizing a single primitive. In either case, the computed color of a vertex is the result of lighting if lighting is enabled, or it is the current color at the time the vertex was specified if lighting is disabled.
Flat and smooth shading are indistinguishable for points. Starting when gl:'begin'/1 is issued and counting vertices and primitives from 1, the GL gives each flat-shaded line segment i the computed color of vertex i+1, its second vertex. Counting similarly from 1, the GL gives each flat-shaded polygon the computed color of the vertex listed in the following table. This is the last vertex to specify the polygon in all cases except single polygons, where the first vertex specifies the flat-shaded color.
Primitive Type of Polygon iVertexSingle polygon ( i== 1) 1
Triangle strip i+2
Triangle fan i+2
Independent triangle 3 i
Quad strip 2 i+2
Independent quad 4 i
Flat and smooth shading are specified by gl:shadeModel with Mode set to ?GL_FLAT and ?GL_SMOOTH, respectively.
See external documentation.
lightf(Light, Pname, Param) -> ok
Types:
Set light source parameters
gl:light sets the values of individual light source parameters. Light names the light and is a symbolic name of the form ?GL_LIGHT i, where i ranges from 0 to the value of ?GL_MAX_LIGHTS - 1. Pname specifies one of ten light source parameters, again by symbolic name. Params is either a single value or a pointer to an array that contains the new values.
To enable and disable lighting calculation, call gl:enable/1 and gl:enable/1 with argument ?GL_LIGHTING. Lighting is initially disabled. When it is enabled, light sources that are enabled contribute to the lighting calculation. Light source i is enabled and disabled using gl:enable/1 and gl:enable/1 with argument ?GL_LIGHT i.
The ten light parameters are as follows:
?GL_AMBIENT: Params contains four integer or floating-point values that specify the ambient RGBA intensity of the light. 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. Neither integer nor floating-point values are clamped. The initial ambient light intensity is (0, 0, 0, 1).
?GL_DIFFUSE: Params contains four integer or floating-point values that specify the diffuse RGBA intensity of the light. 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. Neither integer nor floating-point values are clamped. The initial value for ?GL_LIGHT0 is (1, 1, 1, 1); for other lights, the initial value is (0, 0, 0, 1).
?GL_SPECULAR: Params contains four integer or floating-point values that specify the specular RGBA intensity of the light. 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. Neither integer nor floating-point values are clamped. The initial value for ?GL_LIGHT0 is (1, 1, 1, 1); for other lights, the initial value is (0, 0, 0, 1).
?GL_POSITION: Params contains four integer or floating-point values that specify the position of the light in homogeneous object coordinates. Both integer and floating-point values are mapped directly. Neither integer nor floating-point values are clamped.
The position is transformed by the modelview matrix when gl:light is called (just as if it were a point), and it is stored in eye coordinates. If the w component of the position is 0, the light is treated as a directional source. Diffuse and specular lighting calculations take the light's direction, but not its actual position, into account, and attenuation is disabled. Otherwise, diffuse and specular lighting calculations are based on the actual location of the light in eye coordinates, and attenuation is enabled. The initial position is (0, 0, 1, 0); thus, the initial light source is directional, parallel to, and in the direction of the -z axis.
?GL_SPOT_DIRECTION: Params contains three integer or floating-point values that specify the direction of the light in homogeneous object coordinates. Both integer and floating-point values are mapped directly. Neither integer nor floating-point values are clamped.
The spot direction is transformed by the upper 3x3 of the modelview matrix when gl:light is called, and it is stored in eye coordinates. It is significant only when ?GL_SPOT_CUTOFF is not 180, which it is initially. The initial direction is (0 0 -1).
?GL_SPOT_EXPONENT: Params is a single integer or floating-point value that specifies the intensity distribution of the light. Integer and floating-point values are mapped directly. Only values in the range [0 128] are accepted.
Effective light intensity is attenuated by the cosine of the angle between the direction of the light and the direction from the light to the vertex being lighted, raised to the power of the spot exponent. Thus, higher spot exponents result in a more focused light source, regardless of the spot cutoff angle (see ?GL_SPOT_CUTOFF, next paragraph). The initial spot exponent is 0, resulting in uniform light distribution.
?GL_SPOT_CUTOFF: Params is a single integer or floating-point value that specifies the maximum spread angle of a light source. Integer and floating-point values are mapped directly. Only values in the range [0 90] and the special value 180 are accepted. If the angle between the direction of the light and the direction from the light to the vertex being lighted is greater than the spot cutoff angle, the light is completely masked. Otherwise, its intensity is controlled by the spot exponent and the attenuation factors. The initial spot cutoff is 180, resulting in uniform light distribution.
?GL_CONSTANT_ATTENUATION
?GL_LINEAR_ATTENUATION
?GL_QUADRATIC_ATTENUATION: Params is a single integer or floating-point value that specifies one of the three light attenuation factors. Integer and floating-point values are mapped directly. Only nonnegative values are accepted. If the light is positional, rather than directional, its intensity is attenuated by the reciprocal of the sum of the constant factor, the linear factor times the distance between the light and the vertex being lighted, and the quadratic factor times the square of the same distance. The initial attenuation factors are (1, 0, 0), resulting in no attenuation.
See external documentation.
lighti(Light, Pname, Param) -> ok
Types:
See lightf/3
lightfv(Light, Pname, Params) -> ok
Types:
See lightf/3
lightiv(Light, Pname, Params) -> ok
Types:
See lightf/3
getLightfv(Light, Pname) -> {float(), float(), float(), float()}
Types:
Return light source parameter values
gl:getLight returns in Params the value or values of a light source parameter. Light names the light and is a symbolic name of the form ?GL_LIGHT i where i ranges from 0 to the value of ?GL_MAX_LIGHTS - 1. ?GL_MAX_LIGHTS is an implementation dependent constant that is greater than or equal to eight. Pname specifies one of ten light source parameters, again by symbolic name.
The following parameters are defined:
?GL_AMBIENT: Params returns four integer or floating-point values representing the ambient intensity of the light source. Integer values, when requested, are linearly mapped from the internal floating-point representation such that 1.0 maps to the most positive representable integer value, and -1.0 maps to the most negative representable integer value. If the internal value is outside the range [-1 1], the corresponding integer return value is undefined. The initial value is (0, 0, 0, 1).
?GL_DIFFUSE: Params returns four integer or floating-point values representing the diffuse intensity of the light source. Integer values, when requested, are linearly mapped from the internal floating-point representation such that 1.0 maps to the most positive representable integer value, and -1.0 maps to the most negative representable integer value. If the internal value is outside the range [-1 1], the corresponding integer return value is undefined. The initial value for ?GL_LIGHT0 is (1, 1, 1, 1); for other lights, the initial value is (0, 0, 0, 0).
?GL_SPECULAR: Params returns four integer or floating-point values representing the specular intensity of the light source. Integer values, when requested, are linearly mapped from the internal floating-point representation such that 1.0 maps to the most positive representable integer value, and -1.0 maps to the most negative representable integer value. If the internal value is outside the range [-1 1], the corresponding integer return value is undefined. The initial value for ?GL_LIGHT0 is (1, 1, 1, 1); for other lights, the initial value is (0, 0, 0, 0).
?GL_POSITION: Params returns four integer or floating-point values representing the position of the light source. Integer values, when requested, are computed by rounding the internal floating-point values to the nearest integer value. The returned values are those maintained in eye coordinates. They will not be equal to the values specified using gl:lightf/3 , unless the modelview matrix was identity at the time gl:lightf/3 was called. The initial value is (0, 0, 1, 0).
?GL_SPOT_DIRECTION: Params returns three integer or floating-point values representing the direction of the light source. Integer values, when requested, are computed by rounding the internal floating-point values to the nearest integer value. The returned values are those maintained in eye coordinates. They will not be equal to the values specified using gl:lightf/3 , unless the modelview matrix was identity at the time gl:lightf/3 was called. Although spot direction is normalized before being used in the lighting equation, the returned values are the transformed versions of the specified values prior to normalization. The initial value is (0 0 -1).
?GL_SPOT_EXPONENT: Params returns a single integer or floating-point value representing the spot exponent of the light. An integer value, when requested, is computed by rounding the internal floating-point representation to the nearest integer. The initial value is 0.
?GL_SPOT_CUTOFF: Params returns a single integer or floating-point value representing the spot cutoff angle of the light. An integer value, when requested, is computed by rounding the internal floating-point representation to the nearest integer. The initial value is 180.
?GL_CONSTANT_ATTENUATION: Params returns a single integer or floating-point value representing the constant (not distance-related) attenuation of the light. An integer value, when requested, is computed by rounding the internal floating-point representation to the nearest integer. The initial value is 1.
?GL_LINEAR_ATTENUATION: Params returns a single integer or floating-point value representing the linear attenuation of the light. An integer value, when requested, is computed by rounding the internal floating-point representation to the nearest integer. The initial value is 0.
?GL_QUADRATIC_ATTENUATION: Params returns a single integer or floating-point value representing the quadratic attenuation of the light. An integer value, when requested, is computed by rounding the internal floating-point representation to the nearest integer. The initial value is 0.
See external documentation.
getLightiv(Light, Pname) -> {integer(), integer(), integer(), integer()}
Types:
See getLightfv/2
lightModelf(Pname, Param) -> ok
Types:
Set the lighting model parameters
gl:lightModel sets the lighting model parameter. Pname names a parameter and Params gives the new value. There are three lighting model parameters:
?GL_LIGHT_MODEL_AMBIENT: Params contains four integer or floating-point values that specify the ambient RGBA intensity of the entire scene. 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. Neither integer nor floating-point values are clamped. The initial ambient scene intensity is (0.2, 0.2, 0.2, 1.0).
?GL_LIGHT_MODEL_COLOR_CONTROL: Params must be either ?GL_SEPARATE_SPECULAR_COLOR or ?GL_SINGLE_COLOR. ?GL_SINGLE_COLOR specifies that a single color is generated from the lighting computation for a vertex. ?GL_SEPARATE_SPECULAR_COLOR specifies that the specular color computation of lighting be stored separately from the remainder of the lighting computation. The specular color is summed into the generated fragment's color after the application of texture mapping (if enabled). The initial value is ?GL_SINGLE_COLOR.
?GL_LIGHT_MODEL_LOCAL_VIEWER: Params is a single integer or floating-point value that specifies how specular reflection angles are computed. If Params is 0 (or 0.0), specular reflection angles take the view direction to be parallel to and in the direction of the -z axis, regardless of the location of the vertex in eye coordinates. Otherwise, specular reflections are computed from the origin of the eye coordinate system. The initial value is 0.
?GL_LIGHT_MODEL_TWO_SIDE: Params is a single integer or floating-point value that specifies whether one- or two-sided lighting calculations are done for polygons. It has no effect on the lighting calculations for points, lines, or bitmaps. If Params is 0 (or 0.0), one-sided lighting is specified, and only the front material parameters are used in the lighting equation. Otherwise, two-sided lighting is specified. In this case, vertices of back-facing polygons are lighted using the back material parameters and have their normals reversed before the lighting equation is evaluated. Vertices of front-facing polygons are always lighted using the front material parameters, with no change to their normals. The initial value is 0.
In RGBA mode, the lighted color of a vertex is the sum of the material emission intensity, the product of the material ambient reflectance and the lighting model full-scene ambient intensity, and the contribution of each enabled light source. Each light source contributes the sum of three terms: ambient, diffuse, and specular. The ambient light source contribution is the product of the material ambient reflectance and the light's ambient intensity. The diffuse light source contribution is the product of the material diffuse reflectance, the light's diffuse intensity, and the dot product of the vertex's normal with the normalized vector from the vertex to the light source. The specular light source contribution is the product of the material specular reflectance, the light's specular intensity, and the dot product of the normalized vertex-to-eye and vertex-to-light vectors, raised to the power of the shininess of the material. All three light source contributions are attenuated equally based on the distance from the vertex to the light source and on light source direction, spread exponent, and spread cutoff angle. All dot products are replaced with 0 if they evaluate to a negative value.
The alpha component of the resulting lighted color is set to the alpha value of the material diffuse reflectance.
In color index mode, the value of the lighted index of a vertex ranges from the ambient to the specular values passed to gl:materialf/3 using ?GL_COLOR_INDEXES. Diffuse and specular coefficients, computed with a (.30, .59, .11) weighting of the lights' colors, the shininess of the material, and the same reflection and attenuation equations as in the RGBA case, determine how much above ambient the resulting index is.
See external documentation.
lightModeli(Pname, Param) -> ok
Types:
See lightModelf/2
lightModelfv(Pname, Params) -> ok
Types:
See lightModelf/2
lightModeliv(Pname, Params) -> ok
Types:
See lightModelf/2
materialf(Face, Pname, Param) -> ok
Types:
Specify material parameters for the lighting model
gl:material assigns values to material parameters. There are two matched sets of material parameters. One, the front-facing set, is used to shade points, lines, bitmaps, and all polygons (when two-sided lighting is disabled), or just front-facing polygons (when two-sided lighting is enabled). The other set, back-facing, is used to shade back-facing polygons only when two-sided lighting is enabled. Refer to the gl:lightModelf/2 reference page for details concerning one- and two-sided lighting calculations.
gl:material takes three arguments. The first, Face , specifies whether the ?GL_FRONT materials, the ?GL_BACK materials, or both ?GL_FRONT_AND_BACK materials will be modified. The second, Pname , specifies which of several parameters in one or both sets will be modified. The third, Params , specifies what value or values will be assigned to the specified parameter.
Material parameters are used in the lighting equation that is optionally applied to each vertex. The equation is discussed in the gl:lightModelf/2 reference page. The parameters that can be specified using gl:material, and their interpretations by the lighting equation, are as follows:
?GL_AMBIENT: Params contains four integer or floating-point values that specify the ambient RGBA reflectance of the material. 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. Neither integer nor floating-point values are clamped. The initial ambient reflectance for both front- and back-facing materials is (0.2, 0.2, 0.2, 1.0).
?GL_DIFFUSE: Params contains four integer or floating-point values that specify the diffuse RGBA reflectance of the material. 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. Neither integer nor floating-point values are clamped. The initial diffuse reflectance for both front- and back-facing materials is (0.8, 0.8, 0.8, 1.0).
?GL_SPECULAR: Params contains four integer or floating-point values that specify the specular RGBA reflectance of the material. 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. Neither integer nor floating-point values are clamped. The initial specular reflectance for both front- and back-facing materials is (0, 0, 0, 1).
?GL_EMISSION: Params contains four integer or floating-point values that specify the RGBA emitted light intensity of the material. 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. Neither integer nor floating-point values are clamped. The initial emission intensity for both front- and back-facing materials is (0, 0, 0, 1).
?GL_SHININESS: Params is a single integer or floating-point value that specifies the RGBA specular exponent of the material. Integer and floating-point values are mapped directly. Only values in the range [0 128] are accepted. The initial specular exponent for both front- and back-facing materials is 0.
?GL_AMBIENT_AND_DIFFUSE: Equivalent to calling gl:material twice with the same parameter values, once with ?GL_AMBIENT and once with ?GL_DIFFUSE.
?GL_COLOR_INDEXES: Params contains three integer or floating-point values specifying the color indices for ambient, diffuse, and specular lighting. These three values, and ?GL_SHININESS, are the only material values used by the color index mode lighting equation. Refer to the gl:lightModelf/2 reference page for a discussion of color index lighting.
See external documentation.
materiali(Face, Pname, Param) -> ok
Types:
See materialf/3
materialfv(Face, Pname, Params) -> ok
Types:
See materialf/3
materialiv(Face, Pname, Params) -> ok
Types:
See materialf/3
getMaterialfv(Face, Pname) -> {float(), float(), float(), float()}
Types:
Return material parameters
gl:getMaterial returns in Params the value or values of parameter Pname of material Face . Six parameters are defined:
?GL_AMBIENT: Params returns four integer or floating-point values representing the ambient reflectance of the material. Integer values, when requested, are linearly mapped from the internal floating-point representation such that 1.0 maps to the most positive representable integer value, and -1.0 maps to the most negative representable integer value. If the internal value is outside the range [-1 1], the corresponding integer return value is undefined. The initial value is (0.2, 0.2, 0.2, 1.0)
?GL_DIFFUSE: Params returns four integer or floating-point values representing the diffuse reflectance of the material. Integer values, when requested, are linearly mapped from the internal floating-point representation such that 1.0 maps to the most positive representable integer value, and -1.0 maps to the most negative representable integer value. If the internal value is outside the range [-1 1], the corresponding integer return value is undefined. The initial value is (0.8, 0.8, 0.8, 1.0).
?GL_SPECULAR: Params returns four integer or floating-point values representing the specular reflectance of the material. Integer values, when requested, are linearly mapped from the internal floating-point representation such that 1.0 maps to the most positive representable integer value, and -1.0 maps to the most negative representable integer value. If the internal value is outside the range [-1 1], the corresponding integer return value is undefined. The initial value is (0, 0, 0, 1).
?GL_EMISSION: Params returns four integer or floating-point values representing the emitted light intensity of the material. Integer values, when requested, are linearly mapped from the internal floating-point representation such that 1.0 maps to the most positive representable integer value, and -1.0 maps to the most negative representable integer value. If the internal value is outside the range [-1 1], the corresponding integer return value is undefined. The initial value is (0, 0, 0, 1).
?GL_SHININESS: Params returns one integer or floating-point value representing the specular exponent of the material. Integer values, when requested, are computed by rounding the internal floating-point value to the nearest integer value. The initial value is 0.
?GL_COLOR_INDEXES: Params returns three integer or floating-point values representing the ambient, diffuse, and specular indices of the material. These indices are used only for color index lighting. (All the other parameters are used only for RGBA lighting.) Integer values, when requested, are computed by rounding the internal floating-point values to the nearest integer values.
See external documentation.
getMaterialiv(Face, Pname) -> {integer(), integer(), integer(), integer()}
Types:
See getMaterialfv/2
colorMaterial(Face, Mode) -> ok
Types:
Cause a material color to track the current color
gl:colorMaterial specifies which material parameters track the current color. When ?GL_COLOR_MATERIAL is enabled, the material parameter or parameters specified by Mode , of the material or materials specified by Face , track the current color at all times.
To enable and disable ?GL_COLOR_MATERIAL, call gl:enable/1 and gl:enable/1 with argument ?GL_COLOR_MATERIAL. ?GL_COLOR_MATERIAL is initially disabled.
See external documentation.
pixelZoom(Xfactor, Yfactor) -> ok
Types:
Specify the pixel zoom factors
gl:pixelZoom specifies values for the x and y zoom factors. During the execution of gl:drawPixels/5 or gl:copyPixels/5 , if ( xr, yr) is the current raster position, and a given element is in the mth row and nth column of the pixel rectangle, then pixels whose centers are in the rectangle with corners at
( xr+n. xfactor, yr+m. yfactor)
( xr+(n+1). xfactor, yr+(m+1). yfactor)
are candidates for replacement. Any pixel whose center lies on the bottom or left edge of this rectangular region is also modified.
Pixel zoom factors are not limited to positive values. Negative zoom factors reflect the resulting image about the current raster position.
See external documentation.
pixelStoref(Pname, Param) -> ok
Types:
Set pixel storage modes
gl:pixelStore sets pixel storage modes that affect the operation of subsequent gl:readPixels/7 as well as the unpacking of texture patterns (see gl:texImage1D/8 , gl:texImage2D/9 , gl:texImage3D/10 , gl:texSubImage1D/7 , gl:texSubImage1D/7 , gl:texSubImage1D/7 ), gl:compressedTexImage1D/7 , gl:compressedTexImage2D/8 , gl:compressedTexImage3D/9 , gl:compressedTexSubImage1D/7 , gl:compressedTexSubImage2D/9 or gl:compressedTexSubImage1D/7 .
Pname is a symbolic constant indicating the parameter to be set, and Param is the new value. Six of the twelve storage parameters affect how pixel data is returned to client memory. They are as follows:
?GL_PACK_SWAP_BYTES: If true, byte ordering for multibyte color components, depth components, or stencil indices is reversed. That is, if a four-byte component consists of bytes b 0, b 1, b 2, b 3, it is stored in memory as b 3, b 2, b 1, b 0 if ?GL_PACK_SWAP_BYTES is true. ?GL_PACK_SWAP_BYTES has no effect on the memory order of components within a pixel, only on the order of bytes within components or indices. For example, the three components of a ?GL_RGB format pixel are always stored with red first, green second, and blue third, regardless of the value of ?GL_PACK_SWAP_BYTES.
?GL_PACK_LSB_FIRST: If true, bits are ordered within a byte from least significant to most significant; otherwise, the first bit in each byte is the most significant one.
?GL_PACK_ROW_LENGTH: If greater than 0, ?GL_PACK_ROW_LENGTH defines the number of pixels in a row. If the first pixel of a row is placed at location p in memory, then the location of the first pixel of the next row is obtained by skipping
k={n l(a/s) |(s n l)/a| s>= a s< a)
components or indices, where n is the number of components or indices in a pixel, l is the number of pixels in a row (?GL_PACK_ROW_LENGTH if it is greater than 0, the width argument to the pixel routine otherwise), a is the value of ?GL_PACK_ALIGNMENT , and s is the size, in bytes, of a single component (if a< s, then it is as if a= s). In the case of 1-bit values, the location of the next row is obtained by skipping
k=8 a |(n l)/(8 a)|
components or indices.
The word component in this description refers to the nonindex values red, green, blue, alpha, and depth. Storage format ?GL_RGB, for example, has three components per pixel: first red, then green, and finally blue.
?GL_PACK_IMAGE_HEIGHT: If greater than 0, ?GL_PACK_IMAGE_HEIGHT defines the number of pixels in an image three-dimensional texture volume, where image is defined by all pixels sharing the same third dimension index. If the first pixel of a row is placed at location p in memory, then the location of the first pixel of the next row is obtained by skipping
k={n l h(a/s) |(s n l h)/a| s>= a s< a)
components or indices, where n is the number of components or indices in a pixel, l is the number of pixels in a row (?GL_PACK_ROW_LENGTH if it is greater than 0, the width argument to gl:texImage3D/10 otherwise), h is the number of rows in a pixel image (?GL_PACK_IMAGE_HEIGHT if it is greater than 0, the height argument to the gl:texImage3D/10 routine otherwise), a is the value of ?GL_PACK_ALIGNMENT , and s is the size, in bytes, of a single component (if a< s, then it is as if a=s).
The word component in this description refers to the nonindex values red, green, blue, alpha, and depth. Storage format ?GL_RGB, for example, has three components per pixel: first red, then green, and finally blue.
?GL_PACK_SKIP_PIXELS, ?GL_PACK_SKIP_ROWS, and ?GL_PACK_SKIP_IMAGES
These values are provided as a convenience to the programmer; they provide no functionality that cannot be duplicated simply by incrementing the pointer passed to gl:readPixels/7 . Setting ?GL_PACK_SKIP_PIXELS to i is equivalent to incrementing the pointer by i n components or indices, where n is the number of components or indices in each pixel. Setting ?GL_PACK_SKIP_ROWS to j is equivalent to incrementing the pointer by j m components or indices, where m is the number of components or indices per row, as just computed in the ?GL_PACK_ROW_LENGTH section. Setting ?GL_PACK_SKIP_IMAGES to k is equivalent to incrementing the pointer by k p, where p is the number of components or indices per image, as computed in the ?GL_PACK_IMAGE_HEIGHT section.
?GL_PACK_ALIGNMENT: Specifies the alignment requirements for the start of each pixel row in memory. The allowable values are 1 (byte-alignment), 2 (rows aligned to even-numbered bytes), 4 (word-alignment), and 8 (rows start on double-word boundaries).
The other six of the twelve storage parameters affect how pixel data is read from client memory. These values are significant for gl:texImage1D/8 , gl:texImage2D/9 , gl:texImage3D/10 , gl:texSubImage1D/7 , gl:texSubImage1D/7 , and gl:texSubImage1D/7
They are as follows:
?GL_UNPACK_SWAP_BYTES: If true, byte ordering for multibyte color components, depth components, or stencil indices is reversed. That is, if a four-byte component consists of bytes b 0, b 1, b 2, b 3, it is taken from memory as b 3, b 2, b 1, b 0 if ?GL_UNPACK_SWAP_BYTES is true. ?GL_UNPACK_SWAP_BYTES has no effect on the memory order of components within a pixel, only on the order of bytes within components or indices. For example, the three components of a ?GL_RGB format pixel are always stored with red first, green second, and blue third, regardless of the value of ?GL_UNPACK_SWAP_BYTES.
?GL_UNPACK_LSB_FIRST: If true, bits are ordered within a byte from least significant to most significant; otherwise, the first bit in each byte is the most significant one.
?GL_UNPACK_ROW_LENGTH: If greater than 0, ?GL_UNPACK_ROW_LENGTH defines the number of pixels in a row. If the first pixel of a row is placed at location p in memory, then the location of the first pixel of the next row is obtained by skipping
k={n l(a/s) |(s n l)/a| s>= a s< a)
components or indices, where n is the number of components or indices in a pixel, l is the number of pixels in a row (?GL_UNPACK_ROW_LENGTH if it is greater than 0, the width argument to the pixel routine otherwise), a is the value of ?GL_UNPACK_ALIGNMENT , and s is the size, in bytes, of a single component (if a< s, then it is as if a= s). In the case of 1-bit values, the location of the next row is obtained by skipping
k=8 a |(n l)/(8 a)|
components or indices.
The word component in this description refers to the nonindex values red, green, blue, alpha, and depth. Storage format ?GL_RGB, for example, has three components per pixel: first red, then green, and finally blue.
?GL_UNPACK_IMAGE_HEIGHT: If greater than 0, ?GL_UNPACK_IMAGE_HEIGHT defines the number of pixels in an image of a three-dimensional texture volume. Where image is defined by all pixel sharing the same third dimension index. If the first pixel of a row is placed at location p in memory, then the location of the first pixel of the next row is obtained by skipping
k={n l h(a/s) |(s n l h)/a| s>= a s< a)
components or indices, where n is the number of components or indices in a pixel, l is the number of pixels in a row (?GL_UNPACK_ROW_LENGTH if it is greater than 0, the width argument to gl:texImage3D/10 otherwise), h is the number of rows in an image (?GL_UNPACK_IMAGE_HEIGHT if it is greater than 0, the height argument to gl:texImage3D/10 otherwise), a is the value of ?GL_UNPACK_ALIGNMENT, and s is the size, in bytes, of a single component (if a< s, then it is as if a=s).
The word component in this description refers to the nonindex values red, green, blue, alpha, and depth. Storage format ?GL_RGB, for example, has three components per pixel: first red, then green, and finally blue.
?GL_UNPACK_SKIP_PIXELS and ?GL_UNPACK_SKIP_ROWS
These values are provided as a convenience to the programmer; they provide no functionality that cannot be duplicated by incrementing the pointer passed to gl:texImage1D/8 , gl:texImage2D/9 , gl:texSubImage1D/7 or gl:texSubImage1D/7 . Setting ?GL_UNPACK_SKIP_PIXELS to i is equivalent to incrementing the pointer by i n components or indices, where n is the number of components or indices in each pixel. Setting ?GL_UNPACK_SKIP_ROWS to j is equivalent to incrementing the pointer by j k components or indices, where k is the number of components or indices per row, as just computed in the ?GL_UNPACK_ROW_LENGTH section.
?GL_UNPACK_ALIGNMENT: Specifies the alignment requirements for the start of each pixel row in memory. The allowable values are 1 (byte-alignment), 2 (rows aligned to even-numbered bytes), 4 (word-alignment), and 8 (rows start on double-word boundaries).
The following table gives the type, initial value, and range of valid values for each storage parameter that can be set with gl:pixelStore.
Pname TypeInitial Value Valid Range?GL_PACK_SWAP_BYTES boolean false true or false
?GL_PACK_LSB_FIRST boolean false true or false
?GL_PACK_ROW_LENGTH integer 0 [0)
?GL_PACK_IMAGE_HEIGHT integer 0 [0)
?GL_PACK_SKIP_ROWS integer 0 [0)
?GL_PACK_SKIP_PIXELS integer 0 [0)
?GL_PACK_SKIP_IMAGES integer 0 [0)
?GL_PACK_ALIGNMENT integer 4 1, 2, 4, or 8
?GL_UNPACK_SWAP_BYTES boolean false true or false
?GL_UNPACK_LSB_FIRST boolean false true or false
?GL_UNPACK_ROW_LENGTH integer 0 [0)
?GL_UNPACK_IMAGE_HEIGHT integer 0 [0)
?GL_UNPACK_SKIP_ROWS integer 0 [0)
?GL_UNPACK_SKIP_PIXELS integer 0 [0)
?GL_UNPACK_SKIP_IMAGES integer 0 [0)
?GL_UNPACK_ALIGNMENT integer 4 1, 2, 4, or 8
gl:pixelStoref can be used to set any pixel store parameter. If the parameter type is boolean, then if Param is 0, the parameter is false; otherwise it is set to true. If Pname is a integer type parameter, Param is rounded to the nearest integer.
Likewise, gl:pixelStorei can also be used to set any of the pixel store parameters. Boolean parameters are set to false if Param is 0 and true otherwise.
See external documentation.
pixelStorei(Pname, Param) -> ok
Types:
See pixelStoref/2
pixelTransferf(Pname, Param) -> ok
Types:
Set pixel transfer modes
gl:pixelTransfer sets pixel transfer modes that affect the operation of subsequent gl:copyPixels/5 , gl:copyTexImage1D/7 , gl:copyTexImage2D/8 , gl:copyTexSubImage1D/6 , gl:copyTexSubImage2D/8 , gl:copyTexSubImage3D/9 , gl:drawPixels/5 , gl:readPixels/7 , gl:texImage1D/8 , gl:texImage2D/9 , gl:texImage3D/10 , gl:texSubImage1D/7 , gl:texSubImage1D/7 , and gl:texSubImage1D/7 commands. Additionally, if the ARB_imaging subset is supported, the routines gl:colorTable/6 , gl:colorSubTable/6 , gl:convolutionFilter1D/6 , gl:convolutionFilter2D/7 , gl:histogram/4 , gl:minmax/3 , and gl:separableFilter2D/8 are also affected. The algorithms that are specified by pixel transfer modes operate on pixels after they are read from the frame buffer ( gl:copyPixels/5 gl:copyTexImage1D/7 , gl:copyTexImage2D/8 , gl:copyTexSubImage1D/6 , gl:copyTexSubImage2D/8 , gl:copyTexSubImage3D/9 , and gl:readPixels/7 ), or unpacked from client memory ( gl:drawPixels/5 , gl:texImage1D/8 , gl:texImage2D/9 , gl:texImage3D/10 , gl:texSubImage1D/7 , gl:texSubImage1D/7 , and gl:texSubImage1D/7 ). Pixel transfer operations happen in the same order, and in the same manner, regardless of the command that resulted in the pixel operation. Pixel storage modes (see gl:pixelStoref/2 ) control the unpacking of pixels being read from client memory and the packing of pixels being written back into client memory.
Pixel transfer operations handle four fundamental pixel types: color, color index , depth, and stencil. Color pixels consist of four floating-point values with unspecified mantissa and exponent sizes, scaled such that 0 represents zero intensity and 1 represents full intensity. Color indices comprise a single fixed-point value, with unspecified precision to the right of the binary point. Depth pixels comprise a single floating-point value, with unspecified mantissa and exponent sizes, scaled such that 0.0 represents the minimum depth buffer value, and 1.0 represents the maximum depth buffer value. Finally, stencil pixels comprise a single fixed-point value, with unspecified precision to the right of the binary point.
The pixel transfer operations performed on the four basic pixel types are as follows:
Color: Each of the four color components is multiplied by a scale factor, then added to a bias factor. That is, the red component is multiplied by ?GL_RED_SCALE, then added to ?GL_RED_BIAS; the green component is multiplied by ?GL_GREEN_SCALE , then added to ?GL_GREEN_BIAS; the blue component is multiplied by ?GL_BLUE_SCALE , then added to ?GL_BLUE_BIAS; and the alpha component is multiplied by ?GL_ALPHA_SCALE , then added to ?GL_ALPHA_BIAS. After all four color components are scaled and biased, each is clamped to the range [0 1]. All color, scale, and bias values are specified with gl:pixelTransfer.
If ?GL_MAP_COLOR is true, each color component is scaled by the size of the corresponding color-to-color map, then replaced by the contents of that map indexed by the scaled component. That is, the red component is scaled by ?GL_PIXEL_MAP_R_TO_R_SIZE, then replaced by the contents of ?GL_PIXEL_MAP_R_TO_R indexed by itself. The green component is scaled by ?GL_PIXEL_MAP_G_TO_G_SIZE, then replaced by the contents of ?GL_PIXEL_MAP_G_TO_G indexed by itself. The blue component is scaled by ?GL_PIXEL_MAP_B_TO_B_SIZE, then replaced by the contents of ?GL_PIXEL_MAP_B_TO_B indexed by itself. And the alpha component is scaled by ?GL_PIXEL_MAP_A_TO_A_SIZE, then replaced by the contents of ?GL_PIXEL_MAP_A_TO_A indexed by itself. All components taken from the maps are then clamped to the range [0 1]. ?GL_MAP_COLOR is specified with gl:pixelTransfer. The contents of the various maps are specified with gl:pixelMapfv/3 .
If the ARB_imaging extension is supported, each of the four color components may be scaled and biased after transformation by the color matrix. That is, the red component is multiplied by ?GL_POST_COLOR_MATRIX_RED_SCALE, then added to ?GL_POST_COLOR_MATRIX_RED_BIAS ; the green component is multiplied by ?GL_POST_COLOR_MATRIX_GREEN_SCALE, then added to ?GL_POST_COLOR_MATRIX_GREEN_BIAS; the blue component is multiplied by ?GL_POST_COLOR_MATRIX_BLUE_SCALE , then added to ?GL_POST_COLOR_MATRIX_BLUE_BIAS; and the alpha component is multiplied by ?GL_POST_COLOR_MATRIX_ALPHA_SCALE, then added to ?GL_POST_COLOR_MATRIX_ALPHA_BIAS . After all four color components are scaled and biased, each is clamped to the range [0 1].
Similarly, if the ARB_imaging extension is supported, each of the four color components may be scaled and biased after processing by the enabled convolution filter. That is, the red component is multiplied by ?GL_POST_CONVOLUTION_RED_SCALE, then added to ?GL_POST_CONVOLUTION_RED_BIAS ; the green component is multiplied by ?GL_POST_CONVOLUTION_GREEN_SCALE, then added to ?GL_POST_CONVOLUTION_GREEN_BIAS; the blue component is multiplied by ?GL_POST_CONVOLUTION_BLUE_SCALE , then added to ?GL_POST_CONVOLUTION_BLUE_BIAS; and the alpha component is multiplied by ?GL_POST_CONVOLUTION_ALPHA_SCALE, then added to ?GL_POST_CONVOLUTION_ALPHA_BIAS . After all four color components are scaled and biased, each is clamped to the range [0 1].
Color index: Each color index is shifted left by ?GL_INDEX_SHIFT bits; any bits beyond the number of fraction bits carried by the fixed-point index are filled with zeros. If ?GL_INDEX_SHIFT is negative, the shift is to the right, again zero filled. Then ?GL_INDEX_OFFSET is added to the index. ?GL_INDEX_SHIFT and ?GL_INDEX_OFFSET are specified with gl:pixelTransfer.
From this point, operation diverges depending on the required format of the resulting pixels. If the resulting pixels are to be written to a color index buffer, or if they are being read back to client memory in ?GL_COLOR_INDEX format, the pixels continue to be treated as indices. If ?GL_MAP_COLOR is true, each index is masked by 2 n-1 , where n is ?GL_PIXEL_MAP_I_TO_I_SIZE, then replaced by the contents of ?GL_PIXEL_MAP_I_TO_I indexed by the masked value. ?GL_MAP_COLOR is specified with gl:pixelTransfer . The contents of the index map is specified with gl:pixelMapfv/3 .
If the resulting pixels are to be written to an RGBA color buffer, or if they are read back to client memory in a format other than ?GL_COLOR_INDEX, the pixels are converted from indices to colors by referencing the four maps ?GL_PIXEL_MAP_I_TO_R, ?GL_PIXEL_MAP_I_TO_G , ?GL_PIXEL_MAP_I_TO_B, and ?GL_PIXEL_MAP_I_TO_A. Before being dereferenced, the index is masked by 2 n-1, where n is ?GL_PIXEL_MAP_I_TO_R_SIZE for the red map, ?GL_PIXEL_MAP_I_TO_G_SIZE for the green map, ?GL_PIXEL_MAP_I_TO_B_SIZE for the blue map, and ?GL_PIXEL_MAP_I_TO_A_SIZE for the alpha map. All components taken from the maps are then clamped to the range [0 1]. The contents of the four maps is specified with gl:pixelMapfv/3 .
Depth: Each depth value is multiplied by ?GL_DEPTH_SCALE, added to ?GL_DEPTH_BIAS , then clamped to the range [0 1].
Stencil: Each index is shifted ?GL_INDEX_SHIFT bits just as a color index is, then added to ?GL_INDEX_OFFSET. If ?GL_MAP_STENCIL is true, each index is masked by 2 n-1, where n is ?GL_PIXEL_MAP_S_TO_S_SIZE, then replaced by the contents of ?GL_PIXEL_MAP_S_TO_S indexed by the masked value.
The following table gives the type, initial value, and range of valid values for each of the pixel transfer parameters that are set with gl:pixelTransfer.
Pname TypeInitial Value Valid Range?GL_MAP_COLOR boolean false true/false
?GL_MAP_STENCIL boolean false true/false
?GL_INDEX_SHIFT integer 0 (-)
?GL_INDEX_OFFSET integer 0 (-)
?GL_RED_SCALE float 1 (-)
?GL_GREEN_SCALE float 1 (-)
?GL_BLUE_SCALE float 1 (-)
?GL_ALPHA_SCALE float 1 (-)
?GL_DEPTH_SCALE float 1 (-)
?GL_RED_BIAS float 0 (-)
?GL_GREEN_BIAS float 0 (-)
?GL_BLUE_BIAS float 0 (-)
?GL_ALPHA_BIAS float 0 (-)
?GL_DEPTH_BIAS float 0 (-)
?GL_POST_COLOR_MATRIX_RED_SCALE float 1 (-)
?GL_POST_COLOR_MATRIX_GREEN_SCALE float 1 (-)
?GL_POST_COLOR_MATRIX_BLUE_SCALE float 1 (-)
?GL_POST_COLOR_MATRIX_ALPHA_SCALE float 1 (-)
?GL_POST_COLOR_MATRIX_RED_BIAS float 0 (-)
?GL_POST_COLOR_MATRIX_GREEN_BIAS float 0 (-)
?GL_POST_COLOR_MATRIX_BLUE_BIAS float 0 (-)
?GL_POST_COLOR_MATRIX_ALPHA_BIAS float 0 (-)
?GL_POST_CONVOLUTION_RED_SCALE float 1 (-)
?GL_POST_CONVOLUTION_GREEN_SCALE float 1 (-)
?GL_POST_CONVOLUTION_BLUE_SCALE float 1 (-)
?GL_POST_CONVOLUTION_ALPHA_SCALE float 1 (-)
?GL_POST_CONVOLUTION_RED_BIAS float 0 (-)
?GL_POST_CONVOLUTION_GREEN_BIAS float 0 (-)
?GL_POST_CONVOLUTION_BLUE_BIAS float 0 (-)
?GL_POST_CONVOLUTION_ALPHA_BIAS float 0 (-)
gl:pixelTransferf can be used to set any pixel transfer parameter. If the parameter type is boolean, 0 implies false and any other value implies true. If Pname is an integer parameter, Param is rounded to the nearest integer.
Likewise, gl:pixelTransferi can be used to set any of the pixel transfer parameters. Boolean parameters are set to false if Param is 0 and to true otherwise. Param is converted to floating point before being assigned to real-valued parameters.
See external documentation.
pixelTransferi(Pname, Param) -> ok
Types:
See pixelTransferf/2
pixelMapfv(Map, Mapsize, Values) -> ok
Types:
Set up pixel transfer maps
gl:pixelMap sets up translation tables, or maps, used by gl:copyPixels/5 , gl:copyTexImage1D/7 , gl:copyTexImage2D/8 , gl:copyTexSubImage1D/6 , gl:copyTexSubImage2D/8 , gl:copyTexSubImage3D/9 , gl:drawPixels/5 , gl:readPixels/7 , gl:texImage1D/8 , gl:texImage2D/9 , gl:texImage3D/10 , gl:texSubImage1D/7 , gl:texSubImage1D/7 , and gl:texSubImage1D/7 . Additionally, if the ARB_imaging subset is supported, the routines gl:colorTable/6 , gl:colorSubTable/6 , gl:convolutionFilter1D/6 , gl:convolutionFilter2D/7 , gl:histogram/4 , gl:minmax/3 , and gl:separableFilter2D/8 . Use of these maps is described completely in the gl:pixelTransferf/2 reference page, and partly in the reference pages for the pixel and texture image commands. Only the specification of the maps is described in this reference page.
Map is a symbolic map name, indicating one of ten maps to set. Mapsize specifies the number of entries in the map, and Values is a pointer to an array of Mapsize map values.
If a non-zero named buffer object is bound to the ?GL_PIXEL_UNPACK_BUFFER target (see gl:bindBuffer/2 ) while a pixel transfer map is specified, Values is treated as a byte offset into the buffer object's data store.
The ten maps are as follows:
?GL_PIXEL_MAP_I_TO_I: Maps color indices to color indices.
?GL_PIXEL_MAP_S_TO_S: Maps stencil indices to stencil indices.
?GL_PIXEL_MAP_I_TO_R: Maps color indices to red components.
?GL_PIXEL_MAP_I_TO_G: Maps color indices to green components.
?GL_PIXEL_MAP_I_TO_B: Maps color indices to blue components.
?GL_PIXEL_MAP_I_TO_A: Maps color indices to alpha components.
?GL_PIXEL_MAP_R_TO_R: Maps red components to red components.
?GL_PIXEL_MAP_G_TO_G: Maps green components to green components.
?GL_PIXEL_MAP_B_TO_B: Maps blue components to blue components.
?GL_PIXEL_MAP_A_TO_A: Maps alpha components to alpha components.
The entries in a map can be specified as single-precision floating-point numbers, unsigned short integers, or unsigned int integers. Maps that store color component values (all but ?GL_PIXEL_MAP_I_TO_I and ?GL_PIXEL_MAP_S_TO_S) retain their values in floating-point format, with unspecified mantissa and exponent sizes. Floating-point values specified by gl:pixelMapfv are converted directly to the internal floating-point format of these maps, then clamped to the range [0,1]. Unsigned integer values specified by gl:pixelMapusv and gl:pixelMapuiv are converted linearly such that the largest representable integer maps to 1.0, and 0 maps to 0.0.
Maps that store indices, ?GL_PIXEL_MAP_I_TO_I and ?GL_PIXEL_MAP_S_TO_S, retain their values in fixed-point format, with an unspecified number of bits to the right of the binary point. Floating-point values specified by gl:pixelMapfv are converted directly to the internal fixed-point format of these maps. Unsigned integer values specified by gl:pixelMapusv and gl:pixelMapuiv specify integer values, with all 0's to the right of the binary point.
The following table shows the initial sizes and values for each of the maps. Maps that are indexed by either color or stencil indices must have Mapsize = 2 n for some n or the results are undefined. The maximum allowable size for each map depends on the implementation and can be determined by calling gl:getBooleanv/1 with argument ?GL_MAX_PIXEL_MAP_TABLE . The single maximum applies to all maps; it is at least 32.
Map Lookup IndexLookup ValueInitial Size Initial Value?GL_PIXEL_MAP_I_TO_I color index color index 1 0
?GL_PIXEL_MAP_S_TO_S stencil index stencil index 1 0
?GL_PIXEL_MAP_I_TO_R color index R 1 0
?GL_PIXEL_MAP_I_TO_G color index G 1 0
?GL_PIXEL_MAP_I_TO_B color index B 1 0
?GL_PIXEL_MAP_I_TO_A color index A 1 0
?GL_PIXEL_MAP_R_TO_R R R 1 0
?GL_PIXEL_MAP_G_TO_G G G 1 0
?GL_PIXEL_MAP_B_TO_B B B 1 0
?GL_PIXEL_MAP_A_TO_A A A 1 0
See external documentation.
pixelMapuiv(Map, Mapsize, Values) -> ok
Types:
See pixelMapfv/3
pixelMapusv(Map, Mapsize, Values) -> ok
Types:
See pixelMapfv/3
getPixelMapfv(Map, Values) -> ok
Types:
Return the specified pixel map
See the gl:pixelMapfv/3 reference page for a description of the acceptable values for the Map parameter. gl:getPixelMap returns in Data the contents of the pixel map specified in Map . Pixel maps are used during the execution of gl:readPixels/7 , gl:drawPixels/5 , gl:copyPixels/5 , gl:texImage1D/8 , gl:texImage2D/9 , gl:texImage3D/10 , gl:texSubImage1D/7 , gl:texSubImage1D/7 , gl:texSubImage1D/7 , gl:copyTexImage1D/7 , gl:copyTexImage2D/8 , gl:copyTexSubImage1D/6 , gl:copyTexSubImage2D/8 , and gl:copyTexSubImage3D/9 . to map color indices, stencil indices, color components, and depth components to other values.
If a non-zero named buffer object is bound to the ?GL_PIXEL_PACK_BUFFER target (see gl:bindBuffer/2 ) while a pixel map is requested, Data is treated as a byte offset into the buffer object's data store.
Unsigned integer values, if requested, are linearly mapped from the internal fixed or floating-point representation such that 1.0 maps to the largest representable integer value, and 0.0 maps to 0. Return unsigned integer values are undefined if the map value was not in the range [0,1].
To determine the required size of Map , call gl:getBooleanv/1 with the appropriate symbolic constant.
See external documentation.
getPixelMapuiv(Map, Values) -> ok
Types:
See getPixelMapfv/2
getPixelMapusv(Map, Values) -> ok
Types:
See getPixelMapfv/2
bitmap(Width, Height, Xorig, Yorig, Xmove, Ymove, Bitmap) -> ok
Types:
Draw a bitmap
A bitmap is a binary image. When drawn, the bitmap is positioned relative to the current raster position, and frame buffer pixels corresponding to 1's in the bitmap are written using the current raster color or index. Frame buffer pixels corresponding to 0's in the bitmap are not modified.
gl:bitmap takes seven arguments. The first pair specifies the width and height of the bitmap image. The second pair specifies the location of the bitmap origin relative to the lower left corner of the bitmap image. The third pair of arguments specifies x and y offsets to be added to the current raster position after the bitmap has been drawn. The final argument is a pointer to the bitmap image itself.
If a non-zero named buffer object is bound to the ?GL_PIXEL_UNPACK_BUFFER target (see gl:bindBuffer/2 ) while a bitmap image is specified, Bitmap is treated as a byte offset into the buffer object's data store.
The bitmap image is interpreted like image data for the gl:drawPixels/5 command, with Width and Height corresponding to the width and height arguments of that command, and with type set to ?GL_BITMAP and format set to ?GL_COLOR_INDEX . Modes specified using gl:pixelStoref/2 affect the interpretation of bitmap image data; modes specified using gl:pixelTransferf/2 do not.
If the current raster position is invalid, gl:bitmap is ignored. Otherwise, the lower left corner of the bitmap image is positioned at the window coordinates
x w=|x r-x o|
y w=|y r-y o|
where (x r y r) is the raster position and (x o y o) is the bitmap origin. Fragments are then generated for each pixel corresponding to a 1 (one) in the bitmap image. These fragments are generated using the current raster z coordinate, color or color index, and current raster texture coordinates. They are then treated just as if they had been generated by a point, line, or polygon, including texture mapping, fogging, and all per-fragment operations such as alpha and depth testing.
After the bitmap has been drawn, the x and y coordinates of the current raster position are offset by Xmove and Ymove . No change is made to the z coordinate of the current raster position, or to the current raster color, texture coordinates, or index.
See external documentation.
readPixels(X, Y, Width, Height, Format, Type, Pixels) -> ok
Types:
Read a block of pixels from the frame buffer
gl:readPixels returns pixel data from the frame buffer, starting with the pixel whose lower left corner is at location ( X , Y ), into client memory starting at location Data . Several parameters control the processing of the pixel data before it is placed into client memory. These parameters are set with gl:pixelStoref/2 . This reference page describes the effects on gl:readPixels of most, but not all of the parameters specified by these three commands.
If a non-zero named buffer object is bound to the ?GL_PIXEL_PACK_BUFFER target (see gl:bindBuffer/2 ) while a block of pixels is requested, Data is treated as a byte offset into the buffer object's data store rather than a pointer to client memory.
gl:readPixels returns values from each pixel with lower left corner at (x+i y+j) for 0<= i< width and 0<= j< height. This pixel is said to be the ith pixel in the jth row. Pixels are returned in row order from the lowest to the highest row, left to right in each row.
Format specifies the format for the returned pixel values; accepted values are:
?GL_STENCIL_INDEX: Stencil values are read from the stencil buffer. Each index is converted to fixed point, shifted left or right depending on the value and sign of ?GL_INDEX_SHIFT , and added to ?GL_INDEX_OFFSET. If ?GL_MAP_STENCIL is ?GL_TRUE, indices are replaced by their mappings in the table ?GL_PIXEL_MAP_S_TO_S.
?GL_DEPTH_COMPONENT: Depth values are read from the depth buffer. Each component is converted to floating point such that the minimum depth value maps to 0 and the maximum value maps to 1. Each component is then multiplied by ?GL_DEPTH_SCALE, added to ?GL_DEPTH_BIAS , and finally clamped to the range [0 1].
?GL_DEPTH_STENCIL: Values are taken from both the depth and stencil buffers. The Type parameter must be ?GL_UNSIGNED_INT_24_8 or ?GL_FLOAT_32_UNSIGNED_INT_24_8_REV .
?GL_RED
?GL_GREEN
?GL_BLUE
?GL_RGB
?GL_BGR
?GL_RGBA
?GL_BGRA: Finally, the indices or components are converted to the proper format, as specified by Type . If Format is ?GL_STENCIL_INDEX and Type is not ?GL_FLOAT, each index is masked with the mask value given in the following table. If Type is ?GL_FLOAT, then each integer index is converted to single-precision floating-point format.
If Format is ?GL_RED, ?GL_GREEN, ?GL_BLUE, ?GL_RGB, ?GL_BGR , ?GL_RGBA, or ?GL_BGRA and Type is not ?GL_FLOAT, each component is multiplied by the multiplier shown in the following table. If type is ?GL_FLOAT, then each component is passed as is (or converted to the client's single-precision floating-point format if it is different from the one used by the GL).
Type Index MaskComponent Conversion?GL_UNSIGNED_BYTE 2 8-1(2 8-1) c
?GL_BYTE 2 7-1((2 8-1) c-1)/2
?GL_UNSIGNED_SHORT 2 16-1(2 16-1) c
?GL_SHORT 2 15-1((2 16-1) c-1)/2
?GL_UNSIGNED_INT 2 32-1(2 32-1) c
?GL_INT 2 31-1((2 32-1) c-1)/2
?GL_HALF_FLOAT none c
?GL_FLOAT none c
?GL_UNSIGNED_BYTE_3_3_2 2 N-1(2 N-1) c
?GL_UNSIGNED_BYTE_2_3_3_REV 2 N-1(2 N-1) c
?GL_UNSIGNED_SHORT_5_6_5 2 N-1 (2 N-1) c
?GL_UNSIGNED_SHORT_5_6_5_REV 2 N-1(2 N-1) c
?GL_UNSIGNED_SHORT_4_4_4_4 2 N-1(2 N-1) c
?GL_UNSIGNED_SHORT_4_4_4_4_REV 2 N-1(2 N-1) c
?GL_UNSIGNED_SHORT_5_5_5_1 2 N-1(2 N-1) c
?GL_UNSIGNED_SHORT_1_5_5_5_REV 2 N-1 (2 N-1) c
?GL_UNSIGNED_INT_8_8_8_8 2 N-1(2 N-1) c
?GL_UNSIGNED_INT_8_8_8_8_REV 2 N-1(2 N-1) c
?GL_UNSIGNED_INT_10_10_10_2 2 N-1(2 N-1) c
?GL_UNSIGNED_INT_2_10_10_10_REV 2 N-1(2 N-1) c
?GL_UNSIGNED_INT_24_8 2 N-1(2 N-1) c
?GL_UNSIGNED_INT_10F_11F_11F_REV -- Special
?GL_UNSIGNED_INT_5_9_9_9_REV -- Special
?GL_FLOAT_32_UNSIGNED_INT_24_8_REV none c (Depth Only)
Return values are placed in memory as follows. If Format is ?GL_STENCIL_INDEX , ?GL_DEPTH_COMPONENT, ?GL_RED, ?GL_GREEN, or ?GL_BLUE, a single value is returned and the data for the ith pixel in the jth row is placed in location (j) width+i. ?GL_RGB and ?GL_BGR return three values, ?GL_RGBA and ?GL_BGRA return four values for each pixel, with all values corresponding to a single pixel occupying contiguous space in Data . Storage parameters set by gl:pixelStoref/2 , such as ?GL_PACK_LSB_FIRST and ?GL_PACK_SWAP_BYTES, affect the way that data is written into memory. See gl:pixelStoref/2 for a description.
See external documentation.
drawPixels(Width, Height, Format, Type, Pixels) -> ok
Types:
Write a block of pixels to the frame buffer
gl:drawPixels reads pixel data from memory and writes it into the frame buffer relative to the current raster position, provided that the raster position is valid. Use gl:rasterPos2d/2 or gl:windowPos2d/2 to set the current raster position; use gl:getBooleanv/1 with argument ?GL_CURRENT_RASTER_POSITION_VALID to determine if the specified raster position is valid, and gl:getBooleanv/1 with argument ?GL_CURRENT_RASTER_POSITION to query the raster position.
Several parameters define the encoding of pixel data in memory and control the processing of the pixel data before it is placed in the frame buffer. These parameters are set with four commands: gl:pixelStoref/2 , gl:pixelTransferf/2 , gl:pixelMapfv/3 , and gl:pixelZoom/2 . This reference page describes the effects on gl:drawPixels of many, but not all, of the parameters specified by these four commands.
Data is read from Data as a sequence of signed or unsigned bytes, signed or unsigned shorts, signed or unsigned integers, or single-precision floating-point values, depending on Type . When Type is one of ?GL_UNSIGNED_BYTE, ?GL_BYTE, ?GL_UNSIGNED_SHORT , ?GL_SHORT, ?GL_UNSIGNED_INT, ?GL_INT, or ?GL_FLOAT each of these bytes, shorts, integers, or floating-point values is interpreted as one color or depth component, or one index, depending on Format . When Type is one of ?GL_UNSIGNED_BYTE_3_3_2 , ?GL_UNSIGNED_SHORT_5_6_5, ?GL_UNSIGNED_SHORT_4_4_4_4, ?GL_UNSIGNED_SHORT_5_5_5_1 , ?GL_UNSIGNED_INT_8_8_8_8, or ?GL_UNSIGNED_INT_10_10_10_2, each unsigned value is interpreted as containing all the components for a single pixel, with the color components arranged according to Format . When Type is one of ?GL_UNSIGNED_BYTE_2_3_3_REV , ?GL_UNSIGNED_SHORT_5_6_5_REV, ?GL_UNSIGNED_SHORT_4_4_4_4_REV, ?GL_UNSIGNED_SHORT_1_5_5_5_REV , ?GL_UNSIGNED_INT_8_8_8_8_REV, or ?GL_UNSIGNED_INT_2_10_10_10_REV, each unsigned value is interpreted as containing all color components, specified by Format , for a single pixel in a reversed order. Indices are always treated individually. Color components are treated as groups of one, two, three, or four values, again based on Format . Both individual indices and groups of components are referred to as pixels. If Type is ?GL_BITMAP, the data must be unsigned bytes, and Format must be either ?GL_COLOR_INDEX or ?GL_STENCIL_INDEX. Each unsigned byte is treated as eight 1-bit pixels, with bit ordering determined by ?GL_UNPACK_LSB_FIRST (see gl:pixelStoref/2 ).
width×height pixels are read from memory, starting at location Data . By default, these pixels are taken from adjacent memory locations, except that after all Width pixels are read, the read pointer is advanced to the next four-byte boundary. The four-byte row alignment is specified by gl:pixelStoref/2 with argument ?GL_UNPACK_ALIGNMENT , and it can be set to one, two, four, or eight bytes. Other pixel store parameters specify different read pointer advancements, both before the first pixel is read and after all Width pixels are read. See the gl:pixelStoref/2 reference page for details on these options.
If a non-zero named buffer object is bound to the ?GL_PIXEL_UNPACK_BUFFER target (see gl:bindBuffer/2 ) while a block of pixels is specified, Data is treated as a byte offset into the buffer object's data store.
The width×height pixels that are read from memory are each operated on in the same way, based on the values of several parameters specified by gl:pixelTransferf/2 and gl:pixelMapfv/3 . The details of these operations, as well as the target buffer into which the pixels are drawn, are specific to the format of the pixels, as specified by Format . Format can assume one of 13 symbolic values:
?GL_COLOR_INDEX: Each pixel is a single value, a color index. It is converted to fixed-point format, with an unspecified number of bits to the right of the binary point, regardless of the memory data type. Floating-point values convert to true fixed-point values. Signed and unsigned integer data is converted with all fraction bits set to 0. Bitmap data convert to either 0 or 1.
Each fixed-point index is then shifted left by ?GL_INDEX_SHIFT bits and added to ?GL_INDEX_OFFSET . If ?GL_INDEX_SHIFT is negative, the shift is to the right. In either case, zero bits fill otherwise unspecified bit locations in the result.
If the GL is in RGBA mode, the resulting index is converted to an RGBA pixel with the help of the ?GL_PIXEL_MAP_I_TO_R, ?GL_PIXEL_MAP_I_TO_G, ?GL_PIXEL_MAP_I_TO_B , and ?GL_PIXEL_MAP_I_TO_A tables. If the GL is in color index mode, and if ?GL_MAP_COLOR is true, the index is replaced with the value that it references in lookup table ?GL_PIXEL_MAP_I_TO_I . Whether the lookup replacement of the index is done or not, the integer part of the index is then ANDed with 2 b-1, where b is the number of bits in a color index buffer.
The GL then converts the resulting indices or RGBA colors to fragments by attaching the current raster position z coordinate and texture coordinates to each pixel, then assigning x and y window coordinates to the nth fragment such that x n=x r+n% width
y n=y r+|n/width|
where (x r y r) is the current raster position. These pixel fragments are then treated just like the fragments generated by rasterizing points, lines, or polygons. Texture mapping, fog, and all the fragment operations are applied before the fragments are written to the frame buffer.
?GL_STENCIL_INDEX: Each pixel is a single value, a stencil index. It is converted to fixed-point format, with an unspecified number of bits to the right of the binary point, regardless of the memory data type. Floating-point values convert to true fixed-point values. Signed and unsigned integer data is converted with all fraction bits set to 0. Bitmap data convert to either 0 or 1.
Each fixed-point index is then shifted left by ?GL_INDEX_SHIFT bits, and added to ?GL_INDEX_OFFSET. If ?GL_INDEX_SHIFT is negative, the shift is to the right. In either case, zero bits fill otherwise unspecified bit locations in the result. If ?GL_MAP_STENCIL is true, the index is replaced with the value that it references in lookup table ?GL_PIXEL_MAP_S_TO_S. Whether the lookup replacement of the index is done or not, the integer part of the index is then ANDed with 2 b-1, where b is the number of bits in the stencil buffer. The resulting stencil indices are then written to the stencil buffer such that the nth index is written to location
x n=x r+n% width
y n=y r+|n/width|
where (x r y r) is the current raster position. Only the pixel ownership test, the scissor test, and the stencil writemask affect these write operations.
?GL_DEPTH_COMPONENT: Each pixel is a single-depth component. Floating-point data is converted directly to an internal floating-point format with unspecified precision. Signed integer data is mapped linearly to the internal floating-point format such that the most positive representable integer value maps to 1.0, and the most negative representable value maps to -1.0. Unsigned integer data is mapped similarly: the largest integer value maps to 1.0, and 0 maps to 0.0. The resulting floating-point depth value is then multiplied by ?GL_DEPTH_SCALE and added to ?GL_DEPTH_BIAS. The result is clamped to the range [0 1].
The GL then converts the resulting depth components to fragments by attaching the current raster position color or color index and texture coordinates to each pixel, then assigning x and y window coordinates to the nth fragment such that
x n=x r+n% width
y n=y r+|n/width|
where (x r y r) is the current raster position. These pixel fragments are then treated just like the fragments generated by rasterizing points, lines, or polygons. Texture mapping, fog, and all the fragment operations are applied before the fragments are written to the frame buffer.
?GL_RGBA
?GL_BGRA: Each pixel is a four-component group: For ?GL_RGBA, the red component is first, followed by green, followed by blue, followed by alpha; for ?GL_BGRA the order is blue, green, red and then alpha. Floating-point values are converted directly to an internal floating-point format with unspecified precision. Signed integer values are mapped linearly to the internal floating-point format such that the most positive representable integer 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.) Unsigned integer data is mapped similarly: The largest integer value maps to 1.0, and 0 maps to 0.0. The resulting floating-point color values are then multiplied by ?GL_c_SCALE and added to ?GL_c_BIAS, where c is RED, GREEN, BLUE, and ALPHA for the respective color components. The results are clamped to the range [0 1].
If ?GL_MAP_COLOR is true, each color component is scaled by the size of lookup table ?GL_PIXEL_MAP_c_TO_c, then replaced by the value that it references in that table. c is R, G, B, or A respectively.
The GL then converts the resulting RGBA colors to fragments by attaching the current raster position z coordinate and texture coordinates to each pixel, then assigning x and y window coordinates to the nth fragment such that
x n=x r+n% width
y n=y r+|n/width|
where (x r y r) is the current raster position. These pixel fragments are then treated just like the fragments generated by rasterizing points, lines, or polygons. Texture mapping, fog, and all the fragment operations are applied before the fragments are written to the frame buffer.
?GL_RED: Each pixel is a single red component. This component is converted to the internal floating-point format in the same way the red component of an RGBA pixel is. It is then converted to an RGBA pixel with green and blue set to 0, and alpha set to 1. After this conversion, the pixel is treated as if it had been read as an RGBA pixel.
?GL_GREEN: Each pixel is a single green component. This component is converted to the internal floating-point format in the same way the green component of an RGBA pixel is. It is then converted to an RGBA pixel with red and blue set to 0, and alpha set to 1. After this conversion, the pixel is treated as if it had been read as an RGBA pixel.
?GL_BLUE: Each pixel is a single blue component. This component is converted to the internal floating-point format in the same way the blue component of an RGBA pixel is. It is then converted to an RGBA pixel with red and green set to 0, and alpha set to 1. After this conversion, the pixel is treated as if it had been read as an RGBA pixel.
?GL_ALPHA: Each pixel is a single alpha component. This component is converted to the internal floating-point format in the same way the alpha component of an RGBA pixel is. It is then converted to an RGBA pixel with red, green, and blue set to 0. After this conversion, the pixel is treated as if it had been read as an RGBA pixel.
?GL_RGB
?GL_BGR: Each pixel is a three-component group: red first, followed by green, followed by blue; for ?GL_BGR, the first component is blue, followed by green and then red. Each component is converted to the internal floating-point format in the same way the red, green, and blue components of an RGBA pixel are. The color triple is converted to an RGBA pixel with alpha set to 1. After this conversion, the pixel is treated as if it had been read as an RGBA pixel.
?GL_LUMINANCE: Each pixel is a single luminance component. This component is converted to the internal floating-point format in the same way the red component of an RGBA pixel is. It is then converted to an RGBA pixel with red, green, and blue set to the converted luminance value, and alpha set to 1. After this conversion, the pixel is treated as if it had been read as an RGBA pixel.
?GL_LUMINANCE_ALPHA: Each pixel is a two-component group: luminance first, followed by alpha. The two components are converted to the internal floating-point format in the same way the red component of an RGBA pixel is. They are then converted to an RGBA pixel with red, green, and blue set to the converted luminance value, and alpha set to the converted alpha value. After this conversion, the pixel is treated as if it had been read as an RGBA pixel.
The following table summarizes the meaning of the valid constants for the type parameter:
TypeCorresponding Type?GL_UNSIGNED_BYTE unsigned 8-bit integer
?GL_BYTE signed 8-bit integer
?GL_BITMAP single bits in unsigned 8-bit integers
?GL_UNSIGNED_SHORT unsigned 16-bit integer
?GL_SHORT signed 16-bit integer
?GL_UNSIGNED_INT unsigned 32-bit integer
?GL_INT 32-bit integer
?GL_FLOAT single-precision floating-point
?GL_UNSIGNED_BYTE_3_3_2 unsigned 8-bit integer
?GL_UNSIGNED_BYTE_2_3_3_REV unsigned 8-bit integer with reversed component ordering
?GL_UNSIGNED_SHORT_5_6_5 unsigned 16-bit integer
?GL_UNSIGNED_SHORT_5_6_5_REV unsigned 16-bit integer with reversed component ordering
?GL_UNSIGNED_SHORT_4_4_4_4 unsigned 16-bit integer
?GL_UNSIGNED_SHORT_4_4_4_4_REV unsigned 16-bit integer with reversed component ordering
?GL_UNSIGNED_SHORT_5_5_5_1 unsigned 16-bit integer
?GL_UNSIGNED_SHORT_1_5_5_5_REV unsigned 16-bit integer with reversed component ordering
?GL_UNSIGNED_INT_8_8_8_8 unsigned 32-bit integer
?GL_UNSIGNED_INT_8_8_8_8_REV unsigned 32-bit integer with reversed component ordering
?GL_UNSIGNED_INT_10_10_10_2 unsigned 32-bit integer
?GL_UNSIGNED_INT_2_10_10_10_REV unsigned 32-bit integer with reversed component ordering
The rasterization described so far assumes pixel zoom factors of 1. If gl:pixelZoom/2 is used to change the x and y pixel zoom factors, pixels are converted to fragments as follows. If (x r y r) is the current raster position, and a given pixel is in the nth column and mth row of the pixel rectangle, then fragments are generated for pixels whose centers are in the rectangle with corners at
(x r+(zoom x) n y r+(zoom y) m)
(x r+(zoom x)(n+1) y r+(zoom y)(m+1))
where zoom x is the value of ?GL_ZOOM_X and zoom y is the value of ?GL_ZOOM_Y .
See external documentation.
copyPixels(X, Y, Width, Height, Type) -> ok
Types:
Copy pixels in the frame buffer
gl:copyPixels copies a screen-aligned rectangle of pixels from the specified frame buffer location to a region relative to the current raster position. Its operation is well defined only if the entire pixel source region is within the exposed portion of the window. Results of copies from outside the window, or from regions of the window that are not exposed, are hardware dependent and undefined.
X and Y specify the window coordinates of the lower left corner of the rectangular region to be copied. Width and Height specify the dimensions of the rectangular region to be copied. Both Width and Height must not be negative.
Several parameters control the processing of the pixel data while it is being copied. These parameters are set with three commands: gl:pixelTransferf/2 , gl:pixelMapfv/3 , and gl:pixelZoom/2 . This reference page describes the effects on gl:copyPixels of most, but not all, of the parameters specified by these three commands.
gl:copyPixels copies values from each pixel with the lower left-hand corner at (x+i y+j) for 0<= i< width and 0<= j< height. This pixel is said to be the ith pixel in the jth row. Pixels are copied in row order from the lowest to the highest row, left to right in each row.
Type specifies whether color, depth, or stencil data is to be copied. The details of the transfer for each data type are as follows:
?GL_COLOR: Indices or RGBA colors are read from the buffer currently specified as the read source buffer (see gl:readBuffer/1 ). If the GL is in color index mode, each index that is read from this buffer is converted to a fixed-point format with an unspecified number of bits to the right of the binary point. Each index is then shifted left by ?GL_INDEX_SHIFT bits, and added to ?GL_INDEX_OFFSET. If ?GL_INDEX_SHIFT is negative, the shift is to the right. In either case, zero bits fill otherwise unspecified bit locations in the result. If ?GL_MAP_COLOR is true, the index is replaced with the value that it references in lookup table ?GL_PIXEL_MAP_I_TO_I. Whether the lookup replacement of the index is done or not, the integer part of the index is then ANDed with 2 b-1, where b is the number of bits in a color index buffer.
If the GL is in RGBA mode, the red, green, blue, and alpha components of each pixel that is read are converted to an internal floating-point format with unspecified precision. The conversion maps the largest representable component value to 1.0, and component value 0 to 0.0. The resulting floating-point color values are then multiplied by ?GL_c_SCALE and added to ?GL_c_BIAS, where c is RED, GREEN, BLUE, and ALPHA for the respective color components. The results are clamped to the range [0,1]. If ?GL_MAP_COLOR is true, each color component is scaled by the size of lookup table ?GL_PIXEL_MAP_c_TO_c , then replaced by the value that it references in that table. c is R, G, B, or A.
If the ARB_imaging extension is supported, the color values may be additionally processed by color-table lookups, color-matrix transformations, and convolution filters.
The GL then converts the resulting indices or RGBA colors to fragments by attaching the current raster position z coordinate and texture coordinates to each pixel, then assigning window coordinates (x r+i y r+j), where (x r y r) is the current raster position, and the pixel was the ith pixel in the jth row. These pixel fragments are then treated just like the fragments generated by rasterizing points, lines, or polygons. Texture mapping, fog, and all the fragment operations are applied before the fragments are written to the frame buffer.
?GL_DEPTH: Depth values are read from the depth buffer and converted directly to an internal floating-point format with unspecified precision. The resulting floating-point depth value is then multiplied by ?GL_DEPTH_SCALE and added to ?GL_DEPTH_BIAS . The result is clamped to the range [0,1].
The GL then converts the resulting depth components to fragments by attaching the current raster position color or color index and texture coordinates to each pixel, then assigning window coordinates (x r+i y r+j), where (x r y r) is the current raster position, and the pixel was the ith pixel in the jth row. These pixel fragments are then treated just like the fragments generated by rasterizing points, lines, or polygons. Texture mapping, fog, and all the fragment operations are applied before the fragments are written to the frame buffer.
?GL_STENCIL: Stencil indices are read from the stencil buffer and converted to an internal fixed-point format with an unspecified number of bits to the right of the binary point. Each fixed-point index is then shifted left by ?GL_INDEX_SHIFT bits, and added to ?GL_INDEX_OFFSET. If ?GL_INDEX_SHIFT is negative, the shift is to the right. In either case, zero bits fill otherwise unspecified bit locations in the result. If ?GL_MAP_STENCIL is true, the index is replaced with the value that it references in lookup table ?GL_PIXEL_MAP_S_TO_S. Whether the lookup replacement of the index is done or not, the integer part of the index is then ANDed with 2 b-1, where b is the number of bits in the stencil buffer. The resulting stencil indices are then written to the stencil buffer such that the index read from the ith location of the jth row is written to location (x r+i y r+j), where (x r y r) is the current raster position. Only the pixel ownership test, the scissor test, and the stencil writemask affect these write operations.
The rasterization described thus far assumes pixel zoom factors of 1.0. If gl:pixelZoom/2 is used to change the x and y pixel zoom factors, pixels are converted to fragments as follows. If (x r y r) is the current raster position, and a given pixel is in the ith location in the jth row of the source pixel rectangle, then fragments are generated for pixels whose centers are in the rectangle with corners at
(x r+(zoom x) i y r+(zoom y) j)
and
(x r+(zoom x)(i+1) y r+(zoom y)(j+1))
where zoom x is the value of ?GL_ZOOM_X and zoom y is the value of ?GL_ZOOM_Y .
See external documentation.
stencilFunc(Func, Ref, Mask) -> ok
Types:
Set front and back function and reference value for stencil testing
Stenciling, like depth-buffering, enables and disables drawing on a per-pixel basis. Stencil planes are first drawn into using GL drawing primitives, then geometry and images are rendered using the stencil planes to mask out portions of the screen. Stenciling is typically used in multipass rendering algorithms to achieve special effects, such as decals, outlining, and constructive solid geometry rendering.
The stencil test conditionally eliminates a pixel based on the outcome of a comparison between the reference value and the value in the stencil buffer. To enable and disable the test, call gl:enable/1 and gl:enable/1 with argument ?GL_STENCIL_TEST . To specify actions based on the outcome of the stencil test, call gl:stencilOp/3 or gl:stencilOpSeparate/4 .
There can be two separate sets of Func , Ref , and Mask parameters; one affects back-facing polygons, and the other affects front-facing polygons as well as other non-polygon primitives. gl:stencilFunc/3 sets both front and back stencil state to the same values. Use gl:stencilFuncSeparate/4 to set front and back stencil state to different values.
Func is a symbolic constant that determines the stencil comparison function. It accepts one of eight values, shown in the following list. Ref is an integer reference value that is used in the stencil comparison. It is clamped to the range [0 2 n-1], where n is the number of bitplanes in the stencil buffer. Mask is bitwise ANDed with both the reference value and the stored stencil value, with the ANDed values participating in the comparison.
If stencil represents the value stored in the corresponding stencil buffer location, the following list shows the effect of each comparison function that can be specified by Func . Only if the comparison succeeds is the pixel passed through to the next stage in the rasterization process (see gl:stencilOp/3 ). All tests treat stencil values as unsigned integers in the range [0 2 n-1], where n is the number of bitplanes in the stencil buffer.
The following values are accepted by Func :
?GL_NEVER: Always fails.
?GL_LESS: Passes if ( Ref & Mask ) < ( stencil & Mask ).
?GL_LEQUAL: Passes if ( Ref & Mask ) <= ( stencil & Mask ).
?GL_GREATER: Passes if ( Ref & Mask ) > ( stencil & Mask ).
?GL_GEQUAL: Passes if ( Ref & Mask ) >= ( stencil & Mask ).
?GL_EQUAL: Passes if ( Ref & Mask ) = ( stencil & Mask ).
?GL_NOTEQUAL: Passes if ( Ref & Mask ) != ( stencil & Mask ).
?GL_ALWAYS: Always passes.
See external documentation.
Types:
Control the front and back writing of individual bits in the stencil planes
gl:stencilMask controls the writing of individual bits in the stencil planes. The least significant n bits of Mask , where n is the number of bits in the stencil buffer, specify a mask. Where a 1 appears in the mask, it's possible to write to the corresponding bit in the stencil buffer. Where a 0 appears, the corresponding bit is write-protected. Initially, all bits are enabled for writing.
There can be two separate Mask writemasks; one affects back-facing polygons, and the other affects front-facing polygons as well as other non-polygon primitives. gl:stencilMask/1 sets both front and back stencil writemasks to the same values. Use gl:stencilMaskSeparate/2 to set front and back stencil writemasks to different values.
See external documentation.
stencilOp(Fail, Zfail, Zpass) -> ok
Types:
Set front and back stencil test actions
Stenciling, like depth-buffering, enables and disables drawing on a per-pixel basis. You draw into the stencil planes using GL drawing primitives, then render geometry and images, using the stencil planes to mask out portions of the screen. Stenciling is typically used in multipass rendering algorithms to achieve special effects, such as decals, outlining, and constructive solid geometry rendering.
The stencil test conditionally eliminates a pixel based on the outcome of a comparison between the value in the stencil buffer and a reference value. To enable and disable the test, call gl:enable/1 and gl:enable/1 with argument ?GL_STENCIL_TEST ; to control it, call gl:stencilFunc/3 or gl:stencilFuncSeparate/4 .
There can be two separate sets of Sfail , Dpfail , and Dppass parameters; one affects back-facing polygons, and the other affects front-facing polygons as well as other non-polygon primitives. gl:stencilOp/3 sets both front and back stencil state to the same values. Use gl:stencilOpSeparate/4 to set front and back stencil state to different values.
gl:stencilOp takes three arguments that indicate what happens to the stored stencil value while stenciling is enabled. If the stencil test fails, no change is made to the pixel's color or depth buffers, and Sfail specifies what happens to the stencil buffer contents. The following eight actions are possible.
?GL_KEEP: Keeps the current value.
?GL_ZERO: Sets the stencil buffer value to 0.
?GL_REPLACE: Sets the stencil buffer value to ref, as specified by gl:stencilFunc/3 .
?GL_INCR: Increments the current stencil buffer value. Clamps to the maximum representable unsigned value.
?GL_INCR_WRAP: Increments the current stencil buffer value. Wraps stencil buffer value to zero when incrementing the maximum representable unsigned value.
?GL_DECR: Decrements the current stencil buffer value. Clamps to 0.
?GL_DECR_WRAP: Decrements the current stencil buffer value. Wraps stencil buffer value to the maximum representable unsigned value when decrementing a stencil buffer value of zero.
?GL_INVERT: Bitwise inverts the current stencil buffer value.
Stencil buffer values are treated as unsigned integers. When incremented and decremented, values are clamped to 0 and 2 n-1, where n is the value returned by querying ?GL_STENCIL_BITS .
The other two arguments to gl:stencilOp specify stencil buffer actions that depend on whether subsequent depth buffer tests succeed ( Dppass ) or fail ( Dpfail ) (see gl:depthFunc/1 ). The actions are specified using the same eight symbolic constants as Sfail . Note that Dpfail is ignored when there is no depth buffer, or when the depth buffer is not enabled. In these cases, Sfail and Dppass specify stencil action when the stencil test fails and passes, respectively.
See external documentation.
Types:
Specify the clear value for the stencil buffer
gl:clearStencil specifies the index used by gl:clear/1 to clear the stencil buffer. S is masked with 2 m-1, where m is the number of bits in the stencil buffer.
See external documentation.
texGend(Coord, Pname, Param) -> ok
Types:
Control the generation of texture coordinates
gl:texGen selects a texture-coordinate generation function or supplies coefficients for one of the functions. Coord names one of the (s, t, r, q ) texture coordinates; it must be one of the symbols ?GL_S, ?GL_T, ?GL_R , or ?GL_Q. Pname must be one of three symbolic constants: ?GL_TEXTURE_GEN_MODE , ?GL_OBJECT_PLANE, or ?GL_EYE_PLANE. If Pname is ?GL_TEXTURE_GEN_MODE , then Params chooses a mode, one of ?GL_OBJECT_LINEAR, ?GL_EYE_LINEAR , ?GL_SPHERE_MAP, ?GL_NORMAL_MAP, or ?GL_REFLECTION_MAP. If Pname is either ?GL_OBJECT_PLANE or ?GL_EYE_PLANE, Params contains coefficients for the corresponding texture generation function.
If the texture generation function is ?GL_OBJECT_LINEAR, the function
g=p 1×x o+p 2×y o+p 3×z o+p 4×w o
is used, where g is the value computed for the coordinate named in Coord , p 1, p 2, p 3, and p 4 are the four values supplied in Params , and x o, y o, z o, and w o are the object coordinates of the vertex. This function can be used, for example, to texture-map terrain using sea level as a reference plane (defined by p 1, p 2, p 3, and p 4). The altitude of a terrain vertex is computed by the ?GL_OBJECT_LINEAR coordinate generation function as its distance from sea level; that altitude can then be used to index the texture image to map white snow onto peaks and green grass onto foothills.
If the texture generation function is ?GL_EYE_LINEAR, the function
g=(p 1)"×x e+(p 2)"×y e+(p 3)"×z e+(p 4)"×w e
is used, where
((p 1)" (p 2)" (p 3)" (p 4)")=(p 1 p 2 p 3 p 4) M -1
and x e, y e, z e, and w e are the eye coordinates of the vertex, p 1, p 2, p 3, and p 4 are the values supplied in Params , and M is the modelview matrix when gl:texGen is invoked. If M is poorly conditioned or singular, texture coordinates generated by the resulting function may be inaccurate or undefined.
Note that the values in Params define a reference plane in eye coordinates. The modelview matrix that is applied to them may not be the same one in effect when the polygon vertices are transformed. This function establishes a field of texture coordinates that can produce dynamic contour lines on moving objects.
If the texture generation function is ?GL_SPHERE_MAP and Coord is either ?GL_S or ?GL_T, s and t texture coordinates are generated as follows. Let u be the unit vector pointing from the origin to the polygon vertex (in eye coordinates). Let n sup prime be the current normal, after transformation to eye coordinates. Let
f=(f x f y f z) T be the reflection vector such that
f=u-2 n" (n") T u
Finally, let m=2 ((f x) 2+(f y) 2+(f z+1) 2). Then the values assigned to the s and t texture coordinates are
s=f x/m+1/2
t=f y/m+1/2
To enable or disable a texture-coordinate generation function, call gl:enable/1 or gl:enable/1 with one of the symbolic texture-coordinate names (?GL_TEXTURE_GEN_S , ?GL_TEXTURE_GEN_T, ?GL_TEXTURE_GEN_R, or ?GL_TEXTURE_GEN_Q) as the argument. When enabled, the specified texture coordinate is computed according to the generating function associated with that coordinate. When disabled, subsequent vertices take the specified texture coordinate from the current set of texture coordinates. Initially, all texture generation functions are set to ?GL_EYE_LINEAR and are disabled. Both s plane equations are (1, 0, 0, 0), both t plane equations are (0, 1, 0, 0), and all r and q plane equations are (0, 0, 0, 0).
When the ARB_multitexture extension is supported, gl:texGen sets the texture generation parameters for the currently active texture unit, selected with gl:activeTexture/1 .
See external documentation.
texGenf(Coord, Pname, Param) -> ok
Types:
See texGend/3
texGeni(Coord, Pname, Param) -> ok
Types:
See texGend/3
texGendv(Coord, Pname, Params) -> ok
Types:
See texGend/3
texGenfv(Coord, Pname, Params) -> ok
Types:
See texGend/3
texGeniv(Coord, Pname, Params) -> ok
Types:
See texGend/3
getTexGendv(Coord, Pname) -> {float(), float(), float(), float()}
Types:
Return texture coordinate generation parameters
gl:getTexGen returns in Params selected parameters of a texture coordinate generation function that was specified using gl:texGend/3 . Coord names one of the (s, t, r, q) texture coordinates, using the symbolic constant ?GL_S, ?GL_T, ?GL_R, or ?GL_Q.
Pname specifies one of three symbolic names:
?GL_TEXTURE_GEN_MODE: Params returns the single-valued texture generation function, a symbolic constant. The initial value is ?GL_EYE_LINEAR.
?GL_OBJECT_PLANE: Params returns the four plane equation coefficients that specify object linear-coordinate generation. Integer values, when requested, are mapped directly from the internal floating-point representation.
?GL_EYE_PLANE: Params returns the four plane equation coefficients that specify eye linear-coordinate generation. Integer values, when requested, are mapped directly from the internal floating-point representation. The returned values are those maintained in eye coordinates. They are not equal to the values specified using gl:texGend/3 , unless the modelview matrix was identity when gl:texGend/3 was called.
See external documentation.
getTexGenfv(Coord, Pname) -> {float(), float(), float(), float()}
Types:
See getTexGendv/2
getTexGeniv(Coord, Pname) -> {integer(), integer(), integer(), integer()}
Types:
See getTexGendv/2
texEnvf(Target, Pname, Param) -> ok
Types:
texEnvi(Target, Pname, Param) -> ok
Types:
texEnvfv(Target, Pname, Params) -> ok
Types:
Set texture environment parameters
A texture environment specifies how texture values are interpreted when a fragment is textured. When Target is ?GL_TEXTURE_FILTER_CONTROL, Pname must be ?GL_TEXTURE_LOD_BIAS . When Target is ?GL_TEXTURE_ENV, Pname can be ?GL_TEXTURE_ENV_MODE , ?GL_TEXTURE_ENV_COLOR, ?GL_COMBINE_RGB, ?GL_COMBINE_ALPHA, ?GL_RGB_SCALE , ?GL_ALPHA_SCALE, ?GL_SRC0_RGB, ?GL_SRC1_RGB, ?GL_SRC2_RGB, ?GL_SRC0_ALPHA , ?GL_SRC1_ALPHA, or ?GL_SRC2_ALPHA.
If Pname is ?GL_TEXTURE_ENV_MODE, then Params is (or points to) the symbolic name of a texture function. Six texture functions may be specified: ?GL_ADD , ?GL_MODULATE, ?GL_DECAL, ?GL_BLEND, ?GL_REPLACE, or ?GL_COMBINE .
The following table shows the correspondence of filtered texture values R t, G t, B t, A t, L t, I t to texture source components. C s and A s are used by the texture functions described below.
Texture Base Internal Format C s A s?GL_ALPHA (0, 0, 0) A t
?GL_LUMINANCE ( L t, L t, L t ) 1
?GL_LUMINANCE_ALPHA ( L t, L t, L t ) A t
?GL_INTENSITY ( I t, I t, I t ) I t
?GL_RGB ( R t, G t, B t ) 1
?GL_RGBA ( R t, G t, B t ) A t
A texture function acts on the fragment to be textured using the texture image value that applies to the fragment (see gl:texParameterf/3 ) and produces an RGBA color for that fragment. The following table shows how the RGBA color is produced for each of the first five texture functions that can be chosen. C is a triple of color values (RGB) and A is the associated alpha value. RGBA values extracted from a texture image are in the range [0,1]. The subscript p refers to the color computed from the previous texture stage (or the incoming fragment if processing texture stage 0), the subscript s to the texture source color, the subscript c to the texture environment color, and the subscript v indicates a value produced by the texture function.
Texture Base Internal Format ?Value?GL_REPLACE Function ?GL_MODULATE Function ?GL_DECAL Function ?GL_BLEND Function ?GL_ADD Function?GL_ALPHA C v= C p C p undefined C p C p
A v= A s A p A s A v=A p A s A p A s
?GL_LUMINANCE C v= C s C p C s undefined C p (1-C s)+C c C s C p+C s
(or 1) A v= A p A p A p A p
?GL_LUMINANCE_ALPHA C v= C s C p C s undefined C p (1-C s)+C c C s C p+C s
(or 2) A v= A s A p A s A p A s A p A s
?GL_INTENSITY C v= C s C p C s undefined C p (1-C s)+C c C s C p+C s
A v= A s A p A s A p (1-A s)+A c A s A p+A s
?GL_RGB C v= C s C p C s C s C p (1-C s)+C c C s C p+C s
(or 3) A v= A p A p A p A p A p
?GL_RGBA C v= C s C p C s C p (1-A s)+C s A s C p (1-C s)+C c C s C p+C s
(or 4) A v= A s A p A s A p A p A s A p A s
If Pname is ?GL_TEXTURE_ENV_MODE, and Params is ?GL_COMBINE, the form of the texture function depends on the values of ?GL_COMBINE_RGB and ?GL_COMBINE_ALPHA .
The following describes how the texture sources, as specified by ?GL_SRC0_RGB, ?GL_SRC1_RGB , ?GL_SRC2_RGB, ?GL_SRC0_ALPHA, ?GL_SRC1_ALPHA, and ?GL_SRC2_ALPHA , are combined to produce a final texture color. In the following tables, ?GL_SRC0_c is represented by Arg0, ?GL_SRC1_c is represented by Arg1, and ?GL_SRC2_c is represented by Arg2.
?GL_COMBINE_RGB accepts any of ?GL_REPLACE, ?GL_MODULATE, ?GL_ADD , ?GL_ADD_SIGNED, ?GL_INTERPOLATE, ?GL_SUBTRACT, ?GL_DOT3_RGB, or ?GL_DOT3_RGBA.
?GL_COMBINE_RGBTexture Function?GL_REPLACE Arg0
?GL_MODULATE Arg0×Arg1
?GL_ADD Arg0+Arg1
?GL_ADD_SIGNED Arg0+Arg1-0.5
?GL_INTERPOLATE Arg0×Arg2+Arg1×(1- Arg2)
?GL_SUBTRACT Arg0-Arg1
?GL_DOT3_RGB or ?GL_DOT3_RGBA 4×((((Arg0 r)-0.5)×((Arg1 r)-0.5))+(((Arg0 g)-0.5)×((Arg1 g)-0.5))+(((Arg0 b)-0.5)×((Arg1 b)-0.5)))
The scalar results for ?GL_DOT3_RGB and ?GL_DOT3_RGBA are placed into each of the 3 (RGB) or 4 (RGBA) components on output.
Likewise, ?GL_COMBINE_ALPHA accepts any of ?GL_REPLACE, ?GL_MODULATE, ?GL_ADD, ?GL_ADD_SIGNED, ?GL_INTERPOLATE, or ?GL_SUBTRACT. The following table describes how alpha values are combined:
?GL_COMBINE_ALPHATexture Function?GL_REPLACE Arg0
?GL_MODULATE Arg0×Arg1
?GL_ADD Arg0+Arg1
?GL_ADD_SIGNED Arg0+Arg1-0.5
?GL_INTERPOLATE Arg0×Arg2+Arg1×(1- Arg2)
?GL_SUBTRACT Arg0-Arg1
In the following tables, the value C s represents the color sampled from the currently bound texture, C c represents the constant texture-environment color, C f represents the primary color of the incoming fragment, and C p represents the color computed from the previous texture stage or C f if processing texture stage 0. Likewise, A s, A c, A f, and A p represent the respective alpha values.
The following table describes the values assigned to Arg0, Arg1, and Arg2 based upon the RGB sources and operands:
?GL_SRCn_RGB?GL_OPERANDn_RGBArgument Value?GL_TEXTURE?GL_SRC_COLOR(C s)
?GL_ONE_MINUS_SRC_COLOR 1-(C s)
?GL_SRC_ALPHA(A s)
?GL_ONE_MINUS_SRC_ALPHA 1-(A s)
?GL_TEXTUREn?GL_SRC_COLOR(C s)
?GL_ONE_MINUS_SRC_COLOR 1-(C s)
?GL_SRC_ALPHA (A s)
?GL_ONE_MINUS_SRC_ALPHA 1-(A s)
?GL_CONSTANT?GL_SRC_COLOR(C c)
?GL_ONE_MINUS_SRC_COLOR 1-(C c)
?GL_SRC_ALPHA(A c)
?GL_ONE_MINUS_SRC_ALPHA 1-(A c)
?GL_PRIMARY_COLOR ?GL_SRC_COLOR(C f)
?GL_ONE_MINUS_SRC_COLOR 1-(C f)
?GL_SRC_ALPHA(A f)
?GL_ONE_MINUS_SRC_ALPHA 1-(A f)
?GL_PREVIOUS?GL_SRC_COLOR (C p)
?GL_ONE_MINUS_SRC_COLOR 1-(C p)
?GL_SRC_ALPHA(A p)
?GL_ONE_MINUS_SRC_ALPHA 1-(A p)
For ?GL_TEXTUREn sources, C s and A s represent the color and alpha, respectively, produced from texture stage n.
The follow table describes the values assigned to Arg0, Arg1, and Arg2 based upon the alpha sources and operands:
?GL_SRCn_ALPHA?GL_OPERANDn_ALPHAArgument Value?GL_TEXTURE?GL_SRC_ALPHA(A s)
?GL_ONE_MINUS_SRC_ALPHA 1-(A s)
?GL_TEXTUREn ?GL_SRC_ALPHA(A s)
?GL_ONE_MINUS_SRC_ALPHA 1-(A s)
?GL_CONSTANT?GL_SRC_ALPHA(A c)
?GL_ONE_MINUS_SRC_ALPHA 1-(A c)
?GL_PRIMARY_COLOR ?GL_SRC_ALPHA(A f)
?GL_ONE_MINUS_SRC_ALPHA 1-(A f)
?GL_PREVIOUS?GL_SRC_ALPHA(A p)
?GL_ONE_MINUS_SRC_ALPHA 1-(A p)
The RGB and alpha results of the texture function are multipled by the values of ?GL_RGB_SCALE and ?GL_ALPHA_SCALE, respectively, and clamped to the range [0 1].
If Pname is ?GL_TEXTURE_ENV_COLOR, Params is a pointer to an array that holds an RGBA color consisting of four values. Integer color components are interpreted linearly such that the most positive integer maps to 1.0, and the most negative integer maps to -1.0. The values are clamped to the range [0,1] when they are specified. C c takes these four values.
If Pname is ?GL_TEXTURE_LOD_BIAS, the value specified is added to the texture level-of-detail parameter, that selects which mipmap, or mipmaps depending upon the selected ?GL_TEXTURE_MIN_FILTER, will be sampled.
?GL_TEXTURE_ENV_MODE defaults to ?GL_MODULATE and ?GL_TEXTURE_ENV_COLOR defaults to (0, 0, 0, 0).
If Target is ?GL_POINT_SPRITE and Pname is ?GL_COORD_REPLACE, the boolean value specified is used to either enable or disable point sprite texture coordinate replacement. The default value is ?GL_FALSE.
See external documentation.
texEnviv(Target, Pname, Params) -> ok
Types:
See texEnvfv/3
getTexEnvfv(Target, Pname) -> {float(), float(), float(), float()}
Types:
Return texture environment parameters
gl:getTexEnv returns in Params selected values of a texture environment that was specified with gl:texEnvfv/3 . Target specifies a texture environment.
When Target is ?GL_TEXTURE_FILTER_CONTROL, Pname must be ?GL_TEXTURE_LOD_BIAS . When Target is ?GL_POINT_SPRITE, Pname must be ?GL_COORD_REPLACE . When Target is ?GL_TEXTURE_ENV, Pname can be ?GL_TEXTURE_ENV_MODE , ?GL_TEXTURE_ENV_COLOR, ?GL_COMBINE_RGB, ?GL_COMBINE_ALPHA, ?GL_RGB_SCALE , ?GL_ALPHA_SCALE, ?GL_SRC0_RGB, ?GL_SRC1_RGB, ?GL_SRC2_RGB, ?GL_SRC0_ALPHA, ?GL_SRC1_ALPHA, or ?GL_SRC2_ALPHA.
Pname names a specific texture environment parameter, as follows:
?GL_TEXTURE_ENV_MODE: Params returns the single-valued texture environment mode, a symbolic constant. The initial value is ?GL_MODULATE.
?GL_TEXTURE_ENV_COLOR: Params returns four integer or floating-point values that are the texture environment color. Integer values, when requested, are linearly mapped from the internal floating-point representation such that 1.0 maps to the most positive representable integer, and -1.0 maps to the most negative representable integer. The initial value is (0, 0, 0, 0).
?GL_TEXTURE_LOD_BIAS: Params returns a single floating-point value that is the texture level-of-detail bias. The initial value is 0.
?GL_COMBINE_RGB: Params returns a single symbolic constant value representing the current RGB combine mode. The initial value is ?GL_MODULATE.
?GL_COMBINE_ALPHA: Params returns a single symbolic constant value representing the current alpha combine mode. The initial value is ?GL_MODULATE.
?GL_SRC0_RGB: Params returns a single symbolic constant value representing the texture combiner zero's RGB source. The initial value is ?GL_TEXTURE.
?GL_SRC1_RGB: Params returns a single symbolic constant value representing the texture combiner one's RGB source. The initial value is ?GL_PREVIOUS.
?GL_SRC2_RGB: Params returns a single symbolic constant value representing the texture combiner two's RGB source. The initial value is ?GL_CONSTANT.
?GL_SRC0_ALPHA: Params returns a single symbolic constant value representing the texture combiner zero's alpha source. The initial value is ?GL_TEXTURE.
?GL_SRC1_ALPHA: Params returns a single symbolic constant value representing the texture combiner one's alpha source. The initial value is ?GL_PREVIOUS.
?GL_SRC2_ALPHA: Params returns a single symbolic constant value representing the texture combiner two's alpha source. The initial value is ?GL_CONSTANT.
?GL_OPERAND0_RGB: Params returns a single symbolic constant value representing the texture combiner zero's RGB operand. The initial value is ?GL_SRC_COLOR.
?GL_OPERAND1_RGB: Params returns a single symbolic constant value representing the texture combiner one's RGB operand. The initial value is ?GL_SRC_COLOR.
?GL_OPERAND2_RGB: Params returns a single symbolic constant value representing the texture combiner two's RGB operand. The initial value is ?GL_SRC_ALPHA.
?GL_OPERAND0_ALPHA: Params returns a single symbolic constant value representing the texture combiner zero's alpha operand. The initial value is ?GL_SRC_ALPHA.
?GL_OPERAND1_ALPHA: Params returns a single symbolic constant value representing the texture combiner one's alpha operand. The initial value is ?GL_SRC_ALPHA.
?GL_OPERAND2_ALPHA: Params returns a single symbolic constant value representing the texture combiner two's alpha operand. The initial value is ?GL_SRC_ALPHA.
?GL_RGB_SCALE: Params returns a single floating-point value representing the current RGB texture combiner scaling factor. The initial value is 1.0.
?GL_ALPHA_SCALE: Params returns a single floating-point value representing the current alpha texture combiner scaling factor. The initial value is 1.0.
?GL_COORD_REPLACE: Params returns a single boolean value representing the current point sprite texture coordinate replacement enable state. The initial value is ?GL_FALSE .
See external documentation.
getTexEnviv(Target, Pname) -> {integer(), integer(), integer(), integer()}
Types:
See getTexEnvfv/2
texParameterf(Target, Pname, Param) -> ok
Types:
Set texture parameters
gl:texParameter assigns the value or values in Params to the texture parameter specified as Pname . Target defines the target texture, either ?GL_TEXTURE_1D , ?GL_TEXTURE_2D, ?GL_TEXTURE_1D_ARRAY, ?GL_TEXTURE_2D_ARRAY, ?GL_TEXTURE_RECTANGLE , or ?GL_TEXTURE_3D. The following symbols are accepted in Pname :
?GL_TEXTURE_BASE_LEVEL: Specifies the index of the lowest defined mipmap level. This is an integer value. The initial value is 0.
?GL_TEXTURE_BORDER_COLOR: The data in Params specifies four values that define the border values that should be used for border texels. If a texel is sampled from the border of the texture, the values of ?GL_TEXTURE_BORDER_COLOR are interpreted as an RGBA color to match the texture's internal format and substituted for the non-existent texel data. If the texture contains depth components, the first component of ?GL_TEXTURE_BORDER_COLOR is interpreted as a depth value. The initial value is ( 0.0, 0.0, 0.0, 0.0 ).
If the values for ?GL_TEXTURE_BORDER_COLOR are specified with gl:texParameterIiv or gl:texParameterIuiv, the values are stored unmodified with an internal data type of integer. If specified with gl:texParameteriv, they are converted to floating point with the following equation: f=2 c+1 2 b-/1. If specified with gl:texParameterfv , they are stored unmodified as floating-point values.
?GL_TEXTURE_COMPARE_FUNC: Specifies the comparison operator used when ?GL_TEXTURE_COMPARE_MODE is set to ?GL_COMPARE_REF_TO_TEXTURE. Permissible values are:
Texture Comparison FunctionComputed result?GL_LEQUAL result={1.0 0.0 r<=(D t) r>(D t))
?GL_GEQUAL result={1.0 0.0 r>=(D t) r<(D t))
?GL_LESS result={1.0 0.0 r<(D t) r>=(D t))
?GL_GREATER result={1.0 0.0 r>(D t) r<=(D t))
?GL_EQUAL result={1.0 0.0 r=(D t) r≠ (D t))
?GL_NOTEQUAL result={1.0 0.0 r≠(D t) r=(D t))
?GL_ALWAYS result=1.0
?GL_NEVER result=0.0
where r is the current interpolated texture coordinate, and D t is the depth texture value sampled from the currently bound depth texture. result is assigned to the the red channel.
?GL_TEXTURE_COMPARE_MODE: Specifies the texture comparison mode for currently bound depth textures. That is, a texture whose internal format is ?GL_DEPTH_COMPONENT_* ; see gl:texImage2D/9 ) Permissible values are:
?GL_COMPARE_REF_TO_TEXTURE: Specifies that the interpolated and clamped r texture coordinate should be compared to the value in the currently bound depth texture. See the discussion of ?GL_TEXTURE_COMPARE_FUNC for details of how the comparison is evaluated. The result of the comparison is assigned to the red channel.
?GL_NONE: Specifies that the red channel should be assigned the appropriate value from the currently bound depth texture.
?GL_TEXTURE_LOD_BIAS: Params specifies a fixed bias value that is to be added to the level-of-detail parameter for the texture before texture sampling. The specified value is added to the shader-supplied bias value (if any) and subsequently clamped into the implementation-defined range [( - bias max)(bias max)], where bias max is the value of the implementation defined constant ?GL_MAX_TEXTURE_LOD_BIAS. The initial value is 0.0.
?GL_TEXTURE_MIN_FILTER: The texture minifying function is used whenever the level-of-detail function used when sampling from the texture determines that the texture should be minified. There are six defined minifying functions. Two of them use either the nearest texture elements or a weighted average of multiple texture elements to compute the texture value. The other four use mipmaps.
A mipmap is an ordered set of arrays representing the same image at progressively lower resolutions. If the texture has dimensions 2 n×2 m, there are max(n m)+1 mipmaps. The first mipmap is the original texture, with dimensions 2 n×2 m. Each subsequent mipmap has dimensions 2(k-1)×2(l-1), where 2 k×2 l are the dimensions of the previous mipmap, until either k=0 or l=0. At that point, subsequent mipmaps have dimension 1×2(l-1) or 2(k-1)×1 until the final mipmap, which has dimension 1×1. To define the mipmaps, call gl:texImage1D/8 , gl:texImage2D/9 , gl:texImage3D/10 , gl:copyTexImage1D/7 , or gl:copyTexImage2D/8 with the level argument indicating the order of the mipmaps. Level 0 is the original texture; level max(n m) is the final 1×1 mipmap.
Params supplies a function for minifying the texture as one of the following:
?GL_NEAREST: Returns the value of the texture element that is nearest (in Manhattan distance) to the specified texture coordinates.
?GL_LINEAR: Returns the weighted average of the four texture elements that are closest to the specified texture coordinates. These can include items wrapped or repeated from other parts of a texture, depending on the values of ?GL_TEXTURE_WRAP_S and ?GL_TEXTURE_WRAP_T , and on the exact mapping.
?GL_NEAREST_MIPMAP_NEAREST: Chooses the mipmap that most closely matches the size of the pixel being textured and uses the ?GL_NEAREST criterion (the texture element closest to the specified texture coordinates) to produce a texture value.
?GL_LINEAR_MIPMAP_NEAREST: Chooses the mipmap that most closely matches the size of the pixel being textured and uses the ?GL_LINEAR criterion (a weighted average of the four texture elements that are closest to the specified texture coordinates) to produce a texture value.
?GL_NEAREST_MIPMAP_LINEAR: Chooses the two mipmaps that most closely match the size of the pixel being textured and uses the ?GL_NEAREST criterion (the texture element closest to the specified texture coordinates ) to produce a texture value from each mipmap. The final texture value is a weighted average of those two values.
?GL_LINEAR_MIPMAP_LINEAR: Chooses the two mipmaps that most closely match the size of the pixel being textured and uses the ?GL_LINEAR criterion (a weighted average of the texture elements that are closest to the specified texture coordinates) to produce a texture value from each mipmap. The final texture value is a weighted average of those two values.
As more texture elements are sampled in the minification process, fewer aliasing artifacts will be apparent. While the ?GL_NEAREST and ?GL_LINEAR minification functions can be faster than the other four, they sample only one or multiple texture elements to determine the texture value of the pixel being rendered and can produce moire patterns or ragged transitions. The initial value of ?GL_TEXTURE_MIN_FILTER is ?GL_NEAREST_MIPMAP_LINEAR .
?GL_TEXTURE_MAG_FILTER: The texture magnification function is used whenever the level-of-detail function used when sampling from the texture determines that the texture should be magified. It sets the texture magnification function to either ?GL_NEAREST or ?GL_LINEAR (see below). ?GL_NEAREST is generally faster than ?GL_LINEAR , but it can produce textured images with sharper edges because the transition between texture elements is not as smooth. The initial value of ?GL_TEXTURE_MAG_FILTER is ?GL_LINEAR .
?GL_NEAREST: Returns the value of the texture element that is nearest (in Manhattan distance) to the specified texture coordinates.
?GL_LINEAR: Returns the weighted average of the texture elements that are closest to the specified texture coordinates. These can include items wrapped or repeated from other parts of a texture, depending on the values of ?GL_TEXTURE_WRAP_S and ?GL_TEXTURE_WRAP_T , and on the exact mapping.
?GL_TEXTURE_MIN_LOD: Sets the minimum level-of-detail parameter. This floating-point value limits the selection of highest resolution mipmap (lowest mipmap level). The initial value is -1000.
?GL_TEXTURE_MAX_LOD: Sets the maximum level-of-detail parameter. This floating-point value limits the selection of the lowest resolution mipmap (highest mipmap level). The initial value is 1000.
?GL_TEXTURE_MAX_LEVEL: Sets the index of the highest defined mipmap level. This is an integer value. The initial value is 1000.
?GL_TEXTURE_SWIZZLE_R: Sets the swizzle that will be applied to the r component of a texel before it is returned to the shader. Valid values for Param are ?GL_RED , ?GL_GREEN, ?GL_BLUE, ?GL_ALPHA, ?GL_ZERO and ?GL_ONE. If ?GL_TEXTURE_SWIZZLE_R is ?GL_RED, the value for r will be taken from the first channel of the fetched texel. If ?GL_TEXTURE_SWIZZLE_R is ?GL_GREEN , the value for r will be taken from the second channel of the fetched texel. If ?GL_TEXTURE_SWIZZLE_R is ?GL_BLUE, the value for r will be taken from the third channel of the fetched texel. If ?GL_TEXTURE_SWIZZLE_R is ?GL_ALPHA, the value for r will be taken from the fourth channel of the fetched texel. If ?GL_TEXTURE_SWIZZLE_R is ?GL_ZERO , the value for r will be subtituted with 0.0. If ?GL_TEXTURE_SWIZZLE_R is ?GL_ONE , the value for r will be subtituted with 1.0. The initial value is ?GL_RED.
?GL_TEXTURE_SWIZZLE_G: Sets the swizzle that will be applied to the g component of a texel before it is returned to the shader. Valid values for Param and their effects are similar to those of ?GL_TEXTURE_SWIZZLE_R. The initial value is ?GL_GREEN .
?GL_TEXTURE_SWIZZLE_B: Sets the swizzle that will be applied to the b component of a texel before it is returned to the shader. Valid values for Param and their effects are similar to those of ?GL_TEXTURE_SWIZZLE_R. The initial value is ?GL_BLUE .
?GL_TEXTURE_SWIZZLE_A: Sets the swizzle that will be applied to the a component of a texel before it is returned to the shader. Valid values for Param and their effects are similar to those of ?GL_TEXTURE_SWIZZLE_R. The initial value is ?GL_ALPHA .
?GL_TEXTURE_SWIZZLE_RGBA: Sets the swizzles that will be applied to the r, g, b, and a components of a texel before they are returned to the shader. Valid values for Params and their effects are similar to those of ?GL_TEXTURE_SWIZZLE_R, except that all channels are specified simultaneously. Setting the value of ?GL_TEXTURE_SWIZZLE_RGBA is equivalent (assuming no errors are generated) to setting the parameters of each of ?GL_TEXTURE_SWIZZLE_R , ?GL_TEXTURE_SWIZZLE_G, ?GL_TEXTURE_SWIZZLE_B, and ?GL_TEXTURE_SWIZZLE_A successively.
?GL_TEXTURE_WRAP_S: Sets the wrap parameter for texture coordinate s to either ?GL_CLAMP_TO_EDGE , ?GL_CLAMP_TO_BORDER, ?GL_MIRRORED_REPEAT, or ?GL_REPEAT. ?GL_CLAMP_TO_EDGE causes s coordinates to be clamped to the range [(1 2/N) 1-(1 2/N)], where N is the size of the texture in the direction of clamping. ?GL_CLAMP_TO_BORDER evaluates s coordinates in a similar manner to ?GL_CLAMP_TO_EDGE. However, in cases where clamping would have occurred in ?GL_CLAMP_TO_EDGE mode, the fetched texel data is substituted with the values specified by ?GL_TEXTURE_BORDER_COLOR. ?GL_REPEAT causes the integer part of the s coordinate to be ignored; the GL uses only the fractional part, thereby creating a repeating pattern. ?GL_MIRRORED_REPEAT causes the s coordinate to be set to the fractional part of the texture coordinate if the integer part of s is even; if the integer part of s is odd, then the s texture coordinate is set to 1- frac(s), where frac(s) represents the fractional part of s. Initially, ?GL_TEXTURE_WRAP_S is set to ?GL_REPEAT.
?GL_TEXTURE_WRAP_T: Sets the wrap parameter for texture coordinate t to either ?GL_CLAMP_TO_EDGE , ?GL_CLAMP_TO_BORDER, ?GL_MIRRORED_REPEAT, or ?GL_REPEAT. See the discussion under ?GL_TEXTURE_WRAP_S. Initially, ?GL_TEXTURE_WRAP_T is set to ?GL_REPEAT.
?GL_TEXTURE_WRAP_R: Sets the wrap parameter for texture coordinate r to either ?GL_CLAMP_TO_EDGE , ?GL_CLAMP_TO_BORDER, ?GL_MIRRORED_REPEAT, or ?GL_REPEAT. See the discussion under ?GL_TEXTURE_WRAP_S. Initially, ?GL_TEXTURE_WRAP_R is set to ?GL_REPEAT.
See external documentation.
texParameteri(Target, Pname, Param) -> ok
Types:
See texParameterf/3
texParameterfv(Target, Pname, Params) -> ok
Types:
See texParameterf/3
texParameteriv(Target, Pname, Params) -> ok
Types:
See texParameterf/3
getTexParameterfv(Target, Pname) -> {float(), float(), float(), float()}
Types:
Return texture parameter values
gl:getTexParameter returns in Params the value or values of the texture parameter specified as Pname . Target defines the target texture. ?GL_TEXTURE_1D, ?GL_TEXTURE_2D, ?GL_TEXTURE_3D, ?GL_TEXTURE_1D_ARRAY, ?GL_TEXTURE_2D_ARRAY , ?GL_TEXTURE_RECTANGLE, ?GL_TEXTURE_CUBE_MAP, ?GL_TEXTURE_CUBE_MAP_ARRAY specify one-, two-, or three-dimensional, one-dimensional array, two-dimensional array, rectangle, cube-mapped or cube-mapped array texturing, respectively. Pname accepts the same symbols as gl:texParameterf/3 , with the same interpretations:
?GL_TEXTURE_MAG_FILTER: Returns the single-valued texture magnification filter, a symbolic constant. The initial value is ?GL_LINEAR.
?GL_TEXTURE_MIN_FILTER: Returns the single-valued texture minification filter, a symbolic constant. The initial value is ?GL_NEAREST_MIPMAP_LINEAR.
?GL_TEXTURE_MIN_LOD: Returns the single-valued texture minimum level-of-detail value. The initial value is -1000.
?GL_TEXTURE_MAX_LOD: Returns the single-valued texture maximum level-of-detail value. The initial value is 1000.
?GL_TEXTURE_BASE_LEVEL: Returns the single-valued base texture mipmap level. The initial value is 0.
?GL_TEXTURE_MAX_LEVEL: Returns the single-valued maximum texture mipmap array level. The initial value is 1000.
?GL_TEXTURE_SWIZZLE_R: Returns the red component swizzle. The initial value is ?GL_RED .
?GL_TEXTURE_SWIZZLE_G: Returns the green component swizzle. The initial value is ?GL_GREEN .
?GL_TEXTURE_SWIZZLE_B: Returns the blue component swizzle. The initial value is ?GL_BLUE .
?GL_TEXTURE_SWIZZLE_A: Returns the alpha component swizzle. The initial value is ?GL_ALPHA .
?GL_TEXTURE_SWIZZLE_RGBA: Returns the component swizzle for all channels in a single query.
?GL_TEXTURE_WRAP_S: Returns the single-valued wrapping function for texture coordinate s, a symbolic constant. The initial value is ?GL_REPEAT.
?GL_TEXTURE_WRAP_T: Returns the single-valued wrapping function for texture coordinate t, a symbolic constant. The initial value is ?GL_REPEAT.
?GL_TEXTURE_WRAP_R: Returns the single-valued wrapping function for texture coordinate r, a symbolic constant. The initial value is ?GL_REPEAT.
?GL_TEXTURE_BORDER_COLOR: Returns four integer or floating-point numbers that comprise the RGBA color of the texture border. Floating-point values are returned in the range [0 1]. Integer values are returned as a linear mapping of the internal floating-point representation such that 1.0 maps to the most positive representable integer and -1.0 maps to the most negative representable integer. The initial value is (0, 0, 0, 0).
?GL_TEXTURE_COMPARE_MODE: Returns a single-valued texture comparison mode, a symbolic constant. The initial value is ?GL_NONE. See gl:texParameterf/3 .
?GL_TEXTURE_COMPARE_FUNC: Returns a single-valued texture comparison function, a symbolic constant. The initial value is ?GL_LEQUAL. See gl:texParameterf/3 .
In addition to the parameters that may be set with gl:texParameterf/3 , gl:getTexParameter accepts the following read-only parameters:
?GL_TEXTURE_IMMUTABLE_FORMAT: Returns non-zero if the texture has an immutable format. Textures become immutable if their storage is specified with gl:texStorage1D/4 , gl:texStorage2D/5 or gl:texStorage3D/6 . The initial value is ?GL_FALSE .
See external documentation.
getTexParameteriv(Target, Pname) -> {integer(), integer(), integer(), integer()}
Types:
getTexLevelParameterfv(Target, Level, Pname) -> {float()}
Types:
Return texture parameter values for a specific level of detail
gl:getTexLevelParameter returns in Params texture parameter values for a specific level-of-detail value, specified as Level . Target defines the target texture, either ?GL_TEXTURE_1D, ?GL_TEXTURE_2D, ?GL_TEXTURE_3D, ?GL_PROXY_TEXTURE_1D , ?GL_PROXY_TEXTURE_2D, ?GL_PROXY_TEXTURE_3D, ?GL_TEXTURE_CUBE_MAP_POSITIVE_X , ?GL_TEXTURE_CUBE_MAP_NEGATIVE_X, ?GL_TEXTURE_CUBE_MAP_POSITIVE_Y, ?GL_TEXTURE_CUBE_MAP_NEGATIVE_Y , ?GL_TEXTURE_CUBE_MAP_POSITIVE_Z, ?GL_TEXTURE_CUBE_MAP_NEGATIVE_Z, or ?GL_PROXY_TEXTURE_CUBE_MAP .
?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()}
Types:
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
Types:
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
Types:
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.
When a texture is first bound, it assumes the specified target: A texture first bound to ?GL_TEXTURE_1D becomes one-dimensional texture, a texture first bound to ?GL_TEXTURE_2D becomes two-dimensional texture, a texture first bound to ?GL_TEXTURE_3D becomes three-dimensional texture, a texture first bound to ?GL_TEXTURE_1D_ARRAY becomes one-dimensional array texture, a texture first bound to ?GL_TEXTURE_2D_ARRAY becomes two-dimensional arary texture, a texture first bound to ?GL_TEXTURE_RECTANGLE becomes rectangle texture, a, texture first bound to ?GL_TEXTURE_CUBE_MAP becomes a cube-mapped texture, a texture first bound to ?GL_TEXTURE_2D_MULTISAMPLE becomes a two-dimensional multisampled texture, and a texture first bound to ?GL_TEXTURE_2D_MULTISAMPLE_ARRAY becomes a two-dimensional multisampled array texture. 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
Types:
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
Types:
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
Types:
See getMapdv/3
getMapiv(Target, Query, V) -> ok
Types:
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