Re: Changing Accumulation Buffer

New Message Reply Date view Thread view Subject view Author view

From: Brian Furtaw (brian++at++sgi.com)
Date: 01/27/2000 07:53:13


I think I have the answer to this. Here is what I am going to try. I am
going to duplicate all the pfGeodes in the scenegraph so I can do this
in one pass through the scenegraph. I'll add pre and post Draw callbacks
to do the following. Set the glBlendColorEXT(0,0,0,0.5) so half the
intensity of each material pass is combined, this way I can at most get
full intensity. Turn on blending glEnable(GL_BLEND), I can't use
pfTranparency here because it turns off the depth buffer. For the first
material the glBlendFunc(GL_CONSTANT_ALPHA_EXT, GL_ZERO) ignore the
background. For the second material glBlendFunc(GL_CONSTANT_ALPHA_EXT,
GL_ONE) adding it to the previous rendering of the object. I am going
to try and leave the depth buffer on because I only want the pixels that
would normally win the depth test. Because the depth buffer is on I will
have to displace (pfLayer Node) the second material pass forward so the
depth test doesn't cancel out my pixels and ruin the blending.

Brian

"Paik, Charles C" wrote:
>
> Thanks for the responses thus far. I believe the best suggestions thus far
> is to use an alpha blending approach. I have considered using alpha
> blending. However, I believe alpha blending may give unwanted effects.
>
> Let's take the example of rendering the scene with the first material
> properties, and then turn on alpha blending and render the scene with the
> second set of material properties. There would a problem with the second
> render if there were objects that overlapped each other, and I would
> definitely have things that would overlap. I have an earth-sky model, a
> terrain model, and other models that populate the terrain. Each time an
> object is rendered in a specific pixel, the alpha blending would blend it in
> with the background pixel. So, I have the potential of blending in the
> earth-sky model, terrain, and other models in a single pixel, but the effect
> I want is to blend only the model with the background. I suppose I might
> want to sort by distance, but I was hoping not to get to that low level of
> control.
>
> I welcome future comment Thanks.
>
> --
> Charles C. Paik
> The Boeing Company
> P.O. Box 516 MC S106-4715
> St. Louis, MO 630166-0516
>
> email: charles.c.paik++at++boeing.com
> phone: 314-233-6807 fax: 314-232-4181
>
> > ----------
> > From: Lawrence Bertoldi[SMTP:lberto++at++bert.clubfed.sgi.com]
> > Sent: Wednesday, January 26, 2000 11:35 PM
> > To: Paik, Charles C
> > Cc: 'info-performer++at++sgi.com'
> > Subject: Re: Changing Accumulation Buffer
> >
> >
> > > Hi,
> > >
> > > I am rendering a scene with 2 different sets of material properties. I
> > > would like to display the scene as if the scene was rendered separately
> > and
> > > additively superimposed. My thought was that the accumulation buffer
> > would
> > > be ideal for this application. I could render each scene independently
> > and
> > > use the accumulation buffer to mix the imagery. However, it seems that
> > > there is a serious performance penalty with the accumulation buffer.
> > >
> > > I used an onyx2 at 1280x1024 resolution as a test bed. It seems that
> > it
> > > takes approximately 3.5 ms for each glAccum operation. In my
> > experiments, I
> > > would
> > >
> > > 1) Render the scene with the first material property to the color
> > buffer,
> > > 2) Copy the color buffer to the accumulation buffer,
> > > 3) Render the scene with the second material property to the color
> > buffer,
> > > 4) Additively transfer the color buffer to the accumulation buffer, and
> > > 5) Copy the accumulation buffer back to the color buffer.
> >
> >
> > Why not render the scene once with the first material to the color buffer
> > Then:
> > change the material,
> > then do something like
> > glBlendFunc(GL_CONSTANT_ALPHA_EXT,GL_ONE_MINUS_CONSTANT_ALPHA_EXT);
> > ( if no alpha (you might want to check the man page for
> > specifics)),
> > glBlendEquationEXT(GL_FUNC_ADD_EXT);
> > glEnable(GL_BLEND);
> >
> > render the object or scene again?
> >
> > >
> > > There are three transfers between the color and accumulation buffers
> > (Steps
> > > 2, 4, & 5). Those three steps have caused an additional 10.5 ms of fill
> > > time. 10.5 ms is a very heavy hit for my application.
> > >
> > > My next thought was to render the second scene directly in the
> > accumulation
> > > buffer, and additively transfer the accumulation buffer back to the
> > color
> > > buffer. But I do not know how to do either of those steps. (Or even if
> > it
> > > is possible.)
> > >
> > > Can anyone offer any suggestions? I am open to any hints, hacks, or
> > > altogether different approaches. Thanks.
> > >
> > >
> > > PS Does anyone know how to load tiff files in performer? Thanks again.
> > > --
> > > Charles C. Paik
> > > The Boeing Company
> > > P.O. Box 516 MC S106-4715
> > > St. Louis, MO 630166-0516
> > >
> > > email: charles.c.paik++at++boeing.com
> > > phone: 314-233-6807 fax: 314-232-4181
> > > -----------------------------------------------------------------------
> > > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > > Submissions: info-performer++at++sgi.com
> > > Admin. requests: info-performer-request++at++sgi.com
> > >
> >
> > Lawrence Eugene Bertoldi
> > graphics consultant
> > SGI Professional Services
> > ~;-}>
> >
> -----------------------------------------------------------------------
> 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 Optimizer/React/PCI Device Drivers


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Thu Jan 27 2000 - 08:16:13 PST

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