Re: Transparent Sorting Bug(?) in Performer

New Message Reply Date view Thread view Subject view Author view

From: Angus Dorbie (dorbie++at++sgi.com)
Date: 04/17/2000 07:58:49

The problem then is drawing the bins in the right order in conjunction
with getting the in front transparent stuff & the in back stuff in the
right bin w.r.t. the draw callback.

It's basically the suggestion in my last email, but I pointed out you
need multiple bins & application level sorting.

CHeers,Angus.

Brian Furtaw wrote:
>
> 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
> -----------------------------------------------------------------------
> 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

New Message Reply Date view Thread view Subject view Author view

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

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