You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

 

 

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:

 

3DelightOther 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.


ClosureDescriptionRay Types
microfacet – ggxModels isotropic or anisotropic GGX BRDF. This model can handle reflection, refraction or both at the same time.reflection, refraction, glossy
microfacet – gtrModels 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 – cooktorranceModels an anisotropic Cook-Torrance BRDF.reflection, glossy
microfacet – blinnModels a Blinn specular BRDFreflection, glossy
oren_nayarModels a diffuse reflector based on the Oren-Nayar model.diffuse
diffuseModels 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
refractionModels a refraction. Fresnel factor is included by 3Delight.refraction
hairModels a Marschner BRDF for hair. Simulates the R, TT and TRT lobe as suitable for a monte carlo simulation.reflection, refraction, glossy.
subsurfaceStarts a subsurface simulation to model a BSSRDF.subsurface
emitteromnidirectional 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:

 

ParameterDescriotion
color realetaReal part of the index of refraction of the thin film.
color complexeetaImaginary part of the index of refraction the thin film.
float thinfilmthicknessThickness of the film on the surface. On metals, this corresponds to the thickness of the oxide.
float thinfilmetaThe index of refraction of the film. On metals, this corresponds to the thickness of the oxide.
float mediumetaIndex 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.05R=0.1
Thin film interference caused by oxide ferum layer
R=0.2R=0.4
a

 

Arbitrary Output Variables

Any closure can be output to a special passthrough() function (name might change)  to be output as an AOV. "Pass through" nodes are familiar to Softimage users: they can be inserted anyway in the 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();

 

 

 

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 order to function properly, the lockgeom has to be defined per parameter anyway. Not per shading group.

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

Most networks are automatically built by intermediate software and such nodes are easy to add automatically.

Performance wise, and additional node doesn't make any practical difference.

  • No labels