{"id":355,"date":"2015-10-23T06:21:49","date_gmt":"2015-10-23T06:21:49","guid":{"rendered":"http:\/\/magiteker.com\/?p=355"},"modified":"2016-10-24T23:10:43","modified_gmt":"2016-10-24T23:10:43","slug":"unity-shader-experiments","status":"publish","type":"post","link":"https:\/\/magiteker.com\/index.php\/2015\/10\/23\/unity-shader-experiments\/","title":{"rendered":"Unity Shader Primer"},"content":{"rendered":"

Shaders are one of the more obscure technologies within the Unity game engine, and while the documentation<\/a> covers most of the shader language and functions it fails to provide comprehensive techniques that would result in compelling graphics. They’re core focus appears to be that of treating shaders as a black box with which materials are constructed and applied to meshes and while this allows for quick iteration and prototyping of mechanics it fails to provide an intuitive means by which a\u00a0game designer can move past hobbyist levels of production value.Unity’s shader language, ShaderLab<\/b> , is based on the Nvidia CG Language<\/a> which is similar in structure to C making it somewhat obscure when it comes to translating graphical concepts to a visible program. As such in this blog post I’ll be detailing and dissecting several shaders I’ve developed after doing my own research into the subject.<\/p>\n

Setup:<\/h1>\n

 <\/p>\n

\"test_scene\"<\/p>\n

To test Unity 5.x shaders I’ve opted to first construct a scene complete with the new physically based rendering bounce lighting effect. To set this up I’ve first constructed some level geometry consisting of four walls, each a separate color, and a floor. The bounce lighting is visible on the floor geometry due to\u00a0 baked light maps Unity 5.x generates based on meshes flagged as being static in the scene. I am also utilizing the default blue skybox for global illumination.<\/p>\n

 <\/p>\n

Global Illumination<\/h2>\n
\n

\"lightsettings\"<\/p>\n

To achieve these lightmap results the following setup is used. The most important portion of these settings is the Precomputed Realtime GI which controls the amount of processing the CPU will use to construct the lightmaps.<\/p>\n

The General GI settings contains the values that affect the lighting being simulated in your scene as they influence the lightmap. The Intensity and Boost values scales the effect of each bounced light ray on a surface, when varied can create some interesting results.<\/p>\n

The atlas size is used to control the size of the baked image, the larger the image the more GPU memory your game will require.<\/p>\n

That should cover the bulk of the scene setup, it should be noted that I have my player settings setup for forward rendering since none of these examples will require using the stencil shader or altering shadows.<\/p>\n

\n<\/div>\n

<\/p>\n

Basic Shader Syntax<\/h1>\n

 <\/p>\n

In the most basic sense the job of any shader is simply to provide detail to some mesh geometry. Shaders accomplish this through a set of inputs or properties exposed by the shader program to the engine. These inputs can hold various types of data such as textures, vectors, or values. Finally using these inputs the shader computes their affect combined with a lighting model to achieve a rendered scene.<\/p>\n

The first line of a shader program contains the Shader<\/strong> keyword followed by the menu structure for unity to use within the editor, and last the name of your shader.<\/p>\n

Shader <\/strong>“SubMenu\/ShaderName”<\/strong><\/p>\n

Properties in any shader are exposed in the first section of the shader program, preceded by the keyword Properties. <\/strong>Within this code block variables are exposed using the syntax:<\/strong><\/p>\n

VariableName <\/strong>(“Variable Description<\/strong>“, Type<\/strong>) = Default Value<\/strong><\/p>\n

Once properties are defined the next code block is the SubShader<\/strong>. The subshader section contains the Tags <\/strong>section which defines the lighting model to be used with the shader, typically all that is required is “RenderType” <\/strong>= “Opaque”<\/strong> but there are many more models to experiment with.<\/p>\n

Next within the subshader block is the #pragma <\/strong> section which tells the GPU which order to execute your shader functions in, as well as any other shader functions you want to include. Tags should be followed by the CGPROGRAM <\/strong>directive to alert the compiler where your shader starts.<\/p>\n

The rest of the shader is similar to a C program wherein you would define a memory structure to access your game data along with declaring any other variables to access your property data. Within the shader function, in this case the surf<\/strong>\u00a0function, you must pass in parameters to utilize the data you need such as UV coordinates, mesh position, time, ect. Also you must define an output for your function to send back to the GPU, in this example inout SurfaceOutput o<\/strong> receives the color data of the texture _MainTex<\/strong> at the UV location stored in IN.uv_MainTex<\/strong>, these variables are passed to a standard function tex2D<\/strong> which returns the color data to o.Albedo<\/strong> to be rendered by Unity.<\/p>\n

Last you have the option of declaring a Fallback<\/strong> shader program just in case there is a problem with your custom shader.<\/p>\n

\n

\r\nShader "Custom\/ShaderExperiment1" {    \r\n\tProperties {\r\n\t  _MainTex ("Texture", 2D) = "white" {}\r\n\t}\r\n\tSubShader {\r\n\t  Tags { "RenderType" = "Opaque" }\r\n\t  CGPROGRAM\r\n\t  #pragma surface surf Lambert\r\n\t  struct Input {\r\n\t\t  float2 uv_MainTex;\r\n\t  };\r\n\t  sampler2D _MainTex;\r\n\t  void surf (Input IN, inout SurfaceOutput o) {\r\n\t\t  o.Albedo = tex2D (_MainTex, IN.uv_MainTex).rgb;\r\n\t  }\r\n\t  ENDCG\r\n\t} \r\n\tFallBack "Diffuse"\r\n}\r\n<\/pre>\n<\/p>\n
<\/p>\n
Shaders and Game Data<\/h1>\n
 <\/p>\n
This next section will explain how to alter a mesh’s texture based on internal game data, such as the gameobject’s world position.<\/p>\n
In order to implement the desired effect first the properties code block must be expanded to include a few new items. The Center<\/strong> property will define the world position vector that the shader will alter itself, and the Radius<\/strong> property which will determine how large the effect will be.<\/p>\n
The next alteration will be in the input <\/strong>struct, an extra field worldPos <\/strong>is added to access the mesh world position at runtime. Then we declare the new properties into the shader above the shader surf<\/strong> function.<\/p>\n
The surf<\/strong> function’s parameters remain unchanged since the Input<\/strong> struct was all that needed to be altered. Inside the function some math is used to determine when to change the mesh. First the distance between the Center<\/strong> and worldPos<\/strong> vectors is stored followed by a delta calculation between 1.0 and 0.0 involving that saturate<\/strong> function, which is a fancy min max function.<\/p>\n
Next the delta variable is altered using a series of step<\/strong> functions, which checks to see if the first parameter is larger than the second, essentially this is a fancy test to check if delta is larger than 0.3 and 0.25 is smaller than delta. This trick is used because shaders are more efficient at math than at doing branches, so while you can write simple if else statements you can achieve higher frame rates relying on pure math.<\/p>\n
\"\"Finally the mesh’s o.Albedo<\/strong> is assigned again using tex2D<\/strong> with its result scaled by the delta variable which sets the color to white. The end result of this shader is that a white circle, with a radius defined by the Radius<\/strong> property, will be projected onto a mesh when that mesh is moved to the position defined by the Center<\/strong> property.<\/p>\n
\n
\r\nShader "Custom\/ShaderExperiment2" {    \r\n\tProperties {\r\n\t  _MainTex ("Texture", 2D) = "white" {}\r\n\t  _Center ("Center", Vector) = (0,0,0,0)\r\n\t  _Radius ("Radius", Float) = 0.5\r\n\t}\r\n\tSubShader {\r\n\t  Tags { "RenderType" = "Opaque" }\r\n\t  CGPROGRAM\r\n\t  #pragma surface surf Lambert\r\n\t  struct Input {\r\n\t\t  float2 uv_MainTex;\r\n\t\t  float3 worldPos;\r\n\t  };\r\n\t  sampler2D _MainTex;\r\n\t  float3 _Center;\r\n\t  float _Radius;\r\n\r\n\t  void surf (Input IN, inout SurfaceOutput o) {\r\n\t\t\tfloat d = distance(_Center, IN.worldPos);\r\n\t\t\tfloat dN = 1 - saturate(d \/ _Radius);\r\n\t\t\tdN = step(0.25, dN) * step(dN, 0.3);\r\n\t\t\to.Albedo = tex2D (_MainTex, IN.uv_MainTex).rgb * (1-dN) + half3(1,1,1) * dN;\r\n\t  }\r\n\t  ENDCG\r\n\t} \r\n\tFallBack "Diffuse"\r\n}\r\n\r\n<\/pre>\n<\/p>\n
<\/p>\n
Vertex Shaders<\/h1>\n
 <\/p>\n
\"\"Since the topic of GPU’s being optimized for math has been touched upon this next section will demonstrate a method of quickly altering mesh geometry for visual effect. More specifically this shader will cause the faces of a mesh to move along the direction of the surface normals.<\/p>\n
The Properties<\/strong> code block for this shader only contains two values, a texture and a ranged float. The ranged float value will be what causes the displacement of the mesh geometry.<\/p>\n
Within the SubShader <\/strong>block the #pragma <\/strong> must be extended to contain our new vertex function by appending vertex:vert<\/strong> to the end of this line. The\u00a0vertex<\/strong> identifier tells the shader compiler that this function will operate on the mesh’s vertexes, and vert<\/strong> simply refers to the new function name. Appending this function the end of\u00a0#pragma<\/strong> means it will be the last function to be called in this shader, so after the mesh has been prepared to be rendered.<\/p>\n
The vert <\/strong>function contains a single inout <\/strong>parameter appdata_full which contains the mesh geometry we want to alter in this case. Within this function each mesh vertex is accessed sequentially then the position of that vertex is added to the scaled vector of the vertex normal by the Amount<\/strong> property. The end result being that the vertex is displaced like we wanted.<\/p>\n
 <\/p>\n
\n
\r\nShader "Custom\/ShaderExperiment3" {    \r\n\tProperties {\r\n\t  _MainTex ("Texture", 2D) = "white" {}\r\n\t  _Amount ("Extrusion Amount", Range(-2, 2)) = 0\r\n\t}\r\n\tSubShader {\r\n\t  Tags { "RenderType" = "Opaque" }\r\n\t  CGPROGRAM\r\n\t  #pragma surface surf Lambert vertex:vert\r\n\t  struct Input {\r\n\t\t  float2 uv_MainTex;\r\n\t  };\r\n\t  float _Amount;\r\n\t  void vert(inout appdata_full v)\r\n\t  {\r\n\t\tv.vertex.xyz += v.normal * _Amount;\r\n\t  }\r\n\r\n\t  sampler2D _MainTex;\r\n\t  void surf (Input IN, inout SurfaceOutput o) {\r\n\t\t\t o.Albedo = tex2D(_MainTex, IN.uv_MainTex).rgb;\r\n\t  }\r\n\t  ENDCG\r\n\t} \r\n\tFallBack "Diffuse"\r\n}\r\n\r\n<\/pre>\n<\/p>\n
<\/p>\n
Accessing Properties At Run-time<\/h1>\n
 <\/p>\n
Both of the example shaders utilize various properties to define their effects and up until now these properties were set in either the editor or the shader itself, however it is possible to access these properties at run-time via the Unity API.<\/p>\n
The API has several setters and getters<\/a> built in for assigning values to a material using a script and they all utilize a string<\/strong> to access a specific shader property. This string <\/strong>is the name assigned to the property in the shader program, i.e. to change the main texture of a material you would use the following function.<\/p>\n
SetTexture(“_MainTex”, NewTexture);<\/strong><\/p>\n
This syntax is similar for all material properties including Colors, Vectors, Matrices, Ints, and Floats, and is shared for the getters where instead of a new value you supply a default value, the important take away is that your script must contain a string with the name of the property you wish to access.<\/p>\n
It’s important to understand the difference between unity materials and instanced materials, in short when you affect a material you change every mesh that uses that material where as if you only change an instanced material your changes will only propagate to the mesh that has that material instance. To illustrate the difference both methods will be described below.<\/p>\n
Non-instanced Material Change<\/h2>\n
 <\/p>\n
There are two ways to change material property values without instancing the material, store a reference to a material in a script, or access the shared material of a game object through the Renderer <\/strong>component.<\/p>\n
Using the first method, storing a material reference, simply create a material field in your script then assign the material you wish to control using the editor. After the material is assigned you can access its properties and changes will propagate to all game objects in the scene.<\/p>\n
The second method requires the script to be attached to a game object using the material you wish to control. Then the script can utilize the GetComponent <\/strong>function to get the object’s Renderer <\/strong>component, from this component the sharedMaterial<\/strong> property can be accessed which stores a reference to your material.<\/p>\n
As an example say you want to change the color of all game enemies, using the enemy material, to a new color. Using the first method would be better in this case since the material we want to control is known and can be stored ahead of time. In which case the following function call would control the material color.<\/p>\n
enemyMaterial.SetColor(“_DiffuseColor”, newColor);<\/strong><\/p>\n
In the second method in order to change the enemy color the material must first be accessed. Its good practice to store a reference to the Renderer<\/strong> component in the script, to assign this reference use the following syntax<\/p>\n
renderer = GetComponent<Renderer>();<\/strong><\/p>\n
After storing the reference to the renderer the next step is to get the shared material which can be accessed and stored like so.<\/p>\n
enemyMaterial = renderer.sharedMaterial;<\/strong><\/p>\n
Then finally we can use the SetColor<\/strong> function just like in the first method.<\/p>\n
Instanced Material Change<\/h2>\n
 <\/p>\n
An important aside to changing materials in this way is that it will increase the draw calls your game must perform, meaning for every material you instance your game will have to draw separately which will take longer for each frame to process. Also material instancing only takes place the first time a script changes a material property per game object.<\/p>\n
For example say a script changes the color of a game object, Unity then makes an instance of that object’s material then alters the _DiffuseColor <\/strong>property value and assigns that material instance its own draw call separate from all other objects that use that material. Now whenever that game object changes color it can alter its own material without affecting other game objects.<\/p>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
Shaders are one of the more obscure technologies within the Unity game engine, and while the documentation covers most of the shader language and functions it fails to provide comprehensive techniques that would result in compelling graphics. They’re core focus appears to be that of treating shaders as a black box with which materials are […]<\/p>\n","protected":false},"author":2,"featured_media":357,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":true,"_jetpack_newsletter_tier_id":0,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false}}},"categories":[21,5],"tags":[],"class_list":["post-355","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-code","category-tutorials"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/magiteker.com\/wp-content\/uploads\/2015\/10\/shader_experiment.png?fit=822%2C463&ssl=1","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p6MIgq-5J","jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/magiteker.com\/index.php\/wp-json\/wp\/v2\/posts\/355","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/magiteker.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/magiteker.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/magiteker.com\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/magiteker.com\/index.php\/wp-json\/wp\/v2\/comments?post=355"}],"version-history":[{"count":46,"href":"https:\/\/magiteker.com\/index.php\/wp-json\/wp\/v2\/posts\/355\/revisions"}],"predecessor-version":[{"id":588,"href":"https:\/\/magiteker.com\/index.php\/wp-json\/wp\/v2\/posts\/355\/revisions\/588"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/magiteker.com\/index.php\/wp-json\/wp\/v2\/media\/357"}],"wp:attachment":[{"href":"https:\/\/magiteker.com\/index.php\/wp-json\/wp\/v2\/media?parent=355"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/magiteker.com\/index.php\/wp-json\/wp\/v2\/categories?post=355"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/magiteker.com\/index.php\/wp-json\/wp\/v2\/tags?post=355"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}