home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / graphics / 12964 < prev    next >
Encoding:
Text File  |  1992-12-16  |  4.1 KB  |  80 lines
  1. Newsgroups: comp.graphics
  2. Path: sparky!uunet!spool.mu.edu!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!geraldo.cc.utexas.edu!portal.austin.ibm.com!awdprime.austin.ibm.com!mark
  3. From: mark@austin.ibm.com (Mark Einkauf)
  4. Subject: Re: Z Buffer Precision and Homogeneous Coordinates
  5. Originator: mark@einkauf.austin.ibm.com
  6. Sender: news@austin.ibm.com (News id)
  7. Message-ID: <BzDEyv.yKr@austin.ibm.com>
  8. Date: Wed, 16 Dec 1992 21:13:43 GMT
  9. References:  <78173@hydra.gatech.EDU>
  10. Organization: IBM Austin
  11. Lines: 67
  12.  
  13.  
  14. In article <78173@hydra.gatech.EDU>, gg10@prism.gatech.EDU (GALLOWAY) writes:
  15. >                       B
  16. >     Z(screen) = A + ------
  17. >                     Z(eye)
  18. > 
  19. > where A and B are constants.  And that this is done so that "in moving
  20. > from eye space to screen space, lines transform into lines and planes
  21. > transform into planes."  The depth value gets normalized from the range
  22. > [near, far] to [0, 1].
  23. > 
  24. > If the viewing transformation matrix consists of only linear operations,
  25. > translation, rotation, and scaling, then this appears to degrade the
  26. > precision of the depth value.  In my current Z buffer-based renderer my
  27. > Z buffer is an array of 32 bit floats.  I preform clipping in the 3D view
  28. > space (or eye space) before perspective projection.
  29. > 
  30. > My questions are:
  31. > 
  32. > a) Why do software (non-hardware) Z buffers normalize the depth value?
  33. >    Why not just keep around a float and compare floats?
  34.         
  35.      Compares are OK for clipping to a rectangular volume, but the trouble
  36.      comes when trying to clip to a frustum (truncated pyramid) - which is 
  37.      what you must do if you want a perspective view (as opposed to parallel).
  38.      There, you want the equations of the planes of the frustum to be very simple
  39.      so your intersection calculation is in turn simple (and therefore fast).
  40.      Likewise, even in a parallel view, if your transforms are such that the 
  41.      view volume is a nice normalized cube (0->1, or 1->1 on all sides) then you can
  42.      use the same equation for finding intersections.  You are then always intersecting    
  43.      with 0 and 1 or 1 and 1, rather than arbitrary boundaries.
  44.  
  45. > 
  46. > b) Are most Z buffers integerized as well?  How many bits?
  47. >    What is the advantage?
  48.  
  49.      Hardware z buffers are integerized, just like the x,y coordinates of your
  50.      display (i.e. there is no such physical pixel as x=145.982, y=389.004).
  51.      In hardware, all there is is bits, so whether you say they are simple
  52.      integers, or in an elaborate float format, your resolution remains the same and
  53.      is determined by the actual number of physical bits per pixel.  Its simpler to
  54.      treat everything as an integer.  Typical z buffers are 16 to 24 bits.
  55.      The more bits, the greater resolution.  If too few bits, things that are actually
  56.      separated in z may map to same hardware z value and interfere with each other.
  57.  
  58. > 
  59. > c) When is the correct time to clip?  And are homogeneous coordinates
  60. >    necessary if you are not current rendering NURBs?
  61. >    For most surface, except NURBs, W is always 1 anyway, right?
  62. > 
  63.      If you have a perspective view, homogenous coordinates are convenient to
  64.      use for clipping.  In the answer to (a) above, recall the frustum.  If you clip
  65.      to the 3d frustum , you must apply the perspective after clipping, which means
  66.      you need more math (takes time).  Foley and Van Dam show how these steps are 
  67.      combined so that you apply the perspective transform before clipping, then
  68.      clip to +/- w.  In this case, w is definitely not always = 1.  After clipping
  69.      to +/- w, you divide x,y,z by w which gets you to your normalized cube.  After
  70.      this divide, w is 1 and you can breathe a sigh of relief - you have survived 4
  71.      dimensions.  From the normalized cube you apply your device scale/translate
  72.      to map to the physical window.  
  73.  
  74.  
  75. -- 
  76.   Mark Einkauf     [ mark@einkauf.austin.ibm.com (only valid within ibm.com) ]
  77.   IBM-AWD Graphics [ VNET EINKAUF@AUSVM6                                     ]
  78.   Austin TX        [                                                         ]
  79.  * Views and opinions expressed herein are not necessarily those of IBM Corp. *
  80.