As I understand it, a "closure" is the thing passed out of those green dots on the ends of those magic black boxes known as "shaders":

enter image description here

I've vaguely imagined that they somehow described a sort of "probability density" of the possible directions an incoming ray could bounce towards, and maybe an albedo for each color channel
(R, G ,B).

What really makes up a "closure"?
And how can you make your own via OSL?

Inspired by this question: What can a custom cycles shader do?

  • $\begingroup$ In terms of OSL a closure is an expression or a function call that will be stored along with necessary contextual information... A closure is a generic holder for any type (data or functions)... Good read: thhube.github.io/tutorials/osl/osl.html $\endgroup$
    – p2or
    Jul 29 '16 at 8:51
  • $\begingroup$ I think taht is another (more general) type of closure, the usual closure term of programming languages. $\endgroup$ Jul 29 '16 at 12:09
  • $\begingroup$ @RóbertLászlóPáli, yes but this is the same principle : a function (or a lexical scope more precisely) and all that this function 'knows'. It's parameters and local variables and other more global other elements (other variables or functions) it can access during it's execution. $\endgroup$
    – lemon
    Jul 29 '16 at 13:29
  • $\begingroup$ I think I was not clear. I ment, that the closure Poor was referring to (the one that is the usual term of programming languages) is another closure, than in the question. $\endgroup$ Jul 29 '16 at 17:23

A closure is a computer science term for a package consisting of a function call and any other information (concrete values of arguments, etc.) needed to execute it later, AS IF in the current context.

In OSL, this is the data type of the thing that the shader network hands to the renderer to describe the properties of a surface or volume at a particular point.

You can think of it as a BSDF (although it can include other information that the shader can pass to the renderer). But the BSDF is not evaluated at the time that the shader is run -- instead, the renderer runs it later, and in fact internally there is not a single method associated with it, but rather it knows how to do a number of things, like choose sample directions, evaluate the amount of light scattering from one direction to another (with supplied with those directions), and so on.

An OSL shader can assemble a closure out of built-in "closure primitives" -- a closure may specifically be a weighted sum of the primitives -- but the actual primitives may not (currently) be authored in OSL itself. They are a part of the renderer, largely because their correct and efficient implementation seems to need to reach deeply into the guts of the renderer internals, which is precisely what OSL shaders are NOT supposed to be concerned with. Each renderer will document a number of BSDF closure primitives that it supports, which may vary from renderer to renderer. At present, there is not a strictly dictated list of which BSDF primitives you can count on in OSL, partly because BSDFs are still a hot research topic, with new and better ones getting published all the time. It doesn't seem stable enough to enshrine in the OSL language quite yet.


I think what you are asking of are the functions also called BSDFs, BRDFs, BTDFs or BSSRFs. More about these terms at this Wikipedia page. They are referred to as closures in OSL terminology, because they are implemented as closures in the programming language.

And how can you make your own via OSL?

This might help.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.