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