...

A RixPattern plugin is used to connect textures and procedurally generated patterns to RiBxdf parametersparameters, or to other patterns to create a shading graph. There are numerous pattern plugins included with the RenderMan software, but if none of the included plugins generate the pattern you want, then this guide will help you write your own pattern plugin. Source code for many of the RenderMan pattern plugins can be found in the PixarRenderMan-Examples-VERSION/plugins/pattern/ directory which is installed as part of the separate examples package.

...

RixPattern.h defines the interface that all pattern plugins must implement. RixPattern is a subclass of RixShadingPlugin, and therefore shares the same initialization, synchronization, and parameter table logic as other shading plugins. Because a  RixPattern  is expected to be a lightweight object that may be created many times over the course of the render,  RixPattern  is expected to take advantage of the the lightweight instancing services  provided by  RixShadingPlugin . Therefore to start developing your own pattern, you can #include "RixPattern.h" and make sure your pattern class implements the required methods inherited from the RixShadingPlugin interface: Init(), Finalize(), Synchronize(), GetParamTable(), and CreateInstanceData() .

The RIX_PATTERNCREATE() method is called by the renderer to create an instance of the pattern plugin. Generally, the implementation of this method should simply return a new allocated copy of your pattern class. Similarly, the RIX_PATTERNDESTROY() method is called by the renderer to delete an instance of the pattern plugin; a typical implementation of this method is to delete the passed in pattern pointer:

...

To read an input value, use the RixShadingContext::EvalParam() method. The desired input parameter to the pattern is selected by an integer paramId, which is the ordinal position of the parameter in the parameter table. Patterns are expected to know the paramId, the type of the associated parameter, and are expected to pass a pointer to a pointer of the appropriate type. As such, it is suggested that a private parameter enumeration is used to keep track of the order that the parameters are created in the parameter table. For more information, please consult the documentation for RixShadingContext::EvalParam()   and  and RixShadingPlugin::GetParamTable().

After reading input values, output values need to be set up. First, memory buffers for the requested outputs should be allocated using the RixShadingContext memory allocation services. These buffers should then be bound to the requested OutputSpec outputs parameter passed to ComputeOutputParams(), and the type and detail information about those outputs filled in as well. This information should match the declarations from the parameter table. The following code is boilerplate code that can be used to set up the memory allocations for the output parameters. It : it reads the plugin's parameter table, loops through and allocates the appropriate buffers, and sets the detail and type assuming that the output is always a varying color or float (typical of most patterns).

...

Finally, the pattern can now actually compute the values that go into the output buffers. This is typically done by using the inputs and looping through the number of shaded points RixShadingContext::numPts to compute some values that are stored in the allocated output buffers.

RtColorRGB* outColor = (RtColorRGB*) out[k_resultRGB].value; 
for (int i=0; i<sctx->numPts; i++)
{
    // Compute some output values based on your input. Here we assume
    // outColor is the memory buffer allocated for an output parameter,
    // and inputColor and inputFloat are two inputs that were returned from
    // EvalParam.
    if (style == 1)
    {
        outColor[i] = inputColor[i] * inputFloat[i];
    }
}

In the simple example above, we outColor is assigned the buffer that was allocated corresponding to the private enumeration value k_resultRGB, which matches the position of that output in the parameter table. We assume the style variable was a uniform RtInt input value, so there is only one value for all the points in the shading context. Meanwhile, the inputColor and inputFloat  variable were varying instead of uniform, so they are pointers to an array of RtColorRGB values and array of RtFloat values respectively, one for each shaded point in the shading context.

...