While it can do many things, RSL is limited by the language. To enhance its functionality, one can implement a plugin using Pixar's RSLPlugin C++ API. For a sub-set of micropolygons my plugin writes RiCurves into an archive rib file that is referenced by a later beauty pass render. There are, therefore, two passes. The first creates moss-like geometry via my C++ plugin and must only be done once, the second generates the final image. For information on how to implement an archive rib, look here.

I tried to bake in the lighting into the rib file. Unfortunately this gave extraordinary values like color(126, 100, 50).

Applying a shader to the curves fixed the problem of trying to pre bake the colors into the moss. This way the plugin generated random variations of the user inputed color and then the shader on the geo container that is reading in the rib archive (how to do that here) takes care of the lighting.

Reference photos

This is really a fake translucency shader meant to be applied to a single sided surface.

The real challenge is forcing the directlighting() function to use the reversed normals. In the old style of coding, one could just say:

       Ci = Os * Cs * (diffuse(nf) + diffuse(-nf) * surfcolor); 

Meaning that the final color (Ci) is the apparent opacity, apparent color,  and the diffuse of the front face added to the diffuse of the back face multiplied by the surface color.

At first I was switching the normals within the directlighting() function and something just wasn't working with the diffuselighting() call to get Ci. After playing, the reverse of the normal was put in the displacement() function, the normal place to initialize normals to the shader, with the following lines of code. The normals were changed as well as the shading context, that holds the information for the material and object, were also inverted.

         N *=  -1;         m_shadingCtx -> m_Ns *= -1; 

Then came the brute force way of getting the lighting information. After gathering a list of lights, the light color and direction was returned from a modified plausible light shader. The modifications to the basic plausible light shader were to force it to return the color and direction of the light. This worked, but did not show shadows.

Eventually I went back to trying the default method of lighting (directlighting()) to try and figure out the path between the material and the light to generate samples for shadows. I did not figure out the path because calling directlighting() returned shadows and translucent light information!

The frosted glass shader was my first attempt at writing a shader that other artists could use. It was written using the RSL2 extensions to the RenderMan Shading Language. Implementing a class based shader makes it surprisingly easy for the shaders (internal) instance variables to be shared by the methods that are called within the shading pipeline.

Frosted glass reference

User Controls: color, frost color, spec color, spec and reflective gain and roughness, internal reflections, index of reflection, displacement amount, and specific frost controls.  The frost is based off of a noise pattern, with user controls, the amount of frost and at what space the frost is coming from.

By entering the name of a null (Houdini) node into the shader, the user can move the frost around. The animation above shows frost “growing” on the teapot. This was done by animating the radius of influence of the null node which is explained more here.

The ramp that is the change from glass to frost is also controllable  and the influence does not have to be smooth, it can change from a straight edge to a noisy one.

For additional functionality I plan on allowing the user to input an image of their own frost. The frost is currently based on wavelet noise, controlled by user input, but it is still not completely under the user’s control.

There is also a test to see if the color was greater than 1, at which point the surface color was defaulted to white. It would probably be a better idea to have three separate if statements checking each rgb value and setting them individually because that would be somewhat awkward to have a white pixel where it should be red since the green and blue values were also changed.

Renderman has a way of programing shaders in RSL, by using classes. This allows a displacement shader to be in the same file as the surfacing function and for physically based shaders.

I've been exploring these new shaders within Houdini, because Houdini is more fun than Maya. I found that I had trouble writing my shaders correctly because I did not understand how the renderer, the material and the light were working together to make the surface color.

 

Plausible Constant

The constant shader is just one constant color across the surface. It never has to access the light and therefore has just one constant color.



Plausible Diffuse

The plausible diffuse shader adds shading to the surface. It is like a lambert shader in that there is no specular or reflective quality.

The material’s surface() function can be substituted with the diffuselighting() function without too much of a difference. The difference in the rendering can be seen here.

The material’s diffuselighting() function asks the light to generate samples for the diffuse color and the shadow and those are saved as the Ci and outputed by the material.




Plausible Specularity

The plausible reflective shader is essentially like a blinn in that you may control the specular highlights and reflectivity of the object. The reflectivity is referred to as “indirect specular”.

The diffuselighting() and specularlighting() functions work by layering their Ci returns on top of each other: diffuse, reflection then specular.

The material actually gathers the sampling information in that order, diffuse, indirect specular and direct specular. This was essential to know in order to separate out the controls for a softer reflection versus specular.