Shader Part 1

Motivation

If you have just recently got interested in shader programming then it can be hard to get to grips with to start with. This tutorial will take you through the basic steps to get a surface and a fragment shader working. It will also introduce you to some of the functions and variables in Unity’s shader includes which can differ from the documentation you find online.

You should read this article if:

You are new to shader programming in general
You want to build shaders to do cool things in your game but you can’t find one that fits your needs
Strumpy Shader Editor isn’t helping because you don’t get the basic principles
You want to manipulate textures inside your shader

This is the first of several articles that will build up to much more complex shaders. This first article is very simple indeed.

About The Author

I’m new to shader programming too – so I decided to write this guide to help people get to grips with the starting point of shaders that I had so much trouble over. I am decidedly not an expert shader programmer.

I read and re-read the documentation trying to work out what I wanted to know and it just wasn’t in the right order for me. So I thought I’d build this tutorial and share the knowledge I used. Now when I read the documentation it makes a lot more sense!

While all of the examples in this tutorial work, there maybe better ways of doing some of these things. If you know one – please add a comment!

My reason for getting into shader programming was to build something that I needed for a world populated with an endless array of different characters. I needed to build a combined mesh out of multiple parts so I only have one draw call per character.

Having enabled and disabled different items of clothing I modify the base meshes with Megafiers – then I need to have only 1 texture for all of the new models but I need to be able to colour skin, clothing and everything else differently for each character.

I came up with a plan that uses 3 tiny 4×4 textures that are unique for every character and a shader to do the work of using these to colour the model. I’m planning to fully explain this shader in this tutorial series.

Shaders & Materials

Ok so a shader‘s job is to take your mesh and render it on the screen. A shader can define a number of properties that you will use to affect what is displayed when your model is rendered – the settings of those properties when stored are a material.

Shaders come in a number of flavours:

Surface shaders – these remove most of the hard work and are great for many circumstances
Fragment shaders – make you do much more work, are harder to write, but also allow you to do low level things like Vertex lighting which is useful on mobile devices and multiple passes which are necessary for more advanced effects.

In this article we will concentrate on Surface shaders

Resources for Writing Shaders

So the three most important resources you can use for information on writing shaders are:

The Shader Pipeline

You are going to find a lot of stuff about the pipeline of shaders – I’m going to dumb this down to my level.

The job of a shader is to take some 3D geometry and turn it into pixels on a 2D screen. The good news is that you only get involved in a couple of bits of that process. For a surface shader it looks like this:

Note that you are really not setting the final color of the pixel which will be lit after your function exits, this means you can pass out a normal to affect the lighting

A fragment shader has a similar path but actually has to have the Vertex Function and needs to do a lot of work in it to work out information for the pixel part. Surface shaders hide that.

So that’s how your code is called, let’s look at what your code needs to look like:

You are going to write a shader and it’s probably going to have some properties and it will have one or more subshaders. The subshader used will depend on the platform that you are running on. You should also specify a Fallback shader that will be used if none of your subshaders can be run on the target device.

Each subshader has at least one pass at the data being brought in and the data going out. You can use these passes to perform different operations, for example in a Grab Pass you could capture the pixels that are already rendered on the display where your object will appear. This could be handy if you wanted some advanced distortion effect. When you are beginning shader programming you will probably not be doing that though! The other reason to have multiple passes is to have different things like write and ignore the depth buffer at different stages of creating your effect.

When you write a surface shader it is written directly inside the Subshader- the system compiles your code into multiple passes.

While a shader is writing to a 2D screen it is also maintaining how far away from the camera every pixel it writes is – this is so that should a subsequent piece of geometry actually be behind something that is already drawn then it won’t overwrite the pixel that is already there.You can control whether this Z buffer has any effect on your shader code or whether your shader writes to this buffer with commands inside the Pass: e.g. Zwrite Off which doesn’t update the Z buffer for anything you output.

You can use this as a technique to cut holes in other objects – by writing to the Z buffer, but never outputting any actual coloured pixels then the objects behind your model using this shader would not be written (because the Z buffer says something is there already).

So here’s some shader code:

Hopefully you can recognise the Properties section, the Subshader and the Fallback.

Understanding Shader Code Magic

The rest of this article is going to focus on understanding what magic is happening inside that simple block of code – because the magic of coding by convention is coming into play and you really have to get it.

