Nestor Prado - RenderMan Portfolio

The teapot compostion

This page demonstrates the basics of scripting shapes RenderMan scene description (rib) protocol. Writing rib files by hand focuses attention on the use of color, opacity and the fundamental concepts related to xyz coordinate system. The preliminary renders have been done using basic shading so that the geometry can be more easily seen.

Using quadrics and simple polygon planes we constructed a basic scene to test out the capabilities of editing rib files directly. Everything in this image was created using a text editor.

What can we find in this example: (Click on any element to view the source code that makes it possible)

Modeling with quadrics and simple geometry
Lighting
Deep Shadows
Texture Mapping (Color and Transparency)
Displacement
Depth of Field

Extras:

Motion Blur
Ambient occlusion (Ray Traced)

Construction of the scene

The first thing was to create an object using simple mathematical 3D surfaces. These surfaces are called Quadrics. Here is a simple video detailing how the process of constructing the teapot out of quadrics was done. When it was finished, it was saved as an rib archive file to use in future tests.

Once the main object was created we built a 3D scene with some elements and the teapots. We created a scene bearing in mind that we wanted to show all the concepts mentioned above. So here the concept of having a foreground scene (the teapot spying into the background) and then a background scene where three teapots where admiring a special teapot up in a pedestal. This distribution of the scene gave us the chance to play around with lighting to different spaces, and also was perfect for using the DOF as a storytelling element and not just as a technical one. This video shows the process of creation of the scene and all the lighting taking place.

In this next section we show extra elements that we studied while learning about RIB files. To see the code involved in any of the elements used for the creation of this scene, plese refer to the index on the top of this page.

Extras:

Occlusion Turn-tables

With our tepot asset we imported it to a new rib file we created a simple turn-table video for both Point Based Occlusion and Ray-Traced Occlusion.

Early ligthing tests

Using basic spotlight shaders we composed a light scene and lighted the scene with 4 spotlighs. We used light-linking to have 4 of the lights affect the teapots but not all of them affect the ground. We also made three deep maps so we could get some shadow interaction with the teapots and the ground. The video on the left flies arround the scene to see the interaction from the different lights with the scene geometry

Motion Blur

Motion blur is normally used to achieve the illusion of movement. Motion blur can be achieved quite easily inside a RIB file. We have to create a Shutter paramameter for the camera and create a a Motion Blur block. We can decide how many samples are used to compute the motion blur for each frame. See the source code for greater detail on how to achive motion blur.

RIB Box

This section is included to see how the knowledge of RIB files and their syntax can enable artist to use this in a 3D software package such as Autodesk Maya.

This scene was created using the RIB box command. This enabled us to create a scene with 1284 proxy planes that are later replaced by our teapot rib archive during render time. We also hide the proxy geometry so it’s not rendered.

The commands used in the RIB box are:

				ReadArchive "full_path/nameofarchive.rib"
  				Attribute "visibility" "int camera" [1]

With this example we can rapidly comprehend what the advantatges are of being able to execute RIB commands during render time without having the 3D software package have to deal with that part of the process. This is only a simple example to illustrate how this technique can be.

Comparative Rendering

This web page displays the results of a number of rendering tests that compare the image quality and rendering speed of Maya's software renderer, mental ray and Pixar's prman.

Oclusion Renders

We are creating occlusion with three methods:

Mental Ray
RenderMan w/ Ray-Tracing
RenderMan w/ Radiosity Pass

Mental Ray

The settings used to render with mental ray where the default values that you get from creating an occlusion pass in maya

This images took 2:14 min.and 0:42 min. to render

Method's weaknesses in this case:

After doing some tests with and without grass on the model, we can conclude that grass, as little as created for this model, the rendering times of the occlusion pass are increased by more than 100%. So where we have a render with grass that takes 2:14 without grass it takes 1:01. So that’s more than half the time.

RenderMan Ray-Tracing

The render settings used:

Globals:

Shading Rate: 1.0 (best value)

Env. Light:

Samples: 128
Max. Variation: 1.0 (best value)

This images took 1:02 min. and 0:22 min to render

RenderMan Radiosity Pass

The render settings used:

Globals:

Shading Rate: 5.0 (faster value)

Radiosity Pass Settings:

