Tutorial Art Design: renderman

OSL / Translating RenderMan RSL to Blender OSL

I decided today to write a little bit of summary about what I have learned in regards to OSL, based on my understanding of RSL.

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:

That terminal will help to see useful Error Messages or Feedback whenever the OSL shader is failed to compile or actually successfully compile.

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()...

You see how further tweaking and modification of a simple Shader can really open up our understanding on Shader Writing.

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=213
http://www.3db-site.com/html/RSL_exercises/rsl_exercises.php

OSL / Blending Mode Functions

Simple Blend Dissolve using OSL

It has been a while since last post. I have a lot to think in my mind. Basically, on one side I like to start making a more finished/polished artworks, while on the other side, I always love the idea of exploring and experimenting with creative ideas in Computer Graphics in general and especially in Blender.

I think I can do both (Quality vs Creative Quantity). Just takes a bit more time in refining.

I also want to go back to doing Animation, although at the same time, I love doing technical works: Rigging, VFX, Particles, etc.

The thing I found with Shader Writing is that this is a never-ending study and exploration. Well almost like everything in CG is like that. The more we dig, the more we found a new complexity. I like the idea of understanding the simplicity of things. Complexity is not always needed.

Anyway, for this post on OSL, I think I will just dump one big large code that is basically containing some useful functions in relation to BLENDING MODE. We probably learn about Layer Blending from Photoshop, as we know we have few Blending Modes to mix 2 layers of pixels together:

Multiply
Darken
Lighten
Dodge
Burn
etc

Most of information and code about Blending is pretty much translated from book "The Renderman Shading Language Guide" by Rudy Cortes and Saty Raghavachary.
http://www.amazon.com/The-RenderMan-Shading-Language-Guide/dp/1598632868

DESIGN PHILOSOPHY OF SHADER WRITING
I like to quote a paragraph from the book above from page 362-363 in regards to Procedural Pattern Creation and Design:
"The most effective strategy to employ toward procedural pattern generation is to divide and conquer. When presented with a pattern to synthesize, the idea is to break the pattern into distinct layers, create each layer using an independent block of code, and then combine the layers to obtain the pattern sought."

I have my own frustration when learning this Shader Writing. Sometimes it feels like re-inventing the wheels. Also, there are not many experts out there care to share their knowledge to help newbies. Lots of important documents are old and starting to break as we are moving to a more modern way. There is as if a huge gaps that artists to leap ahead in order for them to be able to take advantage of the tools.

I think we can take the analogy of Instant Ramen and real Ramen/Noodles made by hand. Or any kind of instant food (pizza, pasta, fried rice etc). Handmade takes longer but may taste a lot better and fresh and healthier too. Understanding of ingredients will make you a better chef. These days, people living in modern city got their fruits, vegetables and meats already pre-made and so easy to cook. Of course it is not always necessary to be able to cut the meat or to plant vegetables and wait for fruits, because that will not be efficient, however, a certain kind of understanding of the component will help us a lot when we are using "all purpose nodes" to create custom original texture that we needs.

More reading as recommendation:
http://www.renderman.org/RMR/Publications/

I really do learn a lot about Shader Writing from RSL (Renderman Shading Language). Slowly, hopefully, we all can gain enough knowledge to translate RSL knowledge to OSL. Somebody with good Shader Writing and OSL knowledge and experience ought to write a NEW book to help future shader writers in near future!

Now, that book above also mentioned a few times that the origin of the blending mode functions were taken from: http://www.pegtop.net/delphi/articles/blendmodes/

The "pegtop" website is the work of Jens Gruschel. So I have to thank him also for the knowledge. These are priceless bits of knowledge of the legacy of shader writing.

NOTE: In this code example, I am also using OSL syntax that load Image File from directory.

I am using these 2 images as Texture to use inside OSL:

TEAPOT A: This is a generic Blender Cycles Render of a basic teapot I modeled in Blender a while ago.

TEAPOT B: This is a photograph of this awesome limited edition Renderman walking teapot (thanks Moxy!),

Using the code below, we are loading the 2 image textures above and blend the two together.

It is very simple thing that we can easily do using Blender Mix Node, but with the idea of learning OSL Shader Writing, we are trying to recreate it with code.

The always handy MIX node.

THE "BLEND MODE" CODE

// HELPER FUNCTIONS THAT CHANGES THE BLENDING
// SOURCE:
// The RenderMan Shading Language Guide Book
// By Rudy Cortes and Saty Raghavachary
// Also: Works of Jens Gruschel (http://pegtop.net)

// OVER MODE
color colorOver(color BaseMap, color Layer, float LayerOpac){
return mix(BaseMap, Layer, LayerOpac);
}

// ADD MODE
color colorAdd(color BaseMap, color Layer, float LayerOpac){
return BaseMap + (Layer * LayerOpac);
}

// SUBSTRACT MODE
color colorSubstract(color BaseMap, color Layer, float LayerOpac){
return BaseMap + ((Layer-1) * LayerOpac);
}

// MULTIPLY MODE
color colorMultiply(color BaseMap, color Layer, float LayerOpac){
return BaseMap * ((Layer * LayerOpac) + (1-LayerOpac));
}

