Name MESAX_texture_stack Name Strings GL_MESAX_texture_stack Contact Ian Romanick, IBM (idr 'at' us.ibm.com) IP Status No known IP issues. Status TBD Version $Date: 2005/12/12$ $Revision: 0.3$ Number 318 Dependencies OpenGL 1.2 or GL_EXT_texture3D is required. Support for ARB_fragment_program is assumed, but not required. Support for ARB_fragment_program_shadow is assumed, but not required. Support for EXT_framebuffer_object is assumed, but not required. Written based on the wording of the OpenGL 2.0 specification and ARB_fragment_program_shadow but not dependent on them. Overview There are a number of circumstances where an application may wish to blend two textures out of a larger set of textures. Moreover, in some cases the selected textures may vary on a per-fragment basis within a polygon. Several examples include: 1. High dynamic range textures. The application stores several different "exposures" of an image as different textures. On a per-fragment basis, the application selects which exposures are used. 2. A terrain engine where the altitude of a point determines the texture applied to it. If the transition is from beach sand to grass to rocks to snow, the application will store each texture in a different texture map, and dynamically select which two textures to blend at run-time. 3. Storing short video clips in textures. Each depth slice is a single frame of video. Several solutions to this problem have been proposed, but they either involve using a separate texture unit for each texture map or using 3D textures without mipmaps. Both of these options have major drawbacks. This extension provides a third alternative that eliminates the major drawbacks of both previous methods. A new texture target, TEXTURE_2D_STACK, is added that functions identically to TEXTURE_3D in all aspects except the sizes of the non-base level images. In traditional 3D texturing, the size of the N+1 LOD is half the size of the N LOD in all three dimensions. For the TEXTURE_2D_STACK target, the height and width of the N+1 LOD is halved, but the depth is the same for all levels of detail. The texture then becomes a "stack" of 2D textures. The per-fragment texel is selected by the R texture coordinate. References: http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=011557 http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=000516 http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=011903 http://www.delphi3d.net/articles/viewarticle.php?article=terraintex.htm Issues (1) Is "texture stack" a good name for this functionality? NO. However, I can't think of anything else that is better. (2) Should the R texture coordinate be treated as normalized or un-normalized? If it were un-normalized, floor(R) could be thought of as a direct index into the texture stack. This may be more convenient for applications. RESOLVED. All texture coordinates are normalized. The issue of un-normalized texture coordinates has been discussed in the ARB before and should be left for a layered extension. (3) How does LOD selection work for stacked textures? RESOLVED. For 2D texture stacks the R coordinate is ignored, and the LOD selection equations for 2D textures are used. For 1D texture stacks the T coordinate is ignored, and the LOD selection equations for 1D textures are used. The expected usage is in a fragment program with an explicit LOD selection. (4) What is the maximum size of a 2D texture stack? Is it the same as for a 3D texture, or should a new query be added? How about for 1D texture stacks? UNRESOLVED. (5) How are texture stacks exposed in GLSL? RESOLVED. For now, they're not exposed at all. Mesa doesn't currently support GLSL, so it's somewhat moot. When this extension is converted to MESA, EXT, or ARB, it is expected that an additional samplers (e.g., sampler1DStack and sampler2DStack) and texture lookup functions (e.g., texture1DStack and texture2Dstack) will be added. (6) Should a 1D texture stack also be exposed? RESOLVED. For orthogonality, yes. (7) How are stacked textures attached to framebuffer objects? SEMI-RESOLVED. Slices of TEXTURE_2D_STACK textures are attached in the same manner as slices of traditional 3D textures. TEXTURE_1D_STACK textures are a bit more tricky. This could be handled one of two ways. The entire texture could be attached using FramebufferTexture2DEXT, or a new function could be created that would allow the attachment of a single 1D slice of the texture. The spec currently uses the former, but the later may be more logical. New Procedures and Functions None New Tokens Accepted by the parameter of Enable, Disable, and IsEnabled, by the parameter of GetBooleanv, GetIntegerv, GetFloatv, and GetDoublev, and by the parameter of TexImage3D, GetTexImage, GetTexLevelParameteriv, GetTexLevelParameterfv, GetTexParameteriv, and GetTexParameterfv: TEXTURE_1D_STACK_MESAX 0x8759 TEXTURE_2D_STACK_MESAX 0x875A Accepted by the parameter of TexImage3D, GetTexLevelParameteriv, and GetTexLevelParameterfv: PROXY_TEXTURE_1D_STACK_MESAX 0x875B PROXY_TEXTURE_2D_STACK_MESAX 0x875C Accepted by the parameter of GetBooleanv, GetIntegerv, GetFloatv, and GetDoublev TEXTURE_1D_STACK_BINDING_MESAX 0x875D TEXTURE_2D_STACK_BINDING_MESAX 0x875E Accepted by the parameter of FramebufferTexture2DEXT: TEXTURE_1D_STACK_MESAX Accepted by the parameter of FramebufferTexture3DEXT: TEXTURE_2D_STACK_MESAX Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation) None Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization) -- Section 3.8.8 "Texture Minification" in the section "Scale Factor and Level of Detail" Change the first paragraph (page 172) to say: "Let s(x,y) be the function that associates an s texture coordinate with each set of window coordinates (x,y) that lie within a primitive; define t(x,y) and r(x,y) analogously. Let u(x,y) = w_t * s(x,y), v(x,y) = h_t * t(x,y), and w(x,y) = d_t * r(x,y), where w_t, h_t, and d_t are as defined by equations 3.15, 3.16, and 3.17 with w_s, h_s, and d_s equal to the width, height, and depth of the image array whose level is level_base. For a one-dimensional texture, define v(x,y) = 0 and w(x,y) = 0; for a two-dimensional texture or a 2D texture stack, define w(x,y) = 0..." -- Section 3.8.8 "Texture Minification" in the section "Mipmapping" After the first paragraph (page 175) add: "For TEXTURE_2D_STACK_MESAX textures, d_b is always treated as zero, regardless of the actual value, when performing mipmap calculations." -- Section 3.8.15 "Texture Application" Change the first paragraph (page 189) to say: "Texturing is enabled or disabled using the generic Enable and Disable commands, respectively, with the symbolic constants TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_STACK_MESAX, or TEXTURE_2D_STACK_MESAX to enable one-, two-, three-dimensional, cube map, or 2D texture stack texture, respectively. If both two- and one-dimensional textures are enabled, the two-dimensional texture is used. If the three-dimensional and either of the two- or one- dimensional textures is enabled, the three-dimensional texture is used. If the cube map texture and any of the three-, two-, or one- dimensional textures is enabled, then cube map texturing is used. If 1D texture stack is enabled and any of cube map, three-, two-, or one-dimensional textures is enabled, 2D texture stack texturing is used. If 2D texture stack is enabled and any of cube map, three-, two-, one-dimensional textures or 1D texture stack is enabled, 2D texture stack texturing is used..." -- Section 3.11.2 of ARB_fragment_program (Fragment Program Grammar and Restrictions): (mostly add to existing grammar rules) ::= "MESAX_texture_stack" ::= "1D" | "2D" | "3D" | "CUBE" | "RECT" | "1D_STACK" | "2D_STACK" -- Add Section 3.11.4.5.4 Texture Stack Option "If a fragment program specifies the "MESAX_texture_stack" program option, the rule is modified to add the texture targets 1D_STACK and 2D_STACK (See Section 3.11.2)." -- Modify Section 3.11.6 Fragment Program Texture Instruction Set (replace 1st and 2nd paragraphs with the following paragraphs) "The first three texture instructions described below specify the mapping of 4-tuple input vectors to 4-tuple output vectors. The sampling of the texture works as described in section 3.8, except that texture environments and texture functions are not applicable, and the texture enables hierarchy is replaced by explicit references to the desired texture target (i.e., 1D, 2D, 3D, cube map, rectangle, 1D_STACK, 2D_STACK). These texture instructions specify how the 4-tuple is mapped into the coordinates used for sampling. The following function is used to describe the texture sampling in the descriptions below: vec4 TextureSample(float s, float t, float r, float lodBias, int texImageUnit, enum texTarget); Note that not all three texture coordinates, s, t, and r, are used by all texture targets. In particular, 1D texture targets only use the s component. 2D, RECT (non-power-of-two), and 1D_STACK texture targets only use the s and t components. SHADOW1D texture targets only use the s and r components. The descriptions of the texture instructions below supply all three components, as would be the case with CUBE, 3D, 2D_STACK, SHADOW2D, and SHADOWRECT targets." Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment Operations) -- 4.4.2.3 Attaching Texture Images to a Framebuffer Change the sixth paragraph to say: "If is TEXTURE_RECTANGLE_ARB, then must be zero. If is TEXTURE_3D or TEXTURE_2D_STACK , then must be greater than or equal to zero and less than or equal to log base 2 of MAX_3D_TEXTURE_SIZE..." Change the ninth paragraph to say: "For FramebufferTexture2DEXT, if is not zero, then must be one of: TEXTURE_2D, TEXTURE_1D_STACK, TEXTURE_RECTANGLE_ARB, TEXTURE_CUBE_MAP_POSITIVE_X, TEXTURE_CUBE_MAP_POSITIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE_MAP_NEGATIVE_Y, or TEXTURE_CUBE_MAP_NEGATIVE_Z." Change the tenth paragraph to say: "For FramebufferTexture3DEXT, if is not zero, then must be TEXTURE_3D or TEXTURE_2D_STACK." Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions) None Additions to Chapter 6 of the OpenGL 2.0 Specification (State and State Requests) None Additions to Appendix A of the OpenGL 2.0 Specification (Invariance) None Additions to the AGL/GLX/WGL Specifications None GLX Protocol None Dependencies on ARB_fragment_program If ARB_fragment_program is not supported, the changes to section 3.11 should be ignored. Dependencies on EXT_framebuffer_object If EXT_framebuffer_object is not supported, the changes to section 4.4.2.3 should be ignored. Errors None New State None New Implementation Dependent State None Revision History ||2005/11/15||0.1||idr||Initial draft version.|| ||2005/12/07||0.2||idr||Added framebuffer object interactions.|| ||2005/12/12||0.3||idr||Updated fragment program interactions.||