Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

Share this Page URL
Help

Chapter 3. Shader Writing Process > Implementation - Pg. 58

58 The RenderMan Shading Language Guide Implementation After finishing your design requirements and the R&D (if necessary), you will be ready to start coding. It is advisable to write a pseudo-code description of all the steps and operations that you plan to follow to reach your goal. You can write these steps within comments so that they are inside your file and not on a piece of paper or some other file. Here is a sample of a shader in pseudo-code: /************************ * watermelon.sl * by Rudy Cortes *************************/ surface watermelon() { /* Layer 1 - Base color */ /* Layer 2 - Dark green stripes */ /* Layer 3 - Veins / Detail within the stripes */ /* Layer 5 - Markings or spots */ /* Illumination model - Use regular plastic*/ } While writing your shaders, always look out for areas in which you can stream- line your code. If you create a procedure that you think you might use again within the shader or in any other shader in the future, you might want to make a func- tion out of that procedure. If you believe the function to be usable on other shaders, then you should move it to a header file (also known as a library file). Testing and Optimization These steps go hand in hand with implementation. They are actually weaved into a loop where you code, test, and optimize over and over until you get the results you are looking for. This stage might take a long time while you find out whether your code actually works and while you constantly ask yourself how to make things faster or simpler. It is very beneficial to have a formal beta testing stage in which you provide the shader to a limited number of users so that they can use it in a production environment. Be sure to let them know that the shader is still in beta stage and not to use it for final objects. Having input from users will usually reveal bugs, misbehaviors, and sometimes design deficiencies. As the shader writer, you might have done something that makes perfect sense to you because you know the "insides" of the shader quite well, but when a user tries to use a feature you implemented, it behaves in a way that is not expected. At that point you might have to reconsider your implemen- tation. Talk to other users and ask if they also get the results the first user did. If they do, then you will have to do some recoding.