[Bf-committers] Shading System Proposals

[Brecht Van Lommel]

Hi Yves,

On Tue, 2009-12-15 at 22:45 -0500, Yves Poissant wrote:
> I think I would prefer that we use the term BSDF instead of BxDF. BSDF means
> the unification of the BRDF and the BTDF while BxDF means that we don't know
> which one of those two we are dealing with. I can see that separating both
> may be desirable for flexibility purposes. But I think that seeing them as
> separate and implementing them separately can only lead to difficult to
> solve issues eventually. While seeing them as unified can allow someone to
> use only the transmissive part of ot or only the reflective part or both in
> combination.

It's just terminology, I don't mind calling it BSDF, the intention was
never to present the user with separate BRDF and BTDF node trees. The
reason I called it BXDF is because depending on the pass being
rendered, we may actually be dealing with a BSDF/BRDF/BTDF. For the
combined pass of course there would be only a BSDF, but we still want
to support diffuse/specular/.. passes.

> There is a usecase I can relate to. To me, layering BSDF makes sense.
> Multiple layer materials are pretty common and it makes perfectly sense to
> model this through a form of layering or stacking of multiple BSDFs.
>
> On the other hand, I don't see what type of problem the "mixing BSDF" model
> is trying to solve and I would like to read usecases of that.

There's plenty of use cases for mixing them, when you want to blend
from one material to another, or varying the material using a texture,
etc. But the point is that we are not restricting ourselves to
physically motivated use cases. We get a node setup created by a user,
and have to deal with that somehow, even if it is a "legacy" material
or doing something that makes no sense physically, a mix node with
different blending nodes is just a basic feature of any node shading
system.

> I'm far from being convinced that a BSDF data type is feasible. I can easily
> see a BSDF node though. I can see its inputs and outputs and its
> functionalities. But I can't see that as a data type that can be passed
> around through nodes. I can't see how such a data type could be used at some
> point in a noodle soup. I can't see why that would be usefull either. What
> type of problems is this passing around a BSDF data type is supposed to
> solve? Why would you need to pass a BSDF around? Why is it more usefull to
> use it "there" instead of "here"? If I need to transform data before feeding
> it to a BSDF, then I can do that through nodes. I don't need to pass the
> BSDF through the nodes. Lots and lots of questions.

Letting the node setup create a BXDF and using that for rendering
(which is similar to pbrt materials), or evaluating the actual nodes
while rendering would really be equivalent when it comes to physically
based rendering algorithms.

Where it becomes useful is when you want to do non-physical things,
like this node setup:
http://wiki.blender.org/uploads/1/1d/Shading_nodes_C.png

In that graph it is using the BXDF implicitly in the Light node, so
not necessarily passing it along between nodes. If we were passing
along a BXDF type it would allow you a bit more flexible setups, in
that you could have multiple Light nodes driven by multiple BXDF's
setup and mix the results of those. I'm not sure if it is worth it
trying to support that use case and I consider this really a detail.
In terms of how you would actually implement nodes or use them in an
integrator, this would make no real difference, just slightly
difference looking code for implementing nodes.

> I have not been able to figure with certainty how a BSDF data type is used
> in VEX either. I think I'm on the same page as Brecht on this issue. In the
> video where we see that noodle where multiple BSDF are being added together,
> it seems to me that it is highly probable that they are only adding color
> values. Just like the typical legacy CG shaders and their noodle fits
> exactly this model too. They feed a BSDF for the diffuse part, add a BSDF
> for the glossy part and then add a BSDF for the specular (mirror) part. This
> model rings so many bells (you know I = kd*D()+ks*S()+kr*R()) that it is
> hard to imagine that this is doing anything fancier than just adding colors.
> So the different BRDFs can use multiple sampling to derive their respective
> shading but I believe that their outputs are nothing more than colors.

I don't think they are only adding color values, how else would they
sample diffuse + highly specular materials with any efficiency? But
what they do doesn't matter that much to me.

Passing along a vector, and having mix/layer nodes pick randomly from
inputs is simple and pretty much what pbrt does. So I know individual
BXDFs + mixing/layering in a node setup will work.

If we don't succeed making difficult cases like color ramps or curves
sample well then users will just have to live with that, don't use
these when you want to do physically based rendering with some
efficiency.

Brecht.