Shading Rate: 1.0 (denser point cloud)

This images took 1:18 min. and 0:49 min. (Using the point cloud file)

Method's Advantages:

Creating a higly dense point cloud will give us faster subsequent renders, although the first time we render it will take a while longer to compute the point cloud. This is an example of the dense point cloud obtained by using a shading rate of 1.0 in the radiosity pass settings.

Final thoughts:

It seams clear that RenderMan can handle way better rendering occlusion passes. Being the method Ray-Tracing or using a Radiosity Pass RenderMan’s prman handles better the occlusion pass with fur.

One other important thing to take into account while using RenderMan’s radiosity pass is that we should use the Shading Rate in the Radiosity Pass at 1.0 or really low value to increase the number of points used to compute the point cloud. This will result in one first render that will take longer to create the cloud. But after being created we can reuse it so it makes the subsequent renders faster. It will also allow us to turn the Shading rate in the render globals to a value that gives us faster renders than having a smaller value without sacrificing that much quality.

Shadows

We are creating shadows with three methods:

Maya Software
Mental Ray
RenderMan w/ Radiosity Pass

Maya Software Renderer

The settings used to render with maya software where the default values that you get from the production quality preset in maya render globals

This renders took 2:47 min. and 2:29 min.

Method's weaknesses in this case:

Basically this method is the worst of them all. The results are pretty bad in terms of shadows, although the production setting is used and ray-tracing shadows are used. Before using this, it would be better to use Mental Ray and wait a bit longer to get far better results.

Mental Ray

The render settings used:

Globals:

Production Quality Preset

Light casting shodows:

Light Angle: 5.0
Shadow Rays: 20

This images took 3:56 min. and 0:51 min. to render

Method overview:

Mental Ray gives us a lot of tweaking capability to make the ray-tracing shadows look convincing. Of course, if we want to get rid of the noise and the aliasing we need to use a lot of shadow rays and turn the anti-aliasing settings to a Production Quality Preset,thus we have to wait almost 4 minutes for the close-up frame with grass.

RenderMan Deep Shadow Pass

The render settings used:

Pass Settings:

Map size: 1024px

This images only took 0:09 min. and 0:07 min. to render once the shadow map was computed.

The results with this method are amazing. Not only for the quality of the rendered shadows but for the time that prman takes to actually render the images. Both images where rendered in under 10 seconds. Giving us the same or even better quality than the mental ray shadows render.

The shadow map creation is a bit like the the point cloud. The bigger the shadow map is the more detail it’ll capture and the better it will be when reused. In our case it’s really simple because we only have one shadow map that covers all the geometry.

Having more lights and more extended sets of geometry may cause a slower render.

Render tests

In this section we show some render tests with different Renderman capabilities, such as Dof, Multi-pass rendering, stereoscopic, etc.

Light setups

We created two lighting setups to see the model in various light condition. The first setup is just a basic studio lighting setup. The second is a little more mood driven. We created different lighting setting to get to see the textures interacting with the light. The objects are ment to be like plastic so we used normal blinn shaders and adapted them to have some lesser diffuse than normal and we created some noise for the specular highlights so it had some interesting effects when lights interact with them. For the red wooden planks we used the primvar technique explained in class to modify the diffuse value randomly depending on which woodplank we're rendering. Thus creating a more natural effect where not all the planks look the same. The tutorial used for implementing this technique can be found at fundza.com

Example of Depth of Field

We tried using RenderMan's built-in depth-of-field capabilities to get an animation of the dof moving through the scene. As we were using deep shadows in mental ray we had to turn the values of the Focus Factor on the render settings to not get the errors that Kevin George encountered and find out how to fix.

Example of aovs (arbitary output variables)

In this example we see an image showing the diferent aovs (what we normally would call render layers/passes if working in Mental Ray) that can be achieved directly from RenderMan. There are many more aovs that can be used but this small breakdown shows some basic ones like: diffuse, specular and occlusion.

Stereoscopic Rendering

This stereoscopic images are Anaglyph and should be viewed with Right Eye Red Left Eye Blue (Hover over to see the same frame using toe-in and without)