// COLOR DISSOLVE
color colorDissolve(color BaseMap, color Layer, float LayerOpac){
//float Random = 5.0;
//getattribute("object:random", Random);
float myRandom = noise("snoise", P * 7);
color out;
if(myRandom < (LayerOpac))
out = Layer;
else
out = BaseMap;

return out;
}

// SCREEN MODE
color colorScreen(color BaseMap, color Layer, float LayerOpac){
return 1 - ((1-BaseMap) * (1-Layer * LayerOpac));
}

// COLOR OVERLAY
color colorOverlay(color BaseMap, color Layer, float LayerOpac){
//float layerval = colorToFloat(Layer);
//float layerval = Layer[1];

// color to grayscale (luminocity method)
// READ: http://www.johndcook.com/blog/2009/08/24/algorithms-convert-color-grayscale/
float layerval = 0.21 * Layer[0] + 0.71 * Layer[1] + 0.07 * Layer[2];

return (layerval>0.5) ? (2*BaseMap*Layer*LayerOpac)+BaseMap*(1-LayerOpac):
1 - ((1-BaseMap) * (1-Layer*LayerOpac))*(2-(1-LayerOpac));
}

// COLOR DARKEN
color colorDarken(color BaseMap, color Layer, float LayerOpac){
float baseval = 0.21 * BaseMap[0] + 0.71 * BaseMap[1] + 0.07 * BaseMap[2];
float layerval = 0.21 * Layer[0] + 0.71 * Layer[1] + 0.07 * Layer[2];
return (baseval<layerval) ? BaseMap: Layer * LayerOpac + (BaseMap*(1-LayerOpac));

}

// COLOR LIGHTEN
color colorLighten(color BaseMap, color Layer, float LayerOpac){
float baseval = 0.21 * BaseMap[0] + 0.71 * BaseMap[1] + 0.07 * BaseMap[2];
float layerval = 0.21 * Layer[0] + 0.71 * Layer[1] + 0.07 * Layer[2];
return (baseval>layerval) ? BaseMap: Layer * LayerOpac + (BaseMap*(1-LayerOpac));

}

// COLOR DIFFERENCE
color colorAbs(color col){
return color(abs(col[0]), abs(col[1]), abs(col[2]));
}

color colorDifference(color BaseMap, color Layer, float LayerOpac){
return colorAbs(BaseMap - (Layer * LayerOpac));
}

// COLOR HARDLIGHT
color colorHardlight(color BaseMap, color Layer, float LayerOpac){
float layerval = 0.21 * Layer[0] + 0.71 * Layer[1] + 0.07 * Layer[2];
return (layerval<0.5) ? (2*BaseMap*Layer*LayerOpac)+BaseMap*(1-LayerOpac):1-((1-BaseMap)*(1-Layer*LayerOpac))*(2-(1-LayerOpac));

}

// COLOR SOFTLIGHT
color colorSoftlight(color BaseMap, color Layer, float LayerOpac){
color ctemp = BaseMap * Layer;
return mix(BaseMap, ctemp+(BaseMap*(1-((1-BaseMap)*(1-Layer))-ctemp)), LayerOpac);
}

// COLOR DODGE
color colorDodge(color BaseMap, color Layer, float LayerOpac){
color ctemp = mix(BaseMap, BaseMap/max(1-Layer, color(0.00001)), LayerOpac);
return clamp(ctemp, color(0), color(1));
}

// COLOR BURN
color colorBurn(color BaseMap, color Layer, float LayerOpac){
color ctemp = mix(BaseMap, 1-((1-BaseMap)/max(Layer, color(0.00001))), LayerOpac);
return clamp(ctemp, color(0), color(1));
}

shader blending (
color BaseMap = color(1,0,0),
color Layer = color (0,1,0),
float LayerOpac = 0.5,
string filenameA = "/Users/jimmygunawan/Desktop/teapotA.png" ,
string filenameB = "/Users/jimmygunawan/Desktop/teapotB.png" ,
vector Pos = P,
output color ColOut = color(0.2)
)
{

color TextureA = texture(filenameA, Pos[0], 1.0 - Pos[1]);
color TextureB = texture(filenameB, Pos[0], 1.0 - Pos[1]);

// change the BLENDING MODE using the helper function of your choice above
//ColOut = colorOver(TextureA, TextureB, LayerOpac);
//ColOut = colorBurn(TextureA, TextureB, LayerOpac);
//ColOut = colorHardlight(TextureA, TextureB, LayerOpac);
ColOut = colorDissolve(TextureA, TextureB, LayerOpac);
}

Feel free to modify and mix the code above.

QUESTION ARISE...

If we compare the built-in Blender MIX Node that does blending with the function above, we can see that the result is a bit different sometimes. I am wondering why is that happening? Is it because things got "normalized" with the premade node and more correct?

I guess I need to compare the code from the book with what comes with Blender. Further investigation needed.

However, with the above code example, we start to think about LAYERING in OSL. OSL is certainly handy for:
- Procedural Pattern and Texture creation
- Texture Mapping
- Complex Blending
- Utility

