I guess I've posted an image showcasing this patch before, but now that 
I'm actually preparing it for a release (not into POV-Ray proper, but an 
unofficial branch I'm currently compiling from various fancy patches 
that have accumulated in my drawer) and have finally tracked down a 
serious performance issue, i thought I might post another set of 
demonstration renders.

The first image was rendered with the standard anti-aliasing mode 2, 
taking 6 seconds to compute. Note the moiree effects near the horizon, 
which are resistent to any increase in anti-aliasing quality settings.

The second image was rendered with the new anti-aliasing mode, taking 
only 5 seconds to compute. Note how the distant moiree is replaced by 
random noise.

The third image demonstrates the increase in render quality that can be 
achieved by cranking up the anti-aliasing quality settings. Moiree 
patterns begin to show again, but they are less pronounced than with 
anti-aliasing mode 2 (which, as I love to re-iterate, will not get any 
better whatever you do). Render time was 84 seconds.


(Render times are comparatively long for such a simple scene because I 
was using a debug version of the binary, with plenty of compiler 
optimizations turned off.)

Post a reply to this message

Attachments:
Download 'am2.png' (193 KB) Download 'am3.png' (256 KB) Download 'am3+.png' (229 KB)

Preview of image 'am2.png'

Preview of image 'am3.png'

Preview of image 'am3+.png'

clipka <ano### [at] anonymousorg> wrote:
> The first image was rendered with the standard anti-aliasing mode 2,
> taking 6 seconds to compute. Note the moiree effects near the horizon,
> which are resistent to any increase in anti-aliasing quality settings.
>
> The second image was rendered with the new anti-aliasing mode, taking
> only 5 seconds to compute. Note how the distant moiree is replaced by
> random noise.

In my experience, method 2 works better for most scenes, but method 1
(non-adaptive) wins hands down for checkered planes.  I have achieved results
similar to your 2nd and 3rd images using method 1 with jitter (+AM1 +J).  What
is the advantage of your new method over method 1?  Is it adaptive like method
2?

Post a reply to this message

Am 23.07.2013 04:05, schrieb Cousin Ricky:

> In my experience, method 2 works better for most scenes, but method 1
> (non-adaptive) wins hands down for checkered planes.  I have achieved results
> similar to your 2nd and 3rd images using method 1 with jitter (+AM1 +J).  What
> is the advantage of your new method over method 1?  Is it adaptive like method
> 2?

Yes, indeed; it uses an approach similar to the oversampling implemented 
in focal blur (but takes neighboring pixels into account to do its 
adaptive thing).

Method 1 with jitter does indeed do a comparatively good job; but its 
quality settings don't always scale well, as the attached image 
demonstrates - this was rendered with +am1 and extremely high-quality 
settings (+a0.01 +r9). Fun fact: With a lower numbr of samples, the 
artifacts in the distance didn't show.

More importantly however, in the branch I'm working on the new 
anti-aliasing mode will serve as a key component to speed up renders 
that combine multiple features that rely on some kind of oversampling, 
like focal blur, area lights, media, SSLT and (coming later) blurred 
reflections.

Post a reply to this message

Attachments:
Download 'am1.png' (198 KB)

Preview of image 'am1.png'

On Tue, 23 Jul 2013 06:58:45 +0200, clipka <ano### [at] anonymousorg> wrote:

>  blurred
> reflections.
>

=D

-- 
-Nekar Xenos-

Post a reply to this message

Am 23.07.2013 21:51, schrieb Nekar Xenos:
> On Tue, 23 Jul 2013 06:58:45 +0200, clipka <ano### [at] anonymousorg> wrote:
>
>>  blurred
>> reflections.
>>
>
> =D

:-D

Post a reply to this message

Attachments:
Download 'stochastic_reflection_blur.png' (433 KB)

Preview of image 'stochastic_reflection_blur.png'

Looking forward to this. Formalist work is tough on AA.

"clipka" <ano### [at] anonymousorg> wrote in message 
news:51ee0d90@news.povray.org...
> Am 23.07.2013 04:05, schrieb Cousin Ricky:
>

Post a reply to this message

On 23/07/2013 21:57, clipka wrote:
> Am 23.07.2013 21:51, schrieb Nekar Xenos:
>> On Tue, 23 Jul 2013 06:58:45 +0200, clipka <ano### [at] anonymousorg>
>> wrote:
>>
>>>  blurred
>>> reflections.
>>>
>>
>> =D
>
> :-D

You tease!

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 23.07.2013 04:05, schrieb Cousin Ricky:
>
> > In my experience, method 2 works better for most scenes, but method 1
> > (non-adaptive) wins hands down for checkered planes.  I have achieved results
> > similar to your 2nd and 3rd images using method 1 with jitter (+AM1 +J).  What
> > is the advantage of your new method over method 1?  Is it adaptive like method
> > 2?
>
> Yes, indeed; it uses an approach similar to the oversampling implemented
> in focal blur (but takes neighboring pixels into account to do its
> adaptive thing).
>
> Method 1 with jitter does indeed do a comparatively good job; but its
> quality settings don't always scale well, as the attached image
> demonstrates - this was rendered with +am1 and extremely high-quality
> settings (+a0.01 +r9). Fun fact: With a lower numbr of samples, the
> artifacts in the distance didn't show.
>
> More importantly however, in the branch I'm working on the new
> anti-aliasing mode will serve as a key component to speed up renders
> that combine multiple features that rely on some kind of oversampling,
> like focal blur, area lights, media, SSLT and (coming later) blurred
> reflections.

Why a branch instead of a predefined version number that would wait this feature
to get counted, like 3.7.5?

Is this because you feel it has too many drawbacks to make it to trunk ever?
what kind of licence would this branch use?

Post a reply to this message

Am 24.07.2013 11:50, schrieb Mr:

>> More importantly however, in the branch I'm working on the new
>> anti-aliasing mode will serve as a key component to speed up renders
>> that combine multiple features that rely on some kind of oversampling,
>> like focal blur, area lights, media, SSLT and (coming later) blurred
>> reflections.
>
> Why a branch instead of a predefined version number that would wait this feature
> to get counted, like 3.7.5?
>
> Is this because you feel it has too many drawbacks to make it to trunk ever?

There are plenty of reasons for this.

First, I guess that users would rather test-drive these patches than 
just being teased with test scenes - and as a matter of fact I myself am 
itching to see the community test-drive it and provide feedback.

Second, the approach is quite different to what POV-Ray is doing now, 
and will need thorough community testing before even deciding whether it 
is worth including in POV-Ray proper.

Third, in the past POV-Ray has seen quite a bunch of patches, so we 
should expect POV-Ray 3.7 to be patched as well, and I think it would be 
good to establish some standards, best practices and easy-to-use 
building blocks for patches and patch collections; a good tool to this 
end would be some "prototype branch". I intend the branch I'm working on 
to double-feature for this exact purpose, both in the sense of begin a 
testbed for establishing those standards, best practices and building 
blocks in the first place, as well as serving as a reference for future 
branches.


> what kind of licence would this branch use?

It will be published under the Affero GNU General Puplic License (AGPL), 
a variation of the GPL.

Post a reply to this message