home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / sci / virtual / 3621 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  2.4 KB
  1. Path: sparky!uunet!ogicse!news.u.washington.edu!stein.u.washington.edu!hlab
  2. From: leech@cs.unc.edu (Jon Leech)
  3. Newsgroups: sci.virtual-worlds
  4. Subject: Re: PAPER: Galilean Antialiasing for VR, Part 01/04
  5. Message-ID: <1992Nov9.220147.11292@u.washington.edu>
  6. Date: 8 Nov 92 22:38:43 GMT
  7. Article-I.D.: u.1992Nov9.220147.11292
  8. References: <lfjuqqINNb62@exodus.Eng.Sun.COM>
  9. Sender: news@u.washington.edu (USENET News System)
  10. Organization: University of Washington
  11. Lines: 38
  12. Approved: cyberoid@milton.u.washington.edu
  13. Originator: hlab@stein.u.washington.edu
  14.  
  15.  
  16.  
  17. In article <lfjuqqINNb62@exodus.Eng.Sun.COM>, deering@deering.Eng.Sun.COM (Micha
  18. el F. Deering) writes:
  19. |> As a designer of digital circuits for rendering, I have a fairly good feel
  20. |> for how much circuitry would be required to implement this sort of algorithm.
  21. |> The problem is that it appears that it would cost *more* to support the smart
  22. |> pixels that the current brute force rendering circuitry takes!  (In the
  23. |> authors defence the relative amounts of circuits needed are not obvious.)
  24.  
  25.     My opinion is similar, that scan conversion is already a solved
  26. problem, and it will turn out to be easier to throw enough hardware at
  27. the front end to sustain 1 update/field than to solve the sampling and
  28. aliasing problems of a "galpixel" buffer. But I'll still offer an
  29. opposing viewpoint.
  30.  
  31.     First, note that the expense of updating a galpixel buffer doesn't
  32. vary with the image complexity. So the balance between frame buffer
  33. and rendering hardware will vary depending on how complex your
  34. database is.
  35.  
  36.     Second, the basic capabilities to do what he describes are already
  37. starting to emerge for texturing, and in that sense won't impose an
  38. extra cost. The current Reality Engine architecture might even support
  39. galpixels at reasonable frame rates, since there's a path from the
  40. frame buffer back to the top of the rendering hardware.
  41.  
  42.     What I'd suggest the author do is trim this paper to about 20
  43. pages describing solely the galpixel concept, add some diagrams and a
  44. block level approach to implementing a G(2) frame buffer, and, most
  45. importantly, produce experimental evidence that Galilean antialiasing
  46. will indeed offer the claimed benefits. The other stuff about
  47. nonplanar displays belongs in a different paper.
  48. --
  49.     Jon Leech (leech@cs.unc.edu)    __@/
  50. UNDERWHELMING OFFER OF THE MONTH:
  51.     "Please feel free to skip the payment on this month's statement.
  52.      Normal finance charges will apply." - NCNB VISA
  53.