I guess, the "best" of OSL is when shader writing is used together with the node network, so this is something we (more artists than coders) can always kept in mind.

REWRITING OSL CODE FOR LAYERING

Still reading this book, but I am most interested with Chapter 12 "Procedural Patterns".

Although some part is still quite complicated to understand, the book is quite consistent in term of explaining the concept of "LAYERING" and "PROCEDURAL PATTERN".

This one example is also translated from the book to OSL. It seems complex at a glance, but this is actually simple and it explains a lot of things. I like how the code is nicely organized and every functions are separated from the main Shader code:

Helper Function to Rotate Texture in 2D: rotate2d()
Few other helper functions: pulse(), repeat(), blend()
Concept of Layering and Opacity (Masking) using code.

CODE:

// converted from book Renderman Shading Language Guide
// page 370, for shader called "Optical Illussion"
// OSL code translation by Jimmy Gunawan

// the following HELPER FUNCTIONS was translated from 'rmannotes.sl'

float pulse (
float a,
float b,
float fuzz,
float x
)
{
return (smoothstep((a)-(fuzz), (a), (x)) - smoothstep((b)-(fuzz), (b), (x)));
}

float repeat(
float x,
float freq
)
{
return (mod((x) * (freq), 1.0));
}

/*
rotate2d is taken from rmannotes.sl
2D rotation of point(x,y) about origin(ox,oy) by and angle rad.
the resulting point is (rx, ry).

*/

void rotate2d (
float x,
float y,
float rad,
float ox,
float oy,
float rx,
float ry
)
{
rx = ((x) - (ox)) * cos(rad) - ((y) - (oy)) * sin(rad) + (ox);
ry = ((x) - (ox)) * sin(rad) + ((y) - (oy)) * cos(rad) + (oy);
}

color blend(
color a,
color b,
color x
)

{
return ((a) * (1-(x)) + (b) * (x));
}


shader optill(
float fuzziness = 0.025,
float freq = 10,
float thickness1 = 0.75,
float thickness2 = 0.75,
float rot = 45,
color baseColor = color(0,0,0),
color c1 = color(1,0,0),
color c2 = color(0,1,0),
vector Pos = P,
output color ColOut = color(1)
)
{
color surface_color;
color layer_color;

color surface_opac;
color layer_opac;

float fuzz = fuzziness;
float ss;
float tt;

surface_color = baseColor;
surface_opac = color(0);

// assign pixel position as s and t
float s = Pos[0];
float t = Pos[1];

// rotate stuff in 2D
rotate2d(s,t,radians(rot), 0.5, 0.5, ss, tt);

// repeat pattern
ss = repeat(ss, freq);
tt = repeat(tt, freq);

float pwh = thickness1 * 1.0/freq;
float pwv = thickness2 * 1.0/freq;

// This is Layer 1 covering Layer 0 (Base Layer)
layer_opac = pulse(0.5-pwh, 0.5+pwh, fuzz, ss);
surface_color = blend(surface_color, c1, layer_opac);

// This is Layer 2 covering Layer 1
layer_opac = pulse(0.5-pwv, 0.5+pwv, fuzz, tt);
surface_color = blend(surface_color, c2, layer_opac);

ColOut = surface_color;

// I omited some code in relation to "Opacity"
// because I am not quite sure how it works.
// However I will revise it in the future, hopefully!

}

The result of the above code can be seen as below.

We have 3 Layers (Color):
- Base
- c1
- c2

We can then try something like below:

We are using Image Textures and using the code above to layer them together:

Thing started to get more interesting, right? I thought so too.

Some parts may still be abstract, but when the code is arranged this way, we started to see something that looks like typical 2D Layerings in 2D image editing packages.

All contained within a single node, instead of complex noodles of node network.

The book is really teaching concept of:
- MULTI LAYER
- OPACITY or MASK
- BLEND as CODE

When thinking of Shader this way, whether we are using pre-made nodes, custom procedural textures, or image textures, or combinations of everything, thing is a lot more simple. We separate the problem in layers and then we will start LAYERING the COMPLEXITY, while still having enough CONTROL to achieve the look we like.

EXPLICIT vs IMPLICIT FUNCTIONS

At this moment, perhaps for me, the hardest part of the code is to think of Pattern Creation "IMPLICITELY", instead of "EXPLICITELY".

When doing coding to draw a shape in program like Processing, we can simply say things like:
ellipse(5,5,0,0);
// draw an ellipse shape of size of 5x5 pixel at position (0,0).
// http://processing.org/reference/ellipse_.html

That's above is actually a simple function that is using EXPLICIT FUNCTIONS.

However, when doing SHADER WRITING (like OSL, OpenGL, RSL), even to create a simple shape of ellipse, we need to think kind of inside out. We are using IMPLICIT FUNCTIONS.
http://www.sciencehq.com/mathematics/implicit-and-explicit-functions.html

Labels

Movies Post

Sports

Music

Business

Pictures

728x90 AdSpace

Travel

Fashion

Design

Movies

Recent Videos

Labels

Category

Slider

Recent Post

Games

Popular Posts

Pages

Find Us On Facebook

Links

About Me

Technology

Breaking News