While continuing to play with media and fog, I stumbled across the fact 
the crand mechanism is not thread safe in a render block, blotchy way.

Do we care enough about this feature to open up a github issue?

It's not on my list of used features. However, it's used in our mist.pov 
sample scene, for example, which forces +wt1 when the scene is included 
in any image comparison testing.

Updating our sample scenes (7 by my count) to not use crand OK with me 
too, but ?

Bill P.

Post a reply to this message

On 03/06/2018 06:44 AM, William F Pokorny wrote:
> While continuing to play with media and fog, I stumbled across the fact 
> the crand mechanism is not thread safe in a render block, blotchy way.
> 
> Do we care enough about this feature to open up a github issue?
> 
> It's not on my list of used features. However, it's used in our mist.pov 
> sample scene, for example, which forces +wt1 when the scene is included 
> in any image comparison testing.
> 
> Updating our sample scenes (7 by my count) to not use crand OK with me 
> too, but ?
> 
> Bill P.

No opinions eh? ;-)

Took a few minutes to search back through the newsgroups and it looks 
like this feature was out of 3.7 development for a time and then 
restored with some asking for it in 3.7.

When I get a moment I'll either open up a github issue or a pull request 
if a quick look at the code shows an easy fix like c++11's thread_local.

Bill P.

Post a reply to this message

On 03/07/2018 08:23 AM, William F Pokorny wrote:
> On 03/06/2018 06:44 AM, William F Pokorny wrote:
> 
> When I get a moment I'll either open up a github issue or a pull request 
> if a quick look at the code shows an easy fix like c++11's thread_local.
> 

Perhaps best I talk to myself... Turns out there is a separate random 
number generator set up for crand - suppose for speed reasons and that 
the set up intentional. Going to walk away.

Use +wt1 if using crand and you want 'frame/view' renders to be the same 
render to render.

Bill P.

Post a reply to this message

Am 07.03.2018 um 15:18 schrieb William F Pokorny:
> On 03/07/2018 08:23 AM, William F Pokorny wrote:
>> On 03/06/2018 06:44 AM, William F Pokorny wrote:
>>
>> When I get a moment I'll either open up a github issue or a pull
>> request if a quick look at the code shows an easy fix like c++11's
>> thread_local.
>>
> 
> Perhaps best I talk to myself... Turns out there is a separate random
> number generator set up for crand - suppose for speed reasons and that
> the set up intentional. Going to walk away.
> 
> Use +wt1 if using crand and you want 'frame/view' renders to be the same
> render to render.
> 
> Bill P.

Maybe we can concoct something that will keep the crand stable when
using the "+HR" option. While currently only having an effect on
radiosity, the intention of the switch was to also change the behaviour
of any other stuff that's affected by thread assignment and render block
ordering.

My suggestion would be to re-seed the crand noise generator each time a
new block is started, maybe using a seed based on the block number in
order to prevent visible repetitions.

Post a reply to this message

(in 3.7.1 beta 9, running 2 threads-- as far as I can tell with my processor.)

I don't know if this helps:
I ran a simple 15-frame animation, of crand on a box. 800 X 600,
Render_Block_Size 80 (so that's 10 blocks across and 7.5 blocks down) Then used
frame 1 as a reference to 'difference' the others from it in Photoshop.

What I see is random blocks being identical from frame to frame, at random
locations. Sometimes only a few blocks, sometimes many. And the individual
frames have some random repeated blocks as well, which change from frame to
frame too.

(BTW, I'm thinking that these results may have some bearing on Bill's earlier
thread about SSLT and its own repeating 'block' behavior. Or maybe not.)

One other note: For crand to show up on an object, the object needs at least
*some* finish{diffuse...} amount. Full ambient or emission by itself doesn't
show it. I didn't know this until now.

--------
#version 3.71;
global_settings {assumed_gamma 1.0}

camera {
  orthographic
  location  <.5, .5, -10>
  look_at   <.5, .5,  0>
  right     x*image_width/image_height
  angle 20
}

light_source {
  0*x                  // light's position (translated below)
  color rgb <1,1,1>    // light's color
  translate <20, 40, -20>
}

plane{z,.1
    pigment{rgb 1}
    finish{ambient 0 emission 0 diffuse 1 crand 1.0}
    }

Post a reply to this message

On 03/07/2018 10:47 AM, clipka wrote:
> Am 07.03.2018 um 15:18 schrieb William F Pokorny:
>> On 03/07/2018 08:23 AM, William F Pokorny wrote:
...
>>
>> Use +wt1 if using crand and you want 'frame/view' renders to be the same
>> render to render.
>>
...
> 
> Maybe we can concoct something that will keep the crand stable when
> using the "+HR" option. While currently only having an effect on
> radiosity, the intention of the switch was to also change the behaviour
> of any other stuff that's affected by thread assignment and render block
> ordering.
> 
> My suggestion would be to re-seed the crand noise generator each time a
> new block is started, maybe using a seed based on the block number in
> order to prevent visible repetitions.
> 

Thanks.

I think using "+HR" here a good idea. Your approach though looks low 
cost cpu wise to me though a more complicated implementation. Maybe fast 
enough the more stable way is how crand could work all the time...

I'll open up a github issue including a pointer back to this thread when 
I get the chance.

Bill P.

Post a reply to this message

On 03/08/2018 08:18 AM, William F Pokorny wrote:
> On 03/07/2018 10:47 AM, clipka wrote:
...
> 
> I'll open up a github issue including a pointer back to this thread when 
> I get the chance.
> 
...
> 

See:

https://github.com/POV-Ray/povray/issues/353

Bill P.

Post a reply to this message