Dewey Anderson (dewey++at++evt.com)
Wed, 30 Apr 1997 14:08:34 -0600
--PART-BOUNDARY=.19704301408.ZM21212.evt.com
Content-Description: Text
Content-Type: text/plain ; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Zm-Decoding-Hint: mimencode -q -u
Thanks for the response, Remi.
On Apr 30, 11:44am, R=E9mi Arnaud wrote:
> Subject: Re: Performer Blending Function
> 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 c=
an't
seem
> > to find that in the documentation anywhere. Can anybody confirm or d=
eny
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.
>
Thanks. Looking at man pfTransparency got me the line I was looking for:=
PFTR_BLEND_ALPHA
IRIS Performer will use the IRIS GL blendfunction(3g) or
OpenGL glBlendFunc(3g) method of transparency.
I use PFTR_BLEND_ALPHA. I set it with:
gstate->setMode( PFSTATE_TRANSPARENCY, PFTR_BLEND_ALPHA );
when building textured rectangles. I had been looking at the man page fo=
r
pfGeoState and the discussion of PFSTATE_TRANSPARENCY mode. That's why I=
missed looking at pfTransparency.
(The rest of this deals with the discussion of available blend funcs.)
> > 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 re=
sults
in
> > something only 75% opaque instead of 100%.) What's needed is a blend=
ing
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 t=
han
> blending.
I'm actually looking at a case where there is only one performer object -=
a
single textured rectangle where the texture has some non-0, non-1 alpha v=
alues
- being drawn over a background that was drawn earlier with OpenGL. (I h=
ave a
draw callback that prevents the screen from clearing.) So I don't think
sorting should matter. As it happens, on a High Impact and Octane Si, we=
trade
off Z-buffer for color and end up turning off bin sorting with:
chan->setTravMode( PFTRAV_CULL, PFCULL_GSET | PFCULL_VIEW );
I'm assuming this doesn't set some flag that says "Don't blend." but, rat=
her,
leaves it to us to make sure we draw things in a sensible order.
> 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 ?
It would seem to me that Destination alpha IS used in determining the res=
ulting
ALPHA (but not the other color components).
Using
Cs to denote a generic source color component
Cd to be a generic destination component
C for generic resulting component
As for source alpha
Ad for destination alpha
we have (for the GL_SRC_APLHA,GL_ONE_MINUS_SRC_ALPHA case):
C =3D Cs*As + Cd*(1-As)
When you apply this to the alpha component, you have:
A =3D As*As + Ad*(1-As)
You can see that the destination alpha is used. Similarly, for the GL_ON=
E,
GL_ONE_MINUS_SRC_ALPHA case we have:
C =3D Cs*1 + Cd*(1-As)
applied to alpha gives
A =3D As*1 + Ad*(1-As) =3D As + Ad - Ad*As
which is what I'd really like.
> 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.
I can see that in CG applications where all you care about is what is dra=
wn on
the SGI's screen. But I'm using the VIDEO out (not graphics) so having a=
lpha
in my Frame Buffer configuration is crucial. I'm taking this alpha OUT o=
f the
box through the video boards and using that externally.
> 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.
I think that depends on your system. When I do glxinfo on our O2, Impact=
and
Octane I find these modes (among others)
O2:
visual x bf lv rg d st r g b a ax dp st accum buffs ms
id dep cl sp sz l ci b ro sz sz sz sz bf th cl r g b a ns b
0x37 24 tc . 32 . r y . 8 8 8 8 . 24 8 16 16 16 16 . .
Impact:
Visual Tra buf lv rg DB ste r g b a aux dep ste accum buffs MS
id dep cl nsp sz l ba reo sz sz sz sz buf th ncl r g b a num b=
uf
0x2b 24 tc . 24 . y y . 8 8 8 8 . . . 16 16 16 16 . =
=2E
Octane:
visual x bf lv rg d st r g b a ax dp st accum buffs ms
id dep cl sp sz l ci b ro sz sz sz sz bf th cl r g b a ns b
0x28 24 tc . 32 . r y . 8 8 8 8 . . . 16 16 16 16 . .
so I have not trouble getting an 8/8/8/8 visual.
> > 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.
What does give me what I need is to have a mode that uses
C =3D Cs*As + Cd*(1-As)
for the r,g,b color components but uses
A =3D As*1 + Ad*(1-As) =3D As + Ad - Ad*As
for the alpha components.
> > 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 in=
put 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 =3D Min(SourceAlpha, 1-DestAlp=
ha)
which
> does not work for you.
Yeah, I looked at that one, too. It seemed to me it would be right half =
the
time, but not the other. What I need is f =3D SourceAlpha ALWAYS.
> 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_EX=
T)
'fraid not.
> I hope that helps
Thanks for the feedback.
Dewey Anderson
dewey++at++evt.com
Evolving Video Technologies
--PART-BOUNDARY=.19704301408.ZM21212.evt.com--
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:55:08 PDT