From: Alexander Lechner (alexander.lechner++at++vertigo-systems.de)
Date: 08/26/2005 06:57:57
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 - 06:58:15 PDT