Re: Transparent Sorting Bug(?) in Performer

New Message Reply Date view Thread view Subject view Author view

From: Brian Furtaw (brian++at++sgi.com)
Date: 04/17/2000 07:43:15

I am coming into this conversation late but why can't you just put the
transparent geometry into its own draw bin. Since it won't be sorted
under a DCS with DRAW callbacks just give it its own draw bin.

Brian

MLM Veraart wrote:
>
> Angus Dorbie wrote:
> >
> > Angus Dorbie wrote:
> > >
> > > This is not a bug.
> > >
> > > After a bit of investigation it looks like you had a draw callback above
> > > the geosets on the logo geode added in the logoNode function, it isn't
> > > #if'ed with ADD_DRAW_CALLBACK. Draw callbacks stop sorting below the
> > > node. Maybe the DCS fixed this because of some undocumented behaviour,
> > > since we don't sort state below a DCS it perhaps didn't see a problem
> >
> > This should read, since we don't sort state *ACROSS* DCSs, my thinking
> > is it might subtly affect the sort heuristics of the 'ping pong' routine
> > when underneath the DCS w.r.t. range sorting.
> >
> > Cheers,Angus.
> >
> Removing the drawcallbacks isn't an option. I need the drawcallbacks to
> render some custom geometry that needs to be sorted back to front because
> it contains transparent polygons. I have looked if I can subclass the pfGeoset
> and implement my own draw method but that would not succeed because the
> pfGeoset::draw() method is not virtual, according to the man page.
>
> After implementing the workaround found in the test program inside the big
> application resulted in a complete relocation of the geometry. Where it went
> I dont know.
>
> With opaque geometry the penalty of no sorting due to drawcallbacks is a little
> extra time for the state switches but the penalty with transparent geometry is
> a visible one. Transparent objects are invisible behind a tranparent polygons
> because the Z-buffer is updated. Disabling the Z-buffer results in the wrong picture
> because the render order is irregular, not back to front all the time.
>
> Is there a possibility to draw custom geometry and let performer sort it
> back to front together with the other transparent geometry?
>
> > > sorting with dept major. Removing the geode draw callback fixed the
> > > problem.
> > >
> > > Also (and I haven't checked the permutations with this) I added the
> > > following calls:
> > >
> > > chan->setBinSort(PFSORT_TRANSP_BIN, PFSORT_BACK_TO_FRONT, NULL);
> > > chan->setTravMode(PFTRAV_CULL, PFCULL_VIEW | PFCULL_SORT |
> > > PFCULL_GSET);
>
> According to the man page these are the default behaviours of the channel.
>
> Mario Veraart
>
> > >
> > > At least one of these is the default but I'm just being explicit here to
> > > make it clear where all the hooks for this stuff are and what's required
> > > to make it work.
> > >
> > > Cheers,ANgus.
> > >
> > > MLM Veraart wrote:
> > > >
> > > > Hello,
> > > >
> > > > I think I have found a bug in Iris Performer.
> > > > It is about sorting of transparent geometry.
> > > > In a testcase have located the error. It can be solved
> > > > by putting an Identity pfDCS() in front of the geometry
> > > > that is wrong sorted.
> > > >
> > > > The performer scene graph of the NON working case is
> > > >
> > > > pfScene
> > > > |
> > > > +-- pfGeode -- pfGeoset (cube flt file)
> > > > |
> > > > +-- pfDCS[T(20,3,0)] -- pfGeode -- pfGeoset
> > > > | (quad with iris texture around 0,0,0)
> > > > |
> > > > +-- pfGeode -- pfGeoset
> > > > | (quad with logo texture around 20,6,0)
> > > > |
> > > > +-- pfDCS[T(20,9,0)] -- pfGeode -- pfGeoset
> > > > | (quad with iris texture around 0,0,0)
> > > > |
> > > > +-- pfGeode -- pfGeoset
> > > > (quad with logo texture around 20,12,0)
> > > >
> > > > When viewed the two logo quads are drawn first and the the two iris quads.
> > > > But when I add a pfDCS with an identity matrix in front of the logo quads
> > > > the sorting is done in the right way.
> > > >
> > > > The performer scene graph of the working case is
> > > >
> > > > pfScene
> > > > |
> > > > +-- pfGeode -- pfGeoset (cube flt file)
> > > > |
> > > > +-- pfDCS[T(20,3,0)] -- pfGeode -- pfGeoset
> > > > | (quad with iris texture around 0,0,0)
> > > > |
> > > > +-- pfDCS[T(0,0,0)] -- pfGeode -- pfGeoset
> > > > | (quad with logo texture around 20,6,0)
> > > > |
> > > > +-- pfDCS[T(20,9,0)] -- pfGeode -- pfGeoset
> > > > | (quad with iris texture around 0,0,0)
> > > > |
> > > > +-- pfDCS[T(0,0,0)] -- pfGeode -- pfGeoset
> > > > (quad with logo texture around 20,12,0)
> > > >
> > > > For me this is a workaround for the application I have now.
> > > >
> > > > Is this a bug in performer 2.2.4?
> > > >
> > > > You can find the files of the test program based on complex.C
> > > > at the following URL http://alley.fel.tno.nl/~rioj7/TransparentSorting/
> > > >
> > > > Thanks in advance.
> > > >
> > > > Mario Veraart
> > > > -----------------------------------------------------------------------
> > > > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > > > Submissions: info-performer++at++sgi.com
> > > > Admin. requests: info-performer-request++at++sgi.com
> > >
> > > --
> > > For Performer+OpenGL tutorials http://www.dorbie.com/
> > >
> > > "In the middle of difficulty lies opportunity."
> > > --Albert Einstein
> > > -----------------------------------------------------------------------
> > > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > > Submissions: info-performer++at++sgi.com
> > > Admin. requests: info-performer-request++at++sgi.com
> >
> > --
> > For Performer+OpenGL tutorials http://www.dorbie.com/
> >
> > "In the middle of difficulty lies opportunity."
> > --Albert Einstein
> > -----------------------------------------------------------------------
> > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com 

-- 
    ----oOOo----    ----oOOo----    ----oOOo----    ----oOOo----

Brian Furtaw  (brian++at++sgi.com)	
Graphics Guru		       Office:(301)572-3293   Fax: (301)572-3280
12200-G  Plum  Orchard  Drive  OpenGL/Performer/OpenInventor/ImageVision	
Silver Spring, Maryland 20904  Volumizer/Optimizer/React/PCI Device
Drivers

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Mon Apr 17 2000 - 07:45:18 PDT

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