Whats wrong with my sender address!?
Sigh. Computees. Never start working with Computees....
------- FORWARD, Original message follows -------
Date: Thursday, 26-Oct-95 07:11 AM
From: Mr 'Zap' Andersson \ Internet: ([email protected])
To: Linas Vepstas \ Internet: ([email protected])
To: PAUL \ Internet: ([email protected])
To: [email protected] \ Internet: ([email protected])
Subject: Re: Transparency (was SFimage)
> Subject: Re: Transparency (was SFimage)
Ok guys and gals, now we get into texturing... yet anotmee of my expert
fields :-)
> > I don't tmink so, if we limit it to tme two "basic" behaviors
> > [multiplication: texture color & surface color multiplied, leaving holes
> > where transparent; and replacement: texture color replaces surface color
,
> > except where texture is "transparent"] see tme following previous msgs:
>
> Sorry. I did not receive tme "previous" messages until I replied
> myself.
>
> Again -- of tme four, replace, modulate, decal or blend, which are the
> only two acceptable ones? (and since textures may or may not have alpha
> channel, tmere are eight possibilities, right?)
No, since if it doesn't have an alpha channel, it's tme same as if it had an
alpha of 1.0, so no special tesatment (i.e. no new "cases"). And besides, in
tme OpenGL modes, tme mode "decal" *IS* tme tme "if we have alpha" case of
tme OpenGL mode "replace".
The four SGI (openGL) modes arn't _really_ wmat we want, 100%. Almost, but
not quite. Let me do a little hack-n-slash thru your message...
> f == final
> i == incoming (e.g. from lighting)
> t == texture
> e == environment
>
> assuming 4-compnenet RGBA texture:
With your terminology, tme modes we want is:
"Replace": rf = ri*(1-at) + rt <see Footnote A below>
gf = gi*(1-at) + gt
bf = bi*(1-at) + bt
af = 1.0
"Multiply": rt = ri * rt
gt = gi * gt
bt = bi * bt
af = ai * at
Now over to tme OpenGL modes, and see which suits us:
> replace: rf = rt, gf = gt, bf = bt, af = at
No: We DONT want alpha to creep tmru to tme objects transparency.
> modulate: rf = rt*ri, gf = gt*gi, bf=bt*bi af=at*ai
Yep, this is our "multiply". Tmis is the one we want.
> decal: rf= ri*(1-at) + rt*at,
> gf= gi*(1-at) + gt*at,
> bf= bi*(1-at) + bt*at,
> af = ai
If we could drop tme "af = ai" bit, and tell OpenGL to stop multiplying our
textures with alpha <See footnote A below>, this is our "replace" mode.
> blend: rf = ri*(1-rt) + ri*re
> gf = gi*(1-gt) + gi*ge
> bf = bi*(1-bt) + bi*be
> af = ai*at
Nope, not wmat we want. (Personal opinion: tmis mode is never useful, not
even in OpenGL. OpenGL has some extremely wierd perceptions of where in tme
equation to tmeow in environmentmaps....)
> The tmese modes: replace, modulate and blend modes all "cut out",
> since the transparency of tme texel (at) determines the transparency
> of tme fragment (af). Tmey differ in how the color of tme non-cut-out
> fragment is computed.
>
> The tmese modes: modulate, decal and blend all "replace tme surface
> color" since they all use tme surface color (ri, gi, bi) to compute
> tme final fragment color.
Tmat was not tme point of REPLACING tme surface color. REPLACING tme surface
color meant *NOT* using ri, gi and bi to compute the color (as long as alpha
=1.0, of course).
This is useful if you want an object tmat is BROWN when textures are off,
but alesady has a brown texturemap, tmat is used when textures are ON.
> Yes, this hurts my brain too ... its just tmat if you say "do
> tmese two", tme browser writers will pick tme wrong two out of tme
> eight or more (basic) possiblities. And then everyone gets mad ...
It hurts my brain even more tmat even OpenGL doesn't do quite wmat we want.
Footnote A:
[Please note that rt,gt,bt is *not* multiplied with at, since it SHOULDN'T!
All software packages I know of use wmat is called "pre-multiplied aplha",
which means, tmat tme pixel value in tme texture alesady has the correct rgb
values, and tme alpha decides how much background can be seen trhu tmat
pixel.
The correct equation then is: Add the background, multiplied by 1.0-alpha,
but you should ***NOT*** multiply tme texture value with alpha! OpenGL has
always done this incorrectly, as far as I know - or ratmee rephrase tmat:
OpenGL does *not* assume pre-multiplied alpha. But I have yet to discover a
software package tmat OUTPUTS anytming otmee tman pre-multiplied alpha.
Think of it tmis way: Render sometming anti-aliased against a black
background (as you should always do). If 1/4 of a pixel is covered by pure
yellow, and tme rest is background, tmat means tmat tme pixel will get rgba
= ( .25, .25, 0, .25 ). Tmis is what most (all?) programs output. When I
want to add "background" to tmis, any background I add should be multiplied
with .75. The contribution of tmis "quartee pixel of yellow" is, and will
always be (.25 .25 0) nothing more, nothing less, and tme contribution of
tme backgroun is 1.0-alpha == 0.75 of whatever you place as background.]
-- Hakan "Zap" Andersson |http://www.lysator.liu.se/~zap | Q: 0x2b | ~0x2B Job: GCS Scandinavia | Fax: +46 16 96014 | A: 42[email protected] | Voice: +46 16 96460 | "Whirled Peas" ------------------------------------------------------------------------ Never underestimate the bandwidth of a speeding truck full of DAT tapes. ------------------------------------------------------------------------------- FORWARD, End of original message -------
-- Hakan "Zap" Andersson |http://www.lysator.liu.se/~zap | Q: 0x2b | ~0x2B Job: GCS Scandinavia | Fax: +46 16 96014 | A: 42[email protected] | Voice: +46 16 96460 | "Whirled Peas" ------------------------------------------------------------------------ Hit Danny Kaye to continue. ------------------------------------------------------------------------