[Bf-cycles] Shadow Catcher BSDF

[Sergey Sharybin]

Hi,

First of all it is to be defined what exactly "shadow catcher" is and how
it fits into VFX workflow. Is it approach to BSDF shading or is it a render
pass? Or maybe just more advanced light path/visibility control in the
material? Strictly defining what exactly our goal is the best first step
IMO.

Now, as for the approach: differential rendering is the only way to get
proper shadows as far as i concerned. The only thing is you need to do it
without extending render times by the factor of 2. The problem you
mentioned i'm not really sure. Of course material used to catch the shadow
is important, you wouldn't want to use magenta material to get shadows for
the light gray material (unless it's artistic decision).

If you're asking which heuristics are possible to achieve faster
differential rendering -- you'll need to have a research on this i'm afraid.

On Wed, Feb 11, 2015 at 11:59 PM, Lukas Stockner <lukas.stockner at freenet.de>
wrote:

> Hi,
> I've been trying out how to implement a shadow catcher in Cycles, but
> apparently there are many different approaches.
>
> My current idea is: At the point being shaded, evaluate the direct
> light, but also separately accumulate the contribution of lights without
> considering occlusion (the shadow_blocked check). Then, a shadow ratio
> can be calculated from "L_regular / L_no_occlusion". The shadow ratio is
> then used in a Holdout-like setup to set alpha and terminate the ray.
> For non-camera rays a diffuse BSDF is generated, but that could easily
> solved by adding a BSDF input to the shadow catcher node which allows to
> set a non-camera BSDF. By using an AlphaOver in the compositor, this can
> be easily combined with a suitable background.
> There are two problems with this approach: First of all, it doesn't
> consider indirect lighting such as caustics or, which is more important,
> diffuse light. Therefore, the area around objects on the shadow catcher
> looks slightly darker than it should look. And secondly, the standard
> implementation "calculate both values, divide, set alpha" inside the
> shader doesn't work, because both values must be accumulated separately.
> This could be implemented as an auxiliary internal pass, though, so that
> the division is performed in the buffer code. Still, not as nice and
> clean as I had hoped for.
>
> Another approach is
> http://www.pauldebevec.com/Research/IBL/debevec-siggraph98.pdf, which
> basically works with a difference. However, as far as I see, that needs
> a really precise and accurate scene (for example, in the page 9 example,
> a wrong color for the plane would instantly give weird-colored shadows).
> Also, it produces negative colors in the difference image, which will
> probably cause havoc in the compositor.
>
> So, my question would be: Are there any approaches that might work
> better? Am I overlooking something? If not, would one of these
> approaches be useful?
> Any input is most appreciated :)
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>



-- 
With best regards, Sergey Sharybin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20150212/f627aba9/attachment.htm