home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / amiga / graphics / 5790 < prev    next >
Encoding:
Text File  |  1992-08-26  |  2.9 KB  |  64 lines
  1. Newsgroups: comp.sys.amiga.graphics
  2. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!masscomp!mark
  3. From: mark@westford.ccur.com (Mark Thompson)
  4. Subject: Re: arenderman update!
  5. Message-ID: <1992Aug26.221226.21108@westford.ccur.com>
  6. Sender: usenet@westford.ccur.com (UNIX news)
  7. Organization: Radiant Image Productions, Merrimack NH.
  8. References: <Bt0nyu.6En@chinet.chi.il.us> <1992Aug17.204956.10418@westford.ccur.com> <Bt82vA.8q0@chinet.chi.il.us>
  9. Date: Wed, 26 Aug 1992 22:12:26 GMT
  10. Lines: 52
  11.  
  12. It took a while to reply, but I've been super busy....
  13.  
  14. In article <Bt82vA.8q0@chinet.chi.il.us> katefans@chinet.chi.il.us (Chris'n'Vickie of Chicago) writes:
  15. >>speed is definitely not one of RenderMan's strengths.
  16. >  Not true. Digital Arts 3.8 is the most fully RenderMan complient renderer
  17. >yet, and frankly it runs rings around everything I have found on the Amiga.
  18.     
  19. I did briefly take a look at Digital Arts at Siggraph but was unaware that
  20. they were now fully RenderMan compliant. It looked quite good.
  21.  
  22. >>Doing things like breaking all primitives up into stochastically
  23. >>super-sampled sub-pixel micro polygons is extremely compute intensive
  24. >   Not really. In real terms the slowest part of the renderer is still
  25. >determining visibility.
  26.  
  27. While the RenderMan specification does not define any specific method for
  28. determining visibility, the REYES render typically uses a Zbuffer which
  29. is computationally trivial. However......
  30.  
  31. >Breaking the "primitives" into micro-polys is
  32. >actually quite quick, although it _is_ hard-disk intensive.
  33.  
  34. While dicing may be quick, those micro-polys must be stochatically super
  35. sampled with a Z interpolation for each sample point. So while the method
  36. of visibility determination is simple, the shear number of calculations
  37. forced by super sampling makes quite a burden. Ofcourse this means you
  38. get nice clean surface intersections :-)
  39.  
  40. > From what I've seen, the REYES algorthym is faster than any raytracer.
  41.  
  42. True, but typically much slower than the more standard scanline/Zbuffer
  43. rendering methods.
  44.  
  45. >  On the system mentioned above, I get broadcast quality animation at a very
  46. >reasonable 5 minutes a frame.
  47.  
  48. Not bad, not bad at all. One can only hope that an Amiga implementation
  49. fairs as well. I would really like to see that happen.
  50.  
  51. >Of course this presupposes that the
  52. >operator is not afraid to get his fingers dirty in the RenderMan .RIB
  53. >file. This leaves our Mac friends out in the cold.
  54.  
  55. :-) :-) :-) :-) :-)
  56.  
  57. %~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~%
  58. %      `       '        Mark Thompson                 CONCURRENT COMPUTER  %
  59. % --==* RADIANT *==--   mark@westford.ccur.com        Principal Graphics   %
  60. %      ' Image `        ...!uunet!masscomp!mark       Hardware Architect   %
  61. %     Productions       (508)392-2480 (603)424-1829   & General Nuisance   %
  62. %                                                                          %
  63.  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  64.