| Name |
| |
| ARB_texture_cube_map |
| |
| Name Strings |
| |
| GL_ARB_texture_cube_map |
| |
| Contact |
| |
| Michael Gold, NVIDIA (gold 'at' nvidia.com) |
| |
| Notice |
| |
| Copyright (c) 1999-2013 The Khronos Group Inc. Copyright terms at |
| http://www.khronos.org/registry/speccopyright.html |
| |
| Specification Update Policy |
| |
| Khronos-approved extension specifications are updated in response to |
| issues and bugs prioritized by the Khronos OpenGL Working Group. For |
| extensions which have been promoted to a core Specification, fixes will |
| first appear in the latest version of that core Specification, and will |
| eventually be backported to the extension document. This policy is |
| described in more detail at |
| https://www.khronos.org/registry/OpenGL/docs/update_policy.php |
| |
| Status |
| |
| Complete. Approved by ARB on 12/8/1999 |
| |
| Version |
| |
| Last Modified Date: December 14, 1999 |
| |
| Number |
| |
| ARB Extension #7 |
| |
| Dependencies |
| |
| None. |
| |
| Written based on the wording of the OpenGL 1.2.1 specification but |
| not dependent on it. |
| |
| Overview |
| |
| This extension provides a new texture generation scheme for cube |
| map textures. Instead of the current texture providing a 1D, 2D, |
| or 3D lookup into a 1D, 2D, or 3D texture image, the texture is a |
| set of six 2D images representing the faces of a cube. The (s,t,r) |
| texture coordinates are treated as a direction vector emanating from |
| the center of a cube. At texture generation time, the interpolated |
| per-fragment (s,t,r) selects one cube face 2D image based on the |
| largest magnitude coordinate (the major axis). A new 2D (s,t) is |
| calculated by dividing the two other coordinates (the minor axes |
| values) by the major axis value. Then the new (s,t) is used to |
| lookup into the selected 2D texture image face of the cube map. |
| |
| Unlike a standard 1D, 2D, or 3D texture that have just one target, |
| a cube map texture has six targets, one for each of its six 2D texture |
| image cube faces. All these targets must be consistent, complete, |
| and have equal width and height (ie, square dimensions). |
| |
| This extension also provides two new texture coordinate generation modes |
| for use in conjunction with cube map texturing. The reflection map |
| mode generates texture coordinates (s,t,r) matching the vertex's |
| eye-space reflection vector. The reflection map mode |
| is useful for environment mapping without the singularity inherent |
| in sphere mapping. The normal map mode generates texture coordinates |
| (s,t,r) matching the vertex's transformed eye-space |
| normal. The normal map mode is useful for sophisticated cube |
| map texturing-based diffuse lighting models. |
| |
| The intent of the new texgen functionality is that an application using |
| cube map texturing can use the new texgen modes to automatically |
| generate the reflection or normal vectors used to look up into the |
| cube map texture. |
| |
| An application note: When using cube mapping with dynamic cube |
| maps (meaning the cube map texture is re-rendered every frame), |
| by keeping the cube map's orientation pointing at the eye position, |
| the texgen-computed reflection or normal vector texture coordinates |
| can be always properly oriented for the cube map. However if the |
| cube map is static (meaning that when view changes, the cube map |
| texture is not updated), the texture matrix must be used to rotate |
| the texgen-computed reflection or normal vector texture coordinates |
| to match the orientation of the cube map. The rotation can be |
| computed based on two vectors: 1) the direction vector from the cube |
| map center to the eye position (both in world coordinates), and 2) |
| the cube map orientation in world coordinates. The axis of rotation |
| is the cross product of these two vectors; the angle of rotation is |
| the arcsin of the dot product of these two vectors. |
| |
| Issues |
| |
| Should we place the normal/reflection vector in the (s,t,r) texture |
| coordinates or (s,t,q) coordinates? |
| |
| RESOLUTION: (s,t,r). Even if hardware uses "q" for the third |
| component, the API should claim to support generation of (s,t,r) |
| and let the texture matrix (through a concatenation with the |
| user-supplied texture matrix) move "r" into "q". |
| |
| Should the texture coordinate generation functionality for cube |
| mapping be specified as a distinct extension from the actual cube |
| map texturing functionality? |
| |
| RESOLUTION: NO. Real applications and real implementations of |
| cube mapping will tie the texgen and texture generation functionality |
| together. Applications won't have to query two separate |
| extensions then. |
| |
| While applications will almost always want to use the texgen |
| functionality for automatically generating the reflection or normal |
| vector as texture coordinates (s,t,r), this extension does permit |
| an application to manually supply the reflection or normal vector |
| through glTexCoord3f explicitly. |
| |
| Note that the NV_texgen_reflection extension does "unbundle" |
| the texgen functionality from cube maps. |
| |
| Should you be able to have some texture coordinates computing |
| REFLECTION_MAP_ARB and others not? Same question with NORMAL_MAP_ARB. |
| |
| RESOLUTION: YES. This is the way that SPHERE_MAP works. It is |
| not clear that this would ever be useful though. |
| |
| Should something special be said about the handling of the q |
| texture coordinate for this spec? |
| |
| RESOLUTION: NO. But the following paragraph is useful for |
| implementors concerned about the handling of q. |
| |
| The REFLECTION_MAP_ARB and NORMAL_MAP_ARB modes are intended to supply |
| reflection and normal vectors for cube map texturing hardware. |
| When these modes are used for cube map texturing, the generated |
| texture coordinates can be thought of as an reflection vector. |
| The value of the q texture coordinate then simply scales the |
| vector but does not change its direction. Because only the vector |
| direction (not the vector magnitude) matters for cube map texturing, |
| implementations are free to leave q undefined when any of the s, |
| t, or r texture coordinates are generated using REFLECTION_MAP_ARB |
| or NORMAL_MAP_ARB. |
| |
| How should the cube faces be labeled? |
| |
| RESOLUTION: Match the render man specification's names of "px" |
| (positive X), "nx" (negative x), "py", "ny", "pz", and "nz". |
| There does not actually need to be an "ordering for the faces" |
| (Direct3D 7.0 does number their cube map faces.) For this |
| extension, the symbolic target names (TEXTURE_CUBE_MAP_POSITIVE_X_ARB, |
| etc) is sufficient without requiring any specific ordering. |
| |
| What coordinate system convention should be used? LHS or RHS? |
| |
| RESOLUTION: The coordinate system is left-handed if you think |
| of yourself within the cube. The coordinate system is |
| right-handed if you think of yourself outside the cube. |
| |
| This matches the convention of the RenderMan interface. If |
| you look at Figure 12.8 (page 265) in "The RenderMan Companion", |
| think of the cube being folded up with the observer inside |
| the cube. Then the coordinate system convention is |
| left-handed. |
| |
| The spec just linearly interpolates the reflection vectors computed |
| per-vertex across polygons. Is there a problem interpolating |
| reflection vectors in this way? |
| |
| Probably. The better approach would be to interpolate the eye |
| vector and normal vector over the polygon and perform the reflection |
| vector computation on a per-fragment basis. Not doing so is likely |
| to lead to artifacts because angular changes in the normal vector |
| result in twice as large a change in the reflection vector as normal |
| vector changes. The effect is likely to be reflections that become |
| glancing reflections too fast over the surface of the polygon. |
| |
| Note that this is an issue for REFLECTION_MAP_ARB, but not |
| NORMAL_MAP_ARB. |
| |
| What happens if an (s,t,q) is passed to cube map generation that |
| is close to (0,0,0), ie. a degenerate direction vector? |
| |
| RESOLUTION: Leave undefined what happens in this case (but |
| may not lead to GL interruption or termination). |
| |
| Note that a vector close to (0,0,0) may be generated as a |
| result of the per-fragment interpolation of (s,t,r) between |
| vertices. |
| |
| Do we need a distinct proxy texture mechanism for cube map |
| textures? |
| |
| RESOLUTION: YES. Cube map textures take up six times the |
| memory as a conventional 2D image texture so proxy 2D texture |
| determinations won't be of value for a cube map texture. |
| Cube maps need their own proxy target. |
| |
| Should we require the 2D texture image width and height to |
| be identical (ie, square only)? |
| |
| RESOLUTION: YES. This limitation is quite a reasonable limitation |
| and DirectX 7 has the same limitation. |
| |
| This restriction is enforced by generating an INVALID_VALUE |
| when calling TexImage2D or CopyTexImage2D with a non-equal |
| width and height. |
| |
| Some consideration was given to enforcing the "squarness" |
| constraint as a texture consistency constraint. This is |
| confusing however since the squareness is known up-front |
| at texture image specification time so it seems confusing |
| to silently report the usage error as a texture consistency |
| issue. |
| |
| Texture consistency still says that all the level 0 textures |
| of all six faces must have the same square size. |
| |
| If some combination of 1D, 2D, 3D, and cube map texturing is |
| enabled, which really operates? |
| |
| RESOLUTION: Cube map texturing. In OpenGL 1.2, 3D takes |
| priority over 2D takes priority over 1D. Cube mapping should |
| take priority over all conventional n-dimensional texturing |
| schemes. |
| |
| Does anything need to be said about combining cube mapping with |
| multitexture? |
| |
| RESOLUTION: NO. Cube mapping should be available on all texture |
| units. The hardware should fully orthogonal in its handling of |
| cube map textures. |
| |
| Does it make sense to support borders for cube map textures. |
| |
| Actually, it does. It would be nice if the texture border pixels |
| match the appropriate texels from the edges of the other cube map |
| faces that they junction with. For this reason, we'll leave the |
| texture border capability implicitly supported. |
| |
| How does mipmap level-of-detail selection work for cube map |
| textures? |
| |
| The existing spec's language about LOD selection is fine. |
| |
| Should the implementation dependent value for the maximum |
| texture size for a cube map be the same as MAX_TEXTURE_SIZE? |
| |
| RESOLUTION: NO. OpenGL 1.2 has a different MAX_3D_TEXTURE_SIZE |
| for 3D textures, and cube maps should take six times more space |
| than a 2D texture map of the same width & height. The implementation |
| dependent MAX_CUBE_MAP_TEXTURE_SIZE_ARB constant should be used for |
| cube maps then. |
| |
| Note that the proxy cube map texture provides a better way to |
| find out the maximum cube map texture size supported since the |
| proxy mechanism can take into account the internal format, etc. |
| |
| In section 3.8.10 when the "largest magnitude coordinate direction" |
| is choosen, what happens if two or more of the coordinates (rx,ry,rz) |
| have the identical magnitude? |
| |
| RESOLUTION: Implementations can define their own rule to choose |
| the largest magnitude coordinate direction whne two or more of the |
| coordinates have the identical magnitude. The only restriction is |
| that the rule must be deterministic and depend only on (rx,ry,rz). |
| |
| In practice, (s,t,r) is interpolated across polygons so the cases |
| where |s|==|t|, etc. are pretty arbitary (the equality depends on |
| interpolation precision). This extension could mandate a particular |
| rule, but that seems heavy-handed and there is no good reason that |
| multiple vendors should be forced to implement the same rule. |
| |
| Should there be limits on the supported border modes for cube maps? |
| |
| RESOLUTION: NO. The specificiation is written so that cube map |
| texturing proceeds just like conventional 2D texture mapping once |
| the face determination is made. |
| |
| Therefore, all OpenGL texture wrap modes should be supported though |
| some modes are clearly inappropriate for cube maps. The WRAP mode |
| is almost certainly incorrect for cube maps. Likewise, the CLAMP |
| mode without a texture border is almost certainly incorrect for cube |
| maps. CLAMP when a texture border is present and CLAMP_TO_EDGE are |
| both reasonably suited for cube maps. Ideally, CLAMP with a texture |
| border works best if the cube map edges can be replicated in the |
| approriate texture borders of adjacent cube map faces. In practice, |
| CLAMP_TO_EDGE works reasonably well in most circumstances. |
| |
| Perhaps another extension could support a special cube map wrap |
| mode that automatically wraps individual texel fetches to the |
| appropriate adjacent cube map face. The benefit from such a mode |
| is small and the implementation complexity is involved so this wrap |
| mode should not be required for a basic cube map texture extension. |
| |
| How is mipmap LOD selection handled for cube map textures? |
| |
| RESOLUTION: The specification is written so that cube map texturing |
| proceeds just like conventional 2D texture mapping once the face |
| determination is made. |
| |
| Thereforce, the partial differentials in Section 3.8.5 (page |
| 126) should be evaluated for the u and v parameters based on the |
| post-face determination s and t. |
| |
| In Section 2.10.3 "Normal Transformation", there are several versions |
| of the eye-space normal vector to choose from. Which one should |
| the NORMAL_MAP_ARB texgen mode use? |
| |
| RESOLUTION: nf. The nf vector is the final normal, post-rescale |
| normal and post-normalize. In practice, the rescale normal and |
| normalize operations do not change the direction of the vector |
| so the choice of which version of transformed normal is used is |
| not important for cube maps. |
| |
| New Procedures and Functions |
| |
| None |
| |
| New Tokens |
| |
| Accepted by the <param> parameters of TexGend, TexGenf, and TexGeni |
| when <pname> parameter is TEXTURE_GEN_MODE: |
| |
| NORMAL_MAP_ARB 0x8511 |
| REFLECTION_MAP_ARB 0x8512 |
| |
| When the <pname> parameter of TexGendv, TexGenfv, and TexGeniv is |
| TEXTURE_GEN_MODE, then the array <params> may also contain |
| NORMAL_MAP_ARB or REFLECTION_MAP_ARB. |
| |
| Accepted by the <cap> parameter of Enable, Disable, IsEnabled, and |
| by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, |
| and GetDoublev, and by the <target> parameter of BindTexture, |
| GetTexParameterfv, GetTexParameteriv, TexParameterf, TexParameteri, |
| TexParameterfv, and TexParameteriv: |
| |
| TEXTURE_CUBE_MAP_ARB 0x8513 |
| |
| Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, |
| GetFloatv, and GetDoublev: |
| |
| TEXTURE_BINDING_CUBE_MAP_ARB 0x8514 |
| |
| Accepted by the <target> parameter of GetTexImage, |
| GetTexLevelParameteriv, GetTexLevelParameterfv, TexImage2D, |
| CopyTexImage2D, TexSubImage2D, and CopySubTexImage2D: |
| |
| TEXTURE_CUBE_MAP_POSITIVE_X_ARB 0x8515 |
| TEXTURE_CUBE_MAP_NEGATIVE_X_ARB 0x8516 |
| TEXTURE_CUBE_MAP_POSITIVE_Y_ARB 0x8517 |
| TEXTURE_CUBE_MAP_NEGATIVE_Y_ARB 0x8518 |
| TEXTURE_CUBE_MAP_POSITIVE_Z_ARB 0x8519 |
| TEXTURE_CUBE_MAP_NEGATIVE_Z_ARB 0x851A |
| |
| Accepted by the <target> parameter of GetTexLevelParameteriv, |
| GetTexLevelParameterfv, GetTexParameteriv, and TexImage2D: |
| |
| PROXY_TEXTURE_CUBE_MAP_ARB 0x851B |
| |
| Accepted by the <pname> parameter of GetBooleanv, GetDoublev, |
| GetIntegerv, and GetFloatv: |
| |
| MAX_CUBE_MAP_TEXTURE_SIZE_ARB 0x851C |
| |
| Additions to Chapter 2 of the 1.2 Specification (OpenGL Operation) |
| |
| -- Section 2.10.4 "Generating Texture Coordinates" |
| |
| Change the last sentence in the 1st paragraph (page 37) to: |
| |
| "If <pname> is TEXTURE_GEN_MODE, then either <params> points to |
| or <param> is an integer that is one of the symbolic constants |
| OBJECT_LINEAR, EYE_LINEAR, SPHERE_MAP, REFLECTION_MAP_ARB, or |
| NORMAL_MAP_ARB." |
| |
| Add these paragraphs after the 4th paragraph (page 38): |
| |
| "If TEXTURE_GEN_MODE indicates REFLECTION_MAP_ARB, compute the |
| reflection vector r as described for the SPHERE_MAP mode. Then the |
| value assigned to an s coordinate (the first TexGen argument value |
| is S) is s = rx; the value assigned to a t coordinate is t = ry; |
| and the value assigned to a r coordinate is r = rz. Calling TexGen |
| with a <coord> of Q when <pname> indicates REFLECTION_MAP_ARB |
| generates the error INVALID_ENUM. |
| |
| If TEXTURE_GEN_MODE indicates NORMAL_MAP_ARB, compute the normal |
| vector nf as described in section 2.10.3. Then the value assigned |
| to an s coordinate (the first TexGen argument value is S) is s = |
| nfx; the value assigned to a t coordinate is t = nfy; and the |
| value assigned to a r coordinate is r = nfz. (The values nfx, nfy, |
| and nfz are the components of nf.) Calling TexGen with a <coord> |
| of Q when <pname> indicates NORMAL_MAP_ARB generates the error |
| INVALID_ENUM. |
| |
| The last paragraph's first sentence (page 38) should be changed to: |
| |
| "The state required for texture coordinate generation comprises a |
| five-valued integer for each coordinate indicating coordinate |
| generation mode, ..." |
| |
| Additions to Chapter 3 of the 1.2 Specification (Rasterization) |
| |
| -- Section 3.6.5 "Pixel Transfer Operations" under "Convolution" |
| |
| Change this paragraph (page 103) to say: |
| |
| ... "If CONVOLUTION_2D is enabled, the two-dimensional convolution |
| filter is applied only to the two-dimensional images passed to |
| DrawPixels, CopyPixels, ReadPixels, TexImage2D, TexSubImage2D, |
| CopyTexImage2D, CopyTexSubImage2D, and CopyTexSubImage3D, and |
| returned by GetTexImage with one of the targets TEXTURE_2D, |
| TEXTURE_CUBE_MAP_POSITIVE_X_ARB, TEXTURE_CUBE_MAP_NEGATIVE_X_ARB, |
| TEXTURE_CUBE_MAP_POSITIVE_Y_ARB, TEXTURE_CUBE_MAP_NEGATIVE_Y_ARB, |
| TEXTURE_CUBE_MAP_POSITIVE_Z_ARB, or TEXTURE_CUBE_MAP_NEGATIVE_Z_ARB." |
| |
| -- Section 3.8.1 "Texture Image Specification" |
| |
| Change the second and third to last sentences on page 116 to: |
| |
| "<target> must be one of TEXTURE_2D for a 2D texture, or one of |
| TEXTURE_CUBE_MAP_POSITIVE_X_ARB, TEXTURE_CUBE_MAP_NEGATIVE_X_ARB, |
| TEXTURE_CUBE_MAP_POSITIVE_Y_ARB, TEXTURE_CUBE_MAP_NEGATIVE_Y_ARB, |
| TEXTURE_CUBE_MAP_POSITIVE_Z_ARB, or TEXTURE_CUBE_MAP_NEGATIVE_Z_ARB |
| for a cube map texture. Additionally, <target> can be either |
| PROXY_TEXTURE_2D for a 2D proxy texture or PROXY_TEXTURE_CUBE_MAP_ARB |
| for a cube map proxy texture as discussed in section 3.8.7." |
| |
| Add the following paragraphs after the first paragraph on page 117: |
| |
| "A 2D texture consists of a single 2D texture image. A cube |
| map texture is a set of six 2D texture images. The six cube map |
| texture targets form a single cube map texture though each target |
| names a distinct face of the cube map. The TEXTURE_CUBE_MAP_*_ARB |
| targets listed above update their appropriate cube map face 2D |
| texture image. Note that the six cube map 2D image tokens such as |
| TEXTURE_CUBE_MAP_POSITIVE_X_ARB are used when specifying, updating, |
| or querying one of a cube map's six 2D image, but when enabling |
| cube map texturing or binding to a cube map texture object (that is |
| when the cube map is accessed as a whole as opposed to a particular |
| 2D image), the TEXTURE_CUBE_MAP_ARB target is specified. |
| |
| When the target parameter to TexImage2D is one of the six cube map |
| 2D image targets, the error INVALID_VALUE is generated if the width |
| and height parameters are not equal. |
| |
| If cube map texturing is enabled at the time a primitive is |
| rasterized and if the set of six targets are not "cube complete", |
| then it is as if texture mapping were disabled. The targets of |
| a cube map texture are "cube complete" if the array 0 of all six |
| targets have identical, positive, and square dimensions, the array |
| 0 of all six targets were specified with the same internalformat, |
| and the array 0 of all six targets have the same border width." |
| |
| After the 14th paragraph (page 116) add: |
| |
| "In a similiar fashion, the maximum allowable width and height |
| (they must be the same) of a cube map texture must be at least |
| 2^(k-lod)+2bt for image arrays level 0 through k, where k is the |
| log base 2 of MAX_CUBE_MAP_TEXTURE_SIZE_ARB." |
| |
| -- Section 3.8.2 "Alternate Texture Image Specification Commands" |
| |
| Update the second paragraph (page 120) to say: |
| |
| ... "Currently, <target> must be |
| TEXTURE_2D, TEXTURE_CUBE_MAP_POSITIVE_X_ARB, |
| TEXTURE_CUBE_MAP_NEGATIVE_X_ARB, TEXTURE_CUBE_MAP_POSITIVE_Y_ARB, |
| TEXTURE_CUBE_MAP_NEGATIVE_Y_ARB, TEXTURE_CUBE_MAP_POSITIVE_Z_ARB, |
| or TEXTURE_CUBE_MAP_NEGATIVE_Z_ARB." ... |
| |
| Add after the second paragraph (page 120), the following: |
| |
| "When the target parameter to CopyTexImage2D is one of the six cube |
| map 2D image targets, the error INVALID_VALUE is generated if the |
| width and height parameters are not equal." |
| |
| Update the fourth paragraph (page 121) to say: |
| |
| ... "Currently the target arguments of TexSubImage1D and |
| CopyTexSubImage1D must be TEXTURE_1D, the <target> arguments of |
| TexSubImage2D and CopyTexSubImage2D must be one of TEXTURE_2D, |
| TEXTURE_CUBE_MAP_POSITIVE_X_ARB, TEXTURE_CUBE_MAP_NEGATIVE_X_ARB, |
| TEXTURE_CUBE_MAP_POSITIVE_Y_ARB, TEXTURE_CUBE_MAP_NEGATIVE_Y_ARB, |
| TEXTURE_CUBE_MAP_POSITIVE_Z_ARB, or TEXTURE_CUBE_MAP_NEGATIVE_Z_ARB, |
| and the <target> arguments of TexSubImage3D and CopyTexSubImage3D |
| must be TEXTURE_3D." ... |
| |
| -- Section 3.8.3 "Texture Parameters" |
| |
| Change paragraph one (page 124) to say: |
| |
| ... "<target> is the target, either TEXTURE_1D, |
| TEXTURE_2D, TEXTURE_3D, or TEXTURE_CUBE_MAP_ARB." ... |
| |
| Add a final paragraph saying: |
| |
| "Texture parameters for a cube map texture apply to cube map |
| as a whole; the six distinct 2D texture images use the |
| texture parameters of the cube map itself. |
| |
| -- Section 3.8.5 "Texture Minification" under "Mipmapping" |
| |
| Change the first full paragraph on page 130 to: |
| |
| ... "If texturing is enabled for one-, two-, or three-dimensional |
| texturing but not cube map texturing (and TEXTURE_MIN_FILTER |
| is one that requires a mipmap) at the time a primitive is |
| rasterized and if the set of arrays TEXTURE_BASE_LEVEL through q = |
| min{p,TEXTURE_MAX_LEVEL} is incomplete, based on the dimensions of |
| array 0, then it is as if texture mapping were disabled." |
| |
| Follow the first full paragraph on page 130 with: |
| |
| "If cube map texturing is enabled and TEXTURE_MIN_FILTER is one that |
| requires mipmap levels at the time a primitive is rasterized and |
| if the set of six targets are not "mipmap cube complete", then it |
| is as if texture mapping were disabled. The targets of a cube map |
| texture are "mipmap cube complete" if the six cube map targets are |
| "cube complete" and the set of arrays TEXTURE_BASE_LEVEL through |
| q are not incomplete (as described above)." |
| |
| -- Section 3.8.7 "Texture State and Proxy State" |
| |
| Change the first sentence of the first paragraph (page 131) to say: |
| |
| "The state necessary for texture can be divided into two categories. |
| First, there are the nine sets of mipmap arrays (one each for the |
| one-, two-, and three-dimensional texture targets and six for the |
| cube map texture targets) and their number." ... |
| |
| Change the second paragraph (page 132) to say: |
| |
| "In addition to the one-, two-, three-dimensional, and the six cube |
| map sets of image arrays, the partially instantiated one-, two-, |
| and three-dimensional and one cube map sets of proxy image arrays |
| are maintained." ... |
| |
| After the third paragraph (page 132) add: |
| |
| "The cube map proxy arrays are operated on in the same manner |
| when TexImage2D is executed with the <target> field specified as |
| PROXY_TEXTURE_CUBE_MAP_ARB with the addition that determining that a |
| given cube map texture is supported with PROXY_TEXTURE_CUBE_MAP_ARB |
| indicates that all six of the cube map 2D images are supported. |
| Likewise, if the specified PROXY_TEXTURE_CUBE_MAP_ARB is not |
| supported, none of the six cube map 2D images are supported." |
| |
| Change the second sentence of the fourth paragraph (page 132) to: |
| |
| "Therefore PROXY_TEXTURE_1D, PROXY_TEXTURE_2D, PROXY_TEXTURE_3D, |
| and PROXY_TEXTURE_CUBE_MAP_ARB cannot be used as textures, and their |
| images must never be queried using GetTexImage." ... |
| |
| -- Section 3.8.8 "Texture Objects" |
| |
| Change the first sentence of the first paragraph (page 132) to say: |
| |
| "In addition to the default textures TEXTURE_1D, TEXTURE_2D, |
| TEXTURE_3D, and TEXTURE_CUBE_MAP_ARB, named one-, two-, |
| and three-dimensional texture objects and cube map texture objects |
| can be created and operated on." ... |
| |
| Change the second paragraph (page 132) to say: |
| |
| "A texture object is created by binding an unused name to |
| TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, or TEXTURE_CUBE_MAP_ARB." ... |
| "If the new texture object is bound to TEXTURE_1D, TEXTURE_2D, |
| TEXTURE_3D, or TEXTURE_CUBE_MAP_ARB, it remains a one-, two-, |
| three-dimensional, or cube map texture until it is deleted." |
| |
| Change the third paragraph (page 133) to say: |
| |
| "BindTexture may also be used to bind an existing texture object to |
| either TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, or TEXTURE_CUBE_MAP_ARB." |
| |
| Change paragraph five (page 133) to say: |
| |
| "In the initial state, TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, |
| and TEXTURE_CUBE_MAP have one-dimensional, two-dimensional, |
| three-dimensional, and cube map state vectors associated |
| with them respectively." ... "The initial, one-dimensional, |
| two-dimensional, three-dimensional, and cube map texture is therefore |
| operated upon, queried, and applied as TEXTURE_1D, TEXTUER_2D, |
| TEXTURE_3D, and TEXTURE_CUBE_MAP_ARB respectively while 0 is bound |
| to the corresponding targets." |
| |
| Change paragraph six (page 133) to say: |
| |
| ... "If a texture that is currently bound to one of the targets |
| TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, or TEXTURE_CUBE_MAP_ARB is |
| deleted, it is as though BindTexture has been executed with the |
| same <target> and <texture> zero." ... |
| |
| -- Section 3.8.10 "Texture Application" |
| |
| Replace the beginning sentences of the first paragraph (page 138) |
| with: |
| |
| "Texturing is enabled or disabled using the generic Enable |
| and Disable commands, respectively, with the symbolic constants |
| TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, or TEXTURE_CUBE_MAP_ARB to enable |
| the one-dimensional, two-dimensional, three-dimensional, or cube |
| map texturing 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 texturing is disabled, |
| a rasterized fragment is passed on unaltered to the next stage of the |
| GL (although its texture coordinates may be discarded). Otherwise, |
| a texture value is found according to the parameter values of the |
| currently bound texture image of the appropriate dimensionality. |
| |
| However, when cube map texturing is enabled, the rules are |
| more complicated. For cube map texturing, the (s,t,r) texture |
| coordinates are treated as a direction vector (rx,ry,rz) emanating |
| from the center of a cube. (The q coordinate can be ignored since |
| it merely scales the vector without affecting the direction.) At |
| texture application time, the interpolated per-fragment (s,t,r) |
| selects one of the cube map face's 2D image based on the largest |
| magnitude coordinate direction (the major axis direction). If two |
| or more coordinates have the identical magnitude, the implementation |
| may define the rule to disambiguate this situation. The rule must |
| be deterministic and depend only on (rx,ry,rz). The target column |
| in the table below explains how the major axis direction maps to |
| the 2D image of a particular cube map target. |
| |
| major axis |
| direction target sc tc ma |
| ---------- ------------------------------- --- --- --- |
| +rx TEXTURE_CUBE_MAP_POSITIVE_X_ARB -rz -ry rx |
| -rx TEXTURE_CUBE_MAP_NEGATIVE_X_ARB +rz -ry rx |
| +ry TEXTURE_CUBE_MAP_POSITIVE_Y_ARB +rx +rz ry |
| -ry TEXTURE_CUBE_MAP_NEGATIVE_Y_ARB +rx -rz ry |
| +rz TEXTURE_CUBE_MAP_POSITIVE_Z_ARB +rx -ry rz |
| -rz TEXTURE_CUBE_MAP_NEGATIVE_Z_ARB -rx -ry rz |
| |
| Using the sc, tc, and ma determined by the major axis direction as |
| specified in the table above, an updated (s,t) is calculated as |
| follows |
| |
| s = ( sc/|ma| + 1 ) / 2 |
| t = ( tc/|ma| + 1 ) / 2 |
| |
| This new (s,t) is used to find a texture value in the determined |
| face's 2D texture image using the rules given in sections 3.8.5 |
| and 3.8.6." ... |
| |
| Additions to Chapter 4 of the 1.2 Specification (Per-Fragment Operations |
| and the Frame Buffer) |
| |
| None |
| |
| Additions to Chapter 5 of the 1.2 Specification (Special Functions) |
| |
| -- Section 5.4 "Display Lists" |
| |
| In the first paragraph (page 179), add PROXY_TEXTURE_CUBE_MAP_ARB |
| to the list of PROXY_* tokens. |
| |
| Additions to Chapter 6 of the 1.2 Specification (State and State Requests) |
| |
| -- Section 6.1.3 "Enumerated Queries" |
| |
| Change the fourth paragraph (page 183) to say: |
| |
| "The GetTexParameter parameter <target> may be one of TEXTURE_1D, |
| TEXTURE_2D, TEXTURE_3D, or TEXTURE_CUBE_MAP_ARB, indicating the |
| currently bound one-dimensional, two-dimensional, three-dimensional, |
| or cube map texture object. For GetTexLevelParameter, |
| <target> may be one of TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, |
| TEXTURE_CUBE_MAP_POSITIVE_X_ARB, TEXTURE_CUBE_MAP_NEGATIVE_X_ARB, |
| TEXTURE_CUBE_MAP_POSITIVE_Y_ARB, TEXTURE_CUBE_MAP_NEGATIVE_Y_ARB, |
| TEXTURE_CUBE_MAP_POSITIVE_Z_ARB, TEXTURE_CUBE_MAP_NEGATIVE_Z_ARB, |
| PROXY_TEXTURE_1D, PROXY_TEXTURE_2D, PROXY_TEXTURE_3D, or |
| PROXY_TEXTURE_CUBE_MAP_ARB, indicating the one-dimensional |
| texture object, two-dimensional texture object, three-dimensional |
| texture object, or one of the six distinct 2D images making up |
| the cube map texture object or one-dimensional, two-dimensional, |
| three-dimensional, or cube map proxy state vector. Note that |
| TEXTURE_CUBE_MAP_ARB is not a valid <target> parameter for |
| GetTexLevelParameter because it does not specify a particular cube |
| map face." |
| |
| -- Section 6.1.4 "Texture Queries" |
| |
| Change the first paragraph (page 184) to read: |
| |
| ... "It is somewhat different from the other get commands; <tex> |
| is a symbolic value indicating which texture (or texture face in the |
| case of a cube map texture target name) is to be obtained. |
| TEXTURE_1D indicates a one-dimensional texture, TEXTURE_2D |
| indicates a two-dimensional texture, TEXTURE_3D indicates a |
| three-dimensional texture, and TEXTURE_CUBE_MAP_POSITIVE_X_ARB, |
| TEXTURE_CUBE_MAP_NEGATIVE_X_ARB, TEXTURE_CUBE_MAP_POSITIVE_Y_ARB, |
| TEXTURE_CUBE_MAP_NEGATIVE_Y_ARB, TEXTURE_CUBE_MAP_POSITIVE_Z_ARB, |
| and TEXTURE_CUBE_MAP_NEGATIVE_Z_ARB indicate the respective face of |
| a cube map texture. |
| |
| Additions to the GLX Specification |
| |
| None |
| |
| Errors |
| |
| INVALID_ENUM is generated when TexGen is called with a <coord> of Q |
| when <pname> indicates REFLECTION_MAP_ARB or NORMAL_MAP_ARB. |
| |
| INVALID_VALUE is generated when the target parameter to TexImage2D |
| or CopyTexImage2D is one of the six cube map 2D image targets and |
| the width and height parameters are not equal. |
| |
| New State |
| |
| (table 6.12, p202) add the following entries: |
| |
| Get Value Type Get Command Initial Value Description Sec Attribute |
| --------- ---- ----------- ------------- ----------- ------ -------------- |
| TEXTURE_CUBE_MAP_ARB B IsEnabled False True if cube map 3.8.10 texture/enable |
| texturing is enabled |
| TEXTURE_BINDING_CUBE_MAP_ARB Z+ GetIntegerv 0 Texture object 3.8.8 texture |
| for TEXTURE_CUBE_MAP |
| TEXTURE_CUBE_MAP_POSITIVE_X_ARB nxI GetTexImage see 3.8 positive x face 3.8 - |
| cube map texture |
| image at lod i |
| TEXTURE_CUBE_MAP_NEGATIVE_X_ARB nxI GetTexImage see 3.8 negative x face 3.8 - |
| cube map texture |
| image at lod i |
| TEXTURE_CUBE_MAP_POSITIVE_Y_ARB nxI GetTexImage see 3.8 positive y face 3.8 - |
| cube map texture |
| image at lod i |
| TEXTURE_CUBE_MAP_NEGATIVE_Y_ARB nxI GetTexImage see 3.8 negative y face 3.8 - |
| cube map texture |
| image at lod i |
| TEXTURE_CUBE_MAP_POSITIVE_Z_ARB nxI GetTexImage see 3.8 positive z face 3.8 - |
| cube map texture |
| image at lod i |
| TEXTURE_CUBE_MAP_NEGATIVE_Z_ARB nxI GetTexImage see 3.8 negative z face 3.8 - |
| cube map texture |
| image at lod i |
| |
| (table 6.14, p204) change the entry for TEXTURE_GEN_MODE to: |
| |
| Get Value Type Get Command Initial Value Description Sec Attribute |
| --------- ---- ----------- ------------- ----------- ------ --------- |
| TEXTURE_GEN_MODE 4xZ5 GetTexGeniv EYE_LINEAR Function used for 2.10.4 texture |
| texgen (for s,t,r, |
| and q) |
| |
| (the type changes from 4xZ3 to 4xZ5) |
| |
| New Implementation Dependent State |
| |
| (table 6.24, p214) add the following entry: |
| |
| Get Value Type Get Command Minimum Value Description Sec Attribute |
| --------- ---- ----------- ------------- ----------- ------ -------------- |
| MAX_CUBE_MAP_TEXTURE_SIZE_ARB Z+ GetIntegerv 16 Maximum cube map 3.8.1 - |
| texture image |
| dimension |
| |
| Backwards Compatibility |
| |
| This extension replaces EXT_texture_cube_map. The tokens and |
| name strings now refer to ARB instead of EXT. Enumerant values |
| are unchanged. |