[Bf-committers] Better approaches to Defocus?

[j.bakker at atmind.nl]

Hi Troy, 

the main differences are the luminosity / saturation and the brushes.

The brushes I already have an idea (required for the compositor branch),
the luminosity/saturation is something I didn't had an idea about, but this
can't be that difficult.

I think that if this needs to be implemented it could be implemented with
backwards compatibility with the current defocus node.

I currently don't see that many difference as in implementation between the
focus blur and blender's defocus.

Also as you pointed out, the defocus node is needed even if cycles can do a
better job on this. There are many cases you need to do this inside the
compositor.

Jeroen.


Original Message:
-----------------
From: Troy Sobotka troy.sobotka at gmail.com
Date: Mon, 27 Jun 2011 15:55:10 -0700
To: bf-committers at blender.org
Subject: [Bf-committers] Better approaches to Defocus?


While the compositor is getting an overhaul, I am wondering if there
are possibly better approaches to achieving a defocus cheat than the
current Defocus Node? The Defocus Node delivers wonderful results
under the caveat "When it works."

I realize that Cycles can deliver defocused looks, but it should still
stand that a solid 2D defocus node would be excellent, especially in
the domain of synthetic 2D manipulations.

The Focus Blur plugin seems to yield pretty solid results, albeit
trapped in the 8bpc domain. (http://registry.gimp.org/node/1444) It
would seem that the Z buffer, after a math node or two, would serve
well as a depth map.

Are there any plans currently to refine or replace the Defocus node?

With respect,
TJS
_______________________________________________
Bf-committers mailing list
Bf-committers at blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

--------------------------------------------------------------------
myhosting.com - Premium Microsoft® Windows® and Linux web and application
hosting - http://link.myhosting.com/myhosting