tjh@bucrf11.bu.edu (Tim Hall) (03/07/91)
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 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? Anyhow, surrounding the lrectwrite call by zbuffer FALSE/TRUE commands produced my desired result. -- -Tim Hall tjh@bu-pub.bu.edu The night is filled with the cries of dispossessed children in search of paradise. -Dead Can Dance
bennett@sgi.com (Jim Bennett) (03/09/91)
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)
mds@sgi.com (Mark Stadler) (03/10/91)
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 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? Anyhow, surrounding the lrectwrite call by >zbuffer FALSE/TRUE commands produced my desired result. > >-- >-Tim Hall >tjh@bu-pub.bu.edu > this should not be the case. a machine configuration and a sample program demonstrating the problem (preferable small) could help us in explaining what the problem is (yours or ours). -- -- mds [aka Mark D Stadler mds@sgi.com ...!uunet!sgi!mds (415)335-1327]
mds@sgi.com (Mark Stadler) (03/10/91)
In article <1991Mar10.030239.16096@odin.corp.sgi.com> mds@sgi.com (Mark Stadler) writes: >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 >> >this should not be the case. a machine configuration and a sample >program demonstrating the problem (preferable small) could help >us in explaining what the problem is (yours or ours). > i was corrected immediately after this previous posting. apparantly some architectures do allow zbuffer to affect lrectwrite... news to me. -- -- mds [aka Mark D Stadler mds@sgi.com ...!uunet!sgi!mds (415)335-1327]