[Bf-cycles] Shadow Catcher BSDF

Marc Dion marcdion1974 at gmail.com
Thu Feb 12 20:47:09 CET 2015


If this can be handled by a hybrid Emission/Diffuse shader than it can also
be used for animated scenes which use baked assets for the background
objects without the need for compositing.

I think this problem is mostly the same for cg scenes that use some baked
assets and scenes that mix cg with real camera footage.

A BSDF which mostly has the characteristics of an Emission shader but which
can receive shadows without self-shadowing will solve both problems without
introducing multi-stage compositing hassles.

With a pure white sky (1.0, 1.0, 1.0) and materials that are also set to
(1.0, 1.0, 1.0), we almost have a shadow catcher without any compositing at
all.  The only problem with the following image is that the background
self-shadows when it should only receive them.  Otherwise it would be pure
white everywhere but for the monkey's shadow.

[image: Inline image 1]
(i)  The BSDF should be unaffected by the scene lighting color/intensity
just as an Emission shader would be
(ii)  It should also exclude self-shadowing the same with an Emission
shader.
(iii) It just has to accept shadows the way a Diffuse shader would.  This
could offer a fairly substantial performance increase over standard Diffuse
BSDF since at least two major factors of the lighting calculations are
being excluded.



As a compositing option I think the following works but the main CG
elements may have to be tagged somehow so they would not appear in one of
the two required render passes.

One pass has all the objects and the other pass has only the background
which will catch the shadow(both passes are rendered pure white for
everything).  The second pass has it's color inverted and is mixed with the
first using 'Color Burn'(in PS 7.0)


[image: Inline image 2]







On Wed, Feb 11, 2015 at 11:01 PM, Sergey Sharybin <sergey.vfx at gmail.com>
wrote:

> 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
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20150212/02577f6a/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1passAlmostShadowCatcher.png
Type: image/png
Size: 38244 bytes
Desc: not available
Url : http://lists.blender.org/pipermail/bf-cycles/attachments/20150212/02577f6a/attachment.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: colorBurn.png
Type: image/png
Size: 109663 bytes
Desc: not available
Url : http://lists.blender.org/pipermail/bf-cycles/attachments/20150212/02577f6a/attachment-0001.png 


More information about the Bf-cycles mailing list