From: Alexander Lechner (alexander.lechner++at++vertigo-systems.de)
Date: 08/26/2005 07:31:03
Some clarification:
glDrawPixels of course generates fragments, so the depth buffer should get
updated as well. Your code writes 1.0 into the depth buffer with
glDrawPixels, so this should be fine.
Nevertheless I would try to clear the depth buffer manually with glClear.
Alex
On Friday 26 August 2005 15:57, Alexander Lechner wrote:
> Hi Dan!
>
> Just a guess:
> glDrawPixels only updates the color buffer, so your depth/Z buffer is never
> cleared. So I would try to clear the depth/Z buffer, either before or after
> drawing your background image.
> Also, be aware that glDrawPixels is rather slow, use a texture and a
> fullscreen quad instead.
> I cannot explain why some visuals work and some don't but I remember those
> special clear modes on ONYX hardware when using multisampling. The pixels
> only get tagged as cleared instead of really writing to them.
>
> Good luck.
>
> Alex
> alexander.lechner++at++vertigo-systems.de
>
> On Friday 26 August 2005 15:10, Dan Johnston wrote:
> > Warning! Longish posting, but I'm trying to provide
> >
> > all the needed background and information.
> >
> > I need advice from someone who know the interaction
> >
> > between hardware buffers and raw OpenGL and
> >
> > Performer draw routines.
> >
> > After following the recent discussion on "Background
> >
> > Texture" in this discussion group, I created the
> >
> > attached code to render a pfImage (see source for
> >
> > pfUtil) as a background to my models. The selection
> >
> > of buffer is done with a glDrawBuffer earlier in
> >
> > the draw callback - either BACK for mono or BACK_LEFT
> >
> > or BACK_RIGHT for stereo display modes.
> >
> > The image (in apChan->image) is drawn into the
> >
> > background if there is an image provided, otherwise
> >
> > the callback will call pfClearChan. Then callback
> >
> > will call pfDraw to render the models.
> >
> > This works all the time with no image specified,
> >
> > but only sometimes with an image background.
> >
> > It depends on the visual
> >
> > used by the application. I can force the application
> >
> > to use a specified visual, but I normally select
> >
> > the 'best available' based on a weighted average of
> >
> > the attributes (with a minimum requirement for
> >
> > double-buffered RGBA, and a bias for stereo).
> >
> > On my old O2 (which I use as an X-term into the
> >
> > larger 16 processor, 5 IR2 pipe ONYX) the
> >
> > application selected visual 0x31 as 'best' and
> >
> > correctly draws the image with the model rotating
> >
> > in front. Several other visuals on the O2 also
> >
> > corectly show the model in front of the image, but
> >
> > some have no Z-buffer so display the model poorly.
> >
> > The visuals on the O2 that work are as follows
> >
> > (as listed by 'findvis')
> >
> > 0x30, RGBA 5/5/5/1, db, stereo, accum 16/16/16/16
> > 0x31, RGBA 5/5/5/1, db, stereo, Z 24, S 8, accum 16/16/16/16
> > 0x38, RGBA 8/8/8/0, db, accum 16/16/16/16
> > 0x39, RGBA 8/8/8/0, db, Z 24, S 8, accum 16/16/16/16
> > 0x3a, RGBA 8/8/8/8, db, accum 16/16/16/16
> >
> > Note that 30, 38, and 3a had no Z-buffer.
> >
> > Then I tried it local on an ONYX console. The
> >
> > 'best' visual would display only the image. It
> >
> > appears that the model was there and rendering
> >
> > but that the image was in front. The 'best'
> >
> > visual selected by the application was 0x6b
> >
> > 0x6b, RGBA 12/12/12/12, db, stereo, aux 1, Z 23, S 8, accum 32/32/32/32,
> > samples 4
> >
> > By forcing the app to use other visuals I found
> >
> > some that displayed the model(s) in front of the
> >
> > image, but these did not have good Z-buffer
> >
> > performance. I cannot see why some of these
> >
> > "work" and some visual that failed do not.
> >
> > ("worked" ie model seen in front of image background)
> >
> > 0x4f, RGBA 12/12/12/12, db
> >
> > 0x53, RGBA 12/12/12/12, db, stereo
> >
> > 0x77, RGBA 10/10/10/0, db, aux 1, accum 32/32/32/0, samples 4
> >
> > ... and one or two others
> >
> > ("failed", only the image is seen)
> >
> > 0x6b as show above
> >
> > 0x50, RGBA 12/12/12/12, db, Z 31, S 1
> >
> > 0x55, RGBA 12/12/12/12, db, aux 1, Z 32, S 8, accum 32/32/32/32
> >
> > 0x64, RGBA 12/12/12/12, stereo, Z 15, S 1, accum 32/32/32/32, samples 4
> >
> > 0x6f, RGBA 10/10/10/0, db, Z 31, S 1
> >
> > 0x73, RGBA 10/10/10/0, db, Z 15, S 1, samples 4
> >
> > 0x7d, RGBA 10/10/10/0, db, aux 1, Z 15, S 1, accum 32/32/32/0, samples 4
> > ... and many more
> >
> > So... What is happening here? I have not had a chance
> >
> > to try this version of code on other hardware such
> >
> > as our MS-Windows systems and the loaner Prism. I would
> >
> > like a solution that would render the image as a
> >
> > background on all the OpenGL hardware systems.
> >
> > Thanks for any suggestions!
> >
> > Dan Johnston
> >
> > National Research Council of Canada
> >
> > +++++++++++++++++++++++++++++++++++++++++++++++
> >
> > Here is the image draw function called by each
> >
> > pfChannel's draw callback function.
> >
> > PFAPCDLLEXPORT void
> > DrawBackgroundImage (pfChannel *channel, void *data)
> > {
> > ChanPassData *pass;
> > APchannel * apChan;
> > static int justOnce = 0;
> > int xsize, ysize;
> >
> > pass = (ChanPassData *)data;
> > apChan = pass->apchannel;
> >
> > pfGetChanSize( channel, &xsize, &ysize );
> > if (justOnce == 0)
> > {
> > pfNotify(PFNFY_DEBUG, PFNFY_PRINT,
> > "preDraw, channel size is %d %d!\n",xsize,ysize);
> > justOnce = 1;
> > }
> >
> > /* we need to get our background texture and draw it */
> > pfPushState();
> > pfBasicState();
> >
> > /* in case we were in red/Blue stereo mode */
> > glColorMask( GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE);
> >
> > /* we can skip pfClearChan and get both
> > * buffers (color and depth) initialized by
> > * our background image
> > */
> > glDepthFunc(GL_ALWAYS);
> > glDepthRange(1.0,1.0);
> >
> > glPushMatrix();
> > glLoadIdentity();
> > glMatrixMode(GL_PROJECTION);
> > glPushMatrix();
> > glLoadIdentity();
> > glOrtho(0,xsize,0,ysize, -1.0, 1.0);
> >
> > glRasterPos2i(0, 0);
> > /*match image size to screen size */
> > glPixelZoom( (float)xsize/(float)apChan->imageData->xsize,
> > (float)ysize/(float)apChan->imageData->ysize );
> > glDrawPixels(apChan->imageData->xsize, apChan->imageData->ysize,
> > GL_RGB, GL_UNSIGNED_BYTE, apChan->imageData->packed);
> >
> > glPixelZoom( 1.0f, 1.0f);
> >
> > glPopMatrix();
> > glMatrixMode(GL_MODELVIEW);
> > glPopMatrix();
> >
> > glDepthRange(0.0,1.0);
> > glDepthFunc(GL_LEQUAL);
> >
> > pfPopState();
> > }
> >
> > --
> > ___|__ |
> > / | \ ||\ Daniel (Dan) Johnston
> > /___|___\ || \ Dan.Johnston++at++nrc.gc.ca
> > _____|____ || \ National Research Council of Canada, London, ON
> >
> > | | | || \ Integrated Manufacturing Technologies Institute
> >
> > \___| | | ||____\ Tel: (519) 430-7081 Fax: (519) 430-7140
> > \_o_\___|____|_|______\_ Inst: http://www.nrc.gc.ca/imti
> > \ o / These opinions are my own! Not those of NRC.
> > \________________/ Virtual Reality:
> > http://imti.nrc.gc.ca/vetc_e/vetc_e.html
> > More Tall Ships - Fewer Computers!
> >
> >
> >
> > -----------------------------------------------------------------------
> > List Archives, Info, FAQ: http://www.sgi.com/software/performer/
> > Open Development Project: http://oss.sgi.com/projects/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
> > -----------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Fri Aug 26 2005 - 07:31:20 PDT