home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / sgi / 12793 < prev    next >
Encoding:
Text File  |  1992-08-23  |  3.8 KB  |  103 lines
  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!usc!rpi!usenet.coe.montana.edu!news.u.washington.edu!milton!ulbricht
  3. From: ulbricht@milton.u.washington.edu (Craig Ulbricht)
  4. Subject: Re: z-buffering question
  5. Message-ID: <ulbricht.714600632@milton>
  6. Sender: news@u.washington.edu (USENET News System)
  7. Organization: University of Washington
  8. References: <1992Aug14.175702.22720@ncar.ucar.edu>
  9. Distribution: usa
  10. Date: Sun, 23 Aug 1992 20:10:32 GMT
  11. Lines: 90
  12.  
  13.  
  14.  
  15.  
  16. Z-Buffering problems with overlaying lines on polygons!
  17.  
  18.  
  19.     I've looked at this problem a few times in the past year and half and
  20. I think I've FINALLY come up with a solution that is virtually free, 
  21. both computationally and graphically.  There are other solutions out there
  22. that require you to output your polygon data twice, so you loose the speed of
  23. tmeshes.  I can't afford this due to large data sets I'm using.
  24. This solution has the same visual results as the slower methods but 
  25. with out the cost of speed.
  26.     I've tried your idea before but have also failed.  This time, after
  27. getting to know the perspective matrix, as sgi implements it, I found a
  28. new way (to me atleast) to implement this same idea.  Frankly, this is a total
  29. hack yet without absolute understanding, BUT, a hack that works. So, with
  30. minimal explanation I'll just give you an example of what I came up with.  
  31.  
  32.     The following code is extracted from a C++ module which explains the
  33.     comment notation and the creation of variables in the middle of the funtion.
  34.     If your programming in C (not C++) it will be trivial to rearrange the 
  35.     code so it will work.
  36.  
  37.  
  38.     // get the current matrix mode so it can be preserved
  39.     long om=getmmode();
  40.     // set the matrix mode so you can opperate on the perspective matrix
  41.     mmode(MPROJECTION);
  42.     // get the matrix
  43.     Matrix m;
  44.     getmatrix(m);
  45.     // get the "near-translation" entry of the matrix so it can be preserved
  46.     float nn=m[3][2];
  47.     // get the zbuffer range of your system
  48.     long zmax=getgdesc(GD_ZMAX);
  49.     long zmin=getgdesc(GD_ZMIN);
  50.     // calculate the necessary world translation so when the data is 
  51.     // scaled into the zbuffer it will be offset by ~one step in the zbuffer
  52.     float nna=(float)((double)(view_win_info->far-view_win_info->near)/(double)(zmax-zmin));
  53.     // subtract this from the near-translation entry
  54.     float na=nn-nna;
  55.     // put the new near-translation value into the matrix
  56.     m[3][2]=na;
  57.     // put the modified matrix back on the projection matrix stack
  58.     loadmatrix(m);
  59.     // reset the matrix mode
  60.     // this step seems to be necessary for yet unknown reasons
  61.     mmode(om);
  62.  
  63.     //
  64.     // draw overlaying lines here
  65.     //
  66.  
  67.     // set the matrix mode so you can opperate on the perspective matrix again
  68.     mmode(MPROJECTION);
  69.     // restore the original value of the near-translation entry
  70.     m[3][2]=nn;
  71.     // put the restored matrix back on the projection matrix stack
  72.     loadmatrix(m);
  73.     // and finally, restore the matrix mode
  74.     mmode(om);
  75.  
  76.  
  77.  
  78. A few related comments.
  79.  
  80. Essentially, your just translating your data directly at your eye a little bit.
  81. But, actually your moving your near-far clipping space without officially
  82. telling the graphics engine.
  83.  
  84. This particular solution requires you to be working in multi matrix mode.
  85.  
  86. You may wish to play with a multiple of this step (nna), but I have found that
  87. anything much larger than a factor of two causes lines to start coming 
  88. through the scene where they should not.
  89.  
  90. I have also played with the zfunction() setting with no success.  I suspect
  91. the geometry engine uses reduced floating point (floats with less significant
  92. digits than your floating point data), so even though the z-test ZF_LEQUAL
  93. should work, it doesn't.
  94.  
  95.  
  96. Have fun!
  97.  
  98.  
  99. Craig Ulbricht        
  100. ulbricht@u.washington.edu
  101. Cooperative for Forest-Systems Engineering
  102. University of Washington
  103.