Re: (originally no subject) Texturing modes

New Message Reply Date view Thread view Subject view Author view

Angus Dorbie (dorbie++at++sgi.com)
Mon, 08 Jun 1998 11:10:58 -0700

Moshe Nissim wrote:
>
> > > Prakash Mahesh wrote:
> > >
> > > > --
> > > > We have been attempting to combine different texturing modes (a
> > > > mixture of modulate and decal) in Performer to allow for the following
> > > > behavior for 4 channel texture images:
> > > > C = (1-At)Cf + At(Ct)
> > > > A = At
> > > > where At is the alpha channel for the texel,
> > > > Cf is the color of the fragment,
> > > > and Ct is the color of the texel.
> > > >
> > > That would wonderful to have in OpenGL, wouldn't it?
>
> > No, what's being requested is _very_ strange and has limited
> > application.
> > Perhaps you have something else in mind, but it's unclear exactly what.
>
> I think what I have in mind is what the original post requested.I will mention later why it is not so strange.
>
> A texture environment that blends texture color with fragment color, (instead
> of multiplying them), according to a constant alpha value. This constant alpha
> can be the alpha component of the texture environment color (Cc).

No the original request said At for blend, in otherwords it doesn't want
to
use a constant alpha value I've isolated the relevant parts of the
email:

"C = (1-At)Cf + At(Ct)"
"A = At"
"At is the alpha channel for the texel"

I agree what you describe isn't as strange but it's not what was
requested.
Looks like you did have something else in mind.

>
> GL_MODULATE multiplies Ct and Cf. This may contradict intuition (of some).
> For example, if lighting is enabled, the material colors are greenish,
> and the texture is bluish, the resulting color is blackish.

Well, this is accurate physics and desirable for a 3 band spectrum.

>
> In our Performer loader for SoftImage, this is the exact problem we
> are encountering. SoftImage may define a texture-material interaction which
> is blending by a speficied factor. To implement this in Performer (and OpenGL),
> there is no direct texture environment that is applicable. Like I mentioned,
> GL_MODULATE does not blend at all. GL_ADD is closer, but it does not multiply
> the fragment color (Cf), just the texture color (Ct). The only way to do it
> (without resorting to multipass rendering...)
> is with GL_DECAL, and RGBA texture, with the blend factor written all accross the
> alpha channel of the texture. Then it does Cv=(1-At)Cf+AtCt. However, we need
> to sacrifice the texture's alpha channel for this constant value.
> I would love to see the following texture environemnt:
> Cv=(1-Ac)Cf+AcCt
> Av=(1-Ac)Af+AcAt

Agreed, this would be usefull, but so could lots of other fragment
operations.

Right now most obviously and more usefully for me which the above
approach
could also give me.

Cv=(1-Af)Cf+AfCt

But 3D texture can handle this.

>
> I am including the formula tables from glTexEnv
> You could argue that also some of these are _very_ strange and have limited
> application :)

They are common and intuitive methods texture application once you
understand the equations. If they weren't supported we'd have a
heck of a lot more complaints about lack of functionality in texture
fragment operations.

The permutations from extending current functionality rapidly explode,
everyone requires a different operation and the fragment operation
w.r.t.
the lighting equation (diffuse vs specular) is much more of an issue.
What's needed is something more powerfull than half a dozen pre canned
texture environments, but that requires another look at the glTexEnv.

Cheers,Angus.

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 


For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.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

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:57:31 PDT

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