home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / next / programm / 7813 < prev    next >
Encoding:
Internet Message Format  |  1992-12-20  |  1.4 KB
  1. Path: sparky!uunet!cs.utexas.edu!ut-emx!skye
  2. From: donovan@skye (Donovan Kolbly)
  3. Newsgroups: comp.sys.next.programmer
  4. Subject: A more complicated RenderMan question -- trace()?
  5. Keywords: RenderMan, NeXTSTEP 3.0
  6. Message-ID: <85534@ut-emx.uucp>
  7. Date: 18 Dec 92 05:21:36 GMT
  8. Sender: news@ut-emx.uucp
  9. Reply-To: dkolbly@ccwf.utexas.edu
  10. Lines: 27
  11.  
  12. OK, prman gurus out there:
  13.  
  14. I am trying to do reflections in surfaces (a nice, obvious sort of  
  15. thing to want a renderer to do.)  I can make environment maps work, but  
  16. they don't seem suitable for close-quarters reflections (the RM  
  17. Companion even says so.)
  18.  
  19. So, the question is:  Does "trace()" do what it sounds like it should  
  20. do (that is, actually trace rays), or does it only consider light  
  21. sources?  The RM Companion implies that it is up to the renderer, a la  
  22. illuminate().  So then, what does prman do?  illuminate() SEEMS to only  
  23. consider light sources.  prman doesn't seem to be implement shaders  
  24. using trace(), and thinks it wants only one argument anyway!?  What is  
  25. going on here?
  26.  
  27. The results oriented question:  How can I get good, up close,  
  28. convoluted reflections?
  29.  
  30. The knowledge oriented question:  What is the philosophy of prman in  
  31. this regard?  For that matter, what is the definitive spec of the  
  32. implementation of prman on the NeXT.  I can't afford Pixar's RenderMan  
  33. toolkit.
  34.  
  35. Enough rambling.  Is there a renderman newsgroup?
  36.  
  37. -- Donovan Kolbly
  38.    dkolbly@cs.utexas.edu
  39.