38921

神经网络昆斯林的新闻组分类2006

Newsgroups: comp.graphics
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!noc.near.net!howland.reston.ans.net!usc!cs.utexas.edu!geraldo.cc.utexas.edu!portal.austin.ibm.com!awdprime.austin.ibm.com!mark
From: [e-mail] (Mark Einkauf)
Subject: Re: Need help: Z-buffering lines & areas together
Originator: [e-mail]
Message-ID: <[e-mail]>
Sender: [e-mail] (Mark Einkauf)
Date: Wed, 28 Apr 1993 15:57:00 GMT
References:  <[e-mail]>
Organization: IBM Austin
Keywords: Z-buffer, roundoff, lines, areas
Lines: 105


  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.)

-- 
  Mark Einkauf     [ [e-mail] ]
  IBM - Advanced Workstations and Systems - Graphics Systems
  Austin TX
 * Views and opinions expressed herein are not necessarily those of IBM Corp. *