POV-Ray : Newsgroups : povray.general : recursively defined objects and memory Server Time
29 Jul 2024 06:13:20 EDT (-0400)
  recursively defined objects and memory (Message 11 to 20 of 43)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Bald Eagle
Subject: Re: recursively defined objects and memory
Date: 14 Aug 2013 11:00:01
Message: <web.520b9a75e896405b73fc9ebb0@news.povray.org>
> - Macros are /always/ evaluated during parsing.

I guess I didn't say or mean to imply that they weren't.

> - Functions may be evaluated either during parsing or during rendering,
> depending on the context in which they are used.

And those contexts are?
Function outside of a macro only at parse time, function inside a macro during
parse and render?

Eventually I WILL flowchart this out and do something to explain this with SDL
and graphics, for both my own edification as well as for the benefit of others.


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: recursively defined objects and memory
Date: 14 Aug 2013 13:35:00
Message: <web.520bbf49e896405b45eb5620@news.povray.org>
"Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> scott <sco### [at] scottcom> wrote:
> > > now, from what I've read, it takes more than a thousand iterations to get good
> > > results, but trying to do just fifty iterations makes POV do an imitation of
> > > PAC-Man with my memory and swap space.  All 16GB of it.
> > >
> > > I don't know if this is a bug or a natural limitation of the geometry parsing
> > > engine.
> >
> > It looks to me like at each iteration you are doubling the number of
> > objects POV has in memory (by creating an intersection of two versions
> > of the previous object). That means after 50 iterations you will have
> > about 2^50 objects - I'm surprised you got that far!
>
> That's about what I figured was happening.  And I didn't get that far because
> I had to shut it down.

And no matter what you do, you won't be able to get that many with POV on any
system available on this planet today. Even with references, and no
transformations, it would take 8 petabytes (8192 terabytes) just to store the
references. Realistically you might get 2^30 spheres on a PC, but not with a
regular Windows (you need the a server variant, desktop variants only support 64
GB of RAM) as you will probably need 256 to 512 GB of RAM for it. Or you need a
lot of fast swap space.

Thorsten


Post a reply to this message

From: Shay
Subject: Re: recursively defined objects and memory
Date: 14 Aug 2013 13:52:03
Message: <520bc3c3@news.povray.org>
"Thorsten Froehlich" <nomail@nomail> wrote in message 
news:web.520bbf49e896405b45eb5620@news.povray.org...
> "Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
>> scott <sco### [at] scottcom> wrote:
>> > > now, from what I've read, it takes more than a thousand iterations to 
>> > > get good
>> > > results, but trying to do just fifty iterations makes POV do an 
>> > > imitation of
>> > > PAC-Man with my memory and swap space.  All 16GB of it.
>> > >
>> > > I don't know if this is a bug or a natural limitation of the geometry 
>> > > parsing
>> > > engine.
>> >
>> > It looks to me like at each iteration you are doubling the number of
>> > objects POV has in memory (by creating an intersection of two versions
>> > of the previous object). That means after 50 iterations you will have
>> > about 2^50 objects - I'm surprised you got that far!
>>
>> That's about what I figured was happening.  And I didn't get that far 
>> because
>> I had to shut it down.
>
> And no matter what you do, you won't be able to get that many with POV on 
> any
> system available on this planet today. Even with references, and no
> transformations, it would take 8 petabytes (8192 terabytes) just to store 
> the
> references. Realistically you might get 2^30 spheres on a PC, but not with 
> a
> regular Windows (you need the a server variant, desktop variants only 
> support 64
> GB of RAM) as you will probably need 256 to 512 GB of RAM for it. Or you 
> need a
> lot of fast swap space.

and the website link shows a 10,000-iteration version.

 -Shay


Post a reply to this message

From: Fractracer
Subject: Re: recursively defined objects and memory
Date: 14 Aug 2013 14:00:00
Message: <web.520bc499e896405bda87b1b90@news.povray.org>
"Thorsten Froehlich" <nomail@nomail> wrote:
> "Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> > scott <sco### [at] scottcom> wrote:
> > > > now, from what I've read, it takes more than a thousand iterations to get good
> > > > results, but trying to do just fifty iterations makes POV do an imitation of
> > > > PAC-Man with my memory and swap space.  All 16GB of it.
> > > >
> > > > I don't know if this is a bug or a natural limitation of the geometry parsing
> > > > engine.
> > >
> > > It looks to me like at each iteration you are doubling the number of
> > > objects POV has in memory (by creating an intersection of two versions
> > > of the previous object). That means after 50 iterations you will have
> > > about 2^50 objects - I'm surprised you got that far!
> >
> > That's about what I figured was happening.  And I didn't get that far because
> > I had to shut it down.
>
> And no matter what you do, you won't be able to get that many with POV on any
> system available on this planet today. Even with references, and no
> transformations, it would take 8 petabytes (8192 terabytes) just to store the
> references. Realistically you might get 2^30 spheres on a PC, but not with a
> regular Windows (you need the a server variant, desktop variants only support 64
> GB of RAM) as you will probably need 256 to 512 GB of RAM for it. Or you need a
> lot of fast swap space.
>
> Thorsten

