 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] No Spamthankyou> 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
|
|
| |
| |
|
|
|
|
| |