We can see in this renderings the comparison between using Toe-in and using only parallax. We’ve compared these two methods as using toe-in is not recommended for a eye-sore free experience when watching stereoscopic images. The rotation of the cameras to provide image conversion produces trapezoidal distortion which produces vertical parallax. Vertical parallax is very uncomfortable for the human eye, thus the need to get rid of it. In our case being one image and with not that much separation between the right and the left image we can get away with both. It is just something to keep in mind when working with stereo-imaging so it was worth the comparison.

This is a simple turntable showing our model in anaglyph mode

More information on Chapter 5: Stereoscopic 3D of The VES Handbook of Visual Effects

Snow!

Using Maya’s built-in particle system manager, we’ve created a simple particle cloud that interacts with the geometry of the inside of the snow globe. We created a gravity field that simulates the resistance of the snow particles in the water and we’ve added a turbulence field to add some randomness and organic feel to the snow.

St Coloration

These images show the results of using the RenderMan Shading Language (RSL) to write a variety of special effects surface shaders. The notes and RSL code accompanying each image explain how each effect was achieved.

Special Figures

The goal of this exercise was to familiarize ourselves with the concepts behind st coordinates and how we could use them in a clever way to create procedural mathematical figures in a shader. Hence, here are some examples of the shapes that can be accomplished by using the st coordinates as the x and y cartegian coordinate system to plot some figures.

Click on any image to reveal a simplified version source code in the shader.

float circle1 = (s-offset_s)*(s-offset_s)+
(t-offset_t)*(t-offset_t);
float circle2 = (s-offset_s-0.1)*(s-offset_s-0.1)+
(t-offset_t)*(t-offset_t);
  
    if (circle1 <= radius*radius && circle2 >= radius*radius )
        surfcolor = figureColor;

if( s+offset_s < t+offset_t)
        surfcolor = figureColor;

//The circle is just an elipse with the same width and heigt
    float elipse = ((s-offset_s)/width)*((s-offset_s)/width)+
((t-offset_t)/height)*((t-offset_t)/height)-1; 
    if( elipse <= 0.5)
        surfcolor = figureColor;

float elipse = ((s-offset_s)/width)*((s-offset_s)/width)+
((t-offset_t)/height)*((t-offset_t)/height)-1; 
    if( elipse <= 0.5)
        surfcolor = figureColor;

if( width*sin(s*radius*2*PI)+height <= t )
            surfcolor = figureColor;

if( width*tan(s*radius*2*PI)+height <= t )
            surfcolor = figureColor;

if( width*1/(sin(s*radius*2*PI))+height <= t )
            surfcolor = figureColor;

The interface

We created a simple interface in the shader so the user can experiment with different parameters to change the apperance of the figures. We have a first dropdown menu that gives the possibility of selecting between the different figures: Half Moon, Diagonal, Circle/elipse and trigonometrics. If the trigonometrics option in the dropdown menu is selected this activates the second dropdown menu that will make available the trigonometic functions of: Sine, Cosine, Tangent, and Secant.

This way the user can experiment with all this figures in one compact interface to quickly get what he was looking for.

UI parameters quick reference:

figures: let's the user select between 4 different types of figures.
Kfb: intensity of the overall color of the shader.
Figure Color and Background Color: select the colors for the figures and their background.
offset_s and offset_t: use this values to move the figures in the st coordinate sistem s->x axis and t->y axis in a cartegian space.
trigonometrics: menu to select what trigonometric function must be printed.
width and height: parameters that help change the shape of the figures: circle/elipse and trigonometrics .
radius: in the circle/elipse it is trivial what it acts as. In the trigonometrics this parameter acts as a frequency selector .

The Batman Shader

After the initial experimentation with s t coordinates and how to use them to create mathematical shapes we wanted to create a more complex element. Hence we reproduced the Batman Shader. This is a complex figure created from several equations evaluated in different ranges of s and t.

Click on the image to see the portion of the code that is responsible for creating this figure.

Maya Pattern Animation

The main idea of this project was to use the knowledge gained from learning RSL to create a piece that had a CG element with a custom built shader. The goal was to utilise the power of RSL to create a shader that could be animated in some interesting way.

Here is the final result of this assignment.

The first part of the process was to come up with a shader that could be animated. So we started by creating a simple shader with a customizable stripe that could be scaled and moved up and down in st space.

This is trivial and fairly basic. So to make it a little more interesting we added some noise to the stripe that we could control with the frequency.

