[Bf-committers] Shading System Proposals

[Yves Poissant]

Brecht,

> 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, ...

Yes. I understand. Conceptually, when coding the different passes, it is 
usefull to separate them. It helps divide the problem and conquer it so to 
speak.

> ... but we still want to support diffuse/specular/.. passes.

I agree with that. The way I see it is that this should be intrinsically 
possible with a layered BSDF model. In real materials, specular and diffuse 
components come from different layers of a material too. I seem to recall 
that both you and Matt mention this at some point in your wikis. So the 
coating layer would drive the specular pass and the underlying layer would 
drive the diffuse pass. Given that those are separate BSDFs, the user would 
actually be free to connect the coating BSDF output to the diffuse pass if 
he wishes though.

Typical legacy shaders that combine diffuse and specular actually are 
emulating a double-layer material except that everything is mixed up. Then 
we talk about separating passes from those shaders. This legacy shader model 
made us thinking about this issue in reverse. We should instead think of 
combining the layers instead of separating them. I think it makes the model 
more easily understandable when those "passes" are explicitly separated into 
different layers of BSDFs. And it is nearer to the real thing anyway.

I'm having difficulties seeing how that separated BSDF output thing would 
works for any path further than the camera to material path though. As soon 
as we start accumulating secondary paths contribution, it seems to me that 
this separation starts to get fuzzy since specular component (the coating 
BSDF) from the first hit material receives contribution from everything, 
direct light and indirect light coming from specular and diffuse reflections 
undiscriminately. I think you also acknowledges this in your wiki.

This situation is not only for indirect lighting. Say we are looking at an 
object reflected in a mirror and we see both the object and its reflection 
in the shot. How willl this separation be kept through the mirror? Is the 
reflected image considered totaly specular even if the reflected object is 
partialy specular and partially diffuse? What parts of the reflected image 
will go into the specular pass and in the diffuse pass? If those passes are 
then tweaked in the compositor, how will this affect the reflected image?

My intention is not to prove that this approach should be abandoned. Having 
done production work, I fully understand the need to render in passes and 
tweak in compositor. I mainly want to expose the possible limitations so 
solutions may be examined.

> 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. ...

Yes. I see the point. I wonder if there is not another way of achieving this 
goal though. Blending the output of BSDFs will monotonically blend one 
appearance into another one. This type of blending have the effect of 
temporarily layering two BSDF. Sort of like the inbetween results of a Morph 
blend where we can see both images superposed together.

An alternative way would be to vary the BSDF properties. For instance, 
blending a material into another material could also be done by blending the 
values of a stack of BSDFs properties from one set of properties into 
another set of properties. So one could vary the roughnesses of the coating 
BSDF independently from the roughness of the underlying BSDF and yet 
independently from the absorption of the coating BSDF. They could all follow 
a different IPO curve for instance. This would be more powerfull than 
blending the output. At least, this is a method that should be possible. 
Doing it this way would not produce the superposing effect.

There is a relatively recent paper about mixing BSDF to produce a new BSDF. 
They compiled several BSDFs and the user can vary the appearance by 
manipulating sliders to get a more metalic appearance or a more plastic 
appearance, etc. But they do that by mixing the BSDF properties. Not by 
mixing the BSDF outputs.

> ... 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.

Yes. I understand. I'm not trying to say that simple output blending should 
not be available. There are a ton of situations where we wouldn't need the 
power of blending BSDF proporties. This is fine for animating transitions 
for instance. But when the intention is to produce a different BSDF from 
mixing two BSDFs, I believe that a better result would be achieved by mixing 
the BSDF properties.

So blending BSDF, I agree. I see three ways to do that: 1) blending the 
output colors, 2) blending the monte-carlo integrations. and 3) blending the 
BSDF properties.

> 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.

I'm not sure I understand this one. What do you mean by "Letting the node 
setup create a BXDF"? The user can create a BSDF with a set of nodes? Or a 
set of nodes is designed to produce a BSDF object (or data type) in the form 
of another set of nodes? Or a set of nodes is designed to tweak one of the 
preset BSDF nodes?

> 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. ...

I don't understand what this node setup is doing. Can you explain? You say 
that the BXDF is used implicitly in the Light node. From that I deduct that 
the color output from the Light node is the result of processing the light 
through the BSDF. Is that correct?

What do you mean by "BSDF don't have access to colors that are already lit?"

Otherwise, if I interpret verbatim what I see in those nodes, The light 
color at a hit point is multiplied by the AO factor at the same hit point 
and this is writen in the combined pass. This have the effect of coloring 
the AO with the light color. Then the Lambert BSDF does its shading 
calculation for the same hit point and writes the resulting color in the 
bxdf pass. Later, through compositing, I can combine them.

I guess this node setup is being evaluated for every pixel?

Sorry for so many questions but I feel my miscomprehension of those issues 
is what gets in the way of getting in line with the shading system proposal.

> ... 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. ...

To me, a BSDF interacts with light. That is the fundamental purpose of BSDF. 
It receives light and output reflected light. When I read "multiple Light 
nodes driven by multiple BXDF's", I'm lost. It seems like the reverse of the 
logical thing to do. Lights are what drives the illumination in a scene. 
Lights are not driven. So there seems to be some fundamental assumptions 
behind such a sentence that I am missing and I'd like you to elaborate on 
that.

> I don't think they are only adding color values, how else would they
> sample diffuse + highly specular materials with any efficiency? ...

>From their document "understanding" (Understanding mantra rendering), it is 
obvious that efficiency is not their main concern. Read the section "== 
sampling ==", their description of the sampling methods between the 
micropolygon render and the raytrace render. Their sampling methods are not 
intelligent at all. Search for "10 million" in this document and read their 
example about the 10 million polygon object seen from a far distance. That 
is why I believe they only mix the output and the BSDF has already done its 
deterministic sampling.

> ... But what they do doesn't matter that much to me.

To me neither. I mean, I don't want to keep on speculating on what they 
might do or not. I'd like to get the input from a real Mantra/VEX user 
though.

> 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.

Yup. This will work.

Yves