Re: Performer Blending Function

New Message Reply Date view Thread view Subject view Author view

Rémi Arnaud (remi++at++remi.asd.sgi.com)
Wed, 30 Apr 1997 11:44:28 -0700 (PDT)


Dewey Anderson wrote:
>
> Hey Performulators,
>
> I seem to remember reading once that when transparency is enabled in Performer,
> it uses whatever the current blending function is in OpenGL. But I can't seem
> to find that in the documentation anywhere. Can anybody confirm or deny this?
> And point me to place in the documentation?

 You can use 2 type of transparency:

 MsAplha, screen door using the multisample mask
    pfTransparency(PFTR_MS_ALPHA);

  Blending, using the Alpha plane, for best results
    pfTransparency(PFTR_BLEND_ALPHA);

  see man pfTransparency.

>
>
> A related OpenGL point: The OpenGL book says that
>
> glBlendFunc( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA )
>
> is "the most commonly used blending operation".
>
> For color components, I agree, but this leads to undesired values for alpha
> channel. (e.g. a 50% opaque object on top of a 100% opaque pbject results in
> something only 75% opaque instead of 100%.) What's needed is a blending func
> that does ( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA ) on the colors but does
> ( GL_ONE, GL_ONE_MINUS_SRC_ALPHA ) on the alpha.

  Blending works only if polygons are sorted front to back. see man
  pfChannel, section on Bin sorting. Screen door transparency works
  fine even if polygons are not sorted, with less transparency levels than
  blending.

  The Destination alpha is never used in the GL_SRC_APLHA,GL_ONE_MINUS_SRC_ALPHA nor in your proposed GL_ONE, GL_ONE_MINUS_SRC_ALPHA, so the resulting
  alpha value is not good in either case ?
  The major issue about the above Blend func is that it does not use at all
  the destination alpha, so you do not need to have alpha planes in
  your Frame Buffer configuration for blending to work.

  Note that alpha planes are available on 12/12/12/12 modes, and none
  alpha plane configurations are available on 8/8/8 bits per component.
  see glxinfo.

>
> The only recourse I see is to use ( GL_ONE, GL_ONE_MINUS_SRC_ALPHA ) and
> premultipy all my color components by alpha. Inconvenient. And this leads to
> loss of information, i.e. I can't "recover" a part of an image where I have
> 0'ed the alpha.

 I'm not quite sure what should be a good value for you. Using src+(1-src)*dst
 as resulting alpha doesn't seem to give you what you need.
>
> BTW, for people who only look at the results on the graphics screen, using
> SRC_ALPHA doesn't matter. At that stage you're done with the alpha. For
> people in the video business who then take that alpha out of the box and into a
> switcher, this is a big problem.
>
> I guess this part is just a gripe and a "heads up" for anyone with input to new
> OpenGL extensions.
>

 The only extension I see that have a 1 for alpha and a coeficient for RGB is
 the SRC_ALPHA_SATURATE (f,f,f,1) with f = Min(SourceAlpha, 1-DestAlpha) which
 does not work for you.
 You also use the CONSTANT_COLOR_EXT, if the source alpha value
 is constant for the geoset, seting the color as (alpha,alpha,alpha,1)
 and the blend func as (CONSTANT_COLOR_EXT, ONE_MINUS_CONSTANT_ALPHA_EXT)

  I hope that helps

    _ / _ _
|_) _ ._ _ o /\ |_)|\ | /\ | || \
| \(/_| | || /--\| \| \|/--\|_||_/
                                           
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
            Submissions: info-performer++at++sgi.com
        Admin. requests: info-performer-request++at++sgi.com


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:55:08 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.