Hi,

First, let me say thanks for releasing this as open source, it's
looking very impressive. I'm working on the shading system in Blender
and was looking into how this design compares to what I'm planning and
how I could make my implementation compatible such that OSL could be
plugged in at a later time.

I have a question that I couldn't find an answer to in the
documentation or source code. The BSDFClosure has eval_reflect,
eval_transmit and sample functions. Some rendering engines have an
additional function to compute the average reflected or transmitted
color independent of the incoming light direction, by the integrating
the bsdf over the incoming light direction without any lights. In PBRT
for example this function is called rho.

There are a number of uses for this:
* Compute surface albedo, i.e. "unshaded color", to output as a pass
for example.
* Compute surface opacity (by doing this for transmission), useful as
a pass for compositing, rasterization with alpha or transparent
shadows.
* Importance sampling by picking one of two blended bsdf's
proportional to this.

It would be possible to compute this value by doing the integration
each time, calling the sample function a number of times, but this is
not as efficient as it could be. Or these values could be manually
provided by the shader writer. Maybe there is another way to do this
that I'm missing, or perhaps it was left out intentionally, or not
implemented yet, ..?

Thanks,
Brecht.

Apparently I can't post here from my work address, so resending. Sorry
if somebody gets a duplicate.

Hi Brecht, I'm Alejandro Conty (jandro in the old blender days), we
met
several times at the Blender conference. Nice hearing from you about
this.

I have a question that I couldn't find an answer to in the
documentation or source code. The BSDFClosure has eval_reflect,
eval_transmit and sample functions. Some rendering engines have an
additional function to compute the average reflected or transmitted
color independent of the incoming light direction, by the integrating
the bsdf over the incoming light direction without any lights. In PBRT
for example this function is called rho.

I understand the main use for this is importance sampling. I'm afraid
I'm not allowed to say how we do things here at imageworks, but there
are other ways to do importance sampling. That function would make
things easier, of course, the problem is that not all BSDF's can be
easily integrated. The expensive method is not an option, it would be
overkill. So you need an analytical solution which is not always
available.

There is also a practical issue too. We have this sample function
that
has to return a normalized PDF and so. It turns out that people find
it
very hard to implement it in some cases. Even when the PDF doesn't
have
to match the BSDF exactly. So adding that extra function could be
asking
for too much. But the discussion is open and you are wellcome in.

Let's see what the other guys think about this ...

Alex

On Jan 14, 2010, at 9:31 AM, Alex Conty wrote:

Apparently I can't post here from my work address, so resending. Sorry
if somebody gets a duplicate.

If it's just a case of the message bouncing because it doesn't know you (at work) are a member of the group, try signing up for a second googlegroups membership, using your work address, and check the box that says "web participation only, no email". That will make it accept emails from you but not send you duplicate emails to both your work mail and your gmail account.

I have to say, one of my main annoyances with google code hosting is that so many things require "google credentials" rather than one's normal home or work email and userid.

--
Larry Gritz
l...@...

Hey Alejandro!

Great to hear from you, I had no idea you were involved in this
project.

On Jan 14, 6:31 pm, Alex Conty <a...@...> wrote:

I have a question that I couldn't find an answer to in the
documentation or source code. The BSDFClosure has eval_reflect,
eval_transmit and sample functions. Some rendering engines have an
additional function to compute the average reflected or transmitted
color independent of the incoming light direction, by the integrating
the bsdf over the incoming light direction without any lights. In PBRT
for example this function is called rho.

I understand the main use for this is importance sampling. I'm afraid
I'm not allowed to say how we do things here at imageworks, but there
are other ways to do importance sampling. That function would make
things easier, of course, the problem is that not all BSDF's can be
easily integrated. The expensive method is not an option, it would be
overkill. So you need an analytical solution which is not always
available.

I incorrectly interpreted what would actually be given to the
renderer, I thought it would be a single bsdfclosure that somehow
included additions and multiplications, but looking at the source code
more closely, it's a weighted sum of different closures. That leaves
importance sampling and other things more to the rendering engine, so
that solves my question. I was assuming otherwise because this imposes
a limitation on how you can combine/manipulate closures, but I guess
there's still closures written in OSL that could be used to get around
the limitation.

Thanks,
Brecht.

Great to hear from you, I had no idea you were involved in this
project.

Well, is Larry's baby. I'm in the group that makes the render using
OSL.

I incorrectly interpreted what would actually be given to the
renderer, I thought it would be a single bsdfclosure that somehow
included additions and multiplications, but looking at the source code
more closely, it's a weighted sum of different closures. That leaves

That's right.

importance sampling and other things more to the rendering engine, so

Yeah

that solves my question. I was assuming otherwise because this imposes
a limitation on how you can combine/manipulate closures, but I guess
there's still closures written in OSL that could be used to get around
the limitation.

That's more of a question for Larry. I know osl closures are in the
roadmap, but he is the one to talk to about this.

Alex

On Jan 15, 2010, at 8:55 AM, brecht wrote:

but looking at the source code
more closely, it's a weighted sum of different closures. That leaves
importance sampling and other things more to the rendering engine,

Yes, exactly.

but I guess
there's still closures written in OSL that could be used to get around
the limitation.

It's in the road map to eventually allow closure primitive functions and integrators to be written in OSL. But for now, both are built into the renderer.

--
Larry Gritz
l...@...