[Bf-committers] Shading System Proposals
ypoissant2 at videotron.ca
Tue Jan 5 04:57:40 CET 2010
>> 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
>> even when taking the Fresnel or the Kubelka-Munk factors into account.
>> 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.
>> having that as an example could show how to approach BSDF building in a
>> plausible way.
> The idea would be to have presets that control some node setup, so
> we'll have to figure out good presets and nodes needed to build them.
> I don't have a overall picture of which ones would be needed yet.
I will try to sketch some node setups to illustrate how I see that.
> I'm interested in for the design is, what kind of informations needs
> to flow between nodes for such energy conservation to work for
> example? Currently my thinking is that we need:
> * eval: given in/out vectors, return color
> * sample: given in vector, return out vector + pdf
It might be useful for multiple importance sampling and more generally for
more flexibility, to have two functions: sample(...) and pdf( wi, wo ).
Sample may set the returned pdf value but having a separate function to get
the pdf given a wi, wo pair is also very usefull.
Also, in my experience, letting the BSDF compute the wo must be done with
care. It is not a good idea to let the BSDF have its own independent sample
generator. If two different BSDF sample generators are corelated for several
consecutive paths, this can (and generally will) produce moiré or lisajou or
caustics artifacts. A strategy that works well is to use a
multiple-dimensional sampler per path and you need as many (times 2)
dimensions as there are bounces in your path. Each bounce requires 2 more
dimensions. For example you need dimension 1 and 2 to sample the light
surface and 3, 4 to sample the direction from the light surface. Then you
would need dimensions 5,6 to sample the bounce direction from the BSDF on
the hit point, etc. Sobol sampler can do that by using different prime
numbers for every dimension. This strategy can be hard coded in the BSDF but
it would be more flexible in allowing someone to develop different path
sampling strategies if another sample() function could take u and v
parameters and use those with a warp function to sample the distribution.
> * intensity estimate: given in vector (or not)?, integral over
> outgoing directions
Not sure what this is for. Is this equivalent to the rho function from pbrt?
Or is this like a final gathering function?
> But that might not be enough for all possible setups?
I've been turning that in my head for a while and I think this can be
considered the basic toolbox. From those functions, one can build more
I will reply to the rest of your message later.
I brought the pbrt book with me during the holidays hoping that I would have
time to re-read the BxDF / BSDF and their sampling related parts but I did
not have much time to do that. I actually got stuck on some implementation
differences between how I do that stuff and how pbrt authors do it. I think
pbrt is a very good reference and it has the merit of being public so I
would like to refer to it instead of to how I do that stuff. But I will have
to delve a little deeper into the pbrt "culture".
More information about the Bf-committers