| GL_EXT_blend_equation_separate |
EXT_blend_equation_separate
GL_EXT_blend_equation_separate
Mark Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com)
Copyright NVIDIA Corporation, 2003.
Date: 12/23/2003 Version 1.0
Ready to implement
299
Written based on the wording of the OpenGL 1.5 specification.
OpenGL 1.4 (or ARB_imaging, or EXT_blend_minmax and/or
EXT_blend_subtract) is required for blend equation support.
EXT_blend_func_separate is presumed but not required.
EXT_blend_logic_op interacts with this extension.
EXT_blend_func_separate introduced separate RGB and alpha blend
factors. EXT_blend_minmax introduced a distinct blend equation for
combining source and destination blend terms. (EXT_blend_subtract &
EXT_blend_logic_op added other blend equation modes.) OpenGL 1.4
integrated both functionalities into the core standard.
While there are separate blend functions for the RGB and alpha blend
factors, OpenGL 1.4 provides a single blend equation that applies
to both RGB and alpha portions of blending.
This extension provides a separate blend equation for RGB and alpha
to match the generality available for blend factors.
No known IP issues.
Why not use ATI_blend_equation_separate?
Apple supports this extension in OS X 10.2 but the extension
lacks a specification and, as explained in subsequent issues,
the token naming is inconsistent with OpenGL conventions.
What should the token names be?
RESOLVED: Follow the precedent of EXT_blend_equation_separate.
For example, GL_BLEND_DST becomes GL_BLEND_DST_RGB
and GL_BLEND_DST_ALPHA. So GL_BLEND_EQUATION becomes
GL_BLEND_EQUATION_RGB (same value as GL_BLEND_EQUATION) and
GL_BLEND_EQUATION_ALPHA.
This is different from the ATI_blend_equation_separate approach
which introduces the single name GL_ALPHA_BLEND_EQUATION_ATI
(no RGB name is introduced). The existing OpenGL convention
(example: ARB_texture_env_combine) is to use _RGB and _ALPHA as
a suffix for enumerants, not a prefix.
How should get token values be assigned?
RESOLVED: GL_BLEND_EQUATION_RGB_EXT has the same value as
GL_BLEND_EQUATION. See "Compatibility" section.
For compatibility with ATI_blend_equation_separate,
GL_BLEND_EQUATION_ALPHA_EXT shares the same value (0x883D)
with the ATI_blend_equation_separate's GL_ALPHA_BLEND_EQUATION_ATI
token. The GL_BLEND_EQUATION_ALPHA_EXT name uses the suffixing
convention (rather than prefixing) for adding _ALPHA addition
as done by ARB_texture_env_combine and EXT_blend_func_separate.
   New Procedures and Functions |
void BlendEquationSeparateEXT(enum modeRGB,
enum modeAlpha);
Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
GetFloatv, and GetDoublev:
BLEND_EQUATION_RGB_EXT 0x8009 (same as BLEND_EQUATION)
BLEND_EQUATION_ALPHA_EXT 0x883D
| Additions to Chapter 2 of the 1.5 GL Specification (OpenGL Operation) |
None
| Additions to Chapter 3 of the 1.5 GL Specification (Rasterization) |
None
| Additions to Chapter 4 of the 1.5 GL Specification (Per-Fragment Operations and the Framebuffer) |
Replace the "Blend Equation" discussion in section 4.1.7 (Blending)
with the following:
"The equations used to control blending are determined by the blend
equations. Blend equations are specified with the commands:
void BlendEquation(enum mode);
void BlendEquationSeparateEXT(enum modeRGB, enum modeAlpha);
BlendEquationSeparateEXT arguments modeRGB determines the RGB blend
function while modeAlpha determines the alpha blend equation.
BlendEquation argument mode determines both the RGB and alpha blend
equations. modeRGB and modeAlpha must each be one of FUNC_ADD,
FUNC_SUBTRACT, FUNC_REVERSE_SUBTRACT, MIN, or MAX.
Destination (framebuffer) components are taken to be fixed-point
values represented according to the scheme in section 2.13.9
(Final Color Processing), as are source (fragment) components.
Constant color components are taken to be floating point values.
[ed: paragraph unchanged except that floating-point is hyphenated.]
Prior to blending, each fixed-point color component undergoes an
implied conversion to floating-point. This conversion must leave
the values 0 and 1 invariant. Blending components are treated as
if carried out in floating-point. [ed: paragraph unchanged except
that floating-point is hyphenated.]
Table 4.blendeq provides the corresponding per-component blend
equations for each mode, whether acting on RGB components for modeRGB
or the alpha component for modeAlpha.
In the table, the "s" subscript on a color component abbreviation
(R, G, B, or A) refers to the source color component for an incoming
fragment, the "d" subscript on a color component abbreviation refers
to the destination color component at the corresponding framebuffer
location, and the "c" subscript on a color component abbreviation
refers to the constant blend color component. A color component
abbreviation without a subscript refers to the new color component
resulting from blending. Additionally, Sr, Sg, Sb, and Sa are
the red, green, blue, and alpha components of the source weighting
factors determined by the source blend function, and Dr, Dg, Db, and
Da are the red, green, blue, and alpha components of the destination
weighting factors determined by the destination blend function.
Blend functions are described below.
Mode RGB components Alpha component
--------------------- ---------------------- ----------------------
FUNC_ADD Rc = Rs * Sr + Rd * Dr Ac = As * Sa + Ad * Da
Gc = Gs * Sg + Gd * Dg
Bc = Bs * Sb + Bd * Db
--------------------- ---------------------- ----------------------
FUNC_SUBTRACT Rc = Rs * Sr - Rd * Dr Ac = As * Sa - Ad * Da
Gc = Gs * Sg - Gd * Dg
Bc = Bs * Sb - Bd * Db
--------------------- ---------------------- ----------------------
FUNC_REVERSE_SUBTRACT Rc = Rd * Sr - Rs * Dr Ac = Ad * Sa - As * Da
Gc = Gd * Sg - Gs * Dg
Bc = Bd * Sb - Bs * Db
--------------------- ---------------------- ----------------------
MIN Rc = min(Rs, Rd) Ac = min(As, Ad)
Gc = min(Gs, Gd)
Bc = min(Bs, Bd)
--------------------- ---------------------- ----------------------
MAX Rc = max(Rs, Rd) Ac = max(As, Ad)
Gc = max(Gs, Gd)
Bc = max(Bs, Bd)
--------------------- ---------------------- ----------------------
Table 4.blendeq: RGB and alpha blend equations are their
per-component equations controlling the color components resulting
from blending for each mode."
In the "Blending State" paragraph, replace the initial lines with...
"The state required for blending is two integers for the RGB and alpha
blend equations, four integer indicating the source and destination
RGB and alpha blending functions, four floating-point values to store
the RGBA constant blend color, and a bit indicating whether blending
is enabled or disabled. The initial blending equations for RGB and
alpha are FUNC_ADD. ..."
| Additions to Chapter 5 of the 1.5 GL Specification (Special Functions) |
None
| Additions to Chapter 6 of the 1.5 GL Specification (State and State Requests) |
None
| Additions to the GLX Specification |
None
A new GL rendering command is added. The following command is sent
to the server as part of a glXRender request:
BlendEquationSeparateEXT
2 12 rendering command length
2 4228 rendering command opcode
4 ENUM modeRGB
4 ENUM modeAlpha
| Dependencies on EXT_blend_logic_op |
If EXT_blend_logic_op and EXT_blend_equation_separate are both
supported, the logic op blend equation should be supported separately
for RGB and alpha as with the other blend equation modes.
And add to the table 4.blendeq this line:
Mode RGB components Alpha component
--------------------- ---------------------- ----------------------
LOGIC_OP Rc = Rs OP Rd Ac = As OP Ad
Gc = Gs OP Gd
Bc = Bs OP Bd
--------------------- ---------------------- ----------------------
where OP denotes the logical operation controlled by LogicOp (see
table 4.2).
Note: there is no support for a distinct RGB logical operation
and alpha logical operation (that could be provided by another
extension).
INVALID_ENUM is generated if either the modeRGB or modeAlpha
parameter of BlendEquationSeparateEXT is not one of FUNC_ADD,
FUNC_SUBTRACT, FUNC_REVERSE_SUBTRACT, MAX, or MIN.
INVALID_OPERATION is generated if BlendEquationSeparateEXT
is executed between the execution of Begin and the corresponding
execution of End.
Initial
Get Value Get Command Type Value Attribute
------------------------ ----------- ---- -------- ------------
BLEND_EQUATION_RGB_EXT GetIntegerv Z FUNC_ADD color-buffer
BLEND_EQUATION_ALPHA_EXT GetIntegerv Z FUNC_ADD color-buffer
[remove BLEND_EQUATION from the table, add a note "v1.5 BLEND_EQUATON"
beside BLEND_EQUATION_RGB_EXT to note the legacy name.]
| New Implementation Dependent State |
None
Compatibility
The BLEND_EQUATION_RGB_EXT query token has the same value as the
legacy BLEND_EQUATION query token. This means querying the legacy
BLEND_EQUATION state is identical to querying the RGB blend equation
state.
This is a different approach than taken by the EXT_blend_func_separate
extension, but matches the approach taken by other "split" OpenGL
state such as the SMOOTH_POINT_SIZE_RANGE and ALIASED_POINT_SIZE_RANGE
values split from POINT_SIZE_RANGE.
In the EXT_blend_func_separate case, four new token names
(BLEND_DST_RGB, BLEND_SRC_RGB, BLEND_DST_ALPHA, and BLEND_DST_RGB)
with four new token values (0x80C8, 0x80C9, 0x80CA, and 0x80CB
respectively) were added. Querying the legacy BLEND_DST (0x0BE0) and
BLEND_RGB (0x0BE1) returns the same value as querying BLEND_SRC_RGB
and BLEND_DST_RGB respectively but this was never explicitly
documented.
In the case of the point size ranges, SMOOTH_POINT_SIZE_RANGE was
given the same value as POINT_SIZE_RANGE (0x0B12) and a single new
token ALIASED_POINT_SIZE_RANGE (0x846D).
The point size ranges approach is preferable because it minimizes
the confusion about how the legacy name should be treated by
implementations because the legacy name shares its value with
the new name. This is less prone to confusion by developers and
implementers and less effort to implement.
For token value compatibility with ATI_blend_equation_separate,
GL_BLEND_EQUATION_ALPHA_EXT shares the same value (0x883D) with the
ATI_blend_equation_separate's GL_ALPHA_BLEND_EQUATION_ATI token.
ATI_blend_equation_separate's GL_ALPHA_BLEND_EQUATION_ATI token.
 |  | Last update: November 14, 2006.
Cette page doit être lue avec un navigateur récent respectant le standard XHTML 1.1.
|
