A render of this scene with "+w512 +h256 +am3 +a0.2 +ac0.8 +r1" shows 
definite non-random patterns in the output every time - the red circles 
are post-processing ;-) You can change a lot of the numbers in the code 
and command-line a little bit and still get the same patterns.

Is this a bug/feature of the random number generator algorithm?

#version 3.7
global_settings{radiosity{no_cache count 2}}

sky_sphere { pigment { gradient y
              color_map{[.5 color rgb 2][1 color rgb 0]}
              scale 2 translate -1 }
   rotate x*30 rotate y*45 emission 2 }

plane{y 0 pigment{color rgb 1} finish{diffuse  0.3}}

camera {
   angle 40
   location  <0,3,6> look_at   <0,1,0>
   right x*image_width/image_height
}

Post a reply to this message

Attachments:
Download 'noise.png' (100 KB)

Preview of image 'noise.png'

Here is the difference between two renders of the scene a few minutes 
apart. It seems some blocks always get given the exact same seed for the 
RNG.

Post a reply to this message

Attachments:
Download 'diff.png' (121 KB)

Preview of image 'diff.png'

Am 28.08.2014 11:13, schrieb scott:
> Here is the difference between two renders of the scene a few minutes
> apart. It seems some blocks always get given the exact same seed for the
> RNG.

Did you use the Windows version? If so, did you start the renders from 
the same instance of the GUI?

I suspect that I'm only computing the base seed when POV-Ray is started, 
erroneously using it over and over again during the entire session.

The difference between many of the blocks would then be solely due to 
different assignment of render blocks to threads (because of different 
thread scheduling), and using "+WT1" you should indeed see no 
differences at all.

Post a reply to this message

Le 14-08-28 12:24, clipka a écrit :
> Am 28.08.2014 11:13, schrieb scott:
>> Here is the difference between two renders of the scene a few minutes
>> apart. It seems some blocks always get given the exact same seed for the
>> RNG.
>
> Did you use the Windows version? If so, did you start the renders from
> the same instance of the GUI?
>
> I suspect that I'm only computing the base seed when POV-Ray is started,
> erroneously using it over and over again during the entire session.
>
>

That can be aleviated by not reinitialising the random stream but 
continuing using it from where it was at the end of the previous render.
That way, the last used value effectively becomes the seed of the next 
render.

Post a reply to this message

Am 28.08.2014 22:36, schrieb Alain:
> Le 14-08-28 12:24, clipka a écrit :
>> Am 28.08.2014 11:13, schrieb scott:
>>> Here is the difference between two renders of the scene a few minutes
>>> apart. It seems some blocks always get given the exact same seed for the
>>> RNG.
>>
>> Did you use the Windows version? If so, did you start the renders from
>> the same instance of the GUI?
>>
>> I suspect that I'm only computing the base seed when POV-Ray is started,
>> erroneously using it over and over again during the entire session.
>>
>>
>
> That can be aleviated by not reinitialising the random stream but
> continuing using it from where it was at the end of the previous render.
> That way, the last used value effectively becomes the seed of the next
> render.

Theoretically yes, but in practice no - each render thread needs its own 
stochastic RNG instance, and the render threads only live as long as it 
takes to render an individual image.

Post a reply to this message

>> Here is the difference between two renders of the scene a few minutes
>> apart. It seems some blocks always get given the exact same seed for the
>> RNG.
>
> Did you use the Windows version? If so, did you start the renders from
> the same instance of the GUI?

Yes and yes.

> I suspect that I'm only computing the base seed when POV-Ray is started,
> erroneously using it over and over again during the entire session.

It seems like it.

> The difference between many of the blocks would then be solely due to
> different assignment of render blocks to threads (because of different
> thread scheduling), and using "+WT1" you should indeed see no
> differences at all.

The new version you just uploaded works as expected now, thanks! I find 
that after a long render if I'm still not happy with the level of noise 
I can run it again and average the results - which will work now :-)

BTW I had the same issue when I first started using multi-instances of 
mcpov, it uses the number of seconds as the seed by default, so if you 
start 12 instances simultaneously they all render exactly the same result.

 From a programming point of view, wouldn't it better to use 
milli/micro/nano seconds or ticks to give more chance of avoiding 
creating repeatable RNG streams?

Post a reply to this message

Am 29.08.2014 09:16, schrieb scott:
>>> Here is the difference between two renders of the scene a few minutes
>>> apart. It seems some blocks always get given the exact same seed for the
>>> RNG.
>>
>> Did you use the Windows version? If so, did you start the renders from
>> the same instance of the GUI?
>
> Yes and yes.
>
>> I suspect that I'm only computing the base seed when POV-Ray is started,
>> erroneously using it over and over again during the entire session.
>
> It seems like it.
>
>> The difference between many of the blocks would then be solely due to
>> different assignment of render blocks to threads (because of different
>> thread scheduling), and using "+WT1" you should indeed see no
>> differences at all.
>
> The new version you just uploaded works as expected now, thanks! I find
> that after a long render if I'm still not happy with the level of noise
> I can run it again and average the results - which will work now :-)
>
> BTW I had the same issue when I first started using multi-instances of
> mcpov, it uses the number of seconds as the seed by default, so if you
> start 12 instances simultaneously they all render exactly the same result.

IIRC mcpov also had some command-line or SDL option to choose a custom seed.

>  From a programming point of view, wouldn't it better to use
> milli/micro/nano seconds or ticks to give more chance of avoiding
> creating repeatable RNG streams?

Unfortunately, functions that provide this information tend to (A) not 
be portable, or (B) have an unknown granularity, possibly only 
increasing the value every second as well.

Post a reply to this message