> > Actually only the antialias method 2 can work properly.
> 
> Why is that?

	With method 1 the current pixel and its up and/or left neighbour
are both supersampled if required, and this leads to the opposite result
than the expected one. When I experienced that the first time, I found
it was obvious, but now I don't remember why ;-) Anyway the method 2
works fine since we are supersampling *through* the current pixel, leaving
the neighbours the same.

> > I also use it for focal blur since it helps a little bit to reduce
> > the grainy effect.
> 
> Hmm, I thought focal blur replaced ordinary anti-aliasing...but looking
> at the manual again, it only says AA isn't needed, not that it won't be
> done.

	Yes, ideally the method by itself will produce antialiased pic
since the camera is slightly moving (roughly on a disk). But, as Warp
mentionned on his site (a dedicated page), the sharp zone is not enough
antialiased. Allowing method 2 to work gives pretty good results (again
method 1 is bad). Rendering speed is of course slower. But I think it
worth it, since it also helps a little bit to reduce the grainy effect
produced by random numbers. This effect is especially strong for pure
colours (I only use that for scientific stills/movies), even when there
are a lot of blur_samples and variance is 0 (all rays are traced).

	You may know that similar effects are obtained with area_light
with a few lights inside and jittering. Same also for all the media
stuffs. I wonder if the "random" number generator could be renewed a
little bit to get smoother pictures... but I'm not sure this is the
real cause of those problems, although I suspect it from my tests on
focal blur code.


*** Nicolas Calimet
*** http://pov4grasp.free.fr

Post a reply to this message