 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
#macro Planet(baseRad)
#local Base = sphere { 0.0, baseRad }
#local Plt = Base
#local A = 0;
#while(A < 16)
#local rT = <Rand_Gauss(0.0, 0.33, RdmA), Rand_Gauss(0.0, 0.33, RdmB),
Rand_Gauss(0.0, 0.33, RdmC)>*360;
#declare Plt =
union {
intersection {
object { Plt }
plane { y, 0 rotate rT }
scale (1 + Rand_Gauss(0.0, 0.33, RdmA)*0.15)
}
intersection {
object { Plt }
plane { -y, 0 rotate rT }
scale (1 + Rand_Gauss(0.0, 0.33, RdmB)*0.15)
}
bounded_by { box { -baseRad*0.625, baseRad*0.625 }}
}
#local A = A + 1;
#end
Plt
#end
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.
Since doing it with CSG proved unreasonable, I thought I'd try functions
instead.
This is as far as I got:
#declare baseFn = function(x,y,z,r) { sqrt(x*x + y*y + z*z) - r }
#declare boxFN = function { y * sqrt(x*x + z*z) }
#declare half = function { max(baseFn(x,y,z,3),boxFN(x, y, z)) }
isosurface {
function { min( half(x,y,z), half(x, -y, z)*Rand_Gauss(0.0,0.33,RdmB)) }
threshold 0
max_gradient 5
contained_by{ box {-5, 5} }
pigment { White }
}
the problem is imposing a rotation on the FUNCTION, rather than the isosurface
as a whole. I know how to impose a rotation around a given axis, but going from
there to rotating about all axes is somewhat more problematic without a matrix
transformation (which would be decidedly more elegant, but harder to compute on
the fly)
The rotation transform would be done on the boxFN(...) function in the half
object, and each iteration would redefine baseFn(...)
scaling each half would then be no trouble with variable substitution.
The only way I've come up with to solve the rotation problem is a separate
transformation (using a separate angle variable) for each axis. It would be
messy, but it could work.
My final option for using this algorithm is some kind of pigment, constructed in
much the same fashion, but I'm not sure which patterns I'd use, or if I'd have
to construct functions for the patterns I'd need.
If anyone has suggestions, I'd welcome them.
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> Over the weekend, I was trying to implement a CSG method for generating random
> planets.
......
> The rotation transform would be done on the boxFN(...) function in the half
> object, and each iteration would redefine baseFn(...)
>
> scaling each half would then be no trouble with variable substitution.
>
> The only way I've come up with to solve the rotation problem is a separate
> transformation (using a separate angle variable) for each axis. It would be
> messy, but it could work.
It would help, of course, if POV allowed redefinition of functions...
This is where I am now:
#declare baseFn = function(x,y,z,r) { sqrt(x*x + y*y + z*z) - r }
#declare boxFN = function { y * sqrt(x*x + z*z) }
#declare half = function(x,y,z,P,T) { max(baseFn(x,y,z,3),
boxFN(
(x*cos(radians(-T))-z*sin(radians(-T)))*cos(radians(-P))+y*sin(radians(-P)),
-(x*cos(radians(-T))-z*sin(radians(-T)))*sin(radians(-P))+y*cos(radians(-P)),
x*sin(radians(-T)) + z*cos(radians(-T))
)) }
#for(I,0,1000,1)
#local PHI = Rand_Normal(0.0, 0.33, RdmA)*360;
#local THETA = Rand_Normal(0.0, 0.33, RdmB)*360;
#local s1 = 1 + Rand_Normal(0.0, 0.33, RdmB)*0.025;
#local s2 = 1 - Rand_Normal(0.0, 0.33, RdmB)*0.025;
#local newFn = function {
min(half(x/s1,-y/s1,z/s1,-PHI,THETA),half(x/s2,y/s2,z/s2,PHI,THETA)) }
#undef baseFn
#declare baseFn = newFn;
#undef newFn
#end
isosurface {
function { baseFn(x,y,z) }
threshold 0
max_gradient 5
contained_by{ box {-5, 5} }
pigment { White }
}
but it seems that functions are not evaluated as I thought they were. All it
renders is some permutation of the first iteration. (A sphere, split in half,
both halves scaled independently.)
I was really hoping this would work. Again, if anyone has suggestions, I'd
welcome them.
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It would help, of course, if POV allowed redefinition of functions...
> but it seems that functions are not evaluated as I thought they were. All it
> renders is some permutation of the first iteration. (A sphere, split in half,
> both halves scaled independently.)
>
> I was really hoping this would work. Again, if anyone has suggestions, I'd
> welcome them.
Looks like you've run into the oft-encountered function/macro parse/render
dichotomy.
As I understand it, and folks can correct me if I'm wrong or mis-state this,
functions are evaluated ONCE - at parse time. So if you want something that
gets updated during RENDERING, then you need to call the function with a MACRO.
So do something like:
#macro Do_something (x, y)
[whiles, ifs, elses, ends, equations]
#end
Do_something (x, y)
(Think about macros like defining any CSG object, and then INVOKING it with
object {Object_name} )
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.08.2013 02:46, schrieb Bald Eagle:
> Looks like you've run into the oft-encountered function/macro parse/render
> dichotomy.
>
> As I understand it, and folks can correct me if I'm wrong or mis-state this,
> functions are evaluated ONCE - at parse time. So if you want something that
> gets updated during RENDERING, then you need to call the function with a MACRO.
Um... no, not at all.
- Macros are /always/ evaluated during parsing.
- Functions may be evaluated either during parsing or during rendering,
depending on the context in which they are used.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 14.08.2013 02:46, schrieb Bald Eagle:
>
> > Looks like you've run into the oft-encountered function/macro parse/render
> > dichotomy.
> >
> > As I understand it, and folks can correct me if I'm wrong or mis-state this,
> > functions are evaluated ONCE - at parse time. So if you want something that
> > gets updated during RENDERING, then you need to call the function with a MACRO.
>
> Um... no, not at all.
>
> - Macros are /always/ evaluated during parsing.
>
> - Functions may be evaluated either during parsing or during rendering,
> depending on the context in which they are used.
So... Just not going to work?
The idea was to build up a progressively more complex function for the surface
of the planet. While I could do this using built-in patterns, that wasn't the
point of the exercise.
I finally found the site where I first read about this:
http://freespace.virgin.net/hugo.elias/models/m_landsp.htm
The great thing about it is: the more iterations you do, the better it gets.
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 14/08/2013 07:07, Anthony D. Baye a écrit :
> clipka <ano### [at] anonymousorg> wrote:
>> Am 14.08.2013 02:46, schrieb Bald Eagle:
>>
>>> Looks like you've run into the oft-encountered function/macro parse/render
>>> dichotomy.
>>>
>>> As I understand it, and folks can correct me if I'm wrong or mis-state this,
>>> functions are evaluated ONCE - at parse time. So if you want something that
>>> gets updated during RENDERING, then you need to call the function with a MACRO.
>>
>> Um... no, not at all.
>>
>> - Macros are /always/ evaluated during parsing.
>>
>> - Functions may be evaluated either during parsing or during rendering,
>> depending on the context in which they are used.
>
> So... Just not going to work?
>
> The idea was to build up a progressively more complex function for the surface
> of the planet. While I could do this using built-in patterns, that wasn't the
> point of the exercise.
>
> I finally found the site where I first read about this:
> http://freespace.virgin.net/hugo.elias/models/m_landsp.htm
>
> The great thing about it is: the more iterations you do, the better it gets.
The trick is in iterations: for once, you do not want to keep the real
sphere object, but start with a mesh of a sphere and move/scale parts of
it. As you are not to break any triangle, simply moving the vertex
should be enough.
I hope I will remember that thread & link long enough to expand my mesh
manipulation extension.
(now, I have to find an anisotropic random generator of 3D unit vectors...)
--
Just because nobody complains does not mean all parachutes are perfect.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Anthony D. Baye" wrote in message
news:web.520ab4ece896405b328783aa0@news.povray.org...
> The rotation transform would be done on the boxFN(...) function in the
> half
> object, and each iteration would redefine baseFn(...)
>
That's ugly. Couldn't you just do this with a gradient function and rotate
each instance?
You don't need the tricky macro/function stuff either, just make a loop and
write out 10,000 functions to an include file.
#local f_00000 = function { ...
#local f_00001 = function { f_00000(x, y, z) + ...
That might be a little inelegant for you, but it's what I'd try.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> - 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 13-08-14 08:54, Shay a écrit :
> "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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> - 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 18.08.2013 23:08, schrieb Ger Remmers:
> (*) 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.
Obviously that shouldn't happen. Can you provide a sample scene to
reproduce, dissect and debug the problem?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/18/2013 04:48 PM, clipka wrote:
> Am 18.08.2013 23:08, schrieb Ger Remmers:
>
>> (*) 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.
>
> Obviously that shouldn't happen. Can you provide a sample scene to
> reproduce, dissect and debug the problem?
>
It messes up in the WriteDataFile() macro
#declare DataFilename = "nodes.inc";
#macro WriteDataFile()
#fopen DataFile DataFilename write
#write( DataFile, "#declare NumberOfNodes =
",str(NumberOfNodes,0,0),";\n")
#write( DataFile, "#declare Nodes =array [NumberOfNodes]\n")
#write( DataFile, "{\n")
#for (NodeCount, 0, NumberOfNodes -2, 1)
#write ( DataFile, "<",vstr(3, Nodes[NodeCount],",",0,-1),">,\n")
#end
/*
When including the written data it turns out that the next line is not
executed
*/
#write ( DataFile, "<",vstr(3, Nodes[NumberOfNodes-1],",",0,-1),">\n")
#write (DataFile,"}\n")
#fclose DataFile
#debug concat("Done writing data file with ",str(NumberOfNodes,0,0),"
nodes for frame ",str(frame_number,0,0),"\n")
#end
/*
Only at the first frame do we need to initialize the nodes on the sphere,
after that we load the node data from disk.
*/
#if (frame_number = 1)
#declare NumberOfNodes = 5000000;
/*
With NumberOfNodes < ~800K it works fine
*/
#declare Nodes =array [NumberOfNodes];
#declare dlong = pi * (3-sqrt(5));
#declare dz = 2.0 / NumberOfNodes;
#declare Longitude = 0;
#declare Z = 1 - dz / 2;
#for (NodeCount, 0, NumberOfNodes - 1, 1)
#declare Radius = sqrt(1 - Z * Z);
#declare Nodes[NodeCount] = <cos(Longitude)* Radius, sin(Longitude)
* Radius, Z>;
#declare Z = Z - dz;
#declare Longitude = Longitude + dlong;
#end
#else
#include DataFilename
#end
#declare NumberOfItterations = 5;
#declare RandAngle = seed(66);
#if (frame_number > 1)
#for(Dummy,0, (frame_number - 1) * NumberOfItterations * 4,1)
#declare PlaneAngle = rand(RandAngle);
#end
#end
#declare PlaneAngle = rand(RandAngle);
#declare CuttingPlane = plane{y, 0};
//#declare Cutter = box {<-10, 0.0, -10>,<10, -10, 10>};
#macro AdjustNodes(AngleX, AngleY, AngleZ, Displacement)
#declare Cut = object { CuttingPlane translate y * Displacement
rotate <AngleX, AngleY, AngleZ> };
#for (NodeCount, 0, NumberOfNodes - 1, 1)
#if (inside (Cut, Nodes[NodeCount]))
#declare Nodes[NodeCount] = Nodes[NodeCount] / 1.001;
#else
#declare Nodes[NodeCount] = Nodes[NodeCount] * 1.001;
#end
#end
#end
#for (ItterationCount, 0, NumberOfItterations - 1, 1)
#declare PlaneAngleX = rand(RandAngle) * 360;
#declare PlaneAngleY = rand(RandAngle) * 360;
#declare PlaneAngleZ = rand(RandAngle) * 360;
#declare Displacement = 0.5 - rand(RandAngle);
// #local Cut = object { CuttingPlane rotate PlaneAngle };
AdjustNodes(PlaneAngleX, PlaneAngleY, PlaneAngleZ, Displacement)
// #debug concat(str(PlaneAngle,0,0),"\n")
#end
WriteDataFile()
--
Cheers
Ger
Post a reply to this message
|
|
| |
| |
|
|
From: Ger Remmers
Subject: Re: recursively defined objects and memory (for Clipka full source)
Date: 18 Aug 2013 18:13:45
Message: <52114719$1@news.povray.org>
|
|
|
| |
| |
|
|
/*
Original code from somewhere on the internet.
How to evenly distribute points on a sphere.
dlong := pi*(3-sqrt(5)) ~2.39996323
dz := 2.0/N
long := 0
z := 1 - dz/2
for k := 0 .. N-1
r := sqrt(1-z*z)
node[k] := (cos(long)*r, sin(long)*r, z)
z := z - dz
long := long + dlong
*/
#version 3.7;
/*
Original code transcribed to SDL
Create an array with NumberOfNodes points
evenly distributed on the sphere
*/
#declare DataFilename = "nodes.inc";
#macro WriteDataFile()
#fopen DataFile DataFilename write
#write( DataFile, "#declare NumberOfNodes =
",str(NumberOfNodes,0,0),";\n")
#write( DataFile, "#declare Nodes =array [NumberOfNodes]\n")
#write( DataFile, "{\n")
#for (NodeCount, 0, NumberOfNodes -2, 1)
#write ( DataFile, "<",vstr(3, Nodes[NodeCount],",",0,-1),">,\n")
#end
#write ( DataFile, "<",vstr(3, Nodes[NumberOfNodes-2],",",0,-1),">\n")
#write (DataFile,"}\n")
#fclose DataFile
#debug concat("Done writing data file with ",str(NumberOfNodes,0,0),"
nodes for frame ",str(frame_number,0,0),"\n")
#end
/*
Only at the first frame do we need to initialize the nodes on the sphere,
after that we load the node data from disk.
*/
#if (frame_number = 1)
#declare NumberOfNodes = 5000000;
#declare Nodes =array [NumberOfNodes];
#declare dlong = pi * (3-sqrt(5));
#declare dz = 2.0 / NumberOfNodes;
#declare Longitude = 0;
#declare Z = 1 - dz / 2;
#for (NodeCount, 0, NumberOfNodes - 1, 1)
#declare Radius = sqrt(1 - Z * Z);
#declare Nodes[NodeCount] = <cos(Longitude)* Radius, sin(Longitude)
* Radius, Z>;
#declare Z = Z - dz;
#declare Longitude = Longitude + dlong;
#end
#else
#include DataFilename
#end
/*
Now for the mountainous transformations
We use a plane (Plane) to cut the sphere into 2 halves,
every node "inside" the plane will be lowered, every node "outside"
will be raised.
*/
#declare NumberOfItterations = 5;
#declare RandAngle = seed(66);
#if (frame_number > 1)
#for(Dummy,0, (frame_number - 1) * NumberOfItterations * 4,1)
#declare PlaneAngle = rand(RandAngle);
#end
#end
#declare PlaneAngle = rand(RandAngle);
#declare CuttingPlane = plane{y, 0};
#macro AdjustNodes(AngleX, AngleY, AngleZ, Displacement)
#declare Cut = object { CuttingPlane translate y * Displacement
rotate <AngleX, AngleY, AngleZ> };
#for (NodeCount, 0, NumberOfNodes - 1, 1)
#if (inside (Cut, Nodes[NodeCount]))
#declare Nodes[NodeCount] = Nodes[NodeCount] / 1.001;
#else
#declare Nodes[NodeCount] = Nodes[NodeCount] * 1.001;
#end
#end
#end
#for (ItterationCount, 0, NumberOfItterations - 1, 1)
#declare PlaneAngleX = rand(RandAngle) * 360;
#declare PlaneAngleY = rand(RandAngle) * 360;
#declare PlaneAngleZ = rand(RandAngle) * 360;
#declare Displacement = 0.5 - rand(RandAngle);
AdjustNodes(PlaneAngleX, PlaneAngleY, PlaneAngleZ, Displacement)
#end
WriteDataFile()
/*
And now to make the whole thing visible
*/
#declare Diameter = 2/sqrt(NumberOfNodes);
#declare MutilatedEarth = union {
#for (NodeCount, 0, NumberOfNodes - 1, 1)
sphere{Nodes[NodeCount], Diameter}
#end
pigment{
onion color_map{
[0.0 0.6 color <0, 1, 1> color <1, 0, 0>]
[0.6 0.8 color <1, 0, 0> color <0, 1, 0>]
[0.80 0.85 color <0, 1, 0> color <0, 0, 0.5>]
[0.85 0.9 color <0, 0, 0.5> color <0, 0, 1>]
[0.95 1.0 color <0, 0, 1> color <0, 0, 0>]}
scale 1
}
}
#declare LightStrenght = 1;
light_source {< -400, 1000, -500>*10000, color <1.0, 1.0, 1.0> *
LightStrenght
// area_light 10000, 10000, 51, 51 adaptive 0
}
light_source {< -400, 1000, 500>*1000, color 0.06125/2 * LightStrenght
rotate y * 120 shadowless}
light_source {< -400, 1000, 500>*1000, color 0.06125/2 * LightStrenght
rotate y * -120 shadowless}
light_source {< 0, -100000, 0>, color 0.06125/2 * LightStrenght shadowless}
#declare Blue_Sky3 =
pigment {
granite
turbulence 0.4
color_map {
[0.6 rgb <0, 0, 0.2> * LightStrenght]
[1.0 rgb 0.5 * LightStrenght]
}
}
sky_sphere {pigment {Blue_Sky3 scale < 3, 1, 3>*10}}
global_settings {
ambient_light 0.0
adc_bailout 0.09
max_trace_level 200
noise_generator 3
assumed_gamma 1.0
}
object { MutilatedEarth }
#declare CameraLocation = <0,0,-3>;
#declare CameraLookat = <0, 0, 0>;
camera {
location CameraLocation
look_at CameraLookat
direction z * 1.0
right image_width / image_height * x
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 19.08.2013 00:01, schrieb Ger Remmers:
> On 08/18/2013 04:48 PM, clipka wrote:
>> Am 18.08.2013 23:08, schrieb Ger Remmers:
>>
>>> (*) 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.
>>
>> Obviously that shouldn't happen. Can you provide a sample scene to
>> reproduce, dissect and debug the problem?
>>
>
> It messes up in the WriteDataFile() macro
Thanks, I'll have a closer look at it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> #declare Cut = object { CuttingPlane translate y * Displacement
> rotate <AngleX, AngleY, AngleZ> };
...
> #declare PlaneAngleX = rand(RandAngle) * 360;
> #declare PlaneAngleY = rand(RandAngle) * 360;
> #declare PlaneAngleZ = rand(RandAngle) * 360;
On a separate note, are you sure that method of choosing the plane
orientation gives a uniform random distribution...?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 19.08.2013 14:55, schrieb scott:
>> #declare Cut = object { CuttingPlane translate y * Displacement
>> rotate <AngleX, AngleY, AngleZ> };
>
> ....
>
>> #declare PlaneAngleX = rand(RandAngle) * 360;
>> #declare PlaneAngleY = rand(RandAngle) * 360;
>> #declare PlaneAngleZ = rand(RandAngle) * 360;
>
> On a separate note, are you sure that method of choosing the plane
> orientation gives a uniform random distribution...?
#declare Cut = object { CuttingPlane translate
VRand_On_Sphere(RandAngle) * Displacement };
should do the trick.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/19/2013 07:55 AM, scott wrote:
>> #declare Cut = object { CuttingPlane translate y * Displacement
>> rotate <AngleX, AngleY, AngleZ> };
>
> ....
>
>> #declare PlaneAngleX = rand(RandAngle) * 360;
>> #declare PlaneAngleY = rand(RandAngle) * 360;
>> #declare PlaneAngleZ = rand(RandAngle) * 360;
>
> On a separate note, are you sure that method of choosing the plane
> orientation gives a uniform random distribution...?
>
No, it does not, but doing it this way gives a better result than using
a single rand() for the plane orientation.
--
Cheers
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/19/2013 09:47 AM, clipka wrote:
> Am 19.08.2013 14:55, schrieb scott:
>>> #declare Cut = object { CuttingPlane translate y * Displacement
>>> rotate <AngleX, AngleY, AngleZ> };
>>
>> ....
>>
>>> #declare PlaneAngleX = rand(RandAngle) * 360;
>>> #declare PlaneAngleY = rand(RandAngle) * 360;
>>> #declare PlaneAngleZ = rand(RandAngle) * 360;
>>
>> On a separate note, are you sure that method of choosing the plane
>> orientation gives a uniform random distribution...?
>
> #declare Cut = object { CuttingPlane translate
> VRand_On_Sphere(RandAngle) * Displacement };
>
> should do the trick.
>
Using 3 separate rand()'s gave me a better result than a single rand(),
but by no means uniform. But then again, that was not the problem I was
trying to solve :)
--
Cheers
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ger <ger### [at] nospamthankyou> wrote:
> >> #declare PlaneAngleX = rand(RandAngle) * 360;
> >> #declare PlaneAngleY = rand(RandAngle) * 360;
> >> #declare PlaneAngleZ = rand(RandAngle) * 360;
> >
> > On a separate note, are you sure that method of choosing the plane
> > orientation gives a uniform random distribution...?
> No, it does not, but doing it this way gives a better result than using
> a single rand() for the plane orientation.
Better in what way?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/19/2013 10:51 AM, Warp wrote:
> Ger <ger### [at] nospamthankyou> wrote:
>>>> #declare PlaneAngleX = rand(RandAngle) * 360;
>>>> #declare PlaneAngleY = rand(RandAngle) * 360;
>>>> #declare PlaneAngleZ = rand(RandAngle) * 360;
>>>
>>> On a separate note, are you sure that method of choosing the plane
>>> orientation gives a uniform random distribution...?
>
>> No, it does not, but doing it this way gives a better result than using
>> a single rand() for the plane orientation.
>
> Better in what way?
>
More uniform, but in all honesty, that was not the first thing I was
paying attention to. I'll run a single vs triple rand() test case later.
--
Cheers
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ger <ger### [at] NoSpamthankyou> wrote:
> On 08/19/2013 10:51 AM, Warp wrote:
> > Ger <ger### [at] nospamthankyou> wrote:
> >>>> #declare PlaneAngleX = rand(RandAngle) * 360;
> >>>> #declare PlaneAngleY = rand(RandAngle) * 360;
> >>>> #declare PlaneAngleZ = rand(RandAngle) * 360;
> >>>
> >>> On a separate note, are you sure that method of choosing the plane
> >>> orientation gives a uniform random distribution...?
> >
> >> No, it does not, but doing it this way gives a better result than using
> >> a single rand() for the plane orientation.
> >
> > Better in what way?
> >
> More uniform, but in all honesty, that was not the first thing I was
> paying attention to. I'll run a single vs triple rand() test case later.
>
> --
> Cheers
> Ger
My method was to choose random Phi and Theta for spherical coordinates:
#for(I, 0, 30, 1)
#local Phi = Rand_Gauss(0.0, 0.33, RdmA)*180;
#local Theta = Rand_Gauss(0.0, 0.33, RdmB)*180;
intersection {
sphere { 0.0, 3.0 }
plane { <sin(Phi)*cos(Theta), sin(Phi)*sin(Theta), cos(Phi)>, 0 }
pigment { White }
translate <-15*6 + I*6, 0, 0>
}
#end
if you want to avoid the flaw with hemispherical slices, then you also need a
random offset:
#for(I, 0, 30, 1)
#local Phi = Rand_Gauss(0.0, 0.33, RdmA)*180;
#local Theta = Rand_Gauss(0.0, 0.33, RdmB)*180;
#local Offset = Rand_Gauss(0.0, 0.33, RdmC)*3.0;
intersection {
sphere { 0.0, 3.0 }
plane { <sin(Phi)*cos(Theta), sin(Phi)*sin(Theta), cos(Phi)>, Offset }
pigment { White }
translate <-15*6 + I*6, 0, 0>
}
#end
and in a test scene:
#include "kolors.inc"
#include "rand.inc"
light_source {
0*x
color rgb 1
translate <15, 30, -60>
}
camera {
perspective
location <3, 5, -60>
up y
right x*(image_width/image_height)
look_at 0
}
#for(I, 0, 30, 1)
#local Phi = Rand_Gauss(0.0, 0.33, RdmA)*180;
#local Theta = Rand_Gauss(0.0, 0.33, RdmB)*180;
#local Offset = Rand_Gauss(0.0, 0.33, RdmC)*3.0;
intersection {
sphere { 0.0, 3.0 }
plane { <sin(Phi)*cos(Theta), sin(Phi)*sin(Theta), cos(Phi)>, Offset }
pigment { White }
translate <-15*6 + I*6, 0, 0>
}
#end
Now, obviously, the CSG method isn't going to work because of memory
constraints. but you can easily use this method to generate your plane, and then
take the dot-product like so:
#declare Normal = <sin(Phi)*cos(Theta), sin(Phi)*sin(Theta), cos(Phi)>
#declare Mag = Rand_Gauss(0.0, 0.33, RdmC)*BaseRad;
vdot(Mag*Normal, CurrVertex - Mag*Normal)
At least, I think that should work...
Then scale the vertex coordinates based on whether the dot product is positive
or negative.
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ger <ger### [at] NoSpamthankyou> wrote:
> On 08/19/2013 10:51 AM, Warp wrote:
> > Ger <ger### [at] nospamthankyou> wrote:
> >>>> #declare PlaneAngleX = rand(RandAngle) * 360;
> >>>> #declare PlaneAngleY = rand(RandAngle) * 360;
> >>>> #declare PlaneAngleZ = rand(RandAngle) * 360;
> >>>
> >>> On a separate note, are you sure that method of choosing the plane
> >>> orientation gives a uniform random distribution...?
> >
> >> No, it does not, but doing it this way gives a better result than using
> >> a single rand() for the plane orientation.
> >
> > Better in what way?
> >
> More uniform, but in all honesty, that was not the first thing I was
> paying attention to. I'll run a single vs triple rand() test case later.
>
> --
> Cheers
> Ger
I think I may have spotted the reason why your planet is so turbulent.
You seem to be generating a new displacement for each point in the sphere
individually rather than displacing all the points on one side of the plane by
the same amount.
you should have your displacement macro generate two scaling factors before
iterating through the points: One factor for the positive side of the plane, and
one for the negative side.
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A slight correction:
#local Phi = Rand_Gauss(0.0, 0.33, RdmA)*pi;
#local Theta = Rand_Gauss(0.0, 0.33, RdmB)*pi;
Times like this, I really wish we could edit posts...
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/19/2013 02:03 PM, Anthony D. Baye wrote:
>
> I think I may have spotted the reason why your planet is so turbulent.
>
> You seem to be generating a new displacement for each point in the sphere
> individually rather than displacing all the points on one side of the plane by
> the same amount.
>
Nope, all points outside of the plane are lifted, all points inside the
plane are lowered.
This becomes very obvious if you look at images with < 10 iterations.
> you should have your displacement macro generate two scaling factors before
> iterating through the points: One factor for the positive side of the plane, and
> one for the negative side.
>
I don't generate any scaling factors. It is hard coded at 1.001.
> Regards,
> A.D.B.
>
>
--
Cheers
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ger <ger### [at] NoSpamthankyou> wrote:
> On 08/19/2013 02:03 PM, Anthony D. Baye wrote:
> >
> > I think I may have spotted the reason why your planet is so turbulent.
> >
> > You seem to be generating a new displacement for each point in the sphere
> > individually rather than displacing all the points on one side of the plane by
> > the same amount.
> >
>
> Nope, all points outside of the plane are lifted, all points inside the
> plane are lowered.
> This becomes very obvious if you look at images with < 10 iterations.
>
>
> > you should have your displacement macro generate two scaling factors before
> > iterating through the points: One factor for the positive side of the plane, and
> > one for the negative side.
> >
>
> I don't generate any scaling factors. It is hard coded at 1.001.
>
>
> > Regards,
> > A.D.B.
> >
> >
>
>
> --
> Cheers
> Ger
I see now. I was looking at the wrong part.
What I did was generate a random scaling factor between -0.025 and 0.025 for
each side, then scaled one side by 1+factor1 and the other side by 1-factor2
like so:
#declare factor1 = 0.025*Rand_Gauss(0.0, 0.33, RdmA);
#declare factor2 = 0.025*Rand_Gauss(0.0, 0.33, RdmB);
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> #declare Cut = object { CuttingPlane translate y * Displacement
>>> rotate <AngleX, AngleY, AngleZ> };
>>
>> ....
>>
>>> #declare PlaneAngleX = rand(RandAngle) * 360;
>>> #declare PlaneAngleY = rand(RandAngle) * 360;
>>> #declare PlaneAngleZ = rand(RandAngle) * 360;
>>
>> On a separate note, are you sure that method of choosing the plane
>> orientation gives a uniform random distribution...?
>>
>
> No, it does not, but doing it this way gives a better result than using
> a single rand() for the plane orientation.
But won't the problem be that the more iterations you do the more the
shape will drift away from a sphere (as not every point on the sphere
gets an equal chance to be either raised or lowered)? If you are aiming
for a huge number of iterations then the shape could become quite strange.
I have to try this method, probably outside of POV for speed.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 19-8-2013 21:09, Anthony D. Baye wrote:
> Times like this, I really wish we could edit posts...
At least, you can cancel the message and write a new one. ;-)
Using Thunderbird.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 19.08.2013 00:35, schrieb clipka:
> Am 19.08.2013 00:01, schrieb Ger Remmers:
>> On 08/18/2013 04:48 PM, clipka wrote:
>>> Am 18.08.2013 23:08, schrieb Ger Remmers:
>>>
>>>> (*) 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.
>>>
>>> Obviously that shouldn't happen. Can you provide a sample scene to
>>> reproduce, dissect and debug the problem?
>>>
>>
>> It messes up in the WriteDataFile() macro
>
> Thanks, I'll have a closer look at it.
I was able to track down the issue to a bug in the #for loop, which
causes the loop to terminate one iteration too early if the end value is
large (1048576 or higher on my Windows 7 x64 Intel i7 machine; I'm a bit
surprised you get a lower limit; I'd be interested to know what OS and
harware you are using).
As a workaround, use a #while loop with manual counter increment
instead. It requires a few more tokens per loop, but works with
significantly higher numbers.
I've already come up with a fix, but I'm not sure whether it will make
its way into the 3.7.0 release proper.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/20/2013 10:18 AM, clipka wrote:
>
> I was able to track down the issue to a bug in the #for loop, which
> causes the loop to terminate one iteration too early if the end value is
> large (1048576 or higher on my Windows 7 x64 Intel i7 machine; I'm a bit
> surprised you get a lower limit; I'd be interested to know what OS and
> harware you are using).
>
Sounds about right. I tried it with 1M nodes which worked fine and with
1.25M nodes which failed. The initial value I gave was just a
guess-estimate because I started with 1.5M which failed and then halved
it to 750K which worked.
My OS is OpenSuse 12.3, latest updates on an AMD 8-core with 16GB mem
> As a workaround, use a #while loop with manual counter increment
> instead. It requires a few more tokens per loop, but works with
> significantly higher numbers.
I'll give it a try even though "a few tokens more" is not what you want
in a loop that runs billions of times.
>
> I've already come up with a fix, but I'm not sure whether it will make
> its way into the 3.7.0 release proper.
>
It better, or I want my money back :)
--
Cheers
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/20/2013 02:58 AM, scott wrote:
>
> But won't the problem be that the more iterations you do the more the
> shape will drift away from a sphere (as not every point on the sphere
> gets an equal chance to be either raised or lowered)? If you are aiming
> for a huge number of iterations then the shape could become quite strange.
>
> I have to try this method, probably outside of POV for speed.
>
The shape will/does drift away from a perfect sphere but that's not
because not all points get changed.
The rule is that a plane cuts the sphere into 2 pieces, one possibly
larger then the other, all points on 1 side of the plane get raised, all
other points get lowered. What gets done to what points is totally
dependent on the random stream. If you don't like the endresult then the
only thing you can do is start over with a different seed().
--
Cheers
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
> On 19-8-2013 21:09, Anthony D. Baye wrote:
> > Times like this, I really wish we could edit posts...
>
> At least, you can cancel the message and write a new one. ;-)
>
> Using Thunderbird.
>
> Thomas
Perhaps, but I haven't ever been able to cancel posts written using the web
interface with Thunderbird.
possibly because my Thunderbird credentials differ from the ones I gave the web
interface.
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 20.08.2013 18:30, schrieb Ger:
>> I've already come up with a fix, but I'm not sure whether it will make
>> its way into the 3.7.0 release proper.
>>
>
> It better, or I want my money back :)
Good news: The fix will make it into 3.7.0.
Of course this requires extra effort, so we have decided to increase the
price for POV-Ray by 10%. :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 21-8-2013 14:50, clipka wrote:
> Of course this requires extra effort, so we have decided to increase the
> price for POV-Ray by 10%. :-P
>
Oh no! You can't! You have already brought me close to mendicity!
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
