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.
:-) True as written. I agree well enough that I closed the github issue
once I understood why the partially rendered regions where sometimes
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,
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).
(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