![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> - 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Anthony D. Baye" <Sha### [at] spamnomore hotmail com> wrote:
> scott <sco### [at] scott com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Thorsten Froehlich" <nomail@nomail> wrote in message
news:web.520bbf49e896405b45eb5620@news.povray.org...
> "Anthony D. Baye" <Sha### [at] spamnomore hotmail com> wrote:
>> scott <sco### [at] scott com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Thorsten Froehlich" <nomail@nomail> wrote:
> "Anthony D. Baye" <Sha### [at] spamnomore hotmail com> wrote:
> > scott <sco### [at] scott com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Fractracer" <lg.### [at] gmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> "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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> - 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |