From: Andreas Ekstrand (Andreas.Ekstrand++at++saab.se)
Date: 04/17/2002 05:06:46
Marcin,
The trees are loaded using the FLT loader. Since the trees are actually
transparent, I took for granted that PFSTATE_TRANSPARENCY in their
geostates were set to PFTR_ON and the geosets thereby put in the
transparent bin by the loader. Perhaps this isn't necessarily true?
I realize the geoset problem - my trees are for example cross-formed
quads that probably are being placed in a single geoset by the FLT
loader and thereby can't be sorted invidually. I've heard about a
technique called BSP trees - could that possibly be used here? Is there
any support for BSP in Performer?
By the way, how does the Infinite Reality multisampling manage to avoid
this problem?
Regards,
Andreas
Marcin Romaszewicz wrote:
>
> In order to sort transparent geosets back to front, performer has to know
> that they contain transparent geometry. To tell performer, you have to
> call gstate->setMode(PFSTATE_TRANSPARENCY, PFTR_ON) and you can explicitly
> put your trees into the transparent bin. Doing either of these things
> should force back-to-front sorting. Performer does not sort back-to-front
> within geosets, so if you have one geoset with a bunch of trees, they will
> not be sorted with respect to each other, so only put one per geoset. Do
> your trees have transparency enabled but dont get sorted?
> -- Marcin
>
> On Mon, 15 Apr 2002, Andreas Ekstrand wrote:
>
> > Hi Yair,
> >
> > I thought that Performer used a special bin for all transparent geometry
> > and sorted it from back to front. However, I tried an explicit setup
> > like that and it still didn't work.
> >
> > Cut-out trees are not sufficient for me I'm afraid, I would like the
> > alpha edges to blend nicely with the background. So I realize that the
> > rendering order is of importance. But I can't see why this is happening
> > if the background trees actually are rendered before the foreground
> > trees? Do I have to assign special bins just for these trees? Isn't it
> > enough to use the transparent bin?
> >
> > Regards,
> > Andreas
> >
> >
> > Yair Kurzion wrote:
> > >
> > > Hello Andreas !
> > >
> > > By default, IR/IR2/IR3 use a different transparency method than Octane/Octane2.
> > > For correct semi-transparency, Octane/Octane2 require sorting of objects
> > > from farthest to nearest.
> > >
> > > It looks like your trees are not sorted back-to-front. Do you assign
> > > special bins to the tree geometry ?
> > >
> > > Trees are a special case of transparency. You normally don't want to see
> > > semi-transparent pixels. Each pixel is either completely transparent or
> > > completely opaque (the tree texture defines a cut-out of the polygon).
> > > If all you want is cut-out trees, read on ...
> > >
> > > You can fix the tree edge problem without sorting back-to-front: Take a look
> > > at pfGeoState modes: PFSTATE_ALPHAREF and PFSTATE_ALPHAFUNC. They let you
> > > control what alpha values of a polygon are skipped while rendering.
> > > Take a look at man pfAlphaFunc for more info on this.
> > >
> > > -yair
> > >
> > > > I have noticed that polygons with alpha textures (e.g. flat trees or
> > > > bushes) become somewhat strangely rendered when viewed in front of each
> > > > other. If you're viewing such a polygon in front of another, you can
> > > > actually see through the second polygon through the edges between the
> > > > alpha and non-alpha texels of the first polygon.
> > > >
> > > > I know, this might sound a bit confusing, but I'm sure this is a common
> > > > problem and has been noticed by many Performers out there. It doesn't
> > > > happen on IR/IR2/IR3, but it does with Octane/Octane2 as well as with
> > > > Geforce2/Geforce3. I have attached an image that shows the problem quite
> > > > clearly. Could anyone describe why this is happening and if you could
> > > > avoid it?
> > >
> > > --
> > > \_________ \_____ \__ \__ \_____
> > > \_________ \_____ \__ \__ \_____ Yair Kurzion
> > > \__ \__ \____\__ \__ yair++at++sgi.com
> > > \__ \__ \__ (650) 933-6502
> > > \__ \__ \__
> > > \__ \__ \__
> > > -----------------------------------------------------------------------
> > > List Archives, Info, FAQ: http://www.sgi.com/software/performer/
> > > Open Development Project: http://oss.sgi.com/projects/performer/
> > > Submissions: info-performer++at++sgi.com
> > > Admin. requests: info-performer-request++at++sgi.com
> > > -----------------------------------------------------------------------
> >
> > --
> > ---------------------------------------------------------
> > FDM-AE Andreas Ekstrand |E-mail: Andreas.Ekstrand++at++saab.se
> > Saab AB |Phone: +46 (0)13 - 18 40 42
> > SE-581 88 Linkoping |Fax: +46 (0)13 - 18 41 77
> > SWEDEN |
> > ---------------------------------------------------------
> > -----------------------------------------------------------------------
> > List Archives, Info, FAQ: http://www.sgi.com/software/performer/
> > Open Development Project: http://oss.sgi.com/projects/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
> > -----------------------------------------------------------------------
> > ITEC 2002 Friends of Performer Meeting: Wednesday April 10 17:00h
> > Hainaut Room, Lille Grand Palais, Lille, France
> >
>
> -----------------------------------------------------------------------
> List Archives, Info, FAQ: http://www.sgi.com/software/performer/
> Open Development Project: http://oss.sgi.com/projects/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
> -----------------------------------------------------------------------
> ITEC 2002 Friends of Performer Meeting: Wednesday April 10 17:00h
> Hainaut Room, Lille Grand Palais, Lille, France
-- --------------------------------------------------------- FDM-AE Andreas Ekstrand |E-mail: Andreas.Ekstrand++at++saab.se Saab AB |Phone: +46 (0)13 - 18 40 42 SE-581 88 Linkoping |Fax: +46 (0)13 - 18 41 77 SWEDEN | ---------------------------------------------------------
This archive was generated by hypermail 2b29 : Wed Apr 17 2002 - 05:07:19 PDT