From: "Brecht Van Lommel" <bre...@blender.org> > To get some discussion started, here's two things I'm still unsure > about, extracting a BXDF from node trees and the future role of the > texture stack.
Sorry to come so late in the discussion. Reading all the posts, here and the project wiki pages as well as several pages of the Houdini documentation takes time. And I found myself having difficulties getting on the same page as the discussion. In retrospect and as I form a better mental model of the issues at stake here, I think my difficulties come from different assumptions behing some terms and concepts. But I want to participate in the discussion so here is a start of contribution. > Matt proposes a Sample_F output here but it's not entirely clear to me > how this works, I also couldn't understand from the Houdini > documentation for example if their BSDF F value is just a > vector/scalar value ... >From what I read in the Houdini documentation, the VEX node system related to shading, even PBR, is pretty basic and I would even say old-school. To answer the above question, the Houdini documentation page "Understanding Mantra rendering", there are two snippets of code that reads as F = texture(map) * diffuse() + 0.5 * phong(20); and F = diffuse() * (1.0, 0, 0) That definitely looks like a standard legacy CG shading function. And it is interesting to read their use of "BSDF" in this context. Anyway, it is clear that F type is a RGB vector. > ... or also contains information on how to sample it. I don't know of any BxDF representation that could provide an external function some information on how to sample it. At least not in any efficient manner. This is something I've been thinking about for quite a while and I think that this cannot be done. The best a BxDF can provide to help in this regard, is a warping distribution function that can map a 2D sample point to a direction. Given the state of knowledge about BxDF, that is currently as far as we can go. And this can be implemented in so many ways that it is not exportable. That said, I may misunderstand the sentence because it looks like a mix of concepts. From an implementation POV, we can view a BxDF like a black box that takes some inputs and provides some output. That would fit with the idea of a BxDF as a node. Some of the services a BxDF can provide are: 1) Given a hit point, an incident vector and an excitant vector, provide a reflectance value 2) Given a hit point, an incident vector and a uv point, provide the direction (from a uv to direction maping), the probability of this direction and the corresponding reflectance. I will not go into much more details about that here right now because it needs to be elaborated much more but the idea is that an implementation of a BxDF needs to provide a few services and that those services are all related although that may be called in different circumstances from different shading pipelines. Those services are required by a practical implementation but are usually not discussed in BxDF literature and I think this is those services that are of interest here. Am I right? > 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, This is a place in the discussion where I have problems following. Can you provide usecases where nodes are entirely excluded and where some are partially excluded? > and doing sample distribution by picking randomly from > distributions provided by nodes that contain a BXDF. "Nodes that contain a BxDF" - I believe you see the BxDF as a data type here. Is that right? If we are dealing with multiple distributions and want to combine them, then a way of doing that is through a russian roulette. > 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. Mixing BxDF can be done in different ways depending on the service provided. Mixing the F value requires a simple vector mixing but mixing the distributions require a russian roulette. This is all doable. But I can't see a way, from those mixes to do more clever importance sampling though. > Neither seems particularly elegant or transparent > to the user to me, but I can't think of good alternatives at the > moment. What is the problem that you are trying to solve with this BxDF mixing here? > The texture stack is obviously limited in what it can texture. Nodes > provide a solution here, but the texture stack is still convenient. So > what is the role of the texture stack, do we try to fix it, and if so > do we make it more flexible like allowing to texture nearly > everything, or maybe we just leave it as is mostly and do a few small > tweaks? This is a part that is too implementation related for me to really understand and help. But as a general rule, I would say that textures should be usable for anything. Not only the traditional shader channels but any user defined channels too. For instance, there is this group, (the name McCool comes to mind) that designed, a few years ago, a way to separate BRDF parameters into a set of bitmaps and drive BRDFs on the GPU. Those bitmaps are only usable if interpreted as BRDF parameters. Another usage is if we want to have spatialy changing BxDFs. There already exist spatially varying BRDF around. This is nice for decorative object with mixed painted materials or tissues with mixed threads types of any mixed type surfaces. Yves _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
