need help z buffering lines areas together 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 i m posting this article by itself on comp graphics and virtually the same article with a test program demonstrating the problem on comp windows x pex the problem is hard to describe without pictures hence this article is longish if you can run pexlib x programs and are interested i encourage you to build and run the test program in comp windows x pex to see the effect yourself and play with my approach to dealing with it it depends on the utility code from the above gaskins book instructions for fetching it via anonymous ftp are given 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 any help would be immensely appreciated dave gorgen internet gorgen ann arbor applicon slb com applicon inc gorgen aaaca sinet slb com ann arbor michigan usa uucp uunet sharkey applga gorgen
