Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!sgi!shinobu!odin!bennett
From: bennett@sgi.com (Jim Bennett)
Newsgroups: comp.sys.sgi
Subject: Re: zbuffering and lrectwrite
Message-ID: <1991Mar8.185704.7386@odin.corp.sgi.com>
Date: 8 Mar 91 18:57:04 GMT
References: <76269@bu.edu.bu.edu>
Sender: news@odin.corp.sgi.com (Net News)
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 29

In article <76269@bu.edu.bu.edu> tjh@bu-pub.bu.edu (Tim Hall) writes:
>I was suprised to find out (through experience) that lrectwrite
>is affected by the zbuffer.  That is when zbuffering is turned
>on lrectwrite only paints those pixels have a zvalue less than
>(or greater etc.. depending on zfunction) some threshold value.

Actually, this is unintended behaviour.  The original intent of
lrectwrite was to not be affected by zbuffering, although
technically its behaviour is undefined.  So on some machines it
does and on others it doesn't.

>Actually I'm so suprised that this is the case I wonder if I did
>somthing to cause this.  If this is the normal behavior what is
>the threshold value?

Yes, that is the tricky point, after all there is no Z value
explicitly associated with the lrectwrite.  That is why the
behaviour is undefined.

>  Anyhow, surrounding the lrectwrite call by
>zbuffer FALSE/TRUE commands produced my desired result.

Yes, and this works on all machines.

>-- 
>-Tim Hall
>tjh@bu-pub.bu.edu

Jim Bennett				(bennett@esd.sgi.com)