RIS shading Series #2 Meet The Plugins

Transcription

1 RIS shading Series #2 Meet The Plugins In this tutorial I will be going over what each type of plugin is, what their uses are, and the basic layout of each. By the end you should understand the three basic types of RIS plugins and the elements that set them apart and make each useful. In addition I will touch on how the plugins interact and give the user a vast amount of control over the rendering process. If at any point you find outdated or incorrect information please let me know on the forum, any feedback is appreciated. Note: I will use the terms node, plugin, extension, and shader interchangeably throughout to represent a compiled dynamically linked library (.dll or.so) that is used by Renderman to define a portion of its rendering process. Warning!: This is a dense article so please take you time and try to understand what is being said before moving onto the next part of this series. I will try not to repeat information that is covered in this document but instead spend time on new material. If at any time I am not making any sense you can ask on the forum and I will be happy to respond. Alternatively Pixar does maintain some documentation located here if you need something explained in a different way. Part 1: Pattern Plugins (or, the one that everyone will make creative things with): Pattern Plugins make up the majority of the RIS plugins. By the numbers there are 80 plugins present in PRMan 20.7 and 45 of those are of the pattern verity. These nodes provide the rest of the shading system with procedural or texture information and modify that same data in some way. For example, take the PxrTexture node. It loads texture information from a file than another pattern shader such as PxrExposure or PxrInvert can change that texture in certain ways. After all that is done the result will be passed to a BXDF shader such as PxrDisney. These shaders are the means by which artists feed non-constant information to BXDF nodes. So with this mindset lets take a close look at a bare bones pattern plugin. If you are not familiar with how C++ implements classes you might want to review that before continuing forward. Also all of the plugins that I will show have the definition and declaration in one file. This may not be good practice for C++ but it makes everything more readable. For more complex plugins you will want to split everything into proper headers and source files.

2 So taking this line by line we can start from the beginning. Line 1 is an include for a Pixar declared header required for Pattern type shaders. In that file you can find the parent of the class we are defining here. One Line 3 we can see a fairly typical class definition line that is a child class of RixPattern. Moving onto Lines 7-8 we have the basic constructor and destructor. On line 10 we have a public function called Init that takes in a RixContext object and a char array pointer that points to the location of the plugin. The RixContext object provides us with some useful tools for interacting with Renderman but we will talk about this more in the next tutorial. Init is primarily used to set up your plugin before any rendering happens. Line 11 defines a function called GetParamTable. This function allow your plugin to define what inputs should be passed to it by the user more on using this later. Line 12 has the finalize function. Finalize is called after compute is done before the plugin destructor is called. Finally we have the ComputeOutputParams function. This is called for each sample of your pattern and what is calculated here is sent to the nodes up the chain. Now lets go into the implementation of this plugin. Moving right along we have a basic constructor, destructor and Init functions. We are really doing nothing here in this example but in plugins that are more than a hello world you should declare and initialize your non-changing parameters and objects in one of these functions.

3 For lines we have the GetParamTable function. You can think of this as your means of setting up an input stream for you plugin (not technically accurate but a good way of thinking about it.) All that you need to do in this function and this goes for every plugin type is create a RixSCParamInfo object that contains a list of elements that corresponds to your inputs and outputs. For example, in this pattern I am taking in one float value as an input and passing one float as an output. For a RixSCParamInfo object all you need to give it is the parameter name, the data type you parameter is (Float, Int, etc.) and whether it is an output or not. You can leave the last one off if it is an input as you can see on line 45. At the end of your list make sure to cap it with an empty RixSCParamInfo to indicate the end of the list. After that all you need to do is return this list and your inputs are now set up. On lines is an enum that functions to keep track of our input and output parameters. I strongly recommend using an enum as it makes keeping your inputs and outputs organized much easier. When you see the finalize function in any plugin, just think of it as your first destructor. It is made to finalize or destroy anything you created in the Init function as it has access to a RixContext object.

4 Now we come to where the action is at. In this example all we want to do is output some constant float to the next node. In order to do this we must set up a pool object (line 72) and use it to get the objects that will be bound in memory. The output spec will be that object (line 73). We must also set the outputs pointer to the outputspec instance and the noutputs to the number of outputs we have (lines ) This step tells Renderman where and how many outputs to expect. Now we can create a RtFloat pointer (simply a renamed float type) for our result (76-77.) By setting the attributes of o we effectively tell RIS where everything is and what type of parameter to expect (78-80.) On lines we go through every point that needs shaded and assign them to 1.0. At the end of the basic pattern we have two macro functions create and destroy. All these do is allow Renderman to create and destroy an instance of your plugin. The create a destroy macros can be found in quite a few plugins so it is a good idea to know what they look like. Part 2: BXDF Plugins (or what you will spend countless hours trying to understand)

5 Now that we understand how pattern plugins provide data to BXDFs we now have to answer the question of what do they do with that information. The end result of a BXDF plugin is to provide or return information to the integrator about the material of the object based on other shaders and geometry information. The basic BXDF we will look at in this tutorial is a simplified version of the PxrConstant which outputs only a single color. There are many more things you can do with BXDF's but for sanity s sake I will keep it simple with no shading calculations. A BXDF shader is broken up into two parts the first is a BXDF factory and the second is an evaluator object. The factory's job is to create an instance of the BXDF for the integrator to call upon in order to get information on different lobes for the material. Lobes provide information on a certain aspect of a material such as diffuse or specular information. The evaluator, or BSDF will actually perform the calculations for the BXDF and send that information back to the factory instance. This is how a simple BxdfFactory class is setup. The factory when it is instanced by the integrator will construct itself and initialize data using Init, GetParamTable, Finalize and CreateInstanceData. Inside CreateInstanceData is where decisions are made to differentiate each instance from one another. For example for different PxrConstant nodes you might have one that needs varying presence information while another might be completely present which allows Renderman to skip calculations where it can to speed up the render. The GetInstanceHits is the function that simplifies the job of sampling by allowing the integrator to get hints from the shader such as instance information. Since BXDF's can be working on multiple threads there is a Synchronize function to make sure all instances are working with the right information. The Scatter and Opacity functions are the ones that perform the work of the BXDF by calling the evaluator and passing that information on the Integrator. We will take a quick look at the evaluator but don't worry about understanding everything being done at the moment.

