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< > [email protected]> 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<[email protected]> >> To: bf-blender developers<[email protected]> >> 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 >>> [email protected] >>> http://lists.blender.org/mailman/listinfo/bf-committers >> -- >> Christopher Cherrett >> [email protected] >> http://www.openoctave.org >> >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- Met vriendelijke groet, Jeroen Bakker *At Mind BV * Telefoon: 06 50 611 262 E-mail: [email protected] <mailto:[email protected]> _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
