diffuse closure

[Viewon01]

Hi,

I see that for diffuse closure you use cosine sampling for the
hemisphere and use :
f = N.Wi/Pi
pdf = N.Wi/Pi

But it should be
f = 1/pi
pdf = N.Wi/Pi

Or I have miss something ?

[Viewon01]

I suppose that you already compute the N.Wi of the illumination
equation there, simply ?

Thanks

[Alex Conty]

Yes, we put that term inside the closure to avoid dividing by it (and
then multiplying in reflective like BSDF's. But since the
implementation of the closures now is up to the render, you can change
that and do whatever is best for your app.

Alex

[Viewon01]

No, its fine :-)

Also, in the phong shader, in the "eval_reflect" method you write :

float cosRI = R.dot(omega_in);
float common = 0.5f * (float) M_1_PI * powf(cosRI, m_exponent);

But the phong model is :

(I.R)^n where I is the incident ray and R the reflected one ! So, if I
understand your code "omega_out" is the incident ray and "omega_in" is
the sampled ray ?
(I say this because I see that the "sample" method update the
"omega_in" vector).

Is it right ?

Thanks Alex

[Viewon01]

Sorry, I'm asleep !!!

You use importance sampling of course :-P

NO COMMENT :-D

[Alex Conty]

We picked up the convention that "in" means incoming light. So
omega_out is the vector pointing to the viewer and omega_in would
point to the light source. Therefore when doing regular pathtracing
from the camera we sample omega_in every time we hit a surface
(looking for indirect light).

But those closures are quite outdated, we don't use them anymore. They
are there just to give some examples of how they can be implemented.

[Viewon01]

Thanks Alex,

What I see in your closures is that you sample omega_in... the light
direction !!! So, you assume you are in a path tracer (eye->light) and
not a bidir-path-tracer (light->eye), which sounds more natural :-P
But, anyway it is just a question of convention ;-)

Also, I have notice that you have describe in the "osl specification"
some closures (dielectric, oren-nayar) but they are not implemented.
On the other sire, I see several other closures that are not in the
specification (Westin, ...)

So, maybe you can update the specifications ? Theres are interesting
closures to implement, even if optional !

Regards

Krys

[Alex Conty]

We picked up that convention just because most raytracers are written
this way. But you can just call the sample functions swapping vectors
and it would work. Our BSDF's should be just SDF's cause they are not
bidirectional, but the sample functions should be.

Anyway we changed the way closures work to be completely driven by the
renderer so you can have your own BSDF api. I would completely nuke
the builtin set, but Larry feels there should be some default
implementation. I agree with that for some basic ones like diffuse to
show the idea, but I don't see why we have to mention anything like
westin or cloth.

I would rather start a minimal opensource renderer with its own BSDF
set separated from OSL. But nobody has time, etc ... Looking for
volunteers.

Alex

[Viewon01]

Thanks Alex,

I have my own closures ;-) Simply because I run everything on the
GPU ! I just look at your code... to learn ;-)

My problem is that I don't completely use the OSL code (Just the lexer
+parser), the remainder is home-made !
But I would like to completely follow the OSL specification, for me,
it is interesting to have a "standard" and to be able to
get a shader from my renderer, and use it as is ... in your renderer
by example !

I intend to create a "online" repository with a set of OSL shaders...
freely available of course !

For this, I have to follow the OSL specification, but by example, I
have write a phong-anisotropic closure... and of course I can have
different closure signatures !
If a day you don't use the same signature, we will not be able to
exchange our shaders :-(

So, for me more closure you add, better it is... but it will be fine
to have (at least) an appendix with "optional" closures,
functions,...

Also, for the implementation, it is still interesting to have more
closures, some allow to test some "side effects" of our renderer ! As
you know every material is different and can have different effect
when a bug is introduced ! So, it is always good I think.

Thanks again

Krys