On 9/26/20 8:03 AM, Ash Holsenback wrote:
> On 9/25/20 9:00 AM, William F Pokorny wrote:
...
>> Did you happen to capture the CPU times for the two renders?
> 
> stock povray rendered it at 9 min 24 sec... lol the fix did it at 9:22
> 

Thanks. If you see much lower times with no AA (set threshold negative), 
It's likely for your scene '+am3' was running previously too. I suspect 
for some who previously got good results, method 3 was running to a stop 
at max samples and not the threshold. What run times these renders had 
would depend mostly on +r depth - something which can still sort of 
(confidence setting in play) happen, if the threshold is set small 
enough.

...
>> Were you using area lights?
> 
> not this time... i'll be getting to that eventually because that's 
> exactly how i'm using am3... adaptive 0 on the area lights and rely on 
> am3 to do the rest
> 

I know there is an odd interplay between area lights and AA, but I have 
never gotten my head around what's really happening.

Two adaptive algorithms fighting for what they think is right?

Why do you think am3 will behave better for such situations?

...
> 
> hmmmm... i didn't see much time diff between fixed and not. i wonder if 
> it that's tied to the fact that i never could reproduce the issue that 
> Ton brought up... 
>

Probably. Why your render works could be the compiler, settings when 
compiling, hardware. I don't know and don't plan to burn more time on 
it.

>>
>> I looked at the code at commit 551338 (your release) and it matches 
>> that at 74b3ebe - also not an explanation for your color difference.
> 
> if someone could add to this and maybe explain... i'm lost on that one
> 

The release at which you run - 3.8.0-alpha.10064268 - is in fact git 
commit 551338. The release name is just a name (a git tag). I run v3.8, 
and base povr off of a later commit. On seeing your color change, I 
thought maybe Christoph had made some change after 551338 which might 
explain it. He'd not - at least not in the method 3 core code.

>>
>> Extra credit to those of you asking why only am3 gets the image pixel 
>> count right...
> 
> inquiring minds wanna know
> 
...

I don't myself know! :-) It's been this way since v3.7 at least and it's 
a question of which I'm occasionally reminded.

I vaguely recall methods 1 & 2 doing stuff like always taking 4 pixels 
initially or throwing center samples away. Don't remember exactly, but 
these might be the cause. But then, I ask myself why should these pixels 
be counted with the base pixel count and not as additional pixels due 
the sampling method... It probably blurs the samples per pixel calculation.

Anyone know why the different base pixel counts on activating am1 or 
am2?

Bill P.

Post a reply to this message