David Gorgen writes:  > I'm asking for help on a sticky problem involving unreasonably low > apparent precision in Z-buffering, that I've encountered in 2 different > PEX implementations.  I can't find any discussion of this problem in any > resources I can lay hands on (e.g. the comp.windows.x.pex FAQ, Gaskins's > _PEXlib_Programming_Manual_, vendors' documentation). > > .... > > The problem to be solved is to eliminate or minimize "stitching" > artifacts resulting from the use of Z-buffering with polylines that are > coplanar with filled areas.  The interpolated Z values along a line will > differ slightly, due to roundoff error, from the interpolated Z values > across an area, even when the endpoints of the line are coincident with > vertices of the area.  Because of this, it's a tossup whether the > Z-buffer will allow the line pixels or the area pixels to be displayed. > Visually, the result tends to be a dashed-line effect even though the > line is supposed to be solid. > > Using the PEXlib API, my approach to a solution is to use two slightly > different PEX view mapping transforms, in two view table entries, one > for the areas and one for the lines.  The PEX structures or immediate- > mode output must be organized so that one view table index is always in > effect for areas, and the other is always in effect for lines.  The > result is a slight shift in NPC Z coordinates for the lines, so as to > attempt to bias the tossup situations in favor of the lines. > > This shift is effected by moving the front and back clipping planes used > in the PEXlib view table entry for lines just a hair "backwards" (i.e. > smaller VRC Z coordinates), compared to their positions in the view > table entry used for areas.  This means that when a point is transformed > to NPC, its Z value will be slightly bigger if it comes from a line than > if it comes from an area, thus accomplishing the desired bias. > > I would expect the Z roundoff errors which cause the problem to amount > to a few units at most, out of the entire dynamic range of the Z-buffer, > typically from 0 to 65535 if not 16777215 (i.e. 16 or 24 bit Z-buffers). > Therefore, it seems that a tiny fraction of the range of Z in VRC > between the front and back clip planes ought to suffice to reliably fix > the stitching. > > But in fact, experience shows that the shift has to be as much as 0.003 > to 0.006 of the range.  (Empirically, it's worst when the NPC Z > component of the slope of the surface is high, i.e. when it appears more > or less edge-on to the viewer.)  It's as if only 8 or 9 bits of the > Z-buffer have any dependable meaning!  This amount is so great that one > problem is replaced by another: sometimes the polylines "show through" > areas which they are supposed to lie behind. > > I've observed the problem on both Hewlett-Packard and Digital > workstation PEX servers, to approximately the same degree.  The test > program demonstrates the problem on an MIT PEXlib 5.x implementation; > this version is known to compile and run on an HP-UX system with PEX > 5.1. > > Open questions: >     (1) Why does this happen? >         --  Am I configuring the PEX view table wrongly? >         --  Is there a systematic difference in Z interpolation for lines >             as opposed to areas (e.g. pixel centers versus corners) which >             could be corrected for? >         --  Are PEX implementors wantonly discarding Z precision in their >             interpolators? >         --  Something else? >     (2) What to do about it? >         --  Can I fix my use of the view table to allow better precision >             in Z-buffered HLHSR? >         --  Is there another approach I can take to remove the stitching >             artifacts? >         --  Am I just out of luck? >  We here at IBM have the same problem with our workstations.  I was also shocked when I first realized that you have to offset lines from fills by about 16 bits (assuming 24 bit z buffer).  This seems huge, but is only 1/256 of the dynamic range.  In those terms it doesn't seem so bad.  What is happening is that the interpolation in z is not totally linear, due mainly to roundoff, I believe.  So the polygon is not planar in z, but is more like a Ruffles potato chip.  Ditto with lines.  When you start/end at different x/y values, the "ridges" are out of phase, resulting in the stitch effect.  You have the same problem if you try to draw 1 polygon right on top of another, but with different vertices.  You will likely see a smeared effect where they overlap.   Example:   Try Polygon 1: (100,100,100) (100,200,100) (200,200,100) (200,100,100)       Polygon 2: (125,125,100) (125,175,100) (175,175,100) (175,125,100)  Your implementation is correct.  In fact, we do a similar trick when rendering primitives that have lines and polygons - such as NURBS surfaces with isoparametric lines.  Without the trick, the lines appear stitched, as you say.  When the application draws lines/polygons independently, the system does not have the smarts to automatically do the z shifting, so the application must do it.  This is what you have discovered and are doing. Bravo!  (Note to IBM'ers:  The information given here has been previously disclosed through proper channels so I'm not giving away any new unpublished info.)