[Bf-committers] Shading System Proposals

[Brecht Van Lommel]

Hi Yves,

On Tue, Jan 5, 2010 at 4:57 AM, Yves Poissant <ypoissant2 at videotron.ca> wrote:
>> 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.

I would like to keep the amount of functions as small as possible. But
I can see a separate pdf function is necessary for some algorithms. I
gets a bit tedious having to define all those things to create a bxdf
node, but perhaps there is no way around it.

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

Right, I think the random number or the sampler should indeed be
provided by the caller.

One thing that occured to me is that for an arbitrary node setup you
may need more than two dimensions. In pbrt it seems there are always 3
random numbers passed into Sample_f, which works if you have for
example one mix node + some individual bxdfs plugged into it, but
doesn't generalize to an arbitrary node setup, as you can't reuse
those random numbers. So I guess we need to take that into account as
well somehow.

>> * 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?

It is the rho function from pbrt. I think this is needed for
importance sampling, and also to compute the color pass (at least I
hope it will work well for that).

Brecht.