Page tree

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

Compare with Current View Page History

« Previous Version 5 Next »

Contents

Introduction

This documentation is intended to instruct developers in the authoring of custom bxdfs (previously referred to as surface shaders). Developers should also consult the RixBxdf.h header file for complete details.

The RixBxdfFactory interface defines a shading plugin responsible for creating a RixBxdf object from a shading context (RixShadingContext) and the set of connected patterns (RixPattern).

The RixBxdf interface characterizes the light-scattering behavior (sometimes referred to as material response) for a given point on the surface of an object.

RixBxdfFactory

Integrators (RixIntegrator) uses RixBxdfFactory objects by invoking RixBxdfFactory::BeginScatter()  to obtain a  RixBxdf,  parameterized by the bxdf's potentially varying input parameters.  RixBxdfFactory::BeginScatter()  is expected to invoke  RixShadingContext::EvalParam() for the relevant bxdf parameters. The bxdf acts as a closure, associated with a given shading context.  BeginScatter() will typically call a Bxdf constructor which will get the necessary built-in variables such as shading normal (Nn), geometric normal (Ngn), viewing direction (Vn), etc., by calling the GetBuiltinVar() function for each variable.

RixBxdf

Once a RixBxdf object is obtained, the integrator may invoke the following methods:

  • RixBxdf::GenerateSample() to generate samples of the bxdf function.
  • RixBxdf::EvaluateSample() and RixBxdf::EvaluateSamplesAtIndex()to evaluate the bxdf function.
  • RixBxdf::EmitLocal() to retrieve the bxdf's local emission.

The RixBxdf methods above are expected to return quantities for each point of the shading context originally given to RixBxdfFactor::BeginScatter(), excepting RixBxdf::EvaluateSamplesAtIndex(), that operates on a single point of the shading context, evaluating the bxdf function for one or many directions.

RixOpacity

In certain cases, integrators may also call RixBxdfFactory::BeginOpacity() to retrieve a RixOpacity object, and invoke the following methods:

  • RixBxdf::GetPresence() to evaluate the geometry presence.
  • RixBxdf::GetOpacity() to evaluate the opacity color.

Execution Model

There is one instance of a RixBxdfFactory per bound RiBxdf (RIB) request. This instance may be active in multiple threads simultaneously.

The context for a per-thread execution is signaled by the various methods Begin___() and End___(). As a consequence, RixBxdf objects can be assumed as being used used in a single-threaded context.

The RixBxdfFactory should stash state in the RixBxdf object and consider that the RixBxdf lifetime is under control of the integrator. Generally integrators will attempt to minimize the number of live  RixBxdf  objects but may nonetheless require a large number. For this reason, the  RixBxdf  instances should attempt to minimize  memory consumption and construction / deconstruction costs.

The primary  RixBxdf  entry points operate on a collection of shading points (RixShadingContext) in order to reasonably maximize shading coherency and support SIMD computation. Integrators rely on the  RixBxdf's ability to generate and evaluate samples across the entire collection of points.  Sample evaluation may be performed in an all-points-one-sample variant using  EvaluateSample(), and a 1-point-n-samples variant via  EvaluateSamplesAtIndex(). Generation, however, is constrained to all-points-one-sample. Evaluation typically has different requirements (e.g. for making connections in a bidirectional integrator), whereas generation typically benefits from being performed all points at once.

  • RixBxdf::GenerateSample() generates one sample for each point of the shading context
  • RixBxdf::EvaluateSample() evaluates one direction for each point of the shading context
  • RixBxdf::EvaluateSamplesAtIndex()  evaluates one-or-many directions for a given point of the shading context

Bxdf parameters and correctness

A bxdf should always provide the three methods RixBxdf::GenerateSample()RixBxdf::EvaluateSample() and RixBxdf::EvaluateSamplesAtIndex().

The GenerateSample() function has the following input parameters: transportTrait, lobesWanted, and random number generator. The transportTrait tells the Bxdf the subset of light transport to consider: direct illumination, indirect illumination, or both. lobesWanted specifies what lobes are requested, for example specular reflection, diffuse transmission, etc. The random number generator should be called to generate well-stratified samples; such samples typically reduce noise and improve convergence compared to using uniform random samples.

The GenerateSample() function has the following output parameters (results): lobeSampled, direction, weight, forward pdf, reverse pdf, and compTrans.  lobeSampled is similar to the input lobesWanted, and specifies which lobe was actually sampled. direction (Ln) is the generated ray direction vectors; these directions must have unit length. weight is a color per sample indicating that sample's weight. The forward pdf should account for light moving from the L to V direction where as the reverse pdf account for the opposite (from V to L). Bxdfs should always provide both pdf values for the integrators to use. compTrans is an optional result which can be used to indicate transmission color; this will be used as alpha in compositing. A bxdf should check that compTrans is not NULL before assigning to it.  All results are arrays with one value per sample point.

As an example, a purely Lambertian diffuse bxdf should loop over the sample points and for each sample point set the result values as follows: set lobeSampled to diffuse reflection, set the reflection direction to a randomly generated direction chosen with a cosine distribution on the hemisphere defined by the surface normal (using a well-stratified 2D "random" sample value generated by calling the provided random number generator), set the weight to the diffuse surface albedo color times dot(Nn, L) divided by pi, set the forward pdf to dot(Nn, Ln) divided by pi, and set the reverse pdf to dot(Nn, Vn). More details can be found in the source code for the PxrDiffuse bxdf.

The parameters to the EvaluateSample() function are very similar: transportTrait, lobesWanted, random number generator, lobesEvaluated, direction, weight, forward pdf and reverse pdf.  The main difference is that direction (Ln) is an array of inputs that the function should compute weights and pdfs for.

The EvaluateSamplesAtIndex() function is very similar to EvaluateSample(), but is used to evaluate multiple samples at the same surface position and normal, but with different illumination directions (Ln). The inputs are the same as for EvaluateSample(), except that it has two additional inputs: index and number of samples. index is used to index into built-in variables such as the normal Nn and viewing direction Vn, and number of samples is the number of directions (Ln) to evaluate the bxdf for. The functionality of EvaluateSamplesAtIndex()–  the former only exists to make sample evaluation more efficient in certain light transport settings.

Bxdfs that do not scatter light (e.g. PxrConstant) should disable all lobes and set the forward pdf and reverse pdf to zero.

In order to maintain physical correctness, bxdfs are expected to conserve energy and obey the Helmholtz reciprocity. Care should be taken so that RixBxdf::GenerateSample()RixBxdf::EvaluateSample() and RixBxdf::EvaluateSamplesAtIndex() return consistent results. This allows bxdf plugins to be compatible with different rendering techniques such as:

Additional Considerations

Bxdf Evaluation Domain

Bxdf Lobes

Bxdf Sample Validity

Non-Opaque Surfaces

Alpha for Compositing

Query Ray Properties

Installation

RenderMan will search for bxdf plugins on demand, under the rixplugin searchpath. The following rib stream will search for a plugin file named MyDiffuse.so

Bxdf "MyDiffuse" "diffuse1" "color tint" [0.5 0.5 0.5]

Args files

By convention, arg files (.args) are used to define shader metadata needed by host applications. This includes parameter names, default values, localization and GUI hints.

Arg files are written in a simple xml format and should be easy to parse.

Bridge specific metadata should also be written to arg files. For example, Maya requires nodeid and classification information:

 

<rfmdata nodeid="1053406" classification="shader/surface:rendernode/RenderMan/bxdf:swatch/rmanSwatch"/>

Note that RenderMan itself queries parameter information using the RixBxdfFactory::GetParamTable() method, not by reading arg files.