If I am not wrong, Windows7-32 bits can only have 4GB of memory, while Win7-64
bits can have 192 GB with pro edition.


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: recursively defined objects and memory
Date: 14 Aug 2013 15:00:00
Message: <web.520bd282e896405b45eb5620@news.povray.org>
"Fractracer" <lg.### [at] gmailcom> wrote:
> > And no matter what you do, you won't be able to get that many with POV on any
> > system available on this planet today. Even with references, and no
> > transformations, it would take 8 petabytes (8192 terabytes) just to store the
> > references. Realistically you might get 2^30 spheres on a PC, but not with a
> > regular Windows (you need the a server variant, desktop variants only support 64
> > GB of RAM) as you will probably need 256 to 512 GB of RAM for it. Or you need a
> > lot of fast swap space.
> >
> > Thorsten
>
> If I am not wrong, Windows7-32 bits can only have 4GB of memory, while Win7-64
> bits can have 192 GB with pro edition.

You are right about Win 64, I confused it ith the PAE limit:, for Windows 32 bit
systems the limit is 64 GB if using PAE.

As for the 192 GB, iirc there is a default 128 GB per process limit on available
memory (meaning swap wont help). The server version upper limit is 4 TB of
physical memory, btw.

Thorsten


Post a reply to this message

From: clipka
Subject: Re: recursively defined objects and memory
Date: 14 Aug 2013 15:04:14
Message: <520bd4ae$1@news.povray.org>
Am 14.08.2013 16:55, schrieb Bald Eagle:
>
>> - Macros are /always/ evaluated during parsing.
>
> I guess I didn't say or mean to imply that they weren't.
>
>> - Functions may be evaluated either during parsing or during rendering,
>> depending on the context in which they are used.
>
> And those contexts are?
> Function outside of a macro only at parse time, function inside a macro during
> parse and render?

Macros have /nothing/ to do with the time at which a function is evaluated.

I'm not sure off the top of my head whether there are exceptions, but 
the general rules are as follows:

- Actually, it is not about the time at which a /function/ is evaluated, 
but the time at which an /expression/ is evaluated.

- In any expression, variables (defined with #declare or #local) and 
macro invocations are /always/ resolved during parsing of that 
expression, no matter when the expression as a whole is evaluated.

- Expressions outside of a function{} block are /always/ evaluated as 
soon as they are parsed.

- Expressions inside the function{} block of a function definition are 
evaluated as soon as any expression is evaluated that invokes this function.

- Expressions inside any other function{} block (e.g. in an isosurface 
object, a function pigment, or some such) are evaluated during rendering.


Post a reply to this message

From: Alain
Subject: Re: recursively defined objects and memory
Date: 16 Aug 2013 19:49:21
Message: <520eba81$1@news.povray.org>

> "Anthony D. Baye"  wrote in message
> news:web.5209e02df7af87b1328783aa0@news.povray.org...
>
>> Over the weekend, I was trying to implement a CSG method for
>> generating random
>> planets.
>
>> The basic algorithm is simple: Take a sphere, cut it in half along a
>> random
>> plane, scale each half independently by some small amount, iterate.
>
> That's the concept, not the algorithm. The algorithm is:
>
> * Start with a mesh sphere
> Select a random plane, scale vertices above and below the plane
> independently by some small amount, iterate.
>

Several years ago, I stumbled on something similar, but it never 
manipulated any 3D object. Instead, it created a ray scale image of the 
elevation. That image was a longitude-latitude GIF with a 2:1 aspect ratio.
Sadly, I lost that small application. It could be run from a floppy...


Post a reply to this message

From: Bald Eagle
Subject: Re: recursively defined objects and memory
Date: 16 Aug 2013 20:55:00
Message: <web.520ec950e896405b73fc9ebb0@news.povray.org>
> - Actually, it is not about the time at which a /function/ is evaluated,
> but the time at which an /expression/ is evaluated.
>
> - In any expression, variables (defined with #declare or #local) and
> macro invocations are /always/ resolved during parsing of that
> expression, no matter when the expression as a whole is evaluated.

I see.  Mostly.  I'll likely flowchart this out or write an illustrative POV
file to work it all out .. eventually.

I'll have to take a look at two of my SDL's and compare their #while - #else -
#end loops to get a better idea of when THEY get ... implemented.

Thanks for your clarifications.  I always learn a lot from your posts.
Your time on these newsgroups and your advice and assistance is always
appreciated.


Post a reply to this message

From: clipka
Subject: Re: recursively defined objects and memory
Date: 17 Aug 2013 05:48:08
Message: <520f46d8$1@news.povray.org>
Am 17.08.2013 02:52, schrieb Bald Eagle:

> Thanks for your clarifications.  I always learn a lot from your posts.
> Your time on these newsgroups and your advice and assistance is always
> appreciated.

Glad to hear that.


Post a reply to this message

From: Ger Remmers
Subject: Re: recursively defined objects and memory
Date: 18 Aug 2013 17:08:14
Message: <521137be$1@news.povray.org>
On 08/13/2013 02:28 AM, Anthony D. Baye wrote:

> If anyone has suggestions, I'd welcome them.
>
> Regards,
> A.D.B.
>
>

Doing it the sphere-cut-in-half-rinse-repeat method is obviously not 
going to work as has been discussed.

I have implemented another way to produce a similar result.

Define evenly distributed points on the sphere (you'll need quite a few 
points (I have one running now with 5M points(*)))

Create a random plane to cut the sphere in half, every point inside the 
plane gets lowered, all other points get raised.

Repeat the plane thingy until you get something you like.

(*) Povray seems to have a problem with very large arrays. I  can go as 
high as 800K nodes, after that the last position in the array seems to 
get corrupted.
So, for the > 800K version I have created an external program.

I'll post an example image in pbi

-- 
Cheers
Ger


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.