Re: blackbody and daylight functions

Larry Gritz

We are always interested in PRs that propose and implement new standard OSL functions that are broadly helpful to shader writers. Shy of making an "official" standard library function, we can also simply include sample shader code with the OSL distribution (this may be better for something that's useful, but that perhaps we can't agree that there is one true way to do it).

As Mitch alludes to, there are several computational models that have been published for sky color, and they are usually more complex than merely the raw daylight color temperature -- they are a complex function of position on earth, time of day and year, direction, and atmospheric conditions. These have even been implemented in OSL (though I don't know if any are published). I don't know what the debate would be like in choosing one that everybody could agree on, but if there was consensus that a particularly good one should be part of the language, or like I said as an example for us to ship even if not a language feature per se, we would be happy to receive that submission.

On Jan 9, 2021, at 10:22 AM, Mitch Prater <mprater@...> wrote:

[Edited Message Follows]

Excellent question Chris - thanks for raising it!

The short, and I believe "standard" answer to such questions, is that if OSL doesn't currently provide functionality you desire, you can implement it yourself either using OSL shader code, or by adding that functionality to the language so that it can be incorporated into the OSL repository, or just within your own rendering system implementation if you prefer to not make that public.

The long answer is that color science and its application within lighting, shading, and rendering systems is a fascinating topic and obviously one that deserves a great deal of attention. OSL is fundamentally however, a programming language only. Questions of what color is, how it's controlled, represented, processed, displayed, and finally perceived is more within the purview of the CIE, Open Color IO, and the implementers of your rendering system. OSL in its current form represents color as a 3-tuple, so its ability to process color is constrained to quantities that can be represented by that data type (and the underlying assumptions about the orthogonality of those values). But, since shading is fundamentally a process of generating color, it's absolutely valid to raise the question of how much of the definition of color should be a part of the language and how to manage and implement it. As spectral representations of light make their way out of research and into production renderers, this topic deserves more discussion.

But I digress. The ability to specify a "daylight color" as a function of a temperature value certainly sounds useful. It does bring up the question as to what the atmospheric filtering consists of, and whether you'd want the ability to control that instead. The sun's output is actually constant, so its illumination on the ground is completely a function of the atmospheric conditions and the sun's path through it, so using a temperature value might not be the most useful physically-based control. Pixar had implemented just such an atmospheric light source many years ago. I seem to recall it having been presented at Siggraph, but I can't say for sure.


Larry Gritz

Join to automatically receive all group messages.