| Name |
| |
| EXT_texture_swizzle |
| |
| Name Strings |
| |
| GL_EXT_texture_swizzle |
| |
| Contact |
| |
| Jeff Bolz, NVIDIA Corporation (jbolz 'at' nvidia.com) |
| |
| Contributors |
| |
| Cass Everitt, Id Software |
| Brian Harris, Id Software |
| Pat Brown, NVIDIA |
| Eric Werness, NVIDIA |
| |
| Status |
| |
| Shipping in October, 2008. |
| |
| Version |
| |
| Last Modified Date: September 9, 2008 |
| Author Revision: 1.0 |
| |
| Number |
| |
| 356 |
| |
| Dependencies |
| |
| Written based on the wording of the OpenGL 2.1 specification. |
| |
| Overview |
| |
| Classic OpenGL texture formats conflate texture storage and |
| interpretation, and assume that textures represent color. In |
| modern applications, a significant quantity of textures don't |
| represent color, but rather data like shadow maps, normal maps, |
| page tables, occlusion data, etc.. For the latter class of data, |
| calling the data "RGBA" is just a convenient mapping of what the |
| data is onto the current model, but isn't an accurate reflection |
| of the reality of the data. |
| |
| The existing texture formats provide an almost orthogonal set of |
| data types, sizes, and number of components, but the mappings of |
| this storage into what the shader or fixed-function pipeline |
| fetches is very much non-orthogonal. Previous extensions have |
| added some of the most demanded missing formats, but the problem |
| has not been solved once and for all. |
| |
| This extension provides a mechanism to swizzle the components |
| of a texture before they are applied according to the texture |
| environment in fixed-function or as they are returned to the |
| shader. |
| |
| IP Status |
| |
| No known IP claims. |
| |
| New Tokens |
| |
| Accepted by the <pname> parameters of TexParameteri, |
| TexParameterf, TexParameteriv, TexParameterfv, |
| GetTexParameterfv, and GetTexParameteriv: |
| |
| TEXTURE_SWIZZLE_R_EXT 0x8E42 |
| TEXTURE_SWIZZLE_G_EXT 0x8E43 |
| TEXTURE_SWIZZLE_B_EXT 0x8E44 |
| TEXTURE_SWIZZLE_A_EXT 0x8E45 |
| |
| Accepted by the <pname> parameters of TexParameteriv, |
| TexParameterfv, GetTexParameterfv, and GetTexParameteriv: |
| |
| TEXTURE_SWIZZLE_RGBA_EXT 0x8E46 |
| |
| |
| Additions to Chapter 2 of the OpenGL 2.1 Specification (OpenGL Operation) |
| |
| Modify Section 2.15.4 (Shader Execution), p. 84: |
| |
| Texture Access |
| |
| ...and converts it to a texture source color Cs according to table |
| 3.20 (section 3.8.13), followed by application of the texture swizzle |
| as described in section 3.8.13. A four-component vector (Rs,Gs,Bs,As) |
| is returned to the vertex shader. |
| |
| Additions to Chapter 3 of the OpenGL 2.1 Specification (Rasterization) |
| |
| Modify Section 3.8.4 (Texture Parameters), p. 168: |
| |
| (modify table 3.18, p. 169) |
| Name Type Legal Values |
| ---- ---- ------------ |
| TEXTURE_SWIZZLE_R_EXT enum RED, GREEN, BLUE, ALPHA, ZERO, ONE |
| TEXTURE_SWIZZLE_G_EXT enum RED, GREEN, BLUE, ALPHA, ZERO, ONE |
| TEXTURE_SWIZZLE_B_EXT enum RED, GREEN, BLUE, ALPHA, ZERO, ONE |
| TEXTURE_SWIZZLE_A_EXT enum RED, GREEN, BLUE, ALPHA, ZERO, ONE |
| |
| (append to section 3.8.4, p. 170) |
| |
| TEXTURE_SWIZZLE_RGBA_EXT sets the same state as the R, G, B, A |
| enums in a single call. |
| |
| (append to section 3.8.13, p. 184) |
| The values of the texture parameters TEXTURE_SWIZZLE_R_EXT, |
| TEXTURE_SWIZZLE_G_EXT, TEXTURE_SWIZZLE_B_EXT, and |
| TEXTURE_SWIZZLE_A_EXT, are applied after the swizzling described |
| in Table 3.20 (p. 186). The swizzle parameter |
| TEXTURE_SWIZZLE_R_EXT affects the first component of Cs as: |
| |
| if (TEXTURE_SWIZZLE_R_EXT == RED) { |
| Cs'[0] = Cs[0]; |
| } else if (TEXTURE_SWIZZLE_R_EXT == GREEN) { |
| Cs'[0] = Cs[1]; |
| } else if (TEXTURE_SWIZZLE_R_EXT == BLUE) { |
| Cs'[0] = Cs[2]; |
| } else if (TEXTURE_SWIZZLE_R_EXT == ALPHA) { |
| Cs'[0] = As; |
| } else if (TEXTURE_SWIZZLE_R_EXT == ZERO) { |
| Cs'[0] = 0; |
| } else if (TEXTURE_SWIZZLE_R_EXT == ONE) { |
| Cs'[0] = 1; // float or int depending on texture component type |
| } |
| |
| and similarly for Cs'[1], Cs'[2], and As'. |
| |
| Modify Section 3.11.2 (Shader Execution), p. 197: |
| |
| Texture Access |
| |
| ...and converts it to a texture source color Cs according to table |
| 3.20 (section 3.8.13), followed by application of the texture swizzle |
| as described in section 3.8.13. The GL returns a four-component |
| vector (Rs,Gs,Bs,As) to the fragment shader... |
| |
| Additions to the AGL/EGL/GLX/WGL Specifications |
| |
| None |
| |
| Errors |
| |
| The error INVALID_OPERATION is generated if TexParameteri, |
| TexParameterf, TexParameteriv, or TexParameterfv, parameter <pname> |
| is TEXTURE_SWIZZLE_R_EXT, TEXTURE_SWIZZLE_G_EXT, |
| TEXTURE_SWIZZLE_B_EXT, or TEXTURE_SWIZZLE_A_EXT, and <param> is not |
| RED, GREEN, BLUE, ALPHA, ZERO, or ONE. |
| |
| The error INVALID_OPERATION is generated if TexParameteriv, or |
| TexParameterfv, parameter <pname> TEXTURE_SWIZZLE_RGBA_EXT, and |
| the four consecutive values pointed to by <param> are not all |
| RED, GREEN, BLUE, ALPHA, ZERO, or ONE. |
| |
| New State |
| |
| Changes to table 6.16, p. 277 (Texture, state per texture object) |
| |
| Initial |
| Get Value Type Get Command Value Description Sec. Attribute |
| --------- ---- ----------- ------- ----------- ---- --------- |
| TEXTURE_SWIZZLE_R_EXT Z GetTexParameter RED Red 3.8.4 texture |
| component swizzle |
| TEXTURE_SWIZZLE_G_EXT Z GetTexParameter GREEN Green 3.8.4 texture |
| component swizzle |
| TEXTURE_SWIZZLE_B_EXT Z GetTexParameter BLUE Blue 3.8.4 texture |
| component swizzle |
| TEXTURE_SWIZZLE_A_EXT Z GetTexParameter ALPHA Alpha 3.8.4 texture |
| component swizzle |
| |
| Issues |
| |
| 1) Why not add more new formats instead? |
| |
| RESOLVED: Adding new formats is more implementation burden than |
| one might expect. New formats need to be added to the pixel path, |
| must be considered for FBO support, etc.. This extension avoids |
| those issues by solely affecting the result of a texture fetch. |
| |
| 2) What is the demand for this extension? |
| |
| RESOLVED: There are several independent demands for this, |
| including: |
| - OpenGL 3.0 deprecated support for ALPHA, LUMINANCE, |
| LUMINANCE_ALPHA, and INTENSITY formats. This extension provides |
| a simple porting path for legacy applications that used these |
| formats. |
| |
| - There have been specific requests for (1,1,1,a), or "white alpha" |
| formats that allow a "decal" texture to be used in the same shader |
| as an RGBA texture. This can be accomplished with an OpenGL 2.1 |
| ALPHA texture by doing |
| |
| TexParameteri(target, TEXTURE_SWIZZLE_R_EXT, ONE); |
| TexParameteri(target, TEXTURE_SWIZZLE_G_EXT, ONE); |
| TexParameteri(target, TEXTURE_SWIZZLE_B_EXT, ONE); |
| // TEXTURE_SWIZZLE_A_EXT is already ALPHA |
| or equivalently |
| GLint swiz[4] = {ONE, ONE, ONE, ALPHA}; |
| TexParameteriv(target, TEXTURE_SWIZZLE_RGBA_EXT, swiz); |
| |
| or in OpenGL 3.0 "preview" contexts where ALPHA internal formats |
| are deprecated by using a RED texture: |
| TexParameteri(target, TEXTURE_SWIZZLE_R_EXT, ONE); |
| TexParameteri(target, TEXTURE_SWIZZLE_G_EXT, ONE); |
| TexParameteri(target, TEXTURE_SWIZZLE_B_EXT, ONE); |
| TexParameteri(target, TEXTURE_SWIZZLE_A_EXT, RED); |
| or equivalently |
| GLint swiz[4] = {ONE, ONE, ONE, RED}; |
| TexParameteriv(target, TEXTURE_SWIZZLE_RGBA_EXT, swiz); |
| |
| - This functionality is available on Sony PlayStation 3 and can |
| simplify porting those applications to OpenGL. |
| |
| 3) What names should be used for the components, in both the "source" |
| (<param>) and "destination" (<pname>) enums? RGBA? XYZW? 0123? |
| |
| RESOLVED: RGBA for both source and destination. 0123 could cause |
| confusion with ZERO and ONE. RGBA is a natural choice for source, |
| because the spec describes the values returned by textures as "Color" |
| and "Alpha." There's no particular precedent for destination to be |
| XYZW as this is still part of texture and not the shader, so RGBA |
| it is. |
| |
| 4) How does this interact with depth component textures? |
| |
| RESOLVED: The swizzle is applied after the DEPTH_TEXTURE_MODE. This |
| naturally falls out of specifying the swizzle in terms of Table 3.20. |
| |
| 5) How does this interact with sRGB? |
| |
| RESOLVED: The swizzle is applied after sRGB conversion. |
| |
| 6) How does this interact with NV_register_combiners, |
| NV_texture_shader, and other old "shading" extensions that |
| predate NV/ARB_fragment_program and define their own "interesting" |
| swizzles? |
| |
| RESOLVED: Undefined. Core fixed-function shading (texture_env/combine) |
| are fully supported, but old proprietary "configurable shading" |
| extensions are not. |
| |
| 7) How does the swizzle interact with the fixed-function texture |
| environment referencing the base format? |
| |
| RESOLVED: Note that, by virtue of being defined in terms of Table 3.20, |
| the swizzling occurs *before* the texture environment functions |
| (Table 3.21 and 3.22) are applied. So if you used the first example |
| under Issue (2) with fixed-function, the primary color would "pass |
| through" because the ALPHA base format environment function would |
| still apply. In order to effectively swizzle all four components, an |
| INTENSITY format would give the desired result with the same storage |
| requirements. |
| |
| Revision History |
| |
| Revision 1, 2008/08/21 |
| - Initial draft |
| Revision 2, 2009/01/28 |
| - Add edits to fragment/vertex shader sections to clarify that the |
| swizzle is applied in both. |