Tutorial Art Design: openshadinglanguage

REVIEW / Blender OSL Book

I am currently reading this book titled "Open Shading Language for Blender" by Michel Anders. This book was first mentioned at Blender Nation blog not long ago:
http://www.blendernation.com/2013/10/30/new-book-open-shading-language-for-blender/

Finally.

The very 1st book to talk about OSL in Blender! Yey~! Here it is the first original and fresh book that properly covers OSL! This is actually quite a BIG thing, although somewhat very modest. Just like when Blender goes from 2.49 to 2.5x until today, it was MAJOR, but very MODEST.

I really like that attitude, big kudos to Blender and people like Michel.

So, I got my hand on the book, it only cost under A$10 (after all money conversions) and it worths every dollars. It may be cheaper for you depending on the strength of your currency.
https://www.smashwords.com/books/view/368598

I downloaded the epub format and reading the book on iBooks (iPad).

THE AUTHOR: MICHEL ANDERS
Let's talk about the author a little bit that I knew of (by searching on Google).

This Blender OSL book is the 3rd book that Michel self-published, as mentioned here:
https://www.smashwords.com/profile/view/varkenvarken

Apart from this original OSL book, Michel also has written an active blog on OSL:
http://blenderthings.blogspot.nl

I actually read that blog a lot during my OSL study and exploration. Many shaders over there are pretty complex though!

Michel other blog:
http://michelanders.blogspot.com.au

There is some more personal trivia about the author inside the book, which is kind of nice.

TOPICS COVERED IN THE BOOK
The book started with introduction on why you would learn to write OSL code for shading and texturing.

That question above is definitely something everyone had in mind when they stumbled into something called OSL or Open Shading Language.

Some are probably happy to just use the already provided nodes (which is alright, and can get you quite far in production), while some others get more curious and like to know more about OSL and unlock its huge potential.

From intro topic, the book quickly moves to simple practical OSL shader. It covers a bit about Data types (int, float, string, void, point like data types, array, struct).

Slowly the topics ramp into important topics like: Patterns, Vectors, Normals.

I quite like one chapter titled "Mapping vectors" which covers multiplication (Scale) and Rotation of vectors. This is very important and gladly he answered this big question I had for a very long time.

From then on, Michel goes into specific simple procedural textures and shaders like the basic Checker texture, Polka Dots, before soon we get to more exotic and interesting shaders: Leopard shader, Diamondplate, etc. I have to admit that some shaders are pretty sophisticated.

Michel will give you "warning" whenever we are dealing with Math inside the shader. Math is something that often scares the artist, but we should not be because computer will do the complex calculation based on certain formula, we just need to set it up. So that is the idea that I still tell myself every now and then.

In between shader examples, he will go through and break down the Math behind it. There are thing like Symetry operations concept that explain how we can create a complex texture by mirroring it.

There is one chapter that talks about Splatter shader, where we could use our own PNG texture and randomly stamp the images, here is an example usage using my own coin.png texture (it has Alpha):

With the book, he also provided the working example files, the OSL files and Blender files. Over 80+ shaders given for you to use and to study.

MY VERDICT
I have to say that I am very happy to get hand on this book. It helps me a lot to put together my OSL knowledge so far in place. If I have time to revisit my older post on OSL, I could make the code more efficient followint the example structure of Shader shown on the book.

It is very inspiring for me. Maybe one day I write and publish my own book as well.

Many other books that talk about procedural textures (mostly for Renderman) goes really complex, too fast. But this one slowly explains what important and covers the foundation to help you move.

Similarly to myself, I think Michel put big emphasis on the procedural texture design and creations. OSL can actually do a bit more on top of procedural texture creations, however the most fun bit is the texture creation.

This book is MUST HAVE book in your library for any Shader Artists who has interest in learning OSL or shader writing in general.

MATTER OF CODING AND PROGRAMMING
Again, I have to give encouragement for "artist" who never write code before, since writing OSL shaders involves creating functions and goes further with Computer Graphics theory.

Programming ... is not hard, it just takes time to learn. I was afraid of any coding few years back, which I wish I had not been.

Just like I used to have fear of cooking and used to order foods from restaurants or just cook instant noodles in the past, well... apparently cooking from raw ingredients is not that hard.

Surely, we cannot create amazingly delicious foods at the beginning. But by time and with time, we eventually can.

Watch some movies like these for inspirations (fairly off-topic, but to make a point):
- Jiro: Dream of Sushi
- Taishoken: God of Ramen

And you will figure out soon that many of "amazing works" out there are simply taking some time to create and every skill takes dedication and passion (and obsession) to master.

I don't know what path of programming you will go through from ZERO to HERO, but I am sure you will find a way to overcome any obstacle if you continue not to give up. Remember you can always ask and there are always some nice people out there will answer when you are stuck.

Many of solutions are out there. In fact, many of tools to help you are out there as well.

Processing Programming Language
Start here:
http://www.imaginary-institute.com/blog/author/andrew/
http://funprogramming.org/
But also read some great books out there on Processing.

ChucK Music Programming -> NEW!
https://www.coursera.org/course/chuck101
http://chuck.cs.princeton.edu

There is also Pure Data, Super Collider, and Max (node based).

DESIGN BY NUMBERS by John Maeda
John Maeda's book DBN and tool to learn visual programming is a must read and explore.

Python Programming
http://learnpythonthehardway.org
And many more sources on Python. Remember that inside Blender, we already have Python to play with on any computer at any time. If you use Mac or Linux operating system, you already have Python. Even Raspberry Pi computer has Python!

There is a joy in continuosly learning and discovering, and if you are in Computer Graphics, never stop learning.

OTHER STUFFS
Crazy WebGL Mario at Shader Toy:
https://www.shadertoy.com/view/Msj3zD

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

Tutorial Art Design

Labels

Movies Post

Sports

Music

Business

Pictures

Games

728x90 AdSpace

Travel

Fashion

Design

Movies

Fashion

Sports

Recent Videos

Labels

Movies

News

Category

Slider

Recent Post

Games

Popular Posts

Pages

Find Us On Facebook

Links

About Me

Technology

Breaking News