3Delight supports all the required functions to properly run OSL shaders. That being said, the philosophy of writing OSL shaders for 3Delight differs very slightly from other renderers. In a nutshell, the 3Delight rendering core is organized so that OSL shaders can remain as abstract as possible. For example, it is discouraged (and indeed wrong) to use functions such as backfacing() to write shaders. Also, some shadeops have seen their definition slightly changed to simplify shader writing or to allow 3Delight make a better job at sampling the final image.
Differences in Form
Consider the following simplified "glass" shader and compare it to the "glass" shader distributed with OSL:
| 3Delight | Other Systems |
|---|---|
surface glass
[[ string help = "Simple dielectric material" ]]
(
float Ks = 1,
color Cs = 1,
float eta = 1.5
)
{
Ci = Ks * reflection(N, eta) + Cs * refraction(N, eta);
}
| surface glass
[[ string help = "Simple dielectric material" ]]
(
float Ks = 1,
color Cs = 1,
float eta = 1.5
)
{
float _eta = backfacing() ? 1/eta : eta;
Ci = Ks * reflection(N, _eta) + Cs * refraction(N, _eta);
}
|
As you can see, there are no fresnel terms and no backfacing() call. 3Delight will take the proper decision, based on many factors including the fresnel factors, to properly sample the surface.
Supported Closures
3Delight supports all the most advanced closures. Some of the BRDF went through extensive research in order to extend them beyond the original specs. As an example, 3Delight's GTR can also model refractions, allowing to render realistic frosted glass and other effects.
| Closure | Description | Ray Types |
|---|---|---|
| microfacet – ggx | Models isotropic or anisotropic GGX BRDF. This model can handle reflection, refraction or both at the same time. | reflection, refraction, glossy |
| microfacet – gtr | Models isotropic GTR BRDF. A "gamma" parameter can be supplied to control the "tail" of the highlight to model highly realistic materials. | reflection, refraction, glossy |
| microfacet – cooktorrance | Models an anisotropic Cook-Torrance BRDF. | reflection, glossy |
| microfacet – blinn | Models a Blinn specular BRDF | reflection, glossy |
| oren_nayar | Models a diffuse reflector based on the Oren-Nayar model. | diffuse |
| diffuse | Models a diffuse reflector. | diffuse |
| reflection | Models a perfect reflector. Note that fresnel factor is automatically computed by 3Delight. If no fresnel component is wanted, one can pass 0 as the "eta" parameter. | reflection |
| refraction | Models a refraction. Fresnel factor is included by 3Delight. | refraction |
| hair | Models a Marschner BRDF for hair. Simulates the R, TT and TRT lobe as suitable for a monte carlo simulation. | reflection, refraction, glossy. |
| subsurface | Starts a subsurface simulation to model a BSSRDF. | subsurface |
| emitter | omnidirectional emitter | -- |
3Delight Extension to Closures
Some of the closures, for examples GGX and GTR, have been extended to render some relatively difficult effects. In particular, a lot of research have been done to render "thin film interference" on metallic surfaces. The 3Delight Metal material is a good example of usage.
The following parameters are recognized for the GGX and GTR micro-facet distributions:
| Parameter | Descriotion |
|---|---|
color realeta | Real part of the index of refraction of the thin film. |
color complexeeta | Imaginary part of the index of refraction the thin film. |
float thinfilmthickness | Thickness of the film on the surface. On metals, this corresponds to the thickness of the oxide. |
float thinfilmeta | The index of refraction of the film. On metals, this corresponds to the thickness of the oxide. |
float mediumeta | Index of refraction of the outside medium. Defaults to 1 (vacuum) if not specified |
Here is an example render of a steel sphere with a thin film of oxide ferum. It is rendered with varying roughness.
| R=0.05 | R=0.1 |
|---|---|
 |  |
| R=0.2 | R=0.4 |
 |  |
Gone is lockgeom
A remnant of the RenderMan way of doing things is the 'lockgeom' parameter which hints of symbolic linking of data defined on the geometry to parameters defined in the shader. From our point of view, this is feature is useless, as-is, in the OSL world:
- Symbolic linking is weak in that it is ill-defined : what happens if you have many parameters with the same name in an OSL network ?
- In this situation, OSL networks are not completely defined by themselves but are dependant on some external user setting to function. In other words, it is impossible to understand the working of an OSL network just by inspecting it.
In 3Delight, any parameter with no incoming connection will be optimize out (folded). In order to read any primitive variable from the geometry, the OSL network must contain a reader node that calls the getattribute() function call and outputs it. Most networks are automatically built by intermediate software and such nodes are easy to add automatically.