Brecht,
>> 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 agree we should encourage users to build shaders with layering. > However, I am not sure what you are suggesting. That instead of a node > system we should restrict the user to a layer system? No. I'm not suggesting that we restrict anybody into any ways of working. But the way stuff are represented in an application help the user build a mental image of the concepts. So if the provided preset, legacy or new, BSDFs are designed and represented like layered BSDF, then the user will get used to this representation and this will guide his eventual attempts at building new BSDFs. On the other hand, is supplied BSDF look like the current material nodes, then the users will try to replicate this model. Just provided well designed examples to start. Right now, the shaders are separated as diffuse and specular (and other) and in the UI, the diffuse shader comes first and then the specular. This does not help convey the idea of layered BSDF. It conveys the idea that a typical shader should have a diffuse and a specular components and this is not true. Diffuse and specular are really just two BSDFs. And they don't need to be both present on a material. For example, a colored transparent lacker over a metal would be better represented with two specular BSDF. Right now, the only way to do that is with material nodes and because each material node comes with all the CG shader hacks together, most of them need to be turned off. Also, layering BSDFs and doing that in a physically plausible way by manually linking nodes setups can become a nightmare. It would be nice to have a Layering node that would take care of a lot of that sort of bookkeeping. like keeping the energy balanced between the individual layers even when taking the Fresnel or the Kubelka-Munk factors into account. This could be turned OFF of course. Again, this sort of automatic handling of things would not be a panacea.and could be overriden or done manually. But having that as an example could show how to approach BSDF building in a more plausible way. It would be nice, BTW, to add an "Energy conservation" checkbox for Phong, Blinn, etc legacy shader. For most of those shaders, we know how to do that. Oh yes... And allow the Spec property to be increased beyond 2.0. This currently make it impossible to manually energy ballance the specular shaders even for someone who knows how to do it and would like to do it. Of course, if someone wants to experiment and proceed any other ways, why not. But this is not the sort of issues I'm interested in discussing. I'd rather focus my discussion on looking for possible issues and solutions for eventually integrating the proposed shading system and its node-based BSDF representation into a physically based rendering pipeline. Make sure the proposed shading system will not prevent building plausible BSDFs and using it in a plausible way if needed. If a photon mapping or a path tracer is integrated in Blender, will we be able to design node-based BSDFs that will work in those rendering contexts too? Will we be able to design BSDF that will work in both rendering context? Will a BSDF designed in a GI rendering context be directly usable in a legacy CG rendering context for quick renders? A BSDF designed around a diffuse shader and a specular shader will it give usable results in a GI rendering context? Those are questions that interest me. >> 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. > > Blending output colors and properties are both possible with a node > setup, and if the latter is better we can try to figure out a way to > do that easier than doing it manually. Blending the Monte-carlo integration process could also be handled with nodes if we had a switching node that would switch between two or more BSDFs based on some static or dynamic probabilities for each BSDFs and a russian roulette when come the time to integrate samples. We don't want to sample both/all BSDF and weight-combine the resulting color. We would want to sample/integrate each BSDF according to their probabilities of contributing. > I was referring to implementation. The node would allocate a BXDF in > memory, fill it in and pass that through to the next node. Using the > BXDF in the integrator then would not refer back to the original nodes > but instead use this constructed BXDF. So you could say it creates > another set of nodes in a way. This is like Material GetBSDF in pbrt. > I'm not sure I'm a proponent of this though, I prefer to just keep > using the original nodes. I will have to go and re-read this pbrt section. It's been 4 years already. >> 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. > > For the pixel, plugging something in the combined node would override > automatically using the BSDF for shading the first hit. So it would > compute lighting with the BSDF in the Light node, and then multiply > that with AO and fill it into the pixel. So I would say the effect is > darkening the light with AO. I'm trying to understand. 1) The BXDF input in the output node is there to pass in the Lambert BXDF back to the Light node. So now, the light node can use this BSDF to compute the color of the hit. This shaded color is then multiplied by the AO. Somehow, I doubt this is the correct interpretation because this would mean the BSDF need to travel backward through the multiply note to the Light. or 2) The light and the AO at the hit are multiplied together and that result is passed to the output node where a Lambert BSDF is waiting to pick that information for shading the hit. But then a BSDF needs a light vector and multiplying the light which is light vector dependent with the AO which is not would result in wrong shading. So I doubt this is the correct interpretation too. or 3) ... I don't know. BTW, I assume that the Light node represents any light in the scene. Or is one Light node associated to only one light in the scene? > It is indeed not the right thing to do physically speaking. The > purpose of that would be to allow some more flexibility to do > non-physical things at the first hit, like you can in e.g. renderman. > What goes into the pass outputs like combined is not a BSDF, but a > color, so it is not restricted to being driven by lights, instead the > material can drive the lights and combine things in different ways. > Evidently that doesn't work for all rendering algorithms. I think I would like to concentrate on plausible node flows. What I feel, here, is that the philosophy is to give all the flexibility that can be possible. Allow any node to connect to any node as long as the input and output types are compatible or there are casting operators/nodes for them. The number of possible combinations of nodes is staggering. So in order to have a productive discussion, I'd like to stay with node setups that make sense physically speaking. One thing that I seem to observe is that the hit to camera needs to be pretty much hard-wired and the light to hit too. Is that right? A couple questions: What would be a minimum node setup for just traditional Legacy CG render of a scene? How are multiple-reflection bounces represented in a nodes setup? Implicitly or explicitly? What would a BSDFs node setup look like if designed to be used in a photon map or a path tracer? Yves _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers