General Guidelines

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.

Content:

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 base layer.
`color complexeeta`	Imaginary part of the index of refraction the base layer.
Note that the pair (realeta, complexeeta) replaces the eta parameter. One can still use 'eta' to describe non-metallic surfaces.
`float thinfilmthickness`	Thickness of the film on the surface. As an example, on metals, this corresponds to the thickness of the oxide.
`float thinfilmeta`	The index of refraction of the film. As an example, on metals, this corresponds to the index of refraction of the oxide.
`float mediumeta`	Index of refraction of the outside medium. Defaults to 1 (vacuum) if not specified. An example scenario where the this needs to be change: a varnish
`float gamma`	Pass this to the GTR closure to control the tail of the specular highlight. Setting this value to 2 renders a GGX distribution exactly.

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
a

Arbitrary Output Variables

Any closure can be output to a special outputvariable() function to be output as an AOV. "Pass through" nodes are familiar to Softimage users: they can be inserted anywhere in a Shade Tree to register the downstream subtree as an output variable.

Consider the following simplified line of code and the corresponding evaluation :

Ci = Kd * diffuse() + Ks * specular();

To store the specular and diffuse components, along with weights, into the specular_aov and diffuse_aov output variables the code has to be changed in the following manner:

closure diffuse_aov = Kd * diffuse();
closure specular_aov = Ks * specular();
Ci  = outputvariable("diffuse_aov", diffuse_aov) +
	outputvariable("specular_aov", specular_aov);

Note that AOVs can be output in any node of the OSL tree. If two different OSL nodes contribute to the specular_aov variable 3Delight will correctly blend their contribution together in the final output and in the AOV.

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 ?
lockgeom can be elegantly implemented by a ... connection (explicit linking).

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 and outputs it to the input parameter. This clearly states the behaviour of the network.

In this diagram, "vertex_color" and "Kd" are connected to an OSL node which
executes getattribute(). All the other variables are "folded".

A "drawback" of this method is that one can't easily get the default parameter value if the primitive variable is undefined. But bear in mind that 99% of shader networks are machine generated and this gives us two possible solutions to this problem:

Don't output the getattribute() node when the primitive variable is not present.
Output the proper default value in the getattribute() node in case the primitive variable is not present. This involves shader node interrogation.

Page tree