All images are downscaled. Click on an image for a full 1024x768 png.
The files used to generate these images can be downloaded here: DOF_MB_correlation_error.tar.gz
Times are all from the same machine (a dualcore intel laptop with 2GB of ram). Multithreading was disabled for 3delight. The times are not rigorous or exact and are not intended as benchmarks. I only put them up for rough comparison. The primary purpose of this page is to compare quality, not speed.
Aqsis: 0m 37s
3Delight: 0m 5s
Pretty much the same, although 3delight appears to sample with a slightly better sampling distribution. You can see slight strobing in the Aqsis image.
Aqsis: 0m 32s
3Delight: 0m 10s
No meaningful differences are apparent.
Aqsis: 5m 16s
3Delight: 0m 12s
Even though Aqsis is much slower at rendering this case, 3delight has highly objectionable strobing artifacts. This is likely from high correlation between time and lens position in their sampling strategy.
Time: 0m 12s
Strobing is extreme.
Time: 1m 28s
Strobing is subtler, but still apparent.
Time: 6m 55s
If you look really closely, there is still some strobing. But for most intents and purposes it is gone. Unfortunately, rendering is very slow at these high sampling rates.
Based on the strategies described in "Data-Parallel Rasterization of Micropolygons with Defocus and Motion Blur" (mentioned in a recent Sunday meeting), I suspect that 3Delight exploits correlation between time and lens position of its samples to boost its sampling speed, though I can't be sure. I also may have misread the paper.
When aiming to improve Aqsis' sampling efficiency, I suggest we should also aim to avoid nasty issues like this, even if it's at the expense of a little speed. If we avoid issues like this, then we can achieve better results with fewer samples anyway.
—Nathan
I emailed 3delight to notify them of the strobing issue, and they gave me this response:
Hello Nathan,
From our User's Manual:
Hider "hidden" "extrememotiondof" [0]
The default algorithm used to sample depth of field and motion blur
may cause artifacts when there are a lot of both effects. Setting this
parameter to 1 will use an alternate algorithm which does not cause
the artifacts. This algorithm is much slower so use it only if it is
absolutely required. Values of 2 or greater allow for a speed vs.
quality tradeoff, with large values increasing quality.
Please tell us how it goes.
I tested it out with Hider "hidden" "extrememotiondof" [1], and it works fine. Here's the updated comparison:
Aqsis: 5m 16s
3Delight: 0m 19s
Comparing to Aqsis, even with this option there appears to be some minor strobing in the 3delight image. But it vanishes quickly at higher production-level sampling rates.
What this does tell us, however, is that 3delight's blindingly fast sampler is indeed exploiting correlation between time and lens position to achieve those speeds. It also verifies that even if we stick to correct results, Aqsis' sampling can still be much faster.
Perhaps it would be interesting for Aqsis to do something similar to 3delight, except in reverse. By default Aqsis would have a correct-but-slower sampler, but there would be a hider option to enable a faster-but-incorrect sampler that exploits time/lens coherence.
If Aqsis only has one, though, I would of course opt for slower-but-correct.