When shader programming you are required to call things by the right name, in fact in some cases naming a variable actually makes it assume a particular value.

An Introduction to Properties

You define the properties for your shader in the Properties {…} section just inside the Shader definition. Properties are shared by all sub shaders.

Property definitions follow this format:

_Name ( “Displayed Name”, type ) = default value [{options}]

_Name is the name that this property will be referred to in your program
Displayed Name will appear in the material editor
type is the type of the property, your choices are:
- Color – the value will be a single color for the whole program
- 2D – the value is a power of 2 sized texture that can be sampled by the program for a particular pixel based on the UVs of the model
- Rect – the value is a texture that is not a power of 2 size
- Cube – the value is a 3D cube map texture used for reflections, this can be sampled by the program for a particular pixel
- Range(min, max) – the value is a floating point between a minimum and maximum value
- Float – the value is a floating point number with any value
- Vector – the value is a 4 dimensional vector
default value is the default for the property
- Color – the color expressed as a floating point representation with for parts (r,g,b,a) – e.g. (1,1,1,1)
- 2D/Rect/Cube – for the texture types the default value can be: an empty string or “white”, “black”, “gray”, “bump”
- Float/Range – the value to adopt
- Vector – the 4D vector expressed as: (x,y,z,w)
{ options } only relates to the texture types 2D, Rect and Cube – where it must be specified at least as { }. You can combine multiple options by separating them with spaces, the choices are:
- TexGen texgenmode: Automatic texture coordinate generation mode for this texture. Can be one of ObjectLinear, EyeLinear, SphereMap, CubeReflect, CubeNormal; these correspond directly to OpenGL texgen modes. Note that TexGen is ignored if you write a vertex function.

So a property might look like one of these:

//Define a color with a default value of semi-transparent red
_MainColor ("Main Color", Color) = (1,0,0,0.5)
//Define a texture with a default of white
_Texture ("Texture", 2D) = "white" {}

Note that there is no ; at the end of a property definition.

Shader Structure

Ok so let’s just review the structure of the code inside our shader:

So our CG program is written in CG language which is a lot like C with some interesting bells and whistles. Read the NVidia documentation for lots of detail – I’ll try to cover the basics. We add CGPROGRAM and ENDCG to indicate that whatever comes within is CG programming code. So between those two marks, we can use CG methods.

The most important thing is that floating point and vector variables (vec) can be defined with a number between 2 and 4 after them. This lets you make a float that has up to 4 elements and then actually deal with them individually or together!

//Define a float variable
vec2 coordinate;
//Define a color variable
float4 color;
//Multiply out a color
float3 multipliedColor = color.rgb * coordinate.x;

You can address the individual elements or the whole and you can address just a collection of the elements. You can use .xyzw and .rgba notation interchangeably to reflect what you are storing inside the variable (color, position, normal etc). Obviously you can use just float on its own for a single value. The use of the .rgba etc is known as swizzling.

You will also encounter the half and double types – these are floating point values with half and double (respectively) the resolution of a normal float. half is often used for performance reasons and is less precise. There is also fixed which is a fixed point real value.

You may want to clamp things in the range 0..1 for colors, to do that you use the saturate function, this can also use the swizzled versions e.g. return saturate(somecolor.rgb);You can find the length of a vector using the length command e.g. float size = length(someVec4.xz)

Outputting Information from a Surface Shader

So our surface function is going to be called once per pixel – the system has worked out the current values of our input structure for the single pixel we are working on. It’s basically interpolating values in the Input structure across every face of our mesh.

Let’s look at our surf function:

void surf (Input IN, inout SurfaceOutput o) 
{
     o.Albedo = tex2D (_MainTex, IN.uv_MainTex).rgb;
}

Clearly we are returning something in o.Albedo – which is in our SurfaceOutput structure that Unity has defined for us. Let’s take a quick look at that. The Albedo is the color of the pixel.

struct SurfaceOutput 
{
    half3 Albedo;      //The color of the pixel
    half3 Normal;     //The normal of the pixel
    half3 Emission;   //The emissive color of the pixel
    half Specular;     //Specular power of the pixel
    half Gloss;         //Gloss intensity of the pixel
    half Alpha;         //Alpha value for the pixel
};

You just need to return values in this structure and Unity will work out what it needs to do when it generates the actual passes behind the scenes.

I Promised You Some Magic

Let’s first look at what comes into our surf function – we’ve defined an input structure that looks like this:

