home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / next / programm / 7702 < prev    next >
Encoding:
Text File  |  1992-12-12  |  2.3 KB  |  49 lines
  1. Newsgroups: comp.sys.next.programmer
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!wupost!micro-heart-of-gold.mit.edu!news.media.mit.edu!wave
  3. From: wave@media.mit.edu (Michael B. Johnson)
  4. Subject: Re: Arrgh  - Renderman is crashing - HELP
  5. Message-ID: <1992Dec12.213959.20793@news.media.mit.edu>
  6. Keywords: 3d,molecule,renderman,help
  7. Sender: news@news.media.mit.edu (USENET News System)
  8. Organization: MIT Media Laboratory
  9. References: <Bz5rC9.1A9@rice.edu>
  10. Date: Sat, 12 Dec 1992 21:39:59 GMT
  11. Lines: 36
  12.  
  13. In article <Bz5rC9.1A9@rice.edu> steve@ion.rice.edu writes:
  14. >>
  15. >>For the last few days I've been working on a molecule display app using  
  16. >>renderman. It's now working perfectly, with one exception. Whenever I try to  
  17. >>draw a large molecule (300-400 spheres), renderman chokes. I get a message on  
  18. >>the console about renderman losing it's connection to the window server or  
  19. >>something. After digging around the filesystem for a while, I located the place  
  20. >>where the renderman daemon writes ITS errors, and discovered a variety of  
  21. >>messages all boiling down to "out of memory", including some that explain why  
  22. >>it can't connect to the window server (memory problems again). Thinking back, I  
  23. >>remember similar problems when I tried to put too many spheres in when  
  24. >>debugging Plot3D.   Is there any way to increase the amount of memory the  
  25. >>renderman daemon has available to it???  NeXT's complete lack of documentation  
  26. >>doesn't help the situation at all!    Any advice at all would be greatly  
  27. >>appreciated!
  28.  
  29.  
  30.  
  31. Well, there's documentation, and then there's documentation.  I'm staring
  32. at some mighty fine 3.0 paper doc right now, but unfortunately, not everything
  33. has a man page...
  34.  
  35. Anyway, given the relative fragility of qrman (compared to prman), I'm not
  36. surprised it's choking.  I can't believe there are any compiled in limits
  37. for the amount of geometry, so you might try this on a machine that has
  38. a good amount of memory and lots of swap space and see if it dies in the 
  39. same way (i.e. same size database).  I'm killing qrman pretty repeatedly
  40. these days, when I give it badly shaped polygons, and it wedges it well
  41. enough make it that I have to reboot.  We can only hope 3.1 has a more
  42. robust qrman. 
  43.  
  44. -- 
  45.  
  46. -->  Michael B. Johnson
  47. -->  MIT Media Lab      --  Computer Graphics & Animation Group
  48. -->  (617) 253-0663     --  wave@media-lab.media.mit.edu
  49.