This is an example of the first version of the shader.

The next step, was to incorporate some kind of use of opacity. So we made the opacity be driven by the noisy line. With these two simple effects we started getting a really interesting effect. These are some early render tests testing the use of opacity to create a disintegration effect.

Then we started thinking about a way to use this effect in a interesting way. So we finally decided that a Newton’s cradle could be a interesting element in which we could see our shader in action. One of the main ideas we had, was that we wanted to drive the animation by the motion of the newton’s cradle. So we knew we wanted to create a rigid body simulation and have expressions drive the animation.

So after creating the newtons cradle we started playing with expressions to get the connection between the rigid body interaction and our shader. The main idea was to use the collision moment when a ball hits another ball to trigger an animation procedurally linked to our shader.

How is the stripe procedurally animated?

To put it in plain words this is what the expression mainly does.

The expressions on the shaders are waiting for a collision to happen.
When it happens they take the frame number it occurred on and store it as an initialFrame.
A endFrame for the animation is computed by adding the initialFrame + the animationLength that we can set before we render.
Then we evaluate: If we are still between initialFrame and endFrame, we add an increment to the position of the line, and we also increment the frequency of the noise to create a disintegration effect.

We wanted to use this approach instead of baking the simulation and then animating the sliders because our approach gives a better possibility for art direction. We can change the parameters of the simulation and the animation of the shader will trigger at the correct moment in this new simulation. All the parameters involved in the procedural animation can be changed also giving a lot of flexibility in terms of art direction.

This is the final code we used to link the rigid body simulation to the shader:

Once we had that workflow figured out we started working further on the shader to achieve a more chrome-like looking shader. The first we had to do was to create the specular and diffuse components of the shader, to turn it from a simple surface shader to a more customizable shaded shader. This is fairly easy as RSL has built-in functions that will compute the ambient, diffuse and specular components.

    vector  i = normalize(I);
    normal  n = normalize(N);
    normal  nf = faceforward(n, i);
  
    ambientcolor = Kfb * ambient();
    diffusecolor = Kd * diffuse(nf);
    speccolor = speccolor = Ks * specular(nf, -i, roughness) * hilitecolor;

Once the reflectivity was implemented it had to be correctly used with the diffuse and the ambient color of the shader so we combined it depending on a reflectivity parameter that went from zero to one. The way we combined the colors was (ambient + diffuse + specular) * (1-reflectivity) + reflectivity * reflectionColor. This gives the correct combination of the colors.

    if (n.-i >= 0)  /* only trace from points facing the eye */
    {
       vector R = reflect(normalize(I),normalize(N));
       color hitcolor = 0;
       gather("illuminance", P, R, blur, samples, "surface:Ci", hitcolor) 
        {
              reflectedColor += hitcolor;
            numhits += 1;
        } else {
            if(envMap != "")
                  reflectedColor += environment(envMap, R);
            else
                reflectedColor += color(1,0,0);
             numhits += 1;
       }
       reflectedColor = reflectedColor / (numhits*2);
    }
    
    Ci = Oi * Cs * surfcolor * (ambientcolor + diffusecolor + speccolor)* (1-reflectivity)
                             + Oi * (reflectivity * reflectedColor);

Here is a video of the shader working in a test environment:

As we can see, it has everything we need for our final animation. Diffuse, specular and reflection components. Stripe interaction and custom transparency. All paramaters that can be changed and keyed in Maya using the UI provided from the .slim file.

This is a capture of the GUI of the shader and all the parameters it has.

Brief overview of the paramaters:

envMap: a tex file is read as the environment map to reflect.
Kfb, Kd and Ks: intensity of the ambient, diffuse and specular colors
roughness: roughness of the specular highlight
reflectivity: determines how reflective the shader is. 0 none 1 totally reflective
angle and samples: control the glossiness of the reflections.
tPos:parameter that determines the position of the stripe.
repetitions: repeats the stripe over the t axis.
freq: frequency of the noise.
transparency: toggles the custom transparency of the shader on or off.
Colors: color swatches to pick the base color, the stripe color and the highlight color

Finally it was time to create the environment, the materials and the light set up as well as the camera angles and movements for the final composition.

Technical Breakdown Linked Externaly