Over the last few months, I gained some confident in translating few RSL shaders to OSL. I am not saying I understand everything or whether my understanding is complete, in fact I am in the process of learning as well.
There are some great and complex examples of OSL shaders posted at the Blender Artist Forum, some translated from RSL, some from GLSL. However I found that many did not explain the process or the concept of translation.
Here, I am writing a step by step process of translating RSL to OSL, hopefully this is useful for everyone that is interested in learning about Shader Writing (RSL or OSL).
The RManNotes
This blog post is especially based on this priceless writing of RManNotes by Steve May, so I wanted to give him credits:http://accad.osu.edu/~smay/RManNotes/index.html
RenderMan RSL Compiling Steps
The basic RSL shader "surf1_1.sl" is taken from:http://accad.osu.edu/~smay/RManNotes/WritingShaders/surf1.html
Whenever dealing with RenderMan shaders, there are few steps that need to be done until we can see a result:
1. Write the Shader, save is as *.sl. I am using Sublime Text 2 to do my coding. For the purpose of writing a shader, any simple text editor will do, however a better editor is one that can gives syntax highlighting and more.
2. Compile the shader using the provided compiler. With PRMan (Pixar RenderMan), we do something like this: shader *.sl which then compiles the shader from *.sl to *.slo and ready to use.
3. Next, write a simple RIB file to render or prepare a 3D scene which contains a renderable geometry of some sort, on which we can then apply the compiled shader *.slo. RIB is a description of 3D scene in RenderMan context.
4. Finally, we can render the RIB or scene that uses the Shader. This can be done from the Terminal command: render myScene.RIB or in my case, I am using Pixar RenderMan for Maya and do a render of 3D scene from Maya, which will then call RenderMan to render.
Let's study the actual RenderMan RSL shader:
#include "include/rmannotes.h"
surface surf1_1()
{
color surface_color, layer_color;
color layer_opac;
// background layer
surface_color = color(0.3, 0.3, 0.3); // grey
// layer 1
layer_color = color(0,0,1); // blue
layer_opac = pulse(0.35, 0.65, 0.02, s);
surface_color = blend(surface_color, layer_color, layer_opac);
// layer 2
layer_color = color(0,1,0); // green
layer_opac = pulse(0.35, 0.65, 0.02, t);
surface_color = blend(surface_color, layer_color, layer_opac);
// output
Ci = surface_color;
}
Below my breakdown of the simple shader above:
1.
The line that says #include is basically pointing to outside/external file, typically we do this to source some useful functions that we can re-use in our code. We do NOT need to rewrite the same function or code over and over again, unless we found the need to modify the code to suit our code. This is common inside RSL and OSL as well. In above code, it is pointing to a file named "rmannotes.h". That file has some useful RSL functions that can be translated as OSL functions. I often call this as "helper functions". We can attach those functions on top of our shader code.
Here is a snippet of "rmannotes.h":
We will be translating some of those functions so they can be used inside OSL shader.
2.
Next we have the familiar syntax of a shader:
surface surf1_1()
{
<< bunch of codes... >>
}
That is a syntax to declare a Surface Shader in RSL. RSL made distinction of Surface Shader, Displacement Shader, Light Shader, Volume Shader, and so on.
Surface Shader is usually where you want to check when we like to study Procedural Texture. Inside Surface Shader, we actually specify how the surface will be shaded (as plastic, metal, glass, etc).
Probably the most fun and challenging are to observe for Shader Artist is the code that does the Procedural Texture or Pattern, how we can bend and modify the signals of abstract numbers into visible and beautiful color (when rendered out).
We also need to be aware of Texture Mapping. How Texture will actually tile across the surface.
We will get into details of the code when we are actually doing the translation from RSL to OSL.
3.
One thing I really like is the "Layering" method used by Steve May. You noticed how from the very beginning, inside the code, he is already have some kind of organisation:
- Background Layer
- Layer 1
- Layer 2
- Output
Before I read this book titled "The RenderMan Shading Language Guide" by Rudy Cortes & Saty Raghavachary, and then stumbled into the RenderMan Notes by Steve May, I have never thought of using such "Layering" method.
If you have been reading my article about OSL, you probably notice how I tend to say "FORCE" when working on texture. That "FORCE" is now basically "layer_opac"in style of Steve May shader writing code.
LAYERING IN CODES OR NODES? PROS and CONS
I had some thinking about having multiple Layers that create a single complex texture. It is certainly useful for case such as if we need: procedural banana texture/shader, procedural watermelon texture/shader, etc.I imagine if I were to recreate some Procedural Flag Texture in OSL, that would be interesting exercise. Imagine Australian flag:
1. Background: Blue Color
2. Layer 1: Some Red and White Stripes
3. Layer 2: Some Stars in white
We could write and pack all the code into one and that would be handy, it will just render as Australian flag texture under a single node.
Of course, we could also does the same thing using Node Network, which can feel simpler to understand for some artists, because we do the LAYERING in nodes.
The problem is usually in modifying the node network when the network grows or in need for some advance modifications.
Blender OSL Compiling Steps
Now, let's run Blender and translating RSL to OSL.As we may or may not already know, the compiling process of OSL code in Blender is done automatically when we press "Script Node Update" button inside Text Editor. It will then update the Script node and all kinds of Inputs, Outputs, and Render result will update on the fly.
1. Here is my Blender layout setup when I am translating RSL to OSL:
You see how at this stage, I don't see any 3D or render of the shader. I only want it to compile. At some point, I will start to check the render result of the shader while checking the node we created and compiled from the code.
Be aware that I also have Terminal active on the side:
You will have a good feeling whenever your OSL shader successfully compiled. I guarantee you this one. Of course, you will have the shader failed to compile, MANY times, beforehand.
No worries, the journey is worth the gold.
2. I start by translating from the INPUTS.
The INPUTS is usually what inside the () brackets of the shader code. The above simple shader does not have any inputs, but we could actually add our own input code as it is often required by OSL.
INPUTS IN RSL:
- Separated and ended by ; semicolons
- Value does not need to be declared specifically
- Many variable inputs, if of the same type, can be declared in one go
INPUTS IN OSL:
- Separated by , comma -- and the last variable ended with nothing
- Every variable input needs declared or default value
- Every variable input needs to be declared in separate line
3. Translating the BODY of CODE.
Now, this part can be tricky or not, depending on your experience in reading actual code and translating it. Many of the variables and terminologies are similar. However, you will find that RSL has Global Variables and functions that OSL does not have, and vice versa.
RSL has built in P, s, t, u, v.
OSL does not seem to have built in s and t variable. So I often replace it with P[0] and P[1]. 's' and 't' is related to the actual object surface. Do a Google Search to understand more about it. There is 'stu' and 'uvw'.
P = global variable of pixel position, a Vector type (X,Y,Z)
RSL has Ci and OSL also has Ci. I have to investigate further to understand the difference. I think they are both related to the output Shader and Closure.
The example Shader above from Steve May is fairly easy, we can translate the code line by line. Sometimes you see RSL code that is quite complex, don't be too hard on yourself, that code is indeed complex, and you need to understand what is really happening.
The complexity may be the actual functions use in the code and we don't know how to translate it to OSL because some syntax is different.
One important note:
Sometimes it is really quite easy to translate all the codes. But this does not mean one will understand the actual code. To gain understanding is actually takes time and effort. You will be more rewarded when you understand the code.
// STEP 001
You see how in OSL, I am defining my own INPUT-OUTPUT variable called "Col_Out". I assign a default value of color(0.1), however, that will change depending on the "surface_color" that is assigned to Col_Out at the very end of code.
I tend to test compile the shader and see-ing the result happening (or not happening). It will fail many times, I already know it beforehand. However, slowly, we will translate the code and will get a working OSL shader.
// STEP 002
Continue on, we like to recreate layer 1.
I remember naively translating the whole RSL code to OSL code like below:
Alas, it didn't work. OSL code did not compile. The whole world collapse, we have failed. *kidding* Don't get frustrated easily, this is really common to happen. You will actually get better at figuring out why it does not compile.
So, what is wrong? Check it on the Terminal:
Error Messages:
/var/folders/43/p0rcfy992nx5fzcccdy68m600000gp/T/tmpg3qr66.osl:16: error: 's' was not declared in this scope
/var/folders/43/p0rcfy992nx5fzcccdy68m600000gp/T/tmpg3qr66.osl:16: error: function 'pulse' was not declared in this scope
/var/folders/43/p0rcfy992nx5fzcccdy68m600000gp/T/tmpg3qr66.osl:17: error: function 'blend' was not declared in this scope
Error: OSL script compilation failed, see console for errors
That might scare you, but don't be. What it is really trying to tell you:
- Line 16, variable 's' not declared. OSL does not have 's' global variable unlike RSL.
- Line 16 also, function pulse() is not declared. There is no such function built in.
- Line 17, blend() is not declared.
Ok, now we can fix the code to work for OSL.
The function such as pulse() and blend() is not inside OSL. Actually it is not inside RSL either, but it was included with the code. Remember the #include line? Yes, we can do the same thing in OSL.
For now, however, we just embed the function inside our OSL shader. They will be the helper functions for our OSL code and I will append them on top before the actual shader code.
// FROM rmannotes.h
#define blend(a,b,x) ((a) * (1 - (x)) + (b) * (x))
#define pulse(a,b,fuzz,x) (smoothstep((a)-(fuzz),(a),(x)) - \
smoothstep((b)-(fuzz),(b),(x)))
// HELPER FUNCTIONS TRANSLATED TO OSL
color blend(
color a,
color b,
color x
)
{
return ((a) * (1-(x)) + (b) * (x));
}
float pulse (
float a,
float b,
float fuzz,
float x
)
{
return (smoothstep((a)-(fuzz), (a), (x)) - smoothstep((b)-(fuzz), (b), (x)));
}
You see with the OSL code, we need to be more specific with type of input variables. I have a feeling that we can actually use similar syntax as long it is in *.h --> I think this is code written in C.
Anyways, I added them into my OSL code, which now look like this:
// Helper Functions
color blend(
color a,
color b,
color x
)
{
return ((a) * (1-(x)) + (b) * (x));
}
float pulse (
float a,
float b,
float fuzz,
float x
)
{
return (smoothstep((a)-(fuzz), (a), (x)) - smoothstep((b)-(fuzz), (b), (x)));
}
// Actual Shader Code
shader myShader(
output color Col_Out = color(0.1)
)
{
color surface_color;
color layer_color;
color layer_opac;
// background layer
surface_color = color(0.3,0.3,0.3); // grey
// layer 1
layer_color = color(0,0,1); // blue
layer_opac = pulse(0.35, 0.65, 0.02, s);
surface_color = blend(surface_color, layer_color, layer_opac);
// output
Col_Out = surface_color;
}
Will the shader work now? It should work, but we have not fixed the 's' thing.
Normally my solution for s, t, u thing is to use P[0], P[1], and P[2]. So we are using the pixel position, instead of Point Position on Surface.
However, on top of that, I will use the copy of P instead and assigned it to a vector variable called Pos. What? Who? How? You might said.
Ok, here is what I tend to do:
shader myShader(
vector Pos = P,
output color Col_Out = color(0.1)
)
{
float s = Pos[0];
float t = Pos[1];
float u = Pos[2];
...
}
Watch below also how I use Texture Coordinate node in Blender and plug it into the Pos.
NOTE: I believe that it is possible to replace the Texture Coordinate node with function. But for now, I tend to have a setup like below.
By doing that, we will take care of s, t, u issue and our code will compile again, we will get something like this:
// STEP 003
Ok, so the rest of the code translation is a breeze....
We are done with the translation! Hooray! The RSL is now OSL.
We can stop here, but we could also improve the code further if we like. Not that we will make the code any better. This is the experimental part. Perhaps, we like to give user more flexibility in term of plugging INPUTS or controlling the BIAS of PULSE? Yes, we can certainly do that.
// STEP 004
I want the user to have the ability to change the COLOR of s LINE and t LINE. As well as the FUZZINESS (blur) of lines.
Let's do the FUZZINESS first:
// Helper Functions
color blend(
color a,
color b,
color x
)
{
return ((a) * (1-(x)) + (b) * (x));
}
float pulse (
float a,
float b,
float fuzz,
float x
)
{
return (smoothstep((a)-(fuzz), (a), (x)) - smoothstep((b)-(fuzz), (b), (x)));
}
// Actual Shader Code
shader myShader(
vector Pos = P,
float fuzzy = 0.02,
output color Col_Out = color(0.1)
)
{
float s = Pos[0];
float t = Pos[1];
color surface_color;
color layer_color;
color layer_opac;
// background layer
surface_color = color(0.3,0.3,0.3); // grey
// layer 1
layer_color = color(0,0,1); // blue
layer_opac = pulse(0.35, 0.65, fuzzy, s);
surface_color = blend(surface_color, layer_color, layer_opac);
// layer 2
layer_color = color(0,1,0); // green
layer_opac = pulse(0.35, 0.65, fuzzy, t);
surface_color = blend(surface_color, layer_color, layer_opac);
// output
Col_Out = surface_color;
}
Cool, now we have additional input value called 'fuzzy' to control the blurriness.
This is possible because of the clever pulse() function actually. And the pulse() function itself is a combination of 2 x smoothstep() functions. Smoothstep() function is built-in and common in RSL and OSL. Isn't that interesting?
We can have custom variable 'fuzzyA' and 'fuzzy B', to separate the blurriness of currently Green line and Blue line. Up to you to add it or not.
// STEP 005
Lastly, at least for this simple OSL shader, I want user to be able to change the COLORS that is currently set like below:
- Background = Grey
- LayerA = Blue
- LayerB = Green
// Helper Functions
color blend(
color a,
color b,
color x
)
{
return ((a) * (1-(x)) + (b) * (x));
}
float pulse (
float a,
float b,
float fuzz,
float x
)
{
return (smoothstep((a)-(fuzz), (a), (x)) - smoothstep((b)-(fuzz), (b), (x)));
}
// Actual Shader Code
shader myShader(
vector Pos = P,
float fuzzy = 0.02,
color BG = color(0.3, 0.3, 0.3),
color LayerA = color(0,0,1), // blue
color LayerB = color(0,1,0), // green
output color Col_Out = color(0.1)
)
{
float s = Pos[0];
float t = Pos[1];
color surface_color;
color layer_color;
color layer_opac;
// background layer
surface_color = BG; // grey
// layer 1
layer_color = LayerA; // blue
layer_opac = pulse(0.35, 0.65, fuzzy, s);
surface_color = blend(surface_color, layer_color, layer_opac);
// layer 2
layer_color = LayerB; // green
layer_opac = pulse(0.35, 0.65, fuzzy, t);
surface_color = blend(surface_color, layer_color, layer_opac);
// output
Col_Out = surface_color;
}
Now, we are done with the RSL to OSL translation.
You can of course further do experiment with it, such as testing what happen if we plug Image File Texture or built in procedural texture into the Color INPUTS?
... or maybe plugging Noise to the Global Pos?
You will start to see interesting result and potential modifications.
Built in Noise Texture node is cool, but what if you use the noise() function that is inside OSL?
// Helper Functions
color blend(
color a,
color b,
color x
)
{
return ((a) * (1-(x)) + (b) * (x));
}
float pulse (
float a,
float b,
float fuzz,
float x
)
{
return (smoothstep((a)-(fuzz), (a), (x)) - smoothstep((b)-(fuzz), (b), (x)));
}
// Actual Shader Code
shader myShader(
vector Pos = P,
float fuzzy = 0.02,
color BG = color(0.3, 0.3, 0.3),
color LayerA = color(0,0,1), // blue
color LayerB = color(0,1,0), // green
output color Col_Out = color(0.1)
)
{
float s = Pos[0];
float t = Pos[1];
color surface_color;
color layer_color;
color layer_opac;
// background layer
surface_color = BG; // grey
// layer 1
layer_color = LayerA; // blue
layer_opac = pulse(-0.1, 0.1, fuzzy, 2 * s * sin(t * 10));
surface_color = blend(surface_color, layer_color, layer_opac);
// layer 2
layer_color = LayerB; // green
layer_opac = pulse(-0.1, 0.1, fuzzy, t * noise(Pos*3));
surface_color = blend(surface_color, layer_color, layer_opac);
// output
Col_Out = surface_color;
}
 |
| We can see why it is called noise() and pulse()... |
Being able to write code and see the result is really handy.
So, like I said earlier, TO CODE or TO NODE, which one is best? Probably using both is the best example.
Anyway, hopefully this post is helpful for your baby steps in Shader Writing.
LINKS
http://joomla.renderwiki.com/joomla/index.php?option=com_content&view=article&id=239&Itemid=213http://www.3db-site.com/html/RSL_exercises/rsl_exercises.php
Post a Comment