struct Input {
    float2 uv_MainTex;
};

Simply by creating that structure we have told the system to get us the texture coordinate of MainTex for the current pixel each time we call the surf function. If we had a second texture called _OtherTexture we could get its uv coordinates simply by adding this:

struct Input {
    float2 uv_MainTex;
    float2 uv_OtherTexture;
};

If we had a 2nd set of uvs for the other texture we could get those too:

struct Input 
{
    float2 uv_MainTex;
    float2 uv2_OtherTexture;
};

Our Input structure normally contains a whole set of uv or uv2 coordinates for all of the textures we are using.

If our shader was complicated and needed to know other things about the pixel being shaded then we can ask for these other variables just by including them in the Input struct.

float3 viewDir – will contain view direction, for computing Parallax effects, rim lighting etc.
float4 with COLOR semantic – will contain interpolated per-vertex color.
float4 screenPos – will contain screen space position for reflection effects.
float3 worldPos – will contain world space position.
float3 worldRefl – will contain world reflection vector if surface shader does not write to o.Normal.
float3 worldNormal – will contain world normal vector if surface shader does not write to o.Normal.
INTERNAL_DATA – a structure used by some functions like WorldNormalVector to compute things when we write to o.Normal

You might be asking “What the heck’s COLOR semantic?” Well when you write a normal fragment shader you tell your input structure for that what each variable really represents, so if you were mad you could say: float2 MyUncleFred : TEXCOORD0; and MyUncleFred would be the UV of the model. With surface shaders the only one you have to worry about is COLOR. So float4 currentColor : COLOR; will be the interpolated color for this pixel. You probably don’t need to worry much about this.

Actually Doing Something

Right we are down to the last 2 lines that haven’t been fully discussed.

Sampler2D _MainTex;

For every property you have defined in the Properties section you have to put a variable in the CG program to access it. It must have the same name as the property.

When its a texture the Input structure (or whatever you call it) must use the same name after either uv or uv2 to get the texture coordinates.

The _MainTex variable is a Sampler2D linked to the main texture – it can read a pixel out of that texture given a uv coordinate.

If we had defined a _Color variable then we should define it’s property as:

float4 _Color;

So now the only functional line of our shader

o.Albedo = tex2d( _MainTex, IN.uv_MainTex).rgb;

tex2d samples _MainTex at the uv coordinates we got from the system. Because that texture is a float4 (including alpha) we need to just get the .rgb values of it for o.Albedo – if we wanted to set the alpha too (not much point in our Opaque render type) it might look like this:

float4 texColor = tex2d( _MainTex, IN.uv_MainTex );
o.Albedo = texColor.rgb;
o.Alpha = texColor.a;

Summary

You’ve read a lot of stuff and all we’ve done is build a shader that is pretty limited, but armed with this knowledge part 2 will start to build shaders that use multiple textures, normals and the like – things that actually might be cool

In part #2 we create an accumulative snow shader, where the snow level modifies the model
In part #3 we improve the snow shader to blend the snow at the margin
In part #4 we create a toon shader using black edges and ramp textures
In part #5 we create a vertex/fragment multipass bumped shader – learning all about the complexities of going beyond the surface shader paradigm.
In part #6 we create a vertex/fragment shader with a better toon effect than we managed with the surface shader in part #4

3 Comments

Fayyad Sufyan says:

April 12, 2016 at 10:58 am

Thank you very much for this great tutorial. Well done.

LikeLike

Wee Mad says:

June 16, 2016 at 9:33 am

nice tutorial

LikeLike

Taleh Masnicu says:

June 17, 2016 at 12:56 pm

Well Done, Thanks for your work!

LikeLike

Shader Part 1

Motivation

About The Author

Shaders & Materials

Resources for Writing Shaders

The Shader Pipeline

Understanding Shader Code Magic

An Introduction to Properties

Tags

Shader Structure

Outputting Information from a Surface Shader

I Promised You Some Magic

Actually Doing Something

Summary

3 Comments

Leave a comment Cancel reply

Motivation

About The Author

Shaders & Materials

Resources for Writing Shaders

The Shader Pipeline

Understanding Shader Code Magic

An Introduction to Properties

Tags

Shader Structure

Outputting Information from a Surface Shader

I Promised You Some Magic

Actually Doing Something

Summary

Share this:

3 Comments

Leave a comment Cancel reply