On 1/26/24 07:20, Thorsten wrote:
> On 25.01.2024 16:49, William F Pokorny wrote:
>> Aside: As of writing this I'm unsure what happens with render 
>> continuations.  If the position in the random number streams are 
>> maintained in the state file, continuations should work without issue. 
>> Otherwise continued renders may well show differences when compared to 
>> renders not stopped and re-started.
> 
> Using a random sampling and then always expecting the same result is a 
> user error, not a bug. The random effects may also depend on the thread 
> settings, block size settings, hardware used, etc. because they are 
> random. As such, clearly not a bug.
> 
> Thorsten
> 
> 

:-) True as written. I agree well enough that I closed the github issue 
once I understood why the partially rendered regions where sometimes 
showing differences.

We should though, avoid setting a universal impression AA jitter should 
be avoided where users want repeatable render to render results. This 
especially true in the very latest yuqk release where the v3.8 method 3 
+ss mechanism has been extended to all three AA methods. Being able to 
use a good jitter and get repeatable results is effectively a new, 
desirable feature.


---
The AA / jitter reality across v3.6 -> v4.0 & my yuqk fork is 
complicated over time - as I think might reasonably be user expectations.

Speaking only of anti-aliasing / jitter affected results...

With the latest yuqk release - so long as +ss is set, the render 
pattern, step size and block size is held constant and we are doing full 
frame renders - results are repeatable no matter the number of threads 
used and no matter whether jitter is used or not (jitter of course 
always on or off).

A similar statement can be made for official releases and (non-buggy) 
method 3 (v3.8+) results using jitter or not. Methods 1 & 2 jitter 
onward in official v3.7 onward are mostly repeatable too (jitter is 
using a static table and jitter defaults on), but here the statement is 
weaker as is the quality of the AA when jitter is on.

Users expecting that a partially rendered region of a frame should match 
the same region when the frame is fully render isn't that much of a 
stretch, if they are seeing frame to frame repeatability. The same true 
for renders stopped and restarted via state files - though again, I 
don't myself know what is or is not happening with continued renders 
with respect to jitter / method 3(a).

Bill P.

(a) - If the continuations start after the last full block rendered in 
the context of the an identically ordered (and block numbered) render 
pattern, probably things work fine.

Post a reply to this message