Wasn't it MR who wrote:
>hello,
>
>i know that pov-ray can be a memory hog when it renders.  what
>i've heard is that if the memory it needs to do a render is exceeded,
>the render will crash.
>
>whats the deal on this?  there's such a thing as "virtual" memory,
>isn't there, where the app spools out to the hard drive for memory.
>i know that processing slows to a crawl because this is so time-
>consuming, but i got the impression from the post i read that pov-
>ray won't even go the "virtual" memory route.
>
>by the way... i'm talking windows here.  i believe that 98, ME, NT,
>ad nauseum, all do the virtual mem thingie, although i won't swear
>to it.

No, POV doesn't crash when virtual memory starts shuffling. However, the
VM that's used by Windows is extremely inefficient at handling the sort
of memory accesses that POV needs. I guess that Windows expects programs
to process large chunks of memory in roughly serial fashion, so it tends
to swap fairly large chunks of memory. POV's memory accesses tend to
flit around its memory space rather less predictably - it looks at a few
bytes here and a few bytes there, and that tends to mean that when it
gets to the next pixel the relevant memory page has been shuffled out to
disk. So each pixel ends up needing several disk accesses, and rendering
speeds suddenly fall through the floor.

POV can be a memory hog if you write your scenes in memory consumptive
ways. It's often possible to rewrite complex scenes in memory efficient
ways. (It's mainly the complexity of the scene description that requires
lots of memory, the size of the output image doesn't make much
difference). Expect to have to limit yourself to about 7000 individual
objects for every 16Mb of available memory on your machine. If that's
not enough yo can make POV less memory hungry by switching off the light
buffers and vista buffers.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message