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.

thank you, miker

Post a reply to this message

"MR" <a### [at] bnet> wrote in message news:3bc4eacc$1@news.povray.org...
> hello,
>
> 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.

I'm no expert on memory issues, but I know POV does use virtual
memory. I had a scene that took 580MB memory rendering on
a machine that only has 128MB.

I think the 3.5 beta 5 crashes were due to pov running out of stack space

Gail
--
*************************************************************************
* gsh### [at] monotixcoza                *   Step into the abyss,           *
* http://www.rucus.ru.ac.za/~gail/   *   and let go.          Babylon 5 *
*************************************************************************
* Just think of me as the storm before the calm     Magic: The Gathering*
*************************************************************************

Post a reply to this message

Gail Shaw wrote:
> 
> "MR" <a### [at] bnet> wrote in message news:3bc4eacc$1@news.povray.org...
> > hello,
> >
> > 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.
> 
> I'm no expert on memory issues, but I know POV does use virtual
> memory. I had a scene that took 580MB memory rendering on
> a machine that only has 128MB.

The virtual memory is a thing best left to the OS.
So, if the OS supports it, then POV use it transparently.

Post a reply to this message

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

MR <a### [at] bnet> wrote:
: what
: i've heard is that if the memory it needs to do a render is exceeded,
: the render will crash.

  Where have you heard this? I have never had a crash due to running out
of memory.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

7000 objects per 16MB, eh?

on my drive to work i pass this wooded valley.  the other day
the sun was just coming up and a light fog hung down low
exposing only the tree tops.  i thought to myself, "i could do
that."  there are several nice include files for trees, but when
you tack all the leaves on it, building an entire woods with
maybe 100 or 200 trees is gonna drive the object count thru
the ceiling.

i'm ordering a new 1.2GHz athlon motherboard and 1.5GB of
memory today.  gonna come to around $270 total.

thank you for the information.

miker


"Mike Williams" <mik### [at] nospamplease> wrote in message
news:AW6### [at] econymdemoncouk...
> 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

hi warp,

here's the quote:
*****
This 2gb limit is kinda scary when you consider that we have already seen
at least one POV image that uses more than half of that ... for users of
consumer Microsoft OS's, once scenes start hitting 2gb, no amount of RAM
will help the problem (POV will just fail with a memory allocation error).
*****
came from my hardware post down a few.  now that i reread it, maybe
i misinterpretted it...  i think this quote is saying 2GB is a hardcore
limit,
virtual memory or otherwise, due simply to the limitations of 32-bit
architecture.

thanks, miker



"Warp" <war### [at] tagpovrayorg> wrote in message
news:3bc567d2@news.povray.org...
> MR <a### [at] bnet> wrote:
> : what
> : i've heard is that if the memory it needs to do a render is exceeded,
> : the render will crash.
>
>   Where have you heard this? I have never had a crash due to running out
> of memory.
>
> --
> #macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
> rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
> ],13),8)-3,10>#end blob{N(array[6]{11117333955,
> 7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

MR wrote:
> 
> hi warp,
> 
> here's the quote:
> *****
> This 2gb limit is kinda scary when you consider that we have already seen
> at least one POV image that uses more than half of that ... for users of
> consumer Microsoft OS's, once scenes start hitting 2gb, no amount of RAM
> will help the problem (POV will just fail with a memory allocation error).
> *****

That referred to exceeding memory during parsing, Povray will stop parsing
and tell it connot allocate more memory.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Warp wrote:

> MR <a### [at] bnet> wrote:
> : what
> : i've heard is that if the memory it needs to do a render is exceeded,
> : the render will crash.
>
>   Where have you heard this? I have never had a crash due to running out
> of memory.

I used to have it crash my entire linux box in the case of a runaway object
creation macro...

But that was back with RedHat 5.2, IIRC.


--
Jon A. Cruz
http://www.geocities.com/joncruz/action.html

Post a reply to this message

Wasn't it MR who wrote:
>7000 objects per 16MB, eh?
>
>on my drive to work i pass this wooded valley.  the other day
>the sun was just coming up and a light fog hung down low
>exposing only the tree tops.  i thought to myself, "i could do
>that."  there are several nice include files for trees, but when
>you tack all the leaves on it, building an entire woods with
>maybe 100 or 200 trees is gonna drive the object count thru
>the ceiling.

But if you use Paul T. Dawson's mesh tree macro you can render hundreds
of trees reasonably easily and quickly. The trick is to only have a few
*different* trees and make them look different by scaling and rotating
them by different amounts as you plant them.

The pdt_tree macro builds the trees out of a small number of complicated
meshes, rather than a large number of simple objects, and that works out
to be very memory efficient.

With 10 different reasonably complex trees, each one planted 10 times,
giving a total of 100 trees I get "Peak memory used 70614011 bytes".


-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message