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 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.
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.
AOV Forwarding
3Delight introduces the concept of AOV forwarding to solve a classical problem with reflection, refraction and transmission AOVs. For example, a diffuse surface reflected by a mirror will usually appear in the reflection AOV. In some cases it is much more practical to see that diffuse surfaces in the diffuse AOV, leaving the reflection AOV black for that surface. This feature is not part of OSL language but is an attribute that users can set on a per-object basis. This means that there is no need to change your shaders in order to benefit from this feature.
Follows a visual example of some commong AOVs with and without forwarding:
RGBA | diffuse | reflection | refraction | emission | |
---|---|---|---|---|---|
Without forwarding | |||||
With forwarding |
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.