[Bf-committers] compositor defocus node

[Jeroen Bakker]

Thanks Ian,

I just didn't knew how to set it up. Now I have updated my test-cases 
and it worked perfectly!

I have read some articles that replaces the z-buffer with a different 
kind (xyz-buffer) or uses slicing to reduce the downside effect. But 
you're correct if you want real defocus, we need more information passed 
from the renderer to the compositor.

Jeroen.

On 10/23/2010 12:58 AM, Ian Failing wrote:
> Jeroen, in re "What is the use of these blur types?" These blur types
> emulate this visual effect of lensing:
> http://en.wikipedia.org/wiki/Bokeh
> Note the octagonal shape of the blurred lights in the second image, caused
> by the shape of the aperture. The result of the effect is more noticeable
> with small intense light sources on a dark background. This image is an
> example of a "pixel that is more blurred and lays farther away, [that] can
> effect a pixel that is more in front" (as bright blurry spots can "bleed
> through" or "bend around" occluding objects), and should be a part of an
> algorithm that tries to replicate lensing.
>
> Christopher: (I assume you're not talking about some bug that doesn't befall
> me.) I'm not an expert with this, but I think that physically accurate rack
> focusing is only reasonably possible with a raytracing renderer that
> simulates an aperture -- not something that Blender currently does. The
> Blender renderer models an infinitely small aperture and throws out surfaces
> that are occluded behind other objects, so it doesn't know what light would
> be "showing through" the foreground object in order to properly blur its
> inner edge. Maybe the non-depth-aware blurring could be improved somehow, I
> don't know.
>
> -h/2
>
> On Fri, Oct 22, 2010 at 2:21 PM, Christopher Cherrett<
> ccherrett at openoctave.org>  wrote:
>
>>   While the defocus node is getting some attention I would like to point
>> out that rack focusing with defocus does not work well. Objects jump in
>> and out of focus with hard edged lines on the blur.
>>
>> -------- Original Message  --------
>> Subject: [Bf-committers] compositor defocus node
>> From: Jeroen Bakker<j.bakker at atmind.nl>
>> To: bf-blender developers<bf-committers at blender.org>
>> Date: 10/22/2010 10:09 AM
>>> Hi All,
>>>
>>> I have reverse engineered the compositor defocus algorithm to its purest
>>> form. the result I have posted on my blog.
>>>
>>>
>> http://sicg.atmind.nl/index.php?option=com_content&view=article&id=29:blender-defocus-algorithm
>>> The current implementation is not depth aware. I am not sure that this
>>> is a real issue, as nobody complains. I am also not sure about the many
>>> filter types and settings. the circle has a faster algorithm then the
>>> rest of the filters, but visually they do not differ much.
>>>
>>> Hope it is helpful to you all. Btw I am pleased with the speedup (50% on
>>> my system). Will try on a GTX200 series next week.
>>>
>>> Cheers,
>>> Jeroen
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> --
>> Christopher Cherrett
>> ccherrett at openoctave.org
>> http://www.openoctave.org
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


-- 

Met vriendelijke groet,

Jeroen Bakker

*At Mind BV
*

Telefoon: 06 50 611 262
E-mail: j.bakker at atmind.nl <mailto:j.bakker at atmind.nl>