On 9/25/20 9:00 AM, William F Pokorny wrote:
> On 9/24/20 2:31 PM, Ash Holsenback wrote:
>> image is a comparison of the tracetask.cpp fix that bill ask us to 
>> try... working with 3.8.0-alpha.10064268. saved aside before and after 
>> images and did a compare:
>>
>>
> 
> Thanks.
> 
> 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

> 
> Did you use -j, +ss and +wt1 on both renders?

indeed

> 
> 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

> 
> ---
> Your compare image rekindles thinking about color / intensity and AA 
> approaches; Rendering large and scaling down vs AA or in combination.
> The aa +ag flag/setting. A big pile of subtle trade-offs.
> 
> Where the previous am3 implementation was sort of working / stopping on 
> the threshold test (and not the sample limit) there was too a probable 
> color result change due the uberpov to v3.8 threshold test change.

i think that might explain the results i was seeing in my compare image

> 
> Further, that test could get done after a conversion to grey scale 
> (luminosity) instead - which might work better for what it's trying to 
> do at the expense of CPU time in the threshold test. I'm not sure what 
> impact to the render due sampling depth such a change would have.

after your comment here i've done some digging... thanks for the nudge

> 
> All said. Let me play devil's advocate for a bit with anti-aliasing 
> methods. I took the biscuit scene and played with am3 until I thought it 
> was rendering the the ridges on the biscuits well.
> 
> Now I do these three renders with my current v3.8 based povr:
> 
> --- am3
> povr2 biscuit.pov +am3 +a0.015 +ac0.9 +r5 +w450 +h450
> 438.641
> Pixels:  202500   Samples:  37917505   Smpls/Pxl: 187.25

your am3 settings are similar to what i'm using

> 
> --- am2
> povr2 biscuit.pov +am2 +a0.015 +r5 +w450 +h450
> 413.702
> Pixels:  216225   Samples:  48143226   Smpls/Pxl: 222.65
> 
> --- am1
> povr2 biscuit.pov +am1 +a0.0 +r9 +w450 +h450
> 133.385
> Pixels:  216000   Samples:  16402500   Smpls/Pxl: 75.94
> 
> Attached is an image comparing am1 to am3 in the top row; multiplying 
> the differences by 5. In the bottom row comparing am2 to am3; again 
> multiplying differences by 5.
> 
> What does it all mean? Lots of things I guess. I am comforted that the 
> updated scenes match well for color and intensity across all three 
> methods with the am3 fix.
> 
> I also tried v3.8 at commit 74b3ebe for grins expecting a really long 
> run time (maybe with a color shift to explain yours). Instead I got:
> 
> p380 biscuit_v38.pov +am3 +a0.015 +ac0.9 +r5 +w450 +h450
> 408.578s  (The posted fix costs time)
> Pixels:  202500   Samples: 0   Smpls/Pxl: 0.00

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... fwiw i'm dual core intel g2120 i believe. running leap 
15.1

> 
> I didn't use +ss but still the images compare well fixed to non-fixed. 
> What this confirms is the pre-fix code was 'sometimes' working (no 
> domain errors).
> 
> 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

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

inquiring minds wanna know

> 
> Bill P.

Post a reply to this message