| Name | |
| APPLE_float_pixels | |
| Name Strings | |
| GL_APPLE_float_pixels | |
| Contact | |
| Geoff Stahl, Apple (gstahl 'at' apple.com) | |
| Jeremy Sandmel, Apple (jsandmel 'at' apple.com) | |
| Status | |
| Shipping Mac OS X v10.2.3 (version 1.0) | |
| Version | |
| 1.0 | |
| Number | |
| 368 | |
| Dependencies | |
| Written based on the wording of the OpenGL 2.0 specification. | |
| Depends on (but does not require) ARB_texture_float | |
| Depends on (but does not require) ARB_color_buffer_float | |
| Depends on (but does not require) ARB_half_float_pixel | |
| Interacts with APPLEX_texture_float_16_filter. | |
| Interacts with APPLEX_color_buffer_float_16_blend. | |
| Overview | |
| This extensions adds texture types, texture internal formats and | |
| color buffers composed of both 32 bit and 16 floating point numbers. | |
| 16 bit floats (half float) are very similar to the IEEE | |
| single-precision floating-point standard, except that it has only 5 | |
| exponent bits and 10 mantissa bits. All floating point numbers are | |
| clamped to the limits of the range representable by their respective | |
| format. | |
| Specifically, APPLE_float_pixels adds four pieces of functionality | |
| to OpenGL. First, it provides an HALF_APPLE texture type allowing | |
| clients to pass textures in the half float format. Second, it adds | |
| 12 additional sized internal formats to allow OpenGL to process and | |
| maintain texture data in the requested format if possible. Next, it | |
| provides the COLOR_FLOAT_APPLE pixel format to allow creation of | |
| floating point and half float color buffers. Lastly, it provides an | |
| additional query to allow clients to verify that they have a | |
| floating point color buffer. | |
| The HALF_APPLE texture type allows clients to use source textures | |
| composed of half float color components. This constant is use in | |
| the type parameter in DrawPixels, ReadPixels and texturing commands | |
| with a corresponding GL half data type, which corresponds to a 16 | |
| bit half float, and has no special interpretation. | |
| Clients can use the 12 additional (6 floating point and 6 half | |
| float) sized internal texture formats to specify the mapping of R, | |
| G, B and A values to texture components, as they would with any | |
| other sized internal texture format. Note, as is the standard | |
| practice with OpenGL, implementations should map the sized internal | |
| texture R, G, B and A values to internal components with memory | |
| allocations as close as possible to those specified in the sized | |
| internal format. | |
| Floating point color buffers are created by specifying the | |
| appropriate color floating point pixel format attribute for the | |
| windowing system API in use by the client. Both 128 bit and 64 bit | |
| floating point color buffers can be supported, the former with full | |
| 32 bit floating point components and the latter with 16 bit half | |
| float components. | |
| Additionally, clients can query to see if they have a floating point | |
| color buffer using GetBooleanv with COLOR_FLOAT_APPLE as the get | |
| value. The number of bits per color buffer component can be | |
| determined in the usual manner. | |
| Issues: | |
| 1. How is this extension different from the ARB floating point extensions? | |
| Conceptually, this extension can be considered the union of the | |
| feature sets from the following extensions: | |
| ARB_texture_float | |
| ARB_color_buffer_float | |
| ARB_half_float_pixel | |
| with the following EXCEPTIONS: | |
| * this extension does not support the the per-component | |
| query of TEXTURE_*_TYPE from ARB_texture_float. | |
| * this extension only supports the half float pixel type | |
| from ARB_half_float_pixel for {Draw|Read}|Pixels and | |
| Tex{Sub}Image{1D|2D|3D}, and for color buffers as | |
| described by ARB_color_buffer_float. (Note: unlike the | |
| ARB_half_float extension, APPLE_float_pixels does not | |
| support using 16 bit half float data with the imaging | |
| subset routines that accept images, i.e., | |
| ConvolutionFilter{1D|2D}, ColorTable, etc. | |
| * this extension does not include the ClampColorARB routine | |
| from ARB_color_buffer_float. It does, however, use the | |
| default clamping behavior specified in the | |
| ARB_color_buffer_float extension. | |
| Note that this means the following in this extension: | |
| - vertex color outputs are always clamped, regardless of | |
| color buffer format | |
| - fragment color outputs are clamped when writing to a | |
| fixed point color buffer and unclamped when writing to | |
| a floating point color buffer, and | |
| - the read color returned by | |
| ReadPixels/CopyPixels/GetTexImage/etc. is clamped when | |
| reading from a fixed point format and unclamped when | |
| reading from a floating point format. | |
| * unlike ARB_texture_float, this extension only supports | |
| GL_NEAREST filtering for float (and half float) textures. | |
| * unlike ARB_color_buffer_float, this extension does not | |
| support src/dst alpha blending on float (and half float) | |
| destination color buffers. | |
| 2. Since this extension is more limited than the ARB floating point | |
| extensions, what is the appropriate (and "future-proof") method | |
| for an application to use to query for floating point color | |
| buffer and texture support? | |
| This extension and the related extensions | |
| APPLEX_color_buffer_float_16_blend and | |
| APPLEX_texture_float_16_filter, should be considered | |
| "transitional" in nature. The limited functionality described by | |
| these extensions is superseded by the more powerful ARB | |
| extensions and as hardware becomes more capable, it is possible | |
| that future revisions of OpenGL may deprecate or remove them | |
| altogether. | |
| As such, to allow for ease of transition to support of the ARB | |
| floating point extensions, applications are *strongly* | |
| encouraged to use the following algorithm to query for floating | |
| point texture and color buffer support: | |
| // any Floating Point Support at all? | |
| bool supportsFloatColorBuffers = FALSE; | |
| bool supportsFloatTextures = FALSE; | |
| // 16 bit/component Floating Point Blend/Filter Support? | |
| bool supportsFloat16ColorBufferBlending = FALSE; | |
| bool supportsFloat16TextureFiltering = FALSE; | |
| // 32 bit/component Floating Point Blend/Filter Support? | |
| bool supportsFloat32ColorBufferBlending = FALSE; | |
| bool supportsFloat32TextureFiltering = FALSE; | |
| // =============================================== | |
| // Check for floating point texture support | |
| // | |
| // * First check for full ARB_texture_float | |
| // extension and only then check for more | |
| // limited APPLE and APPLEX texture extensions | |
| // =============================================== | |
| if (extensionSupported("ARB_texture_float")) | |
| { | |
| supportsFloatTextures = TRUE; | |
| supportsFloat16TextureFiltering = TRUE; | |
| supportsFloat32TextureFiltering = TRUE; | |
| } | |
| else if (extensionSupported("APPLE_float_pixels")) | |
| { | |
| supportsFloatTextures = TRUE; | |
| if (extensionSupported("APPLEX_texture_float_16_filter")) | |
| { | |
| supportsFloat16TextureFiltering = TRUE; | |
| } | |
| } | |
| // =============================================== | |
| // Check for floating point color buffer support | |
| // | |
| // * First check for full ARB_color_buffer_float | |
| // extension and only then check for more | |
| // limited APPLE and APPLEX color buffer extensions | |
| // =============================================== | |
| if (extensionSupported("ARB_color_buffer_float")) | |
| { | |
| supportsFloatColorBuffers = TRUE; | |
| supportsFloat16ColorBufferBlending = TRUE; | |
| supportsFloat32ColorBufferBlending = TRUE; | |
| } | |
| else if (extensionSupported("APPLE_float_pixels")) | |
| { | |
| supportsFloatColorBuffers = TRUE; | |
| if (extensionSupported("APPLEX_color_buffer_float_16_blend")) | |
| { | |
| supportsFloat16ColorBufferBlending = TRUE; | |
| } | |
| } | |
| 3. Why does this extension (and the related APPLEX_*_float_* | |
| extensions) even exist, given the existence of the ARB, ATI, and | |
| NVIDIA floating point extensions? | |
| A good question. This extension was developed contemporaneously | |
| with the ATI and NVIDIA extensions and support for this | |
| extension in Mac OS X's OpenGL implementation predates the | |
| definition of the ARB extensions. In addition, this extension | |
| specification attempts to document the behavior of the APPLE | |
| extension to support use of floating point features on hardware | |
| which may not support the full feature set described by the ARB | |
| extensions. The behavior of the APPLE extension more closely | |
| matches the feature set of this class of hardware and can be | |
| used by applications to get a more accurate description of | |
| native hardware support when falling back to software rendering | |
| may not be appropriate. | |
| It is expected that as hardware renderers becomes more capable | |
| the Mac OS X OpenGL implementation will transition to supporting | |
| the ARB extensions and may deprecate and/or remove these APPLE | |
| extensions from the API. Please see issue #2 for details on how | |
| to query for floating point support in a "future-proof" manner. | |
| 4. What will happen when the ARB floating point extensions are | |
| supported? | |
| The APPLE_float_pixels and the related | |
| APPLEX_texture_float_16_filter and | |
| APPLEX_color_buffer_float_16_blend extensions are intended as a | |
| strict subset of the functionality in ARB_texture_float, | |
| ARB_color_buffer_float, and ARB_half_float_pixel. | |
| Consequently, an implementation could legally support all of | |
| these extensions simulataneously, however once the ARB | |
| extensions are supported there is no need to export the | |
| APPLE{X}_* floating point extensions. | |
| Consequently, it's possible that implementations may deprecate | |
| or remove the APPLE_float_pixels, | |
| APPLEX_texture_float_16_filter, and | |
| APPLEX_color_buffer_float_16_blend extensions when the | |
| corresponding ARB extensions are supported by the underlying | |
| hardware. Applications should pay attention to issue #2 above | |
| to prepare for this possibility. | |
| New Procedures and Functions | |
| None | |
| New Tokens | |
| Accepted by the parameters of DrawPixels, ReadPixels, TexImage1D, | |
| TexImage2D, TexImage3D, TexSubImage1D, TexSubImage2D, TexSubImage3D, and | |
| GetTexImage: | |
| HALF_APPLE 0x140B // Same as HALF_FLOAT_NV/ARB | |
| Accepted by the GetBooleanv: | |
| COLOR_FLOAT_APPLE 0x8A0F | |
| Accepted by the parameter of TexImage1D, | |
| TexImage2D, and TexImage3D: | |
| RGBA_FLOAT32_APPLE 0x8814 // Same as RGBA_FLOAT32_ATI/ARB | |
| RGB_FLOAT32_APPLE 0x8815 // Same as RGB_FLOAT32_ATI/ARB | |
| ALPHA_FLOAT32_APPLE 0x8816 // Same as ALPHA_FLOAT32_ATI/ARB | |
| INTENSITY_FLOAT32_APPLE 0x8817 // Same as INTENSITY_FLOAT32_ATI/ARB | |
| LUMINANCE_FLOAT32_APPLE 0x8818 // Same as LUMINANCE_FLOAT32_ATI/ARB | |
| LUMINANCE_ALPHA_FLOAT32_APPLE 0x8819 // Same as LUMINANCE_ALPHA_FLOAT32_ATI/ARB | |
| RGBA_FLOAT16_APPLE 0x881A // Same as RGBA_FLOAT16_ATI/ARB | |
| RGB_FLOAT16_APPLE 0x881B // Same as RGB_FLOAT16_ATI/ARB | |
| ALPHA_FLOAT16_APPLE 0x881C // Same as ALPHA_FLOAT16_ATI/ARB | |
| INTENSITY_FLOAT16_APPLE 0x881D // Same as NTENSITY_FLOAT16_ATI/ARB | |
| LUMINANCE_FLOAT16_APPLE 0x881E // Same as LUMINANCE_FLOAT16_ATI/ARB | |
| LUMINANCE_ALPHA_FLOAT16_APPLE 0x881F // Same as LUMINANCE_ALPHA_FLOAT16_ATI/ARB | |
| Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation) | |
| Add a new Section 2.1.2, (p. 6): | |
| 2.1.2 16-Bit Floating-Point Numbers | |
| A 16-bit floating-point number has a 1-bit sign (S), a 5-bit | |
| exponent (E), and a 10-bit mantissa (M). The value of a 16-bit | |
| floating-point number is determined by the following: | |
| (-1)^S * 0.0, if E == 0 and M == 0, | |
| (-1)^S * 2^-14 * (M / 2^10), if E == 0 and M != 0, | |
| (-1)^S * 2^(E-15) * (1 + M/2^10), if 0 < E < 31, | |
| (-1)^S * INF, if E == 31 and M == 0, or | |
| NaN, if E == 31 and M != 0, | |
| where | |
| S = floor((N mod 65536) / 32768), | |
| E = floor((N mod 32768) / 1024), and | |
| M = N mod 1024. | |
| Implementations are also allowed to use any of the following | |
| alternative encodings: | |
| (-1)^S * 0.0, if E == 0 and M != 0, | |
| (-1)^S * 2^(E-15) * (1 + M/2^10), if E == 31 and M == 0, or | |
| (-1)^S * 2^(E-15) * (1 + M/2^10), if E == 31 and M != 0, | |
| Any representable 16-bit floating-point value is legal as input | |
| to a GL command that accepts 16-bit floating-point data. The | |
| result of providing a value that is not a floating-point number | |
| (such as infinity or NaN) to such a command is unspecified, but | |
| must not lead to GL interruption or termination. Providing a | |
| denormalized number or negative zero to GL must yield predictable | |
| results. | |
| (modify Table 2.2, p. 9) -- add new row | |
| Minimum | |
| GL Type Bit Width Description | |
| ------- --------- ----------------------------------- | |
| half 16 half-precision floating-point value | |
| encoded in an unsigned scalar | |
| Modify Section 2.14, (Colors and Coloring), p. 59 | |
| (modify Table 2.9, p. 59) Add new row to the table: | |
| GL Type Conversion | |
| ------- ---------- | |
| half c | |
| Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization) | |
| Modify Section 3.6.4 (Rasterization of Pixel Rectangles), p. 126 | |
| (modify next-to-last paragraph, p.136, "Final Conversion") ... For | |
| RGBA components, if fragment color clamping is enabled, each element | |
| is clamped to [0,1], and may be converted to fixed-point according | |
| to the rules given in section 2.14.9 (Final Color Processing). If | |
| fragment color clamping is disabled, RGBA components are unmodified. | |
| For the purposes of this specification, fragment color clamping is | |
| enabled implicitly if all enabled color buffers have fixed-point | |
| components. | |
| Modify Section 3.8.1 (Texture Image Specification), p. 150 | |
| (modify second paragraph, p. 151) The selected groups are processed | |
| exactly as for DrawPixels, stopping just before final conversion. | |
| For R, G, B, and A, if the <internalformat> of the texture is | |
| fixed-point, the components are clamped to [0, 1]. Otherwise, the | |
| components are not modified. The depth value so generated is | |
| clamped to [0, 1]. | |
| (modify the second paragraph, p. 152) The internal component resolution | |
| is the number of bits allocated to each value in a texture image. If | |
| <internalformat> is specified as a base internal format, the GL stores | |
| the resulting texture with internal component resolutions of its own | |
| choosing. If a sized internal format is specified, the mapping of the | |
| R, G, B, A, and depth values to texture components is equivalent to the | |
| mapping of the corresponding base internal format's components, as | |
| specified in table 3.15, the type (unsigned int, float, etc.) is | |
| assigned the same type specified by <internalFormat>, and the memory | |
| allocation per texture component is assigned by the GL to match the | |
| allocations listed in table 3.16 as closely as possible. (The definition | |
| of closely is left up to the implementation. Implementations are not | |
| required to support more than one resolution of each type (unsigned int, | |
| float, etc.) for each base internal format.) If a compressed internal | |
| format is specified, the mapping of the R, G, B, A, and depth values to | |
| texture components is equivalent to the mapping of the corresponding | |
| base internal format's components, as specified in table 3.15. The | |
| specified image is compressed using a (possibly lossy) compression | |
| algorithm chosen by the GL. | |
| (add the following to table 3.16, p. 154) | |
| Sized Base R G B A L I | |
| Internal Format Internal Format bits bits bits bits bits bits | |
| --------------------------- --------------- ---- ---- ---- ---- ---- ---- | |
| RGBA32F_ARB RGBA f32 f32 f32 f32 | |
| RGB32F_ARB RGB f32 f32 f32 | |
| ALPHA32F_ARB ALPHA f32 | |
| INTENSITY32F_ARB INTENSITY f32 | |
| LUMINANCE32F_ARB LUMINANCE f32 | |
| LUMINANCE_ALPHA32F_ARB LUMINANCE_ALPHA f32 f32 | |
| RGBA16F_ARB RGBA f16 f16 f16 f16 | |
| RGB16F_ARB RGB f16 f16 f16 | |
| ALPHA16F_ARB ALPHA f16 | |
| INTENSITY16F_ARB INTENSITY f16 | |
| LUMINANCE16F_ARB LUMINANCE f16 | |
| LUMINANCE_ALPHA16F_ARB LUMINANCE_ALPHA f16 f16 | |
| Table 3.16: Correspondence of sized internal formats to base | |
| internal formats, and desired component resolutions for each | |
| sized internal format. The notation <f16> and <f32> imply | |
| 16- and 32-bit floating-point, respectively. | |
| Modify Section 3.8.4 (Texture Parameters), p. 166 | |
| (remove TEXTURE_BORDER_COLOR from end of first paragraph, p. 166) | |
| ... If the value for TEXTURE_PRIORITY is specified as an integer, | |
| the conversion for signed integers from table 2.9 is applied to | |
| convert this value to floating-point, followed by clamping the | |
| value to lie in [0, 1]. | |
| (modify last paragraph, p. 174) ... If the texture contains color | |
| components, the values of TEXTURE BORDER COLOR are interpreted as | |
| an RGBA color to match the texture's internal format in a manner | |
| consistent with table 3.15. The border values for texture | |
| components stored as fixed-point values are clamped to [0, 1] | |
| before they are used. If the texture contains depth ... | |
| Add a new section, after 3.8.9 and prior to section 3.8.10, p. 177 | |
| 3.8.9.5 Floating point formats and texture filters | |
| Due to limitations in current render hardware, textures with | |
| floating point formats may not support minification or magnification | |
| filters that require LINEAR filtering in the manner described above. | |
| Specifically, if the texture filter is neither GL_NEAREST nor | |
| GL_NEAREST_MIPMAP_NEAREST, and *any* of following conditions are | |
| true: | |
| * the <internalformat> of the texture is a 32-bit/component | |
| floating point format and ARB_texture_float is not supported | |
| by the implementation, *or* | |
| * the <internalformat> of the texture is a 16-bit/component | |
| floating point format and APPLEX_texture_float_16_filter | |
| extension is not supported by the implementation, | |
| then the GL will interpret texture minification and magnification filters | |
| according to the table (xxx.1) listed below: | |
| specified filter will behave as: | |
| ---------------- -------------- | |
| LINEAR NEAREST | |
| NEAREST_MIPMAP_LINEAR NEAREST_MIPMAP_NEAREST | |
| LINEAR_MIPMAP_NEAREST NEAREST_MIPMAP_NEAREST | |
| LINEAR_MIPMAP_LINEAR NEAREST_MIPMAP_NEAREST | |
| ---------------------------------------------------- | |
| Table xxx.1 - floating point texture filter behavior | |
| Otherwise, the texture minification and magnfication filters behave | |
| as specified earlier in section 3.8.8 and 3.8.9. | |
| Modify Section 3.8.13 (Texture Environments and Functions), p.182 | |
| (modify third paragraph, p. 183, removing clamping language) | |
| ...TEXTURE_ENV_COLOR is set to an RGBA color by providing four | |
| single-precision floating-point values. If integers are provided | |
| for TEXTURE ENV COLOR, then they are converted to floating-point | |
| as specified in table 2.9 for signed integers. | |
| (replace the sixth paragraph of p. 183) If fragment color clamping | |
| is enabled, all of these color values, including the results, are | |
| clamped to the range [0,1]. If fragment color clamping is | |
| disabled, the values are not clamped. The texture functions are | |
| specified in tables 3.22, 3.23, and 3.24. | |
| (modify seventh paragraph of p. 183) ... ALPHA_SCALE, respectively. | |
| If fragment color clamping is enabled, the arguments and results | |
| used in table 3.24 are clamped to [0,1]. Otherwise, the results | |
| are unmodified. | |
| Modify Section 3.9 (Color Sum), p. 191 | |
| (modify second paragraph) ... the A component of c_sec is unused. | |
| If color sum is disabled, then c_pri is assigned to c. The | |
| components of c are then clamped to the range [0,1] if and only | |
| if fragment color clamping is enabled. | |
| Modify Section 3.10 (Fog), p. 191 | |
| (modify fourth paragraph, p. 192, removing clamping language) ...If | |
| these are not floating-point values, then they are converted to | |
| floating-point using the conversion given in table 2.9 for signed | |
| integers. If fragment color clamping is enabled, the components of | |
| C_r and C_f and the result C are clamped to the range [0,1] before | |
| the fog blend is performed. | |
| Modify Section 3.11.2 (Shader Execution), p. 194 | |
| (modify Shader Inputs, first paragraph, p. 196) The built-in | |
| variables gl_Color and gl_SecondaryColor hold the R, G, B, and A | |
| components, respectively, of the fragment color and secondary | |
| color. If the primary color or the secondary color components are | |
| represented by the GL as fixed-point values, they undergo an | |
| implied conversion to floating-point. This conversion must leave | |
| the values 0 and 1 invariant. Floating-point color components | |
| (resulting from a disabled vertex color clamp) are unmodified. | |
| (modify Shader Outputs, first paragraph, p. 196) ... These are | |
| gl_FragColor, gl_FragData[n], and gl_FragDepth. If fragment | |
| clamping is enabled, the final fragment color values or the final | |
| fragment data values written by a fragment shader are clamped to | |
| the range [0, 1] and then may be converted to fixed-point as | |
| described in section 2.14.9. If fragment clamping is disabled, | |
| the final fragment color values or the final fragment data values | |
| are not modified. The final fragment depth... | |
| Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment | |
| Operations and the Frame Buffer) | |
| Modify Chapter 4 Introduction, (p. 198) | |
| (modify third paragraph, p. 198) Color buffers consist of either | |
| unsigned integer color indices, R, G, B and optionally A unsigned | |
| integer values, or R, G, B, and optionally A floating-point values. | |
| The number of bitplanes... | |
| Modify Section 4.1.3 (Multisample Fragment Operations), p. 200 | |
| (modify last paragraph, p. 200) ...and all 0's corresponding to all | |
| alpha values being 0. The alpha values used to generate a coverage | |
| value are clamped to the range [0,1]. It is also intended ... | |
| Modify Section 4.1.5 (Alpha Test), p. 201 | |
| (modify first paragraph of section, deleting clamping of | |
| reference value) ... The test is controlled with | |
| void AlphaFunc(enum func, float ref); | |
| func is a symbolic constant indicating the alpha test function; | |
| ref is a reference value. When performing the alpha test, the GL | |
| will convert the reference value to the same representation as the | |
| the fragment's alpha value (floating-point or fixed-point). | |
| For fixed-point, the reference value is converted according to the | |
| rules given for an A component in section 2.14.9 and the fragment's | |
| alpha value is rounded to the nearest integer. The possible ... | |
| Modify Section 4.1.8 (Blending), p. 205 | |
| (modify first paragraph, p. 206) Source and destination values are | |
| combined according to the blend equation, quadruplets of source and | |
| destination weighting factors determined by the blend functions, and | |
| a constant blend color to obtain a new set of R, G, B, and A values, | |
| as described below. | |
| If the color buffer is fixed-point, the components of the source | |
| and destination values and blend factors are clamped to [0, 1] | |
| prior to evaluating the blend equation, the components of the | |
| blending result are clamped to [0,1] and converted to fixed- | |
| point values in the manner described in section 2.14.9. If the | |
| color buffer is floating-point, no clamping occurs. The | |
| resulting four values are sent to the next operation. | |
| Blending is dependent on the incoming fragment's alpha value and | |
| that of the corresponding currently stored pixel. Blending applies | |
| only in RGBA mode and only one of the following conditions is true: | |
| * the format of the current color buffer is fixed-point, *or* | |
| * the format of current color buffer(s) is 16 bit floating point | |
| and the APPLEX_color_buffer_float_16_blend extension is | |
| supported by the implementation, *or* | |
| * the format of the current color buffer is floating-point and | |
| the ARB_color_buffer_float extension is supported by the | |
| implementation. | |
| Otherwise, the blending stage is bypassed. Blending is enabled or | |
| disabled using Enable or Disable with the symbolic constant BLEND. | |
| If it is disabled (or bypassed), or if logical operation on color | |
| values is enabled (section 4.1.10), proceed to the next operation. | |
| (modify fifth paragraph, p. 206) Fixed-point destination | |
| (framebuffer) components are taken to be fixed-point values | |
| represented according to the scheme given in section 2.14.9 | |
| (Final Color Processing). Constant color components, floating- | |
| point destination components, and source (fragment) components are | |
| taken to be floating point values. If source components are | |
| represented internally by the GL as either fixed-point values they | |
| are also interepreted according to section 2.14.9. | |
| (modify Blend Color section removing the clamp, p. 209) The | |
| constant color C_c to be used in blending is specified with the | |
| command | |
| void BlendColor(float red, float green, float blue, float alpha); | |
| The constant color can be used in both the source and destination | |
| blending functions. | |
| Replace Section 4.1.9 (Dithering), p. 209 | |
| Dithering selects between two representable color values or indices. | |
| A representable value is a value that has an exact representation in | |
| the color buffer. In RGBA mode dithering selects, for each color | |
| component, either the most positive representable color value (for | |
| that particular color component) that is less than or equal to the | |
| incoming color component value, c, or the most negative | |
| representable color value that is greater than or equal to c. The | |
| selection may depend on the x_w and y_w coordinates of the pixel, as | |
| well as on the exact value of c. If one of the two values does not | |
| exist, then the selection defaults to the other value. | |
| In color index mode dithering selects either the largest | |
| representable index that is less than or equal to the incoming | |
| color value, c, or the smallest representable index that is greater | |
| than or equal to c. If one of the two indices does not exist, then | |
| the selection defaults to the other value. | |
| Many dithering selection algorithms are possible, but an individual | |
| selection must depend only on the incoming color index or component | |
| value and the fragment's x and y window coordinates. If dithering | |
| is disabled, then each incoming color component c is replaced with | |
| the most positive representable color value (for that particular | |
| component) that is less than or equal to c, or by the most negative | |
| representable value, if no representable value is less than or equal | |
| to c; a color index is rounded to the nearest representable index | |
| value. | |
| Dithering is enabled with Enable and disabled with Disable using the | |
| symbolic constant DITHER. The state required is thus a single bit. | |
| Initially dithering is enabled. | |
| Section 4.1.10 (Logical Operation), p. 210 | |
| (insert after the first sentence, p. 210) Logical operation has no | |
| effect on a floating-point destination color buffer. However, if | |
| COLOR_LOGIC_OP is enabled, blending is still disabled. | |
| Modify Section 4.2.3 (Clearing the Buffers), p. 215 | |
| (modify second paragraph, p. 216, removing clamp of clear color) | |
| void ClearColor(float r, float g, float b, float a); | |
| sets the clear value for the color buffers in RGBA mode. | |
| (add to the end of first partial paragraph, p. 217) ... then a | |
| Clear directed at that buffer has no effect. Fixed-point RGBA | |
| color buffers are cleared to a color values derived by taking the | |
| clear color, clamping to [0,1], and converting to fixed-point | |
| according to the rules of section 2.14.9. | |
| Modify Section 4.2.4 (The Accumulation Buffer), p. 217 | |
| (modify second paragraph in section, p. 217) ... Using ACCUM | |
| obtains R, G, B, and A components from the color buffer currently | |
| selected for reading (section 4.3.2). If the color buffer is | |
| fixed-point, each component is considered as a fixed-point value | |
| in [0,1] (see section 2.14.9) and is converted to floating-point. | |
| Each result is then multiplied ... | |
| (modify second paragraph on p. 218) The RETURN operation takes | |
| each color value from the accumulation buffer and multiplies each | |
| of the R, G, B, and A components by <value>. If fragment color | |
| clamping is enabled, the results are then clamped to the range | |
| [0,1]. ... | |
| Modify Section 4.3.2 (Reading Pixels), p. 219 | |
| (modify paragraph at top of page, p. 222) ... For a fixed-point | |
| color buffer, each element is taken to be a fixed-point value in | |
| [0, 1] with m bits, where m is the number of bits in the | |
| corresponding color component of the selected buffer (see | |
| section 2.14.9). For floating-point color buffer, the elements | |
| are unmodified. | |
| (modify Final Conversion, p. 222) For an index, if the type is not | |
| FLOAT or HALF_FLOAT_ARB, final conversion consists of masking the | |
| index with the value given in Table 4.6; if the type is FLOAT or | |
| HALF_FLOAT_ARB, then the integer index is converted to a GL float | |
| or half data value. | |
| For an RGBA color, if <type> is not FLOAT or HALF, or the selected | |
| color buffer is a fixed-point buffer, each component is first | |
| clamped to [0,1]. Then the appropriate conversion... | |
| (modify Table 4.7, p. 224 -- add new row) | |
| type Parameter GL Data Type Component Conversion Formula | |
| -------------- ------------ ---------------------------- | |
| HALF_APPLE half c = f | |
| 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) | |
| Modify Section 6.1.2, Data Conversions, p. 245 | |
| (add new paragraph at the end of the section, p. 245) If fragment | |
| color clamping is enabled, querying of the texture border color, | |
| texture environment color, fog color, alpha test reference value, | |
| blend color, and RGBA clear color will clamp the corresponding | |
| state values to [0,1] before returning them. This behavior | |
| provides compatibility with previous versions of the GL that | |
| clamped these values when specified. | |
| Modifications to the AGL Specification | |
| Modify the values accepted by aglChoosePixelFormat and aglDescribePixelFormat. | |
| AGL_COLOR_FLOAT | |
| If true, this pixel format supports using floating point | |
| color buffers as the destination for rendering. | |
| Modifications to the CGL Specification | |
| Modify the values accepted by CGLChoosePixelFormat and CGLDescribePixelFormat. | |
| kCGLPFAColorFloat | |
| If true, this pixel format supports using floating point | |
| color buffers as the destination for rendering. | |
| Dependencies on ARB_fragment_program | |
| (modify 2nd paragraph of Section 3.11.4.4 language) If fragment | |
| color clamping is enabled, the fragment's color components are first | |
| clamped to the range [0,1] and are optionally converted to fixed | |
| point as in section 2.14.9. If the fragment program does not write | |
| result.color, the color will be undefined in subsequent stages. | |
| Dependencies on ARB_fragment_shader | |
| (modify 1st paragraph of Section 3.11.6 language) ... are | |
| gl_FragColor and gl_FragDepth. If fragment color clamping is | |
| enabled, the final fragment color values written by a fragment | |
| shader are clamped to the range [0,1] and are optionally converted | |
| to fixed-point as described in section 2.14.9, Final Color | |
| Processing. ... | |
| Dependencies on APPLEX_texture_float_16_filter | |
| If APPLEX_texture_float_16_filter is not supported, then all | |
| references to APPLEX_texture_float_16_filter should be removed from | |
| this extension. In this case, 16 bit floating point textures will | |
| behave as if the GL_MAG_FILTER is GL_NEAREST and as if GL_MIN_FILTER | |
| is either GL_NEAREST_MIPMAP_NEAREST (if a mipmap min filter is | |
| requested) or GL_NEAREST (if a non-mipmap min filter is requested). | |
| Dependencies on APPLEX_color_buffer_float_16_blend | |
| If APPLEX_color_buffer_float_16_blend is not supported, then all | |
| references to APPLEX_texture_float_16_filter should be removed from | |
| this extension. In this case, rendering to a 16 bit floating point | |
| color buffer will behave as if the enable state for GL_BLEND is set | |
| to FALSE. | |
| Errors | |
| None. | |
| New State | |
| (table 6.25, p. 215) | |
| Get value Type Get Cmnd Minimum Value Description Sec. Attribute | |
| ----------------- ---- ----------- ------------- --------------------------- ---- --------- | |
| COLOR_FLOAT_APPLE B GetBooleanv - True if color buffers store 2.7 - | |
| floating point components | |
| Revision History | |
| 0.1, 2003, gstahl@apple.com | |
| * preliminary draft, documents shipping behavior as of 10.2.3 | |
| 0.2, 08/16/2005, jsandmel@apple.com | |
| * rewritten to account for the fact that APPLE_float_pixels doesn't support: | |
| - float 16/32 texture filtering | |
| - float 16/32 color buffer blending | |
| - controllable color clamping | |
| - texture per-component float-versus-int type queries | |
| - half float types with imaging subset routines | |
| * added interactions with the shader extensions | |
| * added interactions with the APPLEX_*_float_16_* extensions | |
| * added updates to AGL and CGL | |