From: Angus Dorbie (dorbie++at++sgi.com)
Date: 04/17/2000 07:55:00
This is a design decision which was made way back.
The idea is that a draw callback introduces a heavyweight state change,
Performer pushes and pops state and doesn't really know what the
application gets up to. It avoids invoking the draw callback more than
once, unless geometry below that node is placed in different draw bins.
Your geometry should not have vanished with the WAR, I suspect there is
a problem with the bounding information passed to the CULL, if as you
say this is to get dynamic geometry or it is being depth occluded by
something transparent.
An RFE would be to allow the user to force sorting even below draw
callbacks, which is what the DCS apparently did to the depth sort, for
undocumented reasons. There is a heuristic to turn off state sorting
across DCS's because on legacy platforms this was more expensive than
the potential replication of state changes, and this may have had some
effect on the depth sort. It makes me worry about how often your draw
callbacks were invoked, with the DCS WAR apparently working, I'd be
concerned about the appropriate state being active from my draw CB's
when the sorted geosets were actually drawn. It requires some
investigation.
An alternative and cumbersome solution would be to use multiple custom
draw bins each depth sorted and frequently in the app sort your geometry
into the draw bins based on whether they are in front of or behind your
callback geometry. Each draw bin would then also independently sort.
Cheers,ANgus.
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
-- For Performer+OpenGL tutorials http://www.dorbie.com/"In the middle of difficulty lies opportunity." --Albert Einstein
This archive was generated by hypermail 2b29 : Mon Apr 17 2000 - 07:55:04 PDT