[Bf-committers] Shading System Proposals

[Yves Poissant]

Hi Brecht,

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

> What
> 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 
sophisticated ones.

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

Yves