Rob Jenkins (robj++at++sgi.com)
Wed, 02 Dec 1998 01:49:15 -0800
I just wrote a longer response to this, then double checked something on
an iR and realised the answer is much simpler for this case, I'll leave
the longer response pasted below as it's generally useful as some notes
on texture/framebuffer resolution but for your specific case the banding
is due to the transparency method used:
The default transparency on iR, if you have a visual with multisampling,
is multisample transparency, you get 2^N levels of transparency (where N
is # samples ). This is fast and doesn't need sorting of geometry but
for reasons discussed below, with your low freq changes in alpha would
explain the banding effect. If you turn off anti aliasing in perfly with
your data, the banding goes away. To make it unbanded, and have anti
aliasing in your app, set a different transparency method ( see man
pfTransparency ). On Octane you never get multisamples, so default to
blended transparency.
Cheers
Rob
-----------------------------------------------------------
First pass response, before the penny dropped :-) Still mostly useful
for general ref.
Firstly, you're texture is a 2 component, intensity alpha texture right
So the internal formats for pfTexture of interest are the 2 component
formats.
I doubt filters are related to the banding if we're looking at the
object from perpendicular, low res filters normally give scintillation
effects, not banding, banding is down to image/texture resolution.
By default, on any machine ( Octane or iR ), Performer will pick 16 bit
textures, so running in perfly you get the defaults, in your case the
texture would be internally PFTEX_I_12A_4, in other words, 12 bits for
the intensity, 4 bits for the alpha. This is fine for some kind of
texture like a tree or cloud with high frequency color changes in and
high frequency changes in alpha ( ie 2 adjacent pixels could be very
different colors and very different alpha, in some cases at the edge of
the tree 1 pixel might have alpha of 1, the next pixel alpha of 0 ). In
your example you have a texture where you have low frequency alpha ( and
color ) changes, like a grey scale, you only have 4 bits to represent
the alpha, so only 16 possible levels of alpha over the whole scale so,
you will get banding in the alpha levels.
All that said, if you have a higher res internal format for the texture
and still get banding then the only other variable might be the actual
resolution of the framebuffer visual you have selected for the app, the
same applies, say you only had 4 bits per component in the visual then a
grey scale could look banded ( no matter what res it's stored as in
internal texture memory ). On my Impact, perfly is using:
0x2b, RGBA 5/5/5/1, db, Z 24, S 8, accum 16/16/16/16
So 5 bits for RGB, it doesn't look too bad, if I force perfly to use an
RGB 4 visual ( pick one using findvis, then use perfly -t <visualid) )
it does look banded. ( NB ignore the 1 alpha bit for this visual,
transparency isn't using the framebuffer alpha planes....)
To see what an app is using, run the app, do xwininfo -tree, click the
mouse on the app window, do xwininfo -id <the id of the perfly main
window ). Then look up the id in findvis.
-----------------------------------------------------
> Thanks again Brett for taking time.
>
> -- Jonas
>
> >
> > Brett
> >
> > Jonas Andersson wrote:
> > >
> > > On Tue, 1 Dec 1998, Brett Chladny wrote:
> > >
> > > > Jonas,
> > > >
> > > > I read you letter and I don't think that Rob's reply was what you were
> > > > looking for. I tried your file in Perfly on my Octane MXE and it worked
> > > > just fine. What type of computer are you using?
> > >
> > > Hi Brett, and thank you very much for your letter!
> > > Imagine my surprise when trying the file on our Octane, it looks perfect.
> > >
> > > On our Onyx IR2 it appears banded, and on our O2:s the texture isnīt shown
> > > at all.
> > >
> > > Even if I put all filters to "none" in Multigen it looks perfect on the
> > > Octane, but banded on the Onyx.
> > >
> > > What happens on the Octane that doesnīt on the Onyx?
> > >
> > > >
> > > > It sounds like there is some sort of problem with the texture in texture
> > > > memory. Have you had any other texture problem like this? Also, try
> > > > changing the textures minification filter in MultiGen and view it agian
> > > > in Perfly.
> > > >
> > > > Brett Chladny
> > > >
> > > >
> > > >
> > > > Jonas Andersson wrote:
> > > > >
> > > > > Hi pfAll,
> > > > >
> > > > > With Multigen I have created a square with a texture that is
> > > > > smoothly fading from black to transparent.
> > > > >
> > > > > When loading it with perfly however, it looks like each pixel of the
> > > > > texture is fading "in the opposite direction" of the fading texture.
> > > > >
> > > > > The result is vertical stripes, each stripe being more transparent than
> > > > > itīs left neighbor, but each stripe being more transparent to the
> > > > > left than to the right.
> > > > >
> > > > > It seems to me there are some kind of property I could use to fix this
> > > > > problem, but I donīt know which. If you know, please let me know...
> > > > >
> > > > > Example files are attached in fadetest.tar.
> > > > >
> > > > > Thankīs in advance for any help.
> > > > >
> > > > > -- Jonas
> > > > > ________________________________________________________________________________
> > > > > Jonas Andersson jonasa++at++acc.umu.se, http://www.cs.umu.se/~jonasa
> > > > >
> > > > > ------------------------------------------------------------------------
> > > > >
> > > > > Name: fadetest.tar
> > > > > fadetest.tar Type: Unix Tape Archive (APPLICATION/x-tar)
> > > > > Encoding: BASE64
> > > >
> > >
> > > -- Jonas
> > > ________________________________________________________________________________
> > > Jonas Andersson jonasa++at++acc.umu.se, http://www.cs.umu.se/~jonasa
> >
>
> -- Jonas
> ________________________________________________________________________________
> Jonas Andersson jonasa++at++acc.umu.se, http://www.cs.umu.se/~jonasa
>
> =====================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
-- ________________________________________________________________ Rob Jenkins Silicon Graphics mailto:robj++at++sgi.com
This archive was generated by hypermail 2.0b2 on Wed Dec 02 1998 - 01:54:21 PST