6 The evaluator is responsible for providing surface information for each lobe that the BXDF is called upon to solve for. In this example since we have the PxrConstant shader all of the shading information is a constant color that is unaffected be lighting and other considerations. So for each EvaluateSample call this shader simply sets each lobe to not used and moves on. The only activity is in the EmitLocal function where the color that the user passed in is used to set the emit color for the material. There is a lot here even for a simple material so don't worry to much about the fine details. For the time being just understand that based on passed in information the shader evaluates lobe information for each sample and passes that information to the integrator. Part 3: Integrator Plugins (where everything comes together into a huge mess of debugging ;) ) We can now talk about the mastermind of the plugins, the Integrator. This is where you manage all of that data we collect through the pattern, BXDF and other plugins. In addition to this data the integrator also can, like the other plugins, pull data from the scene objects to help refine your final image. I will not spend a lot of time on the integrator just because it is a complex beast and should be explained more thoroughly later once we have a more complete understanding of the other components.

7 An integrator plugin includes both its own header and that of the bxdf since it must take in the information from that shader type. Having the shading utilities from RixShadingUtils.h also makes the code much more readable by using abstract data types. It starts with a standard constructor destructor combo. Init GetParamTable, and finalize are the same as they always are. The unique stuff begins with RenderBegin and Render End. In these functions we set up the displays that RIS will use. When I say display I mean either a file or any number of programs that Renderman can output display information to. For a complete list of displays look here. RenderEnd as you might have guessed is where we clean up anything we did in RenderBegin. The Integrate function acts like any one of the evaluate functions previously mentioned for the pattern and BXDF shaders. The execution of an integrator proceeds like so. First the integrator is created and constructed. Second, the Init function is called at the appropriate time. Third, GetParamTable is called. Fourth, RenderBegin is called and the integrator sets up its display outputs. Fifth, the Integrate function is called upon to get the color, opacity etc. information from the bxdf nodes and pass it along to the display driver. After that all of the clean up functions are called to destroy what was left behind. The explanation was bit brief but this is a large topic and I can't do it justice with just a few paragraphs. I will have a dedicated tutorial on this topic eventually but until then you can get more information in Pixar's documentation or in the RixIntegrator.h file. Going forward just understand that the execution of all BXDF and pattern plugins are controlled by the Integrate function inside the Integrator. Part 4: What we missed (A result of not having all the time in the word) I understand that I left out quite a bit on how to actually make anything useful with these shader shells. The reason for this is that talking just about how RIS works with its plugins should give you a

8 solid grounding so that the math that goes into the shaders will not be confused with Renderman centric code that way you can easily port your knowledge to other areas of programming and apply anything you already know to RIS now. You might have noticed in the Renderman directory that there are more than just these three types of nodes. There are many other types but since they are not quite as straight forward they will not really be focused on during the remainder of this series. Briefly below I will list the other types. If you want more information you can look at the shader examples that Pixar has provided for that type. Light: This shader is your one stop shop for making custom lighting simulations. Have you ever wanted light to work differently well here you go. Since this plugin is likely to change soon I will not delve any deeper for the time being. Projection: When you set up your scene one of the most important pieces is how you set up your camera. This plugin provides you with the means of changing the camera setup in drastic ways. But since the PxrCamera covers almost all cases for a physically based camera system I will leave this type of plugin till later on in the series (see series chart.) Part 5: Practice Projects (Testing your brain cells) Note: Most of these projects will require you to compile the shaders into linked libraries. You should probably make sure your development environment works before attempting any of these projects. Also the solutions to the second problem can be found in the answers folder of the tutorial file. 2.1: Now that you have the basic idea of how each shader type works, you should be able to take the development environment from part one of this series and compile an example plugin. I would recommend the example pattern plugin as it can be tested fairly easily. In order to use and test the shader you will need an.args file to go with the plugin. You can find a provided.args file in the tutorial files. Remember to add the.args file to both the Renderman server directory and the Renderman studio directory if you are using Maya. 2.2 At this point you should have enough knowledge to change around the basic shaders that I have provided. This exercise involves you setting up a shader in the following way. The pattern shader should have three outputs one with an output of 1.0 and the second with an output of 0.5 and the third with an output of 0.0. The resulting node should be connected as a color to the PxrConstant BXDF node with the inputs serving the role as red, green, and blue respectively. You need not do anything with the integrator or BXDF at this point and should stick with the path tracer integrator and PxrConstant for testing your node. Your result should look something like this when applied to a simple sphere on a black backdrop.

9 Hints: In order to get the float output converted to a color you can use the PxrToFloat3 node. Don't forget to use the problem 2.2 args file to make your plugin show up in Maya, Katana or Blender. Also don't forget to name everything the same so Renderman will use the correct shader. A solution file can be found in the answers folder. Part 6: Moving Forward If you have made it this far congratulations. I know it seems like I left you with more questions than answers but in the next few lessons I hope to start answering some of them. As we continue forward we will be moving from the realm of theory and onto more concrete examples. If you have any questions or concerns with what was presented please let me know and I will be happy to address them. Till next time happy rendering!