home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / graphics / 12891 < prev    next >
Encoding:
Internet Message Format  |  1992-12-14  |  3.0 KB
  1. Xref: sparky comp.graphics:12891 comp.sys.sgi:18016
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!purdue!bu.edu!bass.bu.edu!kiki
  3. From: kiki@bass.bu.edu (Keith Baccki)
  4. Newsgroups: comp.graphics,comp.sys.sgi
  5. Subject: Re: Polhemus Head Tracking / GL problem
  6. Message-ID: <104769@bu.edu>
  7. Date: 13 Dec 92 02:19:38 GMT
  8. References: <1992Dec8.144411.16003@hellgate.utah.edu> <1992Dec9.013147.2709@u.washington.edu>
  9. Sender: news@bu.edu
  10. Reply-To: kiki@bass.bu.edu (Keith Baccki)
  11. Followup-To: comp.graphics
  12. Organization: Boston University
  13. Lines: 59
  14.  
  15. In article <1992Dec9.013147.2709@u.washington.edu> chuckb@stein.u.washington.edu (Charles Bass) writes:
  16. >I need more information to answer this question however I can
  17. >give the following advice:
  18. >
  19. >1) Don't use the lookat(..) function in GL  there are
  20. >singularities that will cause "interesting" behaviour.
  21.  
  22.     Not sure what you mean by interesting behaviour.
  23. Might you be able to elaborate? Surely, you don't want
  24. to restrict the use of lookat() (a very intuitive function
  25. when combined with window() IMHO). What exactly are you
  26. doing with lookat(), and what interesting behaviour does
  27. it produce? Just curious.
  28.  
  29.  
  30. >2) Be careful on how you set up your near and far clipping
  31. >planes.  This range is mapped into a 16 bit range (I'm pretty
  32. >sure it's 16 bit).  Thus if you do something like setting your
  33. >near plane to .1 and your far plane to 10,000,000 you will get
  34. >"interesting" behaviour. You want to set the near and far planes
  35. >to be as close together as possible to maximize your resolution.
  36.  
  37.     Hmmm, not sure about the bit resolution (would guess it's
  38. a long, not a short). Whatever. Again, I must ask what you mean by
  39. interesting behaviour?!?!? Perhaps it's because you're viewing
  40. volume is squat and it distorts the dimensions of your image?
  41. (HINT: yes it is, and that's what it does ;) Far plane only sets
  42. your far clipping plane - i.e. has no effect on the image other
  43. than clipping beyond that distance. Near plane,however, defines
  44. the shape of your viewing volume (together with the dimensions of 
  45. your view plane in window()) So your above statement is misleading.
  46. Any "interesting behaviour" is caused by your view plane dimensions
  47. being disproportionate (is that a word?) to your near plane distance.
  48. Think about it:
  49.         .           .
  50.        .            .
  51.       .             |
  52.      .|             |far
  53.  eye. |near -->     | 
  54.      .|             |
  55.       |             |
  56.        .            . 
  57.         .           .
  58.          .
  59.           .
  60.  
  61. Your view volume is defined by near, far, and dimensions of your
  62. view plane. Note that the viewplane dimension is ~2 X distance to
  63. the near plane => big spread in perspective projection. Consider
  64. putting the near plane twice as far as it is from the eye => the
  65. spread of the volume becomes smaller. It's called "perspective",
  66. it's a wonderful thing. Now, when using zbuffer(), I've been told
  67. that it's accuracy depends on the far plane's distance - anyone
  68. care to comment on this?
  69.  
  70.  
  71.  
  72.                     keith
  73.  
  74.