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.
From: "Matt Ebb" <[email protected]> > I've done some research on this, and I think I have a fair idea of > what's going on in there. I actually suspect it's quite similar to > what I was toying around with before [1]. Rather than containing > merely values, the brdf type probably contains some function pointers > to pre-made functions (i.e. lambert distribution, phong distribution, > etc), since that's really the only way to represent a Scattering > Distribution _Function_. You are about on the same page as I am there. I agree with your BxDF type model. But I don't think the Houdini BSDF (pbr or not) is anywhere near that sophistication though. > It also contains some other flags to say what > kind of scattering it can represent (diffuse, glossy, specular, > emission) etc, ... That is an interesting idea. I never thought of that. I mean I never thought of having a sort of library of scattering functions that could be used by a BSDF. It is not yet clear how this could be used though. It is common to use an appproximation of the true distribution function to generate the sample directions and scale by the probability of the approximated distribution but this is usually done in a controlable way to make sure there are no large discrepancies between the true distribution and the approximated one that may cause severe sampling artifacts. Usually, the approximated distribution is carefully selected to fully cover the whole range os the true distribution for the whole range of the BSDF parameters.. Why do we need an "emission" scattering type? > ... and probably some custom data to represent bsdf > parameters (like a glossiness slider). And/or an input so the glossiness can be varied spatially or temporally. > I'm guessing this via a few VEX functions: > * sample_bsdf() [2] that takes a bsdf, 2d random samples, and shading > geometry as input, and returns an outgoing vector - eg. for lambert a > cosine weighted vector in hemisphere, and You mean a cosine weighted distribution? For a lambert, the probability distribution is constant so it would be uniformly distributed over the hemisphere. It is indeed a good approach to pass in a uv coordinate and have the BSDF compute a direction from that. This way, we can avoid sampling corelation artifacts that can produce interesting moirés and lisajous effects but are undesirable in real rendering situations. In a path tracing approach, every bounce should use the sampling points from 2 dimensions further of a multi-D sampler (Sobol for example). > * eval_bsdf() [3] which takes a bsdf and shading geometry input and > returns a colour (proportion of light that's reflected) - eg for > lambert, L.N . In this case, the cosine weighting that comes from the dot product is correct because we are calculating the irradiance while in the case of sample_bsdf(), the cosine weighting is implied by the fact that the surface is bombarded by samples and the sample densities on the surfaces are intrinsically cosine weighted. That is why the cosine weight is not needed when we sample. > These above functions would basically just execute the bsdf callbacks > with the input information. Yup. > As for how it mixes bsdfs, some ideas are either it somehow > dynamically generates new distribution function callbacks that > represent multiple combined distributions (which i seriously doubt) Me too I doubt. Although it is feasible to mix both the reflectance and the distribution, I can't see any way to use the resulting distribution in an efficient way. I mean, how could we mix importance sampling strategies? > or it uses some kind of internal layering/stacking system where it keeps > track of what BxDFs make up the entire BSDF, and with what weights. 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. >> I can think of a few ways to do this using a node tree, doing the >> computation F by evaluating nodes with some entirely or partially >> excluded, and doing sample distribution by picking randomly from >> distributions provided by nodes that contain a BXDF. > > You don't want to do it randomly, it should be weighted it based on > layering - a probability per BxDF component. So for example if you're > shading a glass shader with perfect specular BRDF and specular BTDF, > blended via fresnel, then if the incoming ray is at glancing angles, > there's much higher probability (fresnel function) of picking an > outgoing vector based on the BRDF, not the BTDF. Yup. I agree with that. >> Another >> possibility would be to pass a long a BXDF type through nodes, then >> for example a mix node could create a new BXDF that can do more clever >> importance sampling. Neither seems particularly elegant or transparent >> to the user to me, but I can't think of good alternatives at the >> moment. > > That's basically what Mantra PBR does, explicitly with the bsdf data > type/node connections. The output node has a bsdf input, so for > situations where you just need to find an outgoing scattering > direction, you a) get the final bsdf arriving at the output via the > node tree, and b) pass that final bsdf to the sample_bsdf() function. Mantra bsdf data type is very basic and their functionalities are constrained to their model of shading. When they do micropolygon pbr, they shoot a user defined number of secondary rays from the micropolygon vertices and when they do raytraced pbr, they shoot a user specified number of secondary rays from a user specified number of pixel samples. Their sampling strategy is globally defined. Not on a per BSDF basis. What the BSDF can do, in addition to returning a color, is return a sample direction from a UV coordinate. That is already more than just returning a color but is insufficient for implementing bidirectional path tracing for instance. Their pbr shading strategy is only a path tracing from the camera into the scene. They supply a set of BSDF such as Phong, Ashikhmin, etc. with very easy to implement direction warping function so their sample distribution exactly match their pdf and their BSDF don't have to provide a probability along with the sampling direction. Bottom line, I'm not impressed by Mantra, pbr or not and I'm not ready to glorify their system. > The more I understand about this, the more I really think it's the > right way to go. They've really done an excellent job coming up with a > modern system, without the 90s trappings, and with the flexibility of > programmable/editable shading. I'd really like to see Blender head > down that path too as a design that will serve us for the future. 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. 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. Yves _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
