From: Benedikt Kessler (bjk++at++sgi.com)
Date: 08/26/2005 07:21:18
Hi!
It looks like none of the visuals had depth buffer (Z) when you saw your models in front of the texture; Thus the order of the draw made your objects visible (with poor (in fact no) depth buffering).
Looks like the depth buffer doesn't get initialized correctly (but I have no real explanation; maybe the depth test is not enabled? IN that case even glDepthFunc(GL_ALWAYS) will do nothing). In InfiniteReality you have the so called tag clear feature to
initialize the depth buffer (MSDEPTH) when multisampling is used.
MSDEPTH clear must come after color clear since writing color resets the tags.
thus can be achieved bu calling pfClear(PFCL_MSDEPTH, NULL) (glTagSampleBufferSGIX() is the OpenGL extension call behind it); pfClear makes sure that you hardware and visual supports that kind of clear.
Thus when tag clear is supported (use pfQueryFeature(PFQFTR_TAG_CLEAR, int *_dst) to find out) then you no need to do the glDepthFunc(GL_ALWAYS); glDepthRange(1.0,1.0); ... stuff; probably you should glDisable(GL_DEPTH_TEST) instead (and turn it back on
at the end).
I haven't tried it out, but I think it should work.
PS: maybe also do a glDisable(GL_DITHER);
Bye! Benedikt
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
> -----------------------------------------------------------------------
-- +---------------------------------+----------------------------------+ |Benedikt J. Kessler | Silicon Graphics GmbH | |Advanced Media Products | Am Hochacker 3 - Technopark | |SGI | 85630 Grasbrunn-Neukeferloh, FRG | | --- __o ,__o | | | ------_ \<,_ _-\_<, | Phone: (+49) 89 46108-366 or -0 | |----- (*)/ (*) (*)/'(*) | Fax: (+49) 89 46107-366 | +---------------------------------+----------------------------------+ |E-Mail: bjk++at++sgi.com Web (private): http://sgiweb.org/bjk | | Web: http://www.sgi.de | +--------------------------------------------------------------------+
This archive was generated by hypermail 2b29 : Fri Aug 26 2005 - 07:21:47 PDT