I'm having an exam soon and got a problem with one alpha blending exercise:

BlendState BS3 {
    BlendEnable[0]     = TRUE;
    SrcBlend[0]        = ONE;
    SrcBlendAlpha[0]   = ZERO;
    DestBlend[0]       = ONE;
    DestBlendAlpha[0]  = ZERO;
    BlendOp[0]         = ADD;

There are 3 triangles overlapping #1, #2 and #3. Each one has it's own RGBA values. The background color is 0.0, 0.0, 0.0, 0.0.

My tries:

SrcBlendAlpha and DestBlendAlpha are both 0.0. I can calculate all rgb values with

1*rgb#3 + 1*rgb#2 + 1*rgb#3

The alpha value is: 0 * alpha#3 + 0 * alpha#2 + 0 * alpha#1 = 0.0

The resulting color then is: (0.0, 0.0, 0.0, 0.0)

Is my approach correct? Does this even make sense having a color with alpha value 0?

  • \$\begingroup\$ Sure, you can have a color with alpha value zero. But just because the alpha is zero does not make the RGB zero. The RGB is just doing additive blending so it will just be the sum of the three triangles' RGBs. \$\endgroup\$ Commented Aug 1, 2013 at 16:47
  • \$\begingroup\$ @NathanReed Okay. But if alpha = 0 -> transparent. Which is the resulting RGB value? 0.0,0.0,0.0 (background) or the blended calculated rgb value? \$\endgroup\$ Commented Aug 1, 2013 at 16:48
  • \$\begingroup\$ Alpha is just another channel. It only means opacity if you set a blend mode that causes it to act like opacity. In this case you have a pure additive blend mode. The RGB is simply going to be the sum of the background and the three triangles' RGBs. There is no crosstalk between the RGB and alpha, so they do not affect each other in any way. \$\endgroup\$ Commented Aug 1, 2013 at 17:00

1 Answer 1


With the introduction of programmable blending units, the intuitive meaning of alpha being a measure of opaqueness doesn't always hold.

In the two-operand blend you have two contributing fragments:

  • the source (what you're blending, the new fragment),
  • the destination (what already exists in the spot you're blending to).

You have two independent blending equations, one for the colour components and one for the alpha. Your blend state controls parameters of those equations, relating the two inputs with the output.

result.rgb = ColorBlendOp(src.rgb * SrcBlendColor, dst.rgb * DestBlendColor);
result.a   = AlphaBlendOp(src.a   * SrcBlendAlpha, dst.a   * DestBlendAlpha);

The blend operations are normally mathematical operations like add, subtract, reverse subtract, multiply, applying the operation to the two operands.

Your blend factors expands to constants or values related to the components of the source and destination fragments:

  • ONE and ZERO expand to literal 1 and 0.
  • SRC_ALPHA expands to (src.a).
  • INV_SRC_ALPHA expands to (1-src.a).
  • DST_ALPHA expands to (dst.a).
  • And so on...

In order to evaluate a blending equation, substitute the blend factors and operations with their mathematical expansion, plug in the values from your source and destination fragments, and evaluate the expression.

At no point here do we attach any particular meaning to alpha and the colour components, they're just constants in an equation. The interpretation of the resulting RGB+alpha is up to the application, not the blender.

For your set of parameters, we get the following equation pair (assuming alpha blending uses the same operation):

result.rgb = Add(src.rgb * 1, dst.rgb * 1);
result.a   = Add(src.a   * 0, dst.a   * 0);

If you've got several blends to perform after each other, take the rgb and a of the previous expression and use it as destination rgb and a after each blend.

For an example of two things blended in turn onto a background, you've got:

final = blend(#2, blend(#1, background)))

or more explicit:

inter = blend(#1, background)
final = blend(#2, inter)
  • \$\begingroup\$ Very impressive and helpful post. \$\endgroup\$ Commented Aug 1, 2013 at 17:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .