From: Angus Dorbie (dorbie++at++sgi.com)
Date: 04/17/2000 09:42:25
MLM Veraart wrote:
>
> Angus Dorbie wrote:
> >
> > 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.
> In the real app I set the bounding box of the geoset, and the same bounding
> sphere of the pfGeode and pfDCS (if present). The geometry is visible
> when the pfDCS is not in the scenegraph. And it is not depth occluded
> because then this should be also the case when the DCS is present
> (the geometry is a certain distance above the terrain surface)
There must be some error in your bounds then. Also the depth occlusion I
meant was with transparent geometry and would be order dependent.
>
> > 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
>
> Where can I find this heuristic method?
You cannot, this is internal code.
>
> > 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.
>
> The number of instantiations of this geometry is not known, ranging from
> 0 .. hundreds, changing in time. So the method of multiple draw bins and
> sorting myself is not very much of an option. I'm not able to setup the
> geometry with a pfGeoset with all attributes pfFluxed because the rendering
> of the geometry is dependend on the position of the viewer in respect to
> the geometry, and there are more than one views of the scene.
>
> What would really help me is a subclass of pfGeoset, where performer handles
> the sorting and the apply of the pfGeoState and I am allowed to implement
> my own drawing routine, or enhance/encapsulate the default draw() method.
Can you represent your dynamic data as a geoset instead of a draw
callback to OpenGL?
>
> Mario Veraart
> >
> > 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
This archive was generated by hypermail 2b29 : Mon Apr 17 2000 - 09:42:32 PDT