xref: /third_party/openGLES/extensions/ARB/ARB_texture_cube_map.txt

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.