re need help z buffering lines areas together 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 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 to if not i e or 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 to 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 or 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 x implementation this version is known to compile and run on an hp ux system with pex open questions 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 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 bits assuming bit z buffer this seems huge but is only 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 polygon right on top of another but with different vertices you will likely see a smeared effect where they overlap example try polygon polygon 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 mark einkauf einkauf austin ibm com ibm advanced workstations and systems graphics systems austin tx views and opinions expressed herein are not necessarily those of ibm corp
