It happens when we end up with a single pixel within a within a thread 
rendering block; When neighborSamples in tracetask.cpp ends up as 1. My 
patch bumps that value to at least '2'. This makes the test to the 
threshold less forgiving, but at worst a few more samples are taken.

The single pixel in a render block isn't something which will happen 
often in practice(a).

As for what happens today on hitting this bug; It will depend on how 
your particular executable is compiled. If nothing else, it's
a component contributing to somewhat flaky render reporting. My fast 
compile ran without a squeak, but it also bailed too early on the AA for 
the single pixel.

Bill P.

(a) - The code involved here has some addition implications related to 
how many initial samples there are available in the block for a given 
pixel. The count changes downstream behavior. At the start of the 
sampling, I don't think it will matter much to the end result. This 
'concern' is mostly mitigated, if using yuqk's anti-aliasing min depth 
option with a depth >0.

Post a reply to this message