Hi, I’m Ned, and I make games! Have you ever wondered how shaders work in Unity? Or, do you want to write your own shaders for the Universal Render Pipeline, but without Shader Graph? Either because you need some special feature or just prefer writing code, this tutorial has you covered.

This is the fourth tutorial in a series on HLSL shaders for URP. If you’re starting here, I recommend downloading the starting scripts, so you have something to work from.

1. Introduction to shaders: simple unlit shaders with textures.
2. Simple lighting and shadows: directional lights and cast shadows.
3. Transparency: blended and cut out transparency.
4. Physically based rendering: normal maps, metallic and specular workflows, and additional blend modes.
5. Advanced lighting: spot, point, and baked lights and shadows.
6. Advanced URP features: depth, depth-normals, screen space ambient occlusion, single pass VR rendering, batching and more.
7. Custom lighting models: accessing and using light data to create your own lighting algorithms.
8. Vertex animation: animating meshes in a shader.
9. Gathering data from C#: additional vertex data, global variables and procedural colors.

If you prefer video tutorials, here’s a link to a video version of this article.

Today, we’re diving deep into material options to give our models more realistic options. With physically based rendering (PBR), we’ll implement normal mapping, metallic workflows, more transparency blending modes, parallax occlusion, and clear coat effects. I’ll end with a section outlining techniques to optimize texture use and make the shader your own.

Before I move on, I want to thank all my patrons for helping make this series possible, and give a big shout out to my “next-gen” patron: Crubidoobidoo! Thank you all so much.

Well, let’s get started!

Physically Based Rendering. So far, we’ve used the Blinn-Phong shading algorithm in MyLit. It’s great for simple objects, but we can do better. Most rendering engines have settled on a standard shading paradigm called “physically based rendering,” commonly abbreviated as PBR. It simulates realistic lighting using a “bidirectional reflectance distribution function.” Thankfully, Unity programmed this already for the default Lit shader!

It’s easy to reuse their implementation in our MyLit shader.

In the ForwardLitPass Fragment function, change the final function call to UniversalFragmentPBR. It accepts the same arguments in Unity 2020 and 2021, making it safe to remove the #if branch.

PBR includes specular lighting by default — the #define in the shader file is not necessary.

In the scene view, things look very similar.

If you’re on Unity 2020, lower the material’s smoothness to a value between 0 and 1. In fact, we can enforce that in the inspector.

In the .shader file, change the _Smoothness property to be the Range type, with bounds 0 and 1.

The inspector renders a slider and clamps the value between the min and max.

That’s really all it takes to use PBR in your shaders, albeit a bare-bones version. We’ll implement more features shortly. Right now, notice the more realistic specular highlights. I won’t go into the math behind the BRDF or PBR algorithms in this tutorial, but if that sounds interesting, please let me know!

Debugging Views. As a shader gets more and more sophisticated, the need for better debugging tools grows. We used the frame debugger in the previous section. It’s useful for viewing draw order, but what if we need to check the value of a variable? In C#, there’s Debug.Log, but HLSL has no similar function.

Well, the fragment function outputs colors, and as we know, colors are just numbers. We can use them to visualize any value — as long as the value ranges from zero to one.

For instance, it’s helpful to output a normal vector as a color. There are a couple small steps to make that happen.

First, remap each component to range from 0 to 1. Since normal vectors are normalized, the length is always 1, and each component ranges from -1 to 1. Remap them by adding 1 and dividing by 2.

Second, Fragment outputs a float4, while normal vectors are float3s. Fix this by appending a 1 to the normal vector using a float4 constructor.

When viewing the results, you can interpret redder values as normals pointing in the positive X axis, green in the Y axis, and blue in the Z axis. Hey! The colors handily match Unity’s XYZ gizmo!

Here are the colors corresponding to each cardinal direction.

You can use this technique to visualize any value! Try outputting smoothness, UVs, or scaled world position. This is the Debug.Log of shader development — it’s a little crude, but a good place to start if you run into a problem!

The Rendering Debugger. Unity 2021 has a new feature called the Rendering Debugger which makes many common outputs automatically available. MyLit should already support a bunch of these!

The logic is inside UniversalFragmentPBR. Many views just output data fed into the InputData and SurfaceData structs.

To support a few more views, set the clip space position field in InputData…

…and add a DEBUG_DISPLAY shader feature to the forward lit pass.

There are still some views MyLit doesn’t support, in which case it will appear either black or white. As we progress through this tutorial series, these gaps will be filled. But, unfortunately, if you’re using Unity 2020, you will need to stick with old fashioned debugging methods.

Normal Mapping. You’ve probably used normal maps already if you’ve worked with 3D models at all. Also called bump maps, these textures encode directions, and modify the model’s normal vectors. Remember that normal vectors determine the strength of diffuse lighting; you can cheaply and easily add detail to a model using normal maps.

Before we implement normal mapping, let’s understand how they work. Textures store colors, but once again, these colors are just numbers. We can interpret them as normalized vectors, similarly to how we output debug normals a few paragraphs ago.

Each pixel stores one vector, remapped to range between zero and one. To reverse this, multiply by two and subtract by one. This gives us a vector centered around zero.

If you plugged in a normal map and tried to output these vectors, they would not look correct. There are two reasons. Number one: Unity encodes normal maps in a special format, optimized for normal vector storage.

This is why Unity frequently bugs you about flagging textures as normal maps in their import settings.

URP has a function to decode normal map texture samples, UnpackNormal, which also includes the remapping step.

These look slightly better, but there’s still something wrong. The normals are all bluish (pointing in the z-direction), and don’t change when the object rotates.

If you took the vector stored in the normal map and used it to apply lighting, it’s obvious we’re missing a step.

Tangent Space. Vectors in normal maps exist in a special frame of reference called tangent space. The easiest way to visualize it is to picture a globe. Up points outwards from the north pole, while right and forward point in perpendicular directions out the equator.

Now, picture yourself standing on the globe’s surface. From your perspective, up points above your head, right along your right arm, and forward in front of you. You exist in tangent space! It’s the perspective of an object standing on the surface of the mesh.

In tangent space, the up, right and forward vectors have special names. The up vector is pretty obviously the mesh’s normal vector. The forward and right vectors are called the tangent and bitangent.

Notice that these directions change (relative to world space) depending on where you stand on the globe.

That’s all well and good, but in the world of shaders, the light, camera, and all other data used in rendering are in world space. The normal vector must be as well if we want to use it in lighting calculations! Thankfully, it’s easy to convert a vector from tangent space to world space using a change of basis transform.

A basis is the mathematical name for the coordinate axes: X-Y-Z in world space or tangent-bitangent-normal in tangent space. If you have the basis directions of one space given in terms of another, it’s easy to convert points between the two spaces.

In the 2D example above, we want to convert a point from tangent space to world space. Given the tangent and bitangent directions in world space, multiply each basis direction with the corresponding component in the point vector and add the products. The point (2, 1) equals the tangent vector times two plus the bitangent vector times one.

So, we need to get the tangent-bitangent-normal basis directions in world space. We already have the normal, given to us through the mesh data. With that, we could technically pick any two vectors that are perpendicular for the tangent and bitangent. However, in shader dev, we define the tangent and bitangent so they correspond to the model’s UV coordinates.

Return to the globe and overlay it with simple UV values, resembling latitude and longitude. The U-coordinate is red while the V-coordinate is green.

The tangent vector points in the direction of growing U-value. In other words, if you walk in the tangent direction, the U-value under your feet will always increase. Similarly, the bitangent points in the direction of growing V-value.

This works out really well. Since normal maps are a texture applied to the model with UVs, the tangent and bitangent align with the texture. If you unwrap the globe and watch where the tangent and bitangent point as you walk around, from the perspective of the normal texture, they always point in the same direction.

Meshes store the tangent and bitangent vectors as a mesh data stream, just like normals or positions. With that, we now have the entire tangent space basis in world space, can convert a vector extracted from the normal map to world space, and use it for lighting.

Voila!

Phew, that was a lot of math, but I feel it’s important to really understand how normal maps work. They’re fundamental to shader development! Let’s get started programming!

Adding Normal Mapping. First open MyLit.shader and add another texture property. Flag it with two attributes. First, the NoScaleOffset attribute hides the tiling fields in the inspector. This is preferable because the normal map should match the color map. Second, this Normal attribute prompts Unity to check that any texture placed inside is correctly encoded.

White is not a good default color for normal maps. White, or one one one, will generate weird unnormalized normals pointing diagonally. The default value should act as if no normal map is present — just using the mesh vertices’s normal vectors for lighting.

The “bump” default has a value of (0.5, 0.5, 1), a periwinkle-like color, which resolves to the (0, 0, 1) tangent space vector.

In MyLitCommon.hlsl, add the texture declaration.

In the forward lit pass, we need the mesh’s tangent and bitangent vectors. Tangents are stored in a vertex data stream with the TANGENT semantic. Like NORMAL, these tangent vectors are in object space.

I did lie earlier… bitangents are not stored in the mesh, at least not directly. Instead, we can derive them from the normal vector, tangent vector, and a special bitangent sign value. Unity stores this sign value in the TANGENT semantic’s w-coordinate.

We also need the tangent and bitangent in the fragment stage, requiring a new tangent field in the Interpolators struct. It will be in world space by now, and also still contain the bitangent sign. Tag it with the next available TEXCOORD semantic.

In the Vertex function, we need to convert the tangent vector to world space. The GetVertexNormalInputs function has an overload taking the tangent vector and bitangent sign, outputting world space tangent vectors. Store this in output, passing along the bitangent sign as the W-component.

Now the Fragment function has everything it needs. First, calculate the tangent space normal vector. As mentioned earlier, Unity encodes normal maps in a special way; use the URP function UnpackNormal to decode the tangent space normal vector inside.

Next up, calculate the tangent space basis. We have the normal and tangent, but not the bitangent!

In 3D space, given any two different directions, there are exactly two directions perpendicular to both — a direction and it’s opposite! Use the bitangent sign to choose a single vector between them. URP will calculate this for us in the CreateTangentToWorld function. Pass it the normal vector, tangent vector, and bitangent sign.

It returns a float3x3 matrix, which is simply three float3 vectors stacked together. You can think of a matrix as a two-dimensional array or a list of vectors. Remember the formula to convert a vector from tangent space to world space? It’s easy to implement this in HLSL using matrix multiplication.

The function TransformTangentToWorld multiplies the tangent space normal vector (from the normal map) with the tangent to world matrix, producing a world space vector. We will use this to calculate lighting!

One final step: normalize this new normal to prevent rounding errors. Some testing is in order! Return the normal vector, remapping it appropriately.

In the scene editor, find a test normal map and, in the texture importer, set it as a normal map. Apply it to your material and make sure everything makes sense. If you remove the normal map, the displaying color should not wildly change. Rotating the model should result in rotated normal vectors.

It even works with double sided rendering! Perfect!

Return to the code and remove the test line. Then set the normal vector in lightingData.

Normal Strength. Apply the normal map to your material again and marvel at the added detail! Sometimes the lighting effect is too strong. There’s an easy way to adjust normal map strength without editing the texture.

Add a normal strength property in MyLit.shader - usually a range from zero to one is recommended.

Add the declaration to the common hlsl file.

Then, switch the UnpackNormal function with UnpackNormalScale, passing the strength.

That’s all there is to it!

Debugging Normal Maps. There’s one more wrinkle you should know about. When choosing a normal map, URP and our shader assume the bitangent points in the direction of growing-V, or from the bottom to top of the normal map. Some other programs use the opposite bitangent. Make sure your normal map follows the “OpenGL” convention and you’re good to go.

Finally, in Unity 2021, we can do a bit more to support additional views in the renderer debugger. Set the tangent to world transformation matrix in lightingData, and the tangent space normal in surfaceInput. (Even though it’s unused in 2020, normalTS does exist in SurfaceData in that version.)

Then, signal to the debugger that the shader supports normal maps by defining this _NORMALMAP keyword in the .shader file.

Now, the renderer debugger can display tangent space normals and remove normal mapping from lighting.

That’s the basics of normal mapping. There is complex math behind it, but URP does a good job helping you get by without thinking about it too much. Be sure to leverage normal maps to help your models shine.

Metallic Workflows. One cool aspect of PBR shaders is their ability to create metallic surfaces. URP’s UniversalFragmentPBR function makes metals really easy to implement in our shaders!

First, add a _Metalness float property in MyLit.shader, which ranges from zero to one.

In MyLitCommon.hlsl, declare the new property.

Then, in MyLitForwardLitPass.hlsl, sync the metallic field in surfaceData to this property.

In the scene editor, try it out! Notice how metallic strength changes the way highlights affect the material. It looks quite dark right now because reflections dominate lighting on metallic surfaces. We will set those up in the next part of this series!

Metalness Masks. Objects are rarely completely metallic, and it would be helpful to vary metalness across the mesh. This is pretty easy to do with another texture! Store metalness values in the texture and read them using UVs, like the color and normal map. Using a texture to turn on and off shader features is commonly called masking.

In your shader file, add another texture property for the metalness mask…

…and the new property to the common HLSL file.

In the Fragment function, sample the metalness mask. Since metalness is a float, only save the red channel’s value. Multiply that with the _Metalness property and set it in surfaceData.

Back in Unity, set a metallic texture in your material. Since this texture encodes special data and not colors, it’s a good idea to turn off the sRBG setting in the texture importer. This should be off for any texture that stores data, like masks or look up textures.

Regardless, only areas where the mask is white should appear metallic.

You can verify this by looking at the metallic view mode in the rendering debugger (or outputting metallic strength). Compare this with your mask by placing the mask in the color map slot.

The Specular Workflow. The Lit shader actually has two distinct modes to handle metallic surfaces: the metallic workflow and the specular workflow. The specular workflow uses a specular color texture to determine the color of specular highlights over the model. The brightness of the specular color controls the metalness at that point.

To enable specular workflow, first #define this keyword in the forward lit pass block of MyLit.shader. We’ll also need properties for the specular texture and a tint.

Define them in MyLitCommon.hlsl too.

In MyLitForwardLitPass.hlsl’s Fragment function, sample the specular map and multiply the color by the specular tint. In specular workflow mode, UniversalFragmentPBR actually ignores the metallic value. Use a #if block to set the specular color only if _SPECULAR_SETUP is enabled, and metallic otherwise.

In the scene view. Try adding a colorful specular texture and see how it affects things! Trippy. Notice that the specular highlight is kind of the inverse of the surface color — this is optics at work!

You can also inspect specular color in the renderer debugger.

You might have noticed we used a keyword to switch between metallic and specular workflows. It’s easy to add a property to toggle keywords on and off, no custom inspector code required!

In MyLit.shader, add a float property with the special Toggle attribute. The keyword name to enable and disable goes inside the attribute. The property name doesn’t really matter, just choose something relevant. Finally, set the property value to zero to disable the keyword by default.

In the forward lit pass block, replace the #define with a #pragma shader_feature_local_fragment.

In the scene editor, you can now easily switch between metallic and specular modes.

Smoothness Masks. While on the topic of specular lighting, it would be very nice to vary a model’s smoothness across its surface. We can do that with another mask texture, this time containing smoothness values.

Add a smoothness texture to the shader properties…

…declare it in the common file…

…and sample it in the forward lit pass fragment function. Using the red channel, multiply it with the preexisting _Smoothness property and set it in surfaceData.

In the scene editor, try adding a smoothness mask. Again turn off sRGB. Pretty cool, these textures go a long way!

If you work with other 3D programs, you might see some use a gloss or glossiness map — this is just another name for a smoothness map. Some others use a roughness mask, which is just the inverse of smoothness. In other words, smoothness equals one minus roughness.

If you want to use roughness in your shader, just invert the texture sample before setting it in surfaceData. You could even add a property to optionally do this! However, for the rest of this tutorial, I will just support simple smoothness masks.

I know those of you with shader experience might be cringing at our use of separate textures for all these masks. At the end of this tutorial, I will explain how we can optimize a bit. Put this in the back of your mind for now.

Transparent Blending Modes. MyLit already has full transparency support, but URP’s lit shader has a few extra transparency modes we could add: additive, multiply, and premultiplied. Additive and multiply modes are very useful for particles, while premultiplied mode helps simulate glass.

The bulk of the work lies in the custom inspector. Add a new BlendType enumeration with the four modes we’ll support: Alpha, Premultiplied, Additive, and Multiply. To store the currently selected blend mode, we’ll add another property, _BlendType, similarly to how we handled _SurfaceType. Get and set this new property in the OnGUI function.

The main difference between all these blend modes is the source and destination blend settings they employ. Remember, these instruct the renderer how to combine colors from the fragment function with colors on the screen. In UpdateSurfaceType, read the blendType property. In the switch statement where we set blend modes, add another switch in the TransparentBlend case. Inside, set the appropriate source and destination blend modes for each case.

The Alpha mode works like we’re used to, blending based on the alpha value of the source pixel. In this mode, the rasterizer multiplies the source color by the alpha value, the destination color by one minus the alpha value, and then adds them together.

Premultiplied mode assumes alpha has already been multiplied with color and stored in a texture’s RGB values. That explains the name — alpha has been previously multiplied. In this case, the source blend type should be one, so alpha isn’t applied again, but the destination should still behave like normal. Premultiplied alpha gives artists better control over how a transparent object looks — effectively, brighter pixels are more opaque.

Additive mode is mathematically the inverse of Premultiplied mode. In this mode, the source is affected by alpha, but the destination is not. The destination color is only ever added to. Additive mode lightens the scene, and is great for particle effects like lighting and fire.

Finally, Multiply mode is for specialized use. It utilizes a new blend mode, SrcColor, which is simply the source pixel’s RGB values. Multiply mode completely ignores alpha, just multiplying the source and destination together. It tends to darken the scene; sometimes useful for otherworldly effects and masking.

In MyLit.shader, don’t forget to add the new _BlendType property.

Check the new modes out in the scene! It’s cool how we can get so many effects just by manipulating blending mode.

Premultipled Mode Specular Opacity. URP further enhances Premultiplied mode by having lighting affect the material’s alpha. It’s again wonderful for glass, where specular highlights appear opaque. UniversalFragmentPBR handles everything, we only need to enable a keyword: _ALPHAPREMULTIPLY_ON.

Back in the custom inspector, enable or disable the keyword appropriately.

Then, in MyLit.shader, add a shader feature to the forward lit pass.

In the scene editor, try it out! The specular highlight definitely appears more opaque.

Emission. Some objects, like electronics or magical artifacts, have small glowing parts. It’s too expensive to use real lights for these fine details, but we can do our best with something called an emission texture! It defines glowing areas on a mesh.

Emission is easy to implement! Add an emission texture property in MyLit.shader, and an emission tint.

The HDR attribute flags the tint as a high-dynamic-range color, meaning that its components can take values greater than one. This is useful in combination with some post-processing effects, like bloom. We’ll talk more about it later in the tutorial series.

Add the new properties to the common HLSL file.

Then sample the emission texture in the forward lit Fragment function. Multiply it with _EmissionTint and store it in surfaceData.

And that’s all you need to support emission. Test it out by grabbing an emission texture and adjusting the emission tint. Note that if emission tint is black, no emission will appear.

You can check out emission in the renderer debugger. If you want to disable it temporarily, there’s an option to do that with the lighting features enumeration.

Emission works by ignoring shadows and overexposing affected areas, it doesn’t actually light the scene, unfortunately. We can fix this by tying it into baked lighting, which will happen in part five of this series!

Parallax Occlusion Mapping. URP’s Complex Lit shader has a few cool options we should look at, the first being parallax occlusion. Parallax is a method of simulating depth by scrolling textures based on their distance from the camera. We can move UVs around to simulate small divots in our material!

Let’s see how it works. First, we need another texture called a height or displacement map to determine which areas are depressed below the surface. White pixels are at the mesh’s surface, while black pixels are lowered below the surface.

Next, pretend this height map actually deforms the mesh. When evaluating the parallax for a specific UV coordinate, cast a ray from the camera, through the UV, until it hits the imaginary deformed surface. Project the impact point back onto the texture and use that new UV coordinate to sample the color map, normal map, etc.

In this way, UVs change based on view direction — more for areas depressed by the height map. The effect gives the illusion of depth.

Luckily, all the math behind the raycasting and such is handled by URP functions. To get started, add a height map and parallax strength property to MyLit.shader.

In MyLitCommon.hlsl, add declarations for these new properties.

In MyLitForwardLitPass.hlsl, rearrange code so the normal and view direction are calculated before any texture sampling. We need to calculate a new UV based on these values! In the process, use these positionWS and viewDirectionWS variables throughout the function, instead of the values in input.

The parallax occlusion mapping algorithm needs view direction in tangent space, since the imaginary surface formed by the height map exists in tangent space. URP provides a GetViewDirectionTangentSpace function to do that. Include SRP’s ParallaxMapping.hlsl file to make it available, and pass it the world space tangent (with bitangent sign), normal, and view direction vectors. GetViewDirectionTangentSpace needs the vertex normal in an unnormalized state, an important bit of info to keep in mind!

Now call the magic function, ParallaxMapping, to do the work. It requires the height map and sampler. To pass textures and samplers to functions, you must use this special macro: TEXTURE2D_ARGS. It exists to get around platform differences, similarly to texture declarations.

Then, pass ParallaxMapping the tangent-space view direction, parallax strength property, and current UV. ParallaxMapping returns the amount to offset UVs, according to the parallax algorithm explained above. Add the offset to the current UV, and be sure to use this new UV while sampling all other textures.

Check it out in the scene! Find a height map and set the parallax strength. It doesn’t take much for a really strong effect! Usually a parallax strength around 0.05 is plenty.

This is as far as Complex Lit’s parallax mapping goes, but there’s a lot more we could do with it. Would you be interested in learning more in another tutorial series? Please let me know.

Clear Coat. Besides parallax, there’s another advanced feature hidden away in the Complex Lit shader: clear coat! You know the shiny coating on car paint? Clear coat can recreate that effect.

Like emission before, it’s easy to implement. Add a clear coat strength mask and float property. Clear coat emulates a transparent coat of paint on top of a surface, so it can have its own, independent smoothness value. Add a clear coat smoothness mask and strength property as well. In the forward lit pass block, define the _CLEARCOATMAP keyword so UniversalFragmentPBR includes the calculation.

In MyLitCommon.hlsl, define the new textures and float properties.

In MyLitForwardLitPass.hlsl, sample the masks, taking their red channels and multiplying with their float properties. Set the clearCoatMask and clearCoatSmoothness fields in surfaceInput.

That’s basically it! Clear coat is useful for many different objects, like cars, furniture, or even candy. It is expensive though, basically requiring two BRDF calculations per material. Consider leaving this out if you don’t need it.

Optimizing Texture Use. With clear coat under our belt, we support just about all surface options built into URP. However, our shader has ballooned quite a bit, and now is a good time to think about slimming it down.

In future parts of this tutorial series, I’m going to stick with this general purpose, unoptimized shader. However, once you know exactly which features your personal shader requires, revisit the techniques in this section to speed it up and make it easier to use.

Step one: figure out which features you need. Always use the metallic workflow? Remove support for the specular workflow, including the specular color texture and tint. Removing expensive features like clear coat, parallax, or normal mapping is worth it. It’s also possible to toggle a feature on or off using a keyword.

Optional Features. For example, say only some of our materials need normal mapping. We can set up the inspector to disable a keyword when no normal map texture is assigned.

In MyLitCustomInspector’s UpdateSurfaceType function, use GetTexture on the material. Enable or disable the _NORMALMAP keyword based on if it returns null.

In order to call UpdateSurfaceType when the normal map changes, move the base.OnGui call in between Begin- and EndChangeCheck.

In MyLit.shader, change the #define to a #pragma shader_feature.

In MyLitForwardLitPass.hlsl, use the mesh’s normal vector if _NORMALMAP is not defined. This corresponds to a tangent-space normal vector of float3(0, 0, 1).

If you go a step farther and remove parallax mapping, you have no need of tangents in general. It’s important for performance to keep the Interpolators struct as small as possible, since each variable is more that the rasterizer has to interpolate. Using a keyword there works great.

Texture Channel Packing. Another useful technique is texture channel packing. Notice how the various mask textures only use the texture’s red channel. What if we combined several masks into one texture? For instance, we can put the metallic mask into red, smoothness into green, clear coat strength into blue, and clear coat smoothness into alpha.

Texture sampling is a big resource hog, especially on mobile platforms, and it’s very nice to merge four samples into one! You can construct this texture using Photoshop or any other photo editing software. Treat each mask as a grayscale texture and place them each in one of the color channels.

Many times, alpha channels aren’t used — they’re prime real estate for masks. If your material is always opaque, you can hide a mask in the color map’s alpha channel. The specular color and emission texture’s alpha channels are usually unused as well!

Heads up! We will be adding one more mask texture later on in this series: an occlusion mask. This controls the strength of ambient lighting across the model. If you go ahead and optimize your shader now, leave room for this texture as it’s quite important.

Adding cool surface features is one of my favorite aspects of shader development. Now, we can make metal objects, glass objects, bumpy objects, and a brand new car!

We’ve done a lot with our own material, it’s time to look outward! In the next tutorial, I will focus on a hotly anticipated topic: advanced lighting. We will learn how to support multiple point and cone lights, baked lights, occlusion textures, reflection probes, light cookies and more!

For reference, here are the final versions of the shader files after completing this tutorial, without any optimizations (as mentioned before).

If you enjoyed this tutorial, consider following me here to receive an email when the next part goes live.

If you want to see this tutorial from another angle, I created a video version you can watch here.

I want to thank my next gen patrons Michael Samuels and Kasey Vann for all their support, as well as all my patrons during the development of this tutorial: Adam R. Vierra, Alexander Thornborough, AlmostFamous Bit, Amin, Anja Irniger, Arturo Pulecio, Ben Luker, Ben Wander, Bert, bgbg, Bohemian Grape, Boscayolo, Brannon Northington, Brian Knox, Brooke Waddington, Cameron Horst, Charlie Jiao, Christopher Ellis, CongDT7, Connor Wendt, Crubidoobidoo, Dan Pearce, Daniel Sim, Danik Tomyn, Davide, Derek Arndt, Drew O’Meara, Elmar Moelzer, Eta Nol, Fabian Watermeier, Henry Chung, Howard Day, Isobel Shasha, Jack Phelps, Jay Liu, Jean-Sébastien Habigand, John Lism Fishman, John Luna, Jon Mayoh, Joseph Hirst, JP Lee, jpzz kim, JY, Kat, Kel Parke, Kyle Harrison, Lasserino, Leah Lycorea, Levino Agaser, lexie Dostal, Lhong Lhi, Lien Dinh, Lukas Schneider, Mad Science, Makoto Fujiwara, Marcin Krzeszowiec, Mattai, Max Thorne, Michael Samuels, Minh Triết Đỗ, MrShiggy, Nazarré Merchant, NotEvenAmatueR Streams, Oliver Davies, P W, Parking Lot Studio, Patrick, Patrik Bergsten, Phoenix Smith, rafael ludescher, Richard Pieterse, Robin Benzinger, Sailing On Thoughts, Sam CD-ROM, Samuel Ang, Sandro Traettino, santhosh, SausageRoll, SHELL SHELL, Shot Out Games, Simo Kemmer, Simon Jackson, starbi, Steph, Stephan Maier, Sung yup Jo, Syll art-design, T, Taavi Varm, Team 21 Studio, thearperson, Thomas Terkildsen, Tim Hart, Tomasz Patek, Tortilla Laser, ultraklei, vabbb, vertex, Vincent Loi, Voids Adrift, Wei Suo, Wojciech Marek, Yuriy T., and 杉上哲也.

If you would like to download all the shaders showcased in this tutorial inside a Unity project, consider joining my Patreon. You will also get early access to tutorials, voting power in topic polls, and more. Thank you!

If you have any questions, feel free to leave a comment or contact me at any of my social media links:

🔗 Tutorial list website ▶️ YouTube 🔴 Twitch 🐦 Twitter 🎮 Discord 📸 Instagram 👽 Reddit 🎶 TikTok 👑 Patreon ☕ Ko-fi 📧 E-mail: nedmakesgames gmail

Thanks so much for reading, and make games!

Change log:

• May 29th 2023: Update custom inspector code to add support for Unity 2022’s material variants.
• Unity Technologies: Shader Calibration Scene
• tonyflanagan: Thailand Girl — Animated
• Aleksei Vlasov ⚡ CRWDE: Phonograph
• Helindu: The ultimate glass pack (cups and bottles)
• Leandro Nicolas: Snow Globe
• Martijn Vaes: DAE — Bilora Bella 46 Camera — Game Ready Asset
• Jasper Flick “Catlike Coding”: Latlon Normal Map
• Joey de Vries: Learn OpenGL Parallax Mapping
• Francesco Coldesina: Violin Burito
• wallon: Audi R8
• Juani Forn: Korean Ornamental Dragon
• Lennart Demes: Ground 054

©️ Timothy Ned Atton 2023. All rights reserved.

All code appearing in GitHub Gists is distributed under the MIT license.

Timothy Ned Atton is a game developer and graphics engineer with ten years experience working with Unity. He is currently employed at GOLF+ working on the VR golf game, GOLF+. This tutorial is not affiliated with nor endorsed by GOLF+, Unity Technologies, or any of the people and organizations listed above. Thanks for reading!

Hi, I’m Ned, and I make games! Have you ever wondered how shaders work in Unity? Or, do you want to write your own shaders for the Universal Render Pipeline, but without Shader Graph? Either because you need some special feature or just prefer writing code, this tutorial has you covered.

This is the third tutorial in a series on HLSL shaders for URP. If you’re starting here, I would recommend at least downloading the starting scripts here, so you have something to work from.

1. Introduction to shaders: simple unlit shaders with textures.
2. Simple lighting and shadows: directional lights and cast shadows.
3. Transparency: blended and cut out transparency.
4. Physically based rendering: normal maps, metallic and specular workflows, and additional blend modes.
5. Advanced lighting: spot, point, and baked lights and shadows.
6. Advanced URP features: depth, depth-normals, screen space ambient occlusion, single pass VR rendering, batching and more.
7. Custom lighting models: accessing and using light data to create your own lighting algorithms.
8. Vertex animation: animating meshes in a shader.
9. Gathering data from C#: additional vertex data, global variables and procedural colors.

If you prefer video tutorials, here’s a link to a video version of this article.

If you talk to shader devs, few words strike more fear into their hearts than “transparency!” Well, in this video, I want to demystify transparent shaders a bit. In the process, we’ll learn about render queues, custom inspectors, blend modes, alpha clipping, winding culling, and double sided normals.

Before I move on, I want to thank all my patrons for helping make this series possible, and give a big shout out to my “next-gen” patron: Crubidoobidoo! Thank you all so much.

Let’s delay no further and get to programming!

Alpha Blending. So far, our shaders have ignored the alpha channel of the main texture, staying completely opaque. I say it’s time we changed that! Transparency is a complicated topic for many reasons, but it’s pretty easy to get started with it — just add one line to your pass block.

This Blend command determines how the rasterizer combines fragment function outputs with colors already present on the screen (or render target). These were drawn by shaders that have run before! The color returned by the fragment function is called the source color, while the color stored on the render target is called the destination color.

The rasterizer multiplies each color by some number and adds the products together, storing the result in the render target and overwriting what was already there. You can specify these multipliers using the Blend command: first the source color multiplier, then the destination color multiplier.

Blend One Zero results in fully opaque materials — the default. For transparency, we need to linearly interpolate between the source and destination colors based on the source color’s alpha. Thankfully, ShaderLab has a “source alpha” and “one minus source alpha” multiplier, perfect for our goals. Add this to your forward lit pass block.

In the scene, test out blending by lowering the alpha on your material’s color tint or slotting in a texture with an alpha channel. Unfortunately, it doesn’t take long to notice some issues. First, transparent objects don’t always blend with objects behind them.

ZWrite Modes. Remember the depth buffer from our discussion of shadow mapping? Currently, the rasterizer stores transparent objects’ positions in the depth buffer, preventing fragments behind it from ever running. We can’t blend colors with a material that was never drawn! We need a way to prevent transparent surfaces from being stored in the depth buffer.

Thankfully, this is also easy to do. Add this ZWrite Off command to your forward lit pass block. This prevents the rasterizer from storing any of this pass’s data in the depth buffer.

Now, surfaces behind this shader will always draw.

Render Queues. Hmm, but there’s still some weirdness. The skybox completely overwrites all transparent objects — due to render order.

The blend operation depends on the order objects draw to the render target. Objects behind a transparent object must draw first in order to blend with them! Thankfully, we can control draw order using render queues.

When preparing to render a scene, URP takes a look at all renderable objects and sorts them by render queue. There are a few queues you can place shaders into using a Queue tag, set in the SubShader tags block. The default setting is “Geometry”, used for opaque materials. The “Transparent” queue tag comes after Geometry. By placing MyLit into this queue, we can ensure opaque objects draw first.

There’s also a Skybox queue, which runs in-between Geometry and Transparent. Previously, the skybox rendered after MyLit, and since MyLit had ZWrite Off, the rasterizer allowed the skybox shader to overwrite it. Using the transparent queue, this is not an issue.

For debugging and a few other more advanced systems, Unity also has a RenderType tag. This should be set to either “Opaque” or “Transparent.” RenderType doesn’t affect render order, but let’s go ahead and set it now.

Now, both transparent spheres should show up in front of the skybox. Notice that the spheres even draw over each other correctly. Knowing what we do about render order, you might guess — correctly — that URP sorts objects within the same queue by distance from the camera, back to front. This is crucial for transparent shaders.

Unfortunately, this sorting does not extend to triangles within a single mesh. If you have a mesh with many pieces that overlap, they might overwrite one another. The only reliable way to fix this is to break your mesh into many pieces. Just one of the headaches you must endure while working with transparent materials…

Before moving on, take a look at the frame debugger. You can see render order and verify that each object is in the correct queue. Look under “DrawTransparentObjects!”

If for some reason you need to tweak the draw order on a material basis, every material has a queue field at the bottom of its inspector. You can change queues and even give priority to certain materials. The “Geometry+1” queue runs after all other objects in the geometry queue, but still before the skybox queue.

There’s one more bug you might have noticed: transparent objects cast fully opaque shadows. Transparent, or partial, shadows are very complicated, and I will not be covering them in this series. For better or worse, the Lit shader does not support transparent shadows either. The best we can do is disable shadows for transparent objects. But, to do that, we need to set up some C# infrastructure…

Custom Material Inspectors. If you wanted to use this shader for opaque materials like before, you could use an opaque texture and tint. However, that’s hardly an optimal solution. Since we turned z-writing off, there would be no protection from overdraw. The queue and render type would also be incorrect.

Is there a way to change these using material properties? Well, yes, but we would have to remember to set them all correctly in unison. Let’s create a custom material inspector script to easily switch between opaque and transparent modes using a single dropdown menu.

Unity editor scripts are placed in folders named “Editor,” so create that first. Inside, create a C# script called “MyLitCustomInspector.”

Open it, and delete the Start and Update functions. Change MyLitCustomInspector to inherit from ShaderGUI, which is located in the UnityEditor namespace.

There’s a lot to editor scripts, but we only need to use a couple key features. First, override the OnGUI method, which Unity calls whenever it needs to draw a material inspector. We can get the currently viewed material using the target field of MaterialEditor.

Before going any further, set up some properties in the shader file. Properties don’t only store values used in HLSL code — they also store metadata about a material. Create a Float _SurfaceType property to remember if this material is opaque or transparent. Add a HideInInspector attribute to ensure this property won’t show up in the user-facing inspector.

Next, create three Float properties for the source blend, destination blend, and z-write modes. To direct ShaderLab to use a property value in the Blend and ZWrite commands, surround the name with brackets. Do this for the ForwardLit pass. The shadow caster can use the default values of Blend One Zero and ZWrite On.

Now we need to change the Queue and RenderType tags! Unfortunately, pure ShaderLab doesn’t support variable tags - take care of this in the C# custom inspector! For now, reset the “RenderType” to “Opaque” and remove the “Queue” tag — it will default to “Geometry.”

Return to the custom inspector. Create an enum containing all “surface types” we’d like to support: opaque and transparent. Then, to add a dropdown containing all values in this enum, call EditorGUILayout.EnumPopup in OnGUI. The first argument is the UI label, while the second is the current value.

Unity stored the current value in the material’s “_SurfaceType” property. However we can’t just read it directly if we want to support serialization, undo, shader variants, and other editor features.

First, Unity encapsulates a property inside a MaterialProperty class. It passes a list to OnGUI containing a MaterialProperty instance for each property of the shader, and provides a BaseShaderGUI.FindProperty method to easily grab the one corresponding to “_SurfaceType.”

MaterialProperty stores property values as floats, but its easy to cast them to SurfaceType. Pass that as the second argument to EnumPopup — the current value. EnumPopup returns the value displayed in the popup— either what was passed or a new value the user selects. Either way, cast it back to a float and reset the value in MaterialProperty.

Surround the EnumPopup call with Begin- and EndProperty functions. These enable material variants and all their cool features — only in Unity 2022. Unfortunately, these functions don’t exist before then. Be sure to either surround them in #if blocks or just omit them if you’re working in Unity 2021 or earlier.

Now, to listen for user input and set material properties appropriately, surround EnumPopup with these Begin- and EndChangeCheck functions. EndChangeCheck returns true if the user picks a new value from the dropdown.

Create an UpdateSurfaceType function, taking the material as an argument. Call it inside the EndChangeCheck if block. UpdateSurfaceType will refresh the ZWrite mode, Blend modes, tags and shadow caster based on the _SurfaceType. Since the function runs post-input, its safe to read properties directly from the material.

Use a switch statement to refresh the material based on the SurfaceType enum. Set render queue using Material.renderQueue. Override the “RenderType” tag using SetOverrideTag. Set ZWrite and Blend properties using SetInt. There’s a handy enumeration from Unity for blend modes- include the Unity.Rendering namespace to access it. As for ZWrite, 1 corresponds to On and 0 to Off.

Lastly, to turn off shadows, we can disable the shadow caster pass. There’s SetShaderPassEnabled to handle this.

Finally, back in OnGUI, ensure a base.OnGUI call comes at the end of the method. This draws the default inspector, which includes all properties of your material without the HideInInspector attribute.

All that’s left to do is register this inspector class to our shader. In the .shader file, use the CustomEditor command inside the Shader block.

Check it out in the scene! You can now easily switch between opaque and transparent modes. Verify that everything looks good in the frame debugger too.

You might notice one issue. If you switch shaders, the material might not initialize correctly until you mess with the surface type dropdown.

The ShaderGUI class has a callback when a new shader is assigned to a material: AssignNewShaderToMaterial. Override it and leave the base call at the top. Check if the new shader is the “MyLit” shader using its name field. If true, call UpdateSurfaceType.

In addition, in Unity 2022, material variants will not update correctly unless we add one more function: ValidateMaterial. Unity calls this whenever a material property changes, either when the user edits it or a parent variant changes. Have it call UpdateSurfaceType.

Another bug squashed!

Alpha Cutouts. Is there a way to combine the flexibility of a transparent material with the performance of an opaque one? Sort of! Another common transparency strategy is called alpha testing, alpha clipping or alpha cutouts. In this mode, we use a texture like a cookie cutter to render only certain parts of a mesh.

It’s a hybrid mode! Each fragment is either fully opaque or fully transparent. No blending is required, making it safe to write to the depth buffer and cast shadows.

Supporting cutouts requires small adjustments to just about all code we’ve written so far, but let’s start with the custom inspector. Add a TransparentCutout member to the SurfaceType enum. While we’re here, rename the Transparent mode to TransparentBlend, to be more clear.

In UpdateSurfaceType, we need to set everything up for cutouts. They have the same Blend and ZWrite modes as opaque surfaces, but a different queue and render type tag. They also do cast shadows. Reorganize the switch statement to take all this into account.

AlphaTest Queue. Notably, cutouts should run in a new queue, called “AlphaTest.” This queue runs after geometry but before skybox. But, since cutouts don’t need blending, why not just use geometry? It’s a question of optimization.

Beyond enabling transparency, draw order is a powerful optimization tool! Imagine this situation: two objects have opaque shaders, but one is much more resource intensive. We’d like to minimize overdraw to prevent shading the expensive material when it’s not visible. Unity tries to achieve this with depth sorting, but it’s not always reliable.

By placing the expensive shader into a later queue, we ensure it’s drawn when more of the depth buffer is filled. Alpha cutouts are more expensive than opaque shaders, so Unity orders them later to save time!

Clip and Discard. But back to the code. In MyLitForwardLitPass.hlsl, utilize this clip HLSL function to do the work. If you pass it a number less than or equal to zero, it will discard the currently running fragment. What does that mean?

discard is a command to the rasterizer, causing it to pretend like it never invoked a particular fragment. It will short circuit the fragment function, returning immediately after clip, and throw out all data pertaining to the fragment — not writing to the depth buffer or render target. It’s as if the fragment function was never called!

We want to clip this fragment if the alpha value is less than a threshold — let’s use one-half for now. Subtract the alpha component by 0.5 and pass that to clip. To apply the color tint’s alpha, multiply it with the texture sample.

Go ahead and try it out! Grab a texture with an alpha channel and change your material to “Transparent Cutout” mode. Pretty cool, but there are several things to fix.

Alpha Cutoff. Let’s start with the easiest. Right now, we always clip pixels below 50% alpha, but that might not be appropriate. Let’s add a property to make this adjustable.

Define a “_Cutoff” property in the .shader file. It should always range between zero and one, so use the special Range property type to create a slider.

By the way, this property has a “magic” name, meaning Unity always expects the alpha cutout threshold in a property named “_Cutoff.” This is important to some advanced features, like baked lighting. For now, just make sure your property is named “_Cutoff.”

Then in MyLitForwardLitPass.hlsl, define _Cutoff near the other properties and subtract _Cutoff from alpha, instead of 0.5.

Now, you can edit your material to better match the alpha values in the texture. Next problem: we’re clipping even in blended materials! This is not only incorrect, simply having a clip function in your shader can drastically decrease performance. We should use a keyword to remove the clip line when in opaque or blended modes.

Shader Features. This will be the first time we’ve actually used a keyword to change our own code. These keywords have no value, not even true or false, so an #if block cannot parse them. Instead, test if the keyword is defined, using the defined function. A keyword is defined when it is enabled, and it is not defined if its disabled.

There’s a shortcut for this: #ifdef. Keep in mind that there is not an #elifdef for whatever reason, so I use the entire defined syntax for clarity sometimes. Anyway, use an _ALPHA_CUTOUT keyword to include or omit the clip function. Wrap the clip call in a #ifdef block and we’re good to go.

It’s possible to enable and disable keywords from C#, so take care of this in the custom inspector. In UpdateSurfaceType, enable or disable _ALPHA_CUTOUT based on the surface type.

Now, we need shader variants based on _ALPHA_CUTOUT. Moving to the .shader file, add a #pragma to generate them. Instead of multi_compile, use a shader_feature_local command. Shader features are just like multi compiles, in that they generate shader variants based on a list of keywords. The difference is in game builds.

When you build your game, or create a distributable, Unity must determine which compiled shader variants to include in the build. It gathers all shaders used by your game and starts filtering shader variants.

Unity includes all variants generated by multi_compile commands, but before including a shader_feature variant, it checks to make sure some material has the required keywords enabled. For instance, Unity only includes MyLit variants with _ALPHA_CUTOUT enabled if a material has a cutout surface type (and thus enables the _ALPHA_CUTOUT keyword).

Since this check happens at build-time, keywords which change dynamically at runtime (like the URP lighting keywords) should use multi_compile. Otherwise, use shader_feature.

Why bother with this? Well, shader variants are not cheap to compile! Shader features help optimize build time.

Shader features always have an implicit “_” in their keyword list; in other words, they always trigger a variant with none of the listed keywords enabled. Of course, that variant may or may not be used by your game, but Unity is ready for the possibility!

Finally, the local suffix indicates that the keyword is unique to this shader and will not be set globally. We set _ALPHA_CUTOUT on a material-by-material basis, so it can use local variants. Keywords set globally by URP, like _MAIN_LIGHT_SHADOWS, cannot be local. Unity has a hard limit on the number of global keywords it can support, so it’s good practice to use local variants when possible.

Your shader should look the same as before, but your FPS will thank you for this optimization!

Common HLSL Files. The next bug to tackle is shadows: objects no longer cast shadows that match their cutout shape! To fix that, clip fragments in the shadow caster pass.

First, let’s take the alpha clipping logic in MyLitForwardLitPass.hlsl and move it to a function, called TestAlphaClip. Pass the color texture sample as an argument. To make this available in MyLitShadowCasterPass.hlsl, we should add it to a separate file and #include it in both files.

Create a new “MyLitCommon.hlsl” file. Remove TestAlphaClip from MyLitForwardLitPass.hlsl and paste it here. TestAlphaClip requires a couple of properties, _Tint and _Cutoff. Properties are defined shader-wide, so it makes sense to move property definitions to the common file. Include the URP library to have access to the TEXTURE2D macros.

In MyLitForwardPass.hlsl, trim duplicated code and #include the new common code file.

Let’s take a moment and think about this. HLSL is very C++-like, and #include causes the compiler to literally copy and paste the contents of the common file over the #include line. What happens if I accidentally #include a file twice? Unity will throw an error saying a variable has already been declared.

OK, but duplicating #include lines is not common. Well, what if MyLitCommon and MyLitForwardPass also #include a file called MyMath.hlsl? Then MyMath would be duplicated!

To simplify things and prevent errors, it’s customary to wrap all code in an HLSL file inside something called a guard keyword block. First, check if a keyword is not defined (that’s what #ifndef does, it’s shorthand for #if !defined()). On the very next line, #define the guard keyword. Don’t forget the #endif at the end of the file!

Now, the first time MyMath is included, the compiler defines the guard keyword. The second time, the guard keyword is enabled, and it skips the code inside. Pretty smart! Go ahead and add guard keywords to MyLitCommon. I also add them to all HLSL files to be safe.

Clip in the Shadow Caster. After all this cleanup, your shader should still work the same. Let’s finally add clipping to the shadow caster.

First, in the .shader file, add the _ALPHA_CUTOUT shader feature to the shadow caster pass.

In MyLitShadowCasterPass.hlsl, add #include “MyLitCommon.hlsl”. At the moment, the shadow caster has no UVs to sample the main texture. We will need to pass them all the way to the fragment stage.

To do that, add a uv field to Interpolators. Each field here is another that the rasterizer has to interpolate, and it’s best to keep this struct as small as possible. Surround the uv field with an #if block, ensuring it’s only interpolated when needed. It’s not as important to do this in the Attributes struct, but it can’t hurt.

In the vertex function, transfer the UV to the output struct, again only if _ALPHA_CUTOUT is defined.

Then, in the fragment function, sample the color texture and call TestAlphaClip. We can wrap all this in an #if block too. Remember, clip discards fragments if passed a value below zero, causing the rasterizer to throw them out and not write to the depth buffer. Since the depth buffer becomes the shadow map, clipped fragments won’t show up there either.

With that, your shadows correctly match the clipped shape. Make sure you test out all modes on your material, to make sure all the #if blocks are set up correctly.

There’s one last problem I want to fix, but it requires a little more explanation…

Double Sided Rendering. Often, games use alpha clipping on flat planes, in which case everything looks fine. But if you turn on alpha clipping on a sphere, you might notice the inside becomes invisible!

Face Culling. This is another optimization technique called face culling, winding culling, or simply “culling.” The particulars aren’t important, but basically, the rasterizer determines whether it’s rendering the front or back of a triangle on the mesh. The back face is usually on the inside of a model, so the rasterizer “culls” it, or decides not to render it. If you’ve ever had weird issues importing from Blender and had to reverse faces, culling is the culprit.

In our case, we’d like to render the inside of the sphere. Luckily, it’s easy to turn off culling.

In MyLit.shader, add a new float property called _Cull. We’ll use this to set another ShaderLab command, Cull. Cull can take three different values: Off, Front and Back. Off completely turns off culling, while the other two cull one side of a triangle.

Unity has a C# enum for these options, and we can instruct the default material inspector to create a dropdown using it. In the enum, Back has an int value of two, so let’s set that as the default.

Then, add a Cull command to your forward lit and shadow caster passes, with the _Cull property in brackets.

Return to the scene and try it out. Turning off culling reveals both sides of the sphere!

Double Sided Normals. But, a new bug! The lighting is incorrect. Notice that both sides of a triangle receive the same amount of light, as if the sphere is made of paper. This is because both sides have the same normal vector — it is not automatically flipped for the back face. We need to do that ourselves.

In MyLitForwardLitPass.hlsl, flip the normal vector given to InputData if rendering the back of a triangle. To flip a vector, simply multiply it by negative one. But, how do we know which side of the triangle is rendering? The rasterizer has this information and makes it available through a special, fragment-stage-only semantic.

To grab it, simply add another argument to the Fragment function. Both the exact semantic and the argument type depend on the current platform. Thankfully, Unity provides macros to sidestep the issue. Regardless, frontFace’s type is essentially a boolean, true if the triangle front face is visible.

Unity also provides another macro to choose a value based on frontFace, like the ternary operator in C#. Use that to either multiply the normal vector by 1 or -1 before setting it in lightingInput.

So, that fixes lighting, but triangle back faces now have shadow acne. Since shadow biases also depend on normals, we need to flip them too. Unfortunately, rasterizer front face data is not available in the vertex stage — it runs before the rasterizer!

Luckily there’s another way. If we assume the normal vector should always point roughly towards the camera, we can flip it if it does not. Let’s try to keep the angle between the normal vector and the view direction less than ninety degrees. If the angle is greater, flip the normal. This brings it back within the acceptable range!

There’s a very simple function to find the angle between two vectors: the dot product. It returns the cosine of that angle. Cosine of ninety degrees is zero, and if the dot product is less than zero, the angle between the vectors is greater than ninety degrees.

Let’s implement this In MyLitShadowCasterPass.hlsl using a new FlipNormalBasedOnViewDir function. Pass it position and normal. Calculate the view direction using a built in URP function (which we also used in the forward lit fragment function). Then, only if the dot product of the normal and view direction is less than zero, multiply the normal by negative one. Return the normal.

Modify the clip space calculation to call FlipNormalBasedOnViewDir.

Back in the scene editor, it looks like there’s no more shadow acne! Mission accomplished!

This technique isn’t perfect — sometimes it creates shadows that kind of flicker as you rotate around the object. But, that’s probably preferable to shadow acne.

Face Rendering Mode. Double sided normals are not free — both the flipping operations and the front face semantic have a bit of overhead. It’s a good idea to use a keyword to turn this feature on and off. Thinking about it, there’s also no reason to ever flip normals if culling is on. This leaves only three useful configurations: back culling, no culling, and no culling with normal flipping.

Let’s address these concerns by updating the custom inspector. Create a new enum, FaceRenderingMode, to encapsulate the aforementioned modes. Similarly to the surface mode, use another hidden property to keep track of this setting. In OnGUI, add another enum dropdown controlling this new property: _FaceRenderingMode (and the appropriate surrounding functions for Unity 2022).

In UpdateSurfaceType, update the _Cull property and either enable or disable a keyword, _DOUBLE_SIDED_NORMALS. If the face rendering mode is FrontOnly, set _Cull to Back using Unity’s CullMode enum. Otherwise, turn culling off. Then, enable or disable our keyword appropriately.

Moving on to MyLit.shader, first hide the _Cull property in the inspector and remove the Enum attribute (it’s handled by code now). Second, add another hidden property for _FaceRenderingMode. Third, add a shader feature for _DOUBLE_SIDED_NORMALS to both passes.

In MyLitForwardLitPass, wrap all the normal flipping code in #if blocks. There’s a bit of trickery to hide the front face semantic when it’s not needed. It’s ugly, but it works!

In MyLitShadowCasterPass, similarly wrap the call to FlipNormalBasedOnViewDir within a #if block.

In the scene editor, try out different face rendering modes to make sure everything works as expected!

In the future, think carefully whether an object actually needs any of these options. Turning off culling can dramatically increase performance cost, and double sided normals aren’t exactly cheap either. These options are very useful for things like foliage — just don’t blindly enable them for all materials!

With that, I would consider this a fully functional shader! It supports all the basic needs: textures, lighting, shadows, transparency, and even goes above and beyond the Lit shader with double sided normals! But, of course, we’re far from done.

In the next tutorial, I will focus on more surface options! We’ll implement a new lighting model called PBR — physically based rendering — which gives more customization options to make lighting more realistic. Rough, metallic, glassy, smooth, shiny, and glowing materials are in our future!

For reference, here are the final versions of the shader files.

If you enjoyed this tutorial, consider following me here to receive an email when the next part goes live. Part 4 is available here!

If you want to see this tutorial from another angle, I created a video version you can watch here.

I want to thank Crubidoobidoo for all their support, as well as all my patrons during the development of this tutorial: Adam R. Vierra, Amin, autumnboy, Ben Luker, Ben Wander, bgbg, Bohemian Grape, Boscayolo, Brannon Northington, Brooke Waddington, Cameron Horst, Charlie Jiao, Christopher Ellis, CongDT7, Connor Wendt, Crubidoobidoo, Dan Pearce, Daniel Sim, Davide, Derek Arndt, Dongsik Gang, Elmar Moelzer, Eren Aydin, far few giants, Henry Chung, Howard Day, Isobel Shasha, Jack Phelps, John Lism Fishman, John Luna, Joseph Hirst, JP Lee, jpzz kim, JY, Kat, Kyle Harrison, Lasserino, Leafenzo (Seclusion Tower), lexie Dostal, Lhong Lhi, Lien Dinh, Lukas Schneider, Mad Science, Marcin Krzeszowiec, Mattai, Minh Triết Đỗ, Oliver Davies, P W, Patrick, Patrik Bergsten, rafael ludescher, Richard Pieterse, Robin Benzinger, Sam CD-ROM, Samuel Ang, Sandro Traettino, santhosh, SHELL SHELL, Simon Jackson, starbi, Steph, Stephan Maier, Steve DeBusschere, Syll art-design, Taavi Varm, Team 21 Studio, thearperson, Thomas Terkildsen, Tim Hart, Tomasz Patek, ultraklei, Vincent Thémereau, Voids Adrift, Wei Suo, Wojciech Marek, Xavier Larrosa Rogel

If you would like to download all the shaders showcased in this tutorial inside a Unity project, consider joining my Patreon. You will also get early access to tutorials, voting power in topic polls, and more. Thank you!

If you have any questions, feel free to leave a comment or contact me at any of my social media links:

🔗 Tutorial list website ▶️ YouTube 🔴 Twitch 🐦 Twitter 🎮 Discord 📸 Instagram 👽 Reddit 🎶 TikTok 👑 Patreon ☕ Ko-fi 📧 E-mail: nedmakesgames gmail

Thanks so much for reading, and make games!

Change log:

• May 29th 2023: Material inspector changes, required for material variants in Unity 2022.
• Unity Technologies: Shader Calibration Scene
• Martijn Vaes: DAE — Bilora Bella 46 Camera — Game Ready Asset
• tonyflanagan: Thailand Girl — Animated
• gugusheep: VR Showroom Gallery for product placement
• Helindu: The ultimate glass pack (cups and bottles)
• Leandro Nicolas: Snow Globe
• Andriy Shekh: Pine tree
• Sergej Majboroda: Studio Small 09

©️ Timothy Ned Atton 2022. All rights reserved.

All code appearing in GitHub Gists is distributed under the MIT license.

Timothy Ned Atton is a game developer and graphics engineer with ten years experience working with Unity. He is currently employed at Golf+ working on the VR golf game, Golf+. This tutorial is not affiliated with nor endorsed by Golf+, Unity Technologies, or any of the people and organizations listed above. Thanks for reading!

Hi, I’m Ned, and I make games! Have you ever wondered how lighting and shadows work in Unity? Or, do you want to write your own shaders for the Universal Render Pipeline, but without Shader Graph? Either because you need some special feature or just prefer writing code, this tutorial has you covered.

In fact, this is the second part in a series about writing HLSL shaders for URP. In this video, I will show how to add lighting to a shader. This includes a simple explanation of shadow mapping — how objects cast and receive shadows in URP — as well as an introduction to keywords and shader variants — an important concept when writing shaders!

As I publish future sections, I will update this page with links! You can also subscribe here to receive a notification when I finish part three. If you’re starting here, I would recommend following the first part, where we write a basic unlit shader. This tutorial will continue directly from it.

1. Introduction to shaders: simple unlit shaders with textures.
2. Simple lighting and shadows: directional lights and cast shadows.
3. Transparency: blended and cut out transparency.
4. Physically based rendering: normal maps, metallic and specular workflows, and additional blend modes.
5. Advanced lighting: spot, point, and baked lights and shadows.
6. Advanced URP features: depth, depth-normals, screen space ambient occlusion, single pass VR rendering, batching and more.
7. Custom lighting models: accessing and using light data to create your own lighting algorithms.
8. Vertex animation: animating meshes in a shader.
9. Gathering data from C#: additional vertex data, global variables and procedural colors.

If you prefer video tutorials, here’s a link to a video version of this article.

Before I move on, I want to thank all my patrons for helping make this series possible, and give a big shout out to my “next-gen” patron: Crubidoobidoo! Thank you all so much.

With that, let’s get started!

Blinn-Phong Shading. So far, we’ve learned to write unlit shaders, or shaders not affected by lights. Obviously, lighting is a very important aspect of rendering; programmers devote a lot of shader code to it. Luckily for us, URP provides a helper function which deals with much of it.

In URP’s “lighting.hlsl” file, there’s a function called UniversalFragmentBlinnPhong. It computes a standard lighting algorithm called the Blinn-Phong lighting model. Blinn-Phong is actually made of two components.

The first calculates diffuse lighting — what illuminates the side of an object facing towards a light.

The second calculates specular lighting — the shine or highlight that brings smooth objects to life.

Open MyLitForwardLitPass.hlsl, and in the Fragment function, call UniversalFragmentBlinnPhong. It returns a color, which we can simply return as well. UniversalFragmentBlinnPhong takes many arguments, but to keep things neat, it bundles them up into two structures. The first, called InputData, holds information about the position and orientation of the mesh at the current fragment. The second, called SurfaceData, holds information about the surface material’s physical properties, like color.

Define a variable for both. These structures have nearly a dozen fields each, but we don’t need to set them all yet. Unlike C#, structure fields must be manually initialized. To set all fields to zero, cast zero to the structure type. This looks strange, but it’s an easy way to initialize a structure without having to know all its fields.

Now, pass inputData and surfaceData to UniversalFragmentBlinnPhong.

Version Differences. Back in part one, I mentioned that there are several differences between Unity 2020 and Unity 2021. Well, here’s the first that affects our shader. In Unity 2020, URP does not have an overload of UniversalFragmentBlinnPhong that takes a SurfaceData struct. You’ll have to pass the fields individually, like below. For now, don’t worry about what each field means, we will get to them soon.

Both to keep this tutorial more organized and to help you upgrade projects in the future, I want the same code to run in Unity 2020 and Unity 2021. Thankfully, there’s an easy way to run different code depending on the current Unity version.

You might have seen a #if preprocessor command in C# — usually it omits code that should only run in the editor. #if is also available in ShaderLab and HLSL, where it’s a common sight! If the expression following #if is true, then the code in between #if and #endif will be compiled. Otherwise, the compiler will ignore it.

#if can only depend on values that are known before compiling code, like constants and number literals. Unity provides a constant called UNITY_VERSION which contains the current Unity version as an integer — basically the version with periods omitted.

So, in our fragment function, we want to switch between passing the surface data struct or its individual fields based on the Unity version. If it’s greater than or equal to “202102,” we can pass the structure. To define an else block, which works just like you would expect, use #else. Inside, call the version with individual arguments.

Anyway, now the shader code will dynamically change depending on which Unity version we’re working with. Neat!

For the future, if you need to support another possibility, you can use #elif, which is short for else-if. Here’s an example for a hypothetical Unity 2030 version.

Check out your shader in the scene editor. It’s now just a black sphere!

To get back to where we were before, we need to fill some fields in the input structs. From the color properties, we can set albedo and alpha, which are fancy names for base color and transparency. But, remember that the shader doesn’t support transparency just yet, so don’t expect it.

Normal Vectors. Next, we need something called a “normal vector.” You may know what normal vectors are from math or Unity’s physics systems, but they’re vectors that point directly outwards from a surface. Blinn-Phong uses them to find where the mesh faces a light source.

Normal vectors apply to faces, but they’re organized into a mesh vertex stream, like position or UVs. This can complicate things. There’s no problem on a sphere, but on sharp cornered meshes, like a cube, it can look like vertices have multiple normal vectors.

In reality, Unity duplicates vertices — one for each normal vector. This way, a vertex’s normal always matches the face it applies to.

Regardless, the input assembler will take care of gathering normal data. Add a new field to the Attributes struct tagged with the NORMAL semantic. These normals are also in object space, like position.

When adding a new data source to a shader, it’s useful to plan out its “journey” through your code. Blinn-Phong needs normals in the fragment stage, but they’re only accessible through the input assembler. We need to pass them through the vertex stage and interpolate them with the rasterizer.

In addition, UniversalBlinnPhong expects normals in world space, and it’s necessary to transform them at some point. We could do that in the fragment stage, but we don’t need object space normals there at all. It’s a bit more optimal to calculate world space normals in the vertex function, since it runs fewer times than the fragment function.

Using this plan, go through the code section by section and modify it as needed.

We already added a normalOS field to Attributes. Add a normalWS field to Interpolators. The rasterizer will interpolate any field tagged with a TEXCOORD semantic, so tag normal with TEXCOORD1.

Why 1 and not 0? Well, TEXCOORD0 was already taken by UVs, and two fields should not have the same semantic. The rasterizer can handle many TEXCOORD variables — two is no problem.

In the vertex function, transform the normal vector from object to world space. URP provides another function to do this, GetVertexNormalInputs, similar to the one we used for positions. Call it, and set the world space normal in the Interpolators struct.

In the fragment function, set normalWS in the InputData struct.

Before moving on, let’s think a little about what happens to the normal vector when it’s interpolated. When the rasterize interpolates vectors, it interpolates each component individually. This can cause a vector’s length to change, like in this example.

For lighting to look its best, all normal vectors must have a length of one. This requirement is common when a vector encodes a direction. We can bring any vector to a length of one using the aptly named normalize function.

normalize is kind of slow, since it has an expensive square root calculation inside. I think this step is worth it for smoother lighting — it’s especially noticeable on specular highlights — but if you’re pressed for processing power, you can skip it.

In the scene editor, we finally have lighting!

Specular Lighting. But, it’s a little flat, with only diffuse lighting. For specular highlights, URP needs a little more data, specifically world space position.

Right now, the fragment function does not have access to world space position, only pixel positions. There’s not an easy way to transform those back to world space; it’s best to pass it as another field in the Interpolators struct. Tag it with another free TEXCOORD variable. (I reorganized them a little here, just for personal preference.)

Set position in the vertex stage using URP’s handy transform function! Then, in the fragment function, set positionWS in InputData. No need to normalize here of course, since position is not a direction and can have any length.

If you move around an object using the default lit shader, you’ll notice the highlights also move slightly. This is because specular lighting depends on the view direction, or the direction from the fragment to the camera.

We can calculate this in the fragment function from world space position using another handy URP function, GetWorldSpaceNormalizeViewDir. Call it and set viewDirectionWS in InputData.

Highlights can sometimes have different colors than the albedo, and URP allows you to specify this with a specular field in the SurfaceData struct. For now, set it to white.

If you take a peek at the scene, there’s still no highlights! It turns out UniversalFragmentBlinnPhong uses a #if command internally to toggle highlights on and off. It uses a special type of constant called a keyword to do so. Keywords are sort of like boolean constants you enable using a #define command.

Shaders make extensive use of keywords to turn on and off different features. It’s faster to disable specular lighting instead of, for instance, setting specular color to black. Either option has the same visual effect, but not evaluating something is obviously quicker than throwing out the result.

However, I want specular lighting in this shader. For organization, I define keywords in the ShaderLab file for each pass, making it obvious which keywords are enabled at a glance. Add #define _SPECULAR_COLOR to your pass block.

Now — finally — highlights! But, they’re too big! URP provides an easy way to shrink them using a value called smoothness. The higher the smoothness, the smaller the highlight. Visualize a perfectly smooth metal ball; the highlight is quite focused!

For now, let’s define smoothness using a material property. Add a property called _Smoothness of the Float type to your shader.

In “MyLitForwardLitPass,” declare _Smoothness at the top of the file and set it in the SurfaceData structure.

Using the material inspector, you can control the size of the highlight using the smoothness property. Note that smoothness works differently depending on the Unity version. 2021’s implementation is much more sensitive. This is just a consequence of how URP calculates lighting behind the scenes.

One note before we move on. The shader only supports the main light for now. We should get the basics down before complicating things with additional lights, but I will show how to add support for them in part 5 of this series!

The Shadow Mapping Algorithm. So far, we’ve worked with just one object. If you create another, you’ll notice that objects with our shader neither cast nor receive shadows. These are separate concepts in the world of shaders, and we’ll need to implement both.

First, let’s investigate how URP handles shadows using an algorithm called “shadow mapping.”

The goal is finding a cheap way to check if a fragment is in shadow, with respect to a light source. Again, let’s only consider the main light.

A naive approach is to check for an object between the fragment and the light. This is very slow, since the shader needs to execute a raycast, looping through all objects in the scene. There’s got to be a faster way.

First, let’s restructure our algorithm to orient the ray starting from the light and shooting out in a straight line, intersecting our fragment and any other surfaces on the same line.

Second, notice that only one surface on the ray is lit. For every surface but the one closest to the light, there is an object between it and the light. To determine if a fragment is in shadow, simply test if the distance to the light is greater than the minimum distance among all surfaces to the light.

This reduces the problem to finding the distance from the light to the closest surface along all light rays. This kind of sounds familiar… When rendering, we draw the color of the closest surface to the camera along all “view rays.” Switch color with distance and the camera with a light and we’re in business!

How can we draw distance? Remember that colors are just numbers, so we can store distance inside the red channel of a color.

URP’s shadow mapping system does this behind the scenes. Before rendering color, it switches the camera to match the perspective of the main light. Then, it utilizes another shader pass, the shadow caster pass, to draw depth for each pixel.

We don’t want these depths to draw to the screen though. URP hijacks the presentation stage and directs it to draw to a special texture, called a render target. This specific render target, containing distances from a light, is called a shadow map, hence the algorithm name.

To calculate if a fragment is in shadow, we need our distance from the light and the distance stored in the shadow map. To sample the shadow map, we need to calculate the shadow map UV — also known as a shadow coord — corresponding to this fragment’s position. URP again comes through with a function, TransformWorldToShadowCoord, to convert world space position to a shadow coord.

URP will deal with comparing distances and sampling the shadow map if we set shadowCoord in the InputData struct. In the fragment function of “MyLitForwardLitPass.hlsl,” go ahead and do that.

Shader Variants. Similarly to specular lighting, URP toggles shadows on and off with a keyword called _MAIN_LIGHT_SHADOWS. However, what if I’m making a dark scene with no main light? In that case, I’d like to turn off shadows, but I don’t want to create a whole new shader with only this keyword undefined.

Luckily, Unity has the system of shader variants for this use case. Using this #pragma multi_compile command, we can have Unity compile a version of our shader with and without _MAIN_LIGHT_SHADOWS enabled. These two versions are called variants of our shader, or more specifically, variants of the forward lit pass.

Multi compile can also take a whole list of keywords, in which case it will create multiple variants, one with each individual keyword enabled

By adding a single underscore, it will also compile a variant with none of the keywords enabled.

Even more conveniently, materials will automatically choose the correct variant for the situation at hand.

You see, if you want to use a variant with _MAIN_LIGHT_SHADOWS defined, simply call EnableKeyword(“_MAIN_LIGHT_SHADOWS”) on the material in C#. DisableKeyword will undefine the keyword. URP does this automatically if it detects a directional light in the scene.

Check it out! Create an object with a default lit material and move it in between your my lit object and the light.

Shadow Cascades and Soft Shadows. If you don’t see shadows, turn off cascades and soft shadows on your URP settings asset. It would be nice to support both of those options for better quality though.

We’ve been talking like the main light has a position, but since it models the sun, it is actually infinitely far away from everything in the scene. This makes it difficult to create a shadow map containing the entire scene while keeping enough detail for good quality. Unity tries to balance this with cascades, where it renders multiple shadow maps, each containing larger slices of the scene, and samples the one with the most detail at any position.

Since the shadow map has square pixels, you sometimes see their jagged edges manifest on surfaces. Soft shadows help eliminate these artifacts by sampling the shadow map a few times around the given shadow coord. It averages these samples, effectively blurring the shadow map a bit.

We don’t need to worry about the details of either system though. We only need to enable two keywords and URP will take care of the rest.

Add more multi compile commands for these new keywords. With multiple multi compile commands, Unity will permute each and create a variant for every possible combination of keywords. We’ve barely started, but that’s already six variants. Each takes time to compile, so it’s worth it to keep this number low.

With that in mind, Unity 2021.2 tweaked the cascade system a little. In 2020, we must enable keywords for main light shadows and cascades, but in 2021, enabling cascades implies main light shadows are enabled. We can handle both using a #if block and reduce variant count in 2021.

Also, notice the _fragment suffix in the soft shadows pragma? We can save a little more compile time by signaling the _SHADOWS_SOFT keyword is only used in the fragment stage. Unity will have the variants created by this multi compile command share a vertex function.

With that, let’s test things out. Be sure to tweak shadow cascades and enable soft shadows to see all your shader variants at work. You can see URP dynamically compiling shader variants when your shader momentarily flickers magenta.

Unity 2022 has additional options for shadow quality: high quality soft shadows and a “conservative enclosing sphere” for shadow cascades. Try enabling them to see what they do — no code changes required.

The Frame Debugger. Now seems like a good time to introduce a powerful debugging tool: the Frame Debugger! Find it in the “Window” dialog under “Analysis.” Enable it using this button in the top left. Make sure your game view is visible — It will also automatically pause if it’s running.

This useful window tells you all kinds of information about how Unity renders your scene. It renders objects in the order they appear in the menu. You can see Unity creating the shadow map before rendering lit passes. You can even check out how the shadow map looks.

The frame debugger also tells you which shader variant is currently active for any object. Navigate to the “DrawOpaqueObjects” dropdown and find your sphere. Check the shader name, it will be “MyLit!”

You can see the current subshader and pass, and under that a list of defined keywords determining the shader variant. Try disabling soft shadows, cascades, and the main light game object and to see how that influences things.

The window doesn’t do a good job of keeping the same object selected, and you’ll have to find your shader again as you toggle things on and off. There will also be slight differences depending on your Unity version, so keep that in mind.

The Shadow Caster Pass. You may have tried to apply the MyLit shader to your shadow caster sphere and noticed it no longer casts shadows. That’s because casting and receiving shadows are completely different processes in 3D rendering, and we haven’t dealt with casting yet!

In the previous section, I mentioned URP creates a shadow map texture using another shader pass, called the shadow caster pass. All we have to do to add shadow casting to MyLit is write this pass.

Remember, passes are shader subdivisions with their own vertex and fragment functions. Passes can also have their own multi compile keywords and shader variants. Each shader pass has a specific job, as given by URP. The UniversalForward (forward lit) pass calculates final pixel color, while the ShadowCaster pass calculates data for the shadow map.

Honestly, it’s much simpler in practice than it sounds. URP takes care of calling the correct pass at the correct time and routing the output colors into the correct target. These abstract passes are hard to visualize, so let’s get something written.

Begin by adding another Pass block to the “MyLit.shader” file. Duplicate the ForwardLit pass, changing the name and light mode tag to ShadowCaster. There will be no lighting here; delete the _SPECULAR_COLOR define and the shader variant pragmas.

For organization, I like to write each pass in its own HLSL file. Change the #include to refer to “MyLitShadowCasterPass.hlsl.” Then, create a new HLSL file called “MyLitShadowCasterPass.hlsl.”

Inside, start by defining the data structs. In Attributes, we’ll only need position, while Interpolators only needs clip space position. In the vertex function, call the URP function to convert position to clip space, set it in the output structure, and return it. In the fragment function, simply return zero.

The Depth Buffer. But wait, isn’t the shadow map supposed to encode distance from the light-camera? It does, but the renderer handles this automatically. See, clip space positions encode something called depth, which is related to distance from the camera. When interpolating, the rasterizer stores the depth of each fragment in a data structure called the depth buffer.

Unity utilizes the depth buffer to help reduce overdraw. Overdraw occurs when two or more fragments with the same pixel position are rendered during a frame. When everything is opaque, as it is now, only the closer fragment is ultimately displayed. Any other fragments are discarded, leading to wasted work. The rasterizer can avoid calling a fragment function if its depth is greater than the stored value in the depth buffer.

URP reuses the depth buffer resulting from the shadow caster pass as the shadow map. But, most other passes have a depth buffer of their own as well.

Shadow Acne. Our MyLit objects should now cast shadows, but you will see some ugly artifacts called shadow acne covering them.

This occurs mostly on the surface of a shadow casting object. It’s another consequence of every programmer’s bane: floating point errors. In this case, the shadow map depth and the mesh depth are nearly equal, so the system sometimes draws the shadow on top of the casting surface.

To fix acne, apply a bias, or offset the shadow caster vertex positions. When calculating clip space positions, there’s no rule that they must exactly match the mesh. We can offset the positions away from the light and also along the mesh’s normals. Both of these biases help prevent shadow acne.

The shadow caster now needs normals, so add a normal field to the Attributes struct. Then, write a new function, GetShadowCasterPositionCS, to calculate the offset clip space position. It requires world space position and normal.

ApplyShadowBias from URP’s library will read and apply shadow bias settings. It requires world space position and normal, as well as the rendering light’s direction. URP provides this in a global variable called _LightDirection. We need to define it, like a material property. Do that above the function and pass it to ApplyShadowBias. ApplyShadowBias returns a position in world space. Transform it to clip space using another URP function, TransformWorldToHClip.

Clip space has depth boundaries, and if we accidentally overstep them when applying biases, the shadow could disappear or flicker. The boundary of depth is defined by something called the “light near clip plane.” Clamp the clip space z-coordinate by the near plane value, defined by UNITY_NEAR_CLIP_VALUE.

To make things more complicated, certain graphics APIs reverse the clip space z-axis. Thankfully, URP provides another boolean constant, UNITY_REVERSED_Z, to tell us if the boundary is a minimum or maximum. Use a #if statement to handle both cases and return the final clip space position.

In the vertex function, calculate the world space position and normal using URP’s conversion functions, then call your custom shadow caster clip space function.

Back in the scene editor, things might look immediately better. If not, edit the shadow bias settings and light near clip plane on the main light component.

You can set global bias settings on the URP settings asset too.

ColorMask. Before wrapping up, we can optimize the shadow caster a little by adding some metadata to the pass block. Since the shadow caster only uses the depth buffer, we can basically turn off color using the ColorMask command.

This ColorMask 0 command does just that, basically directing the renderer to write no color. By default, ColorMask is set to RGBA, which is what we want in the forward lit pass, for example. With this setting it draws all color channels.

Lighting and shadows are some of the most fun aspects of shaders, and we will be revisiting them much more throughout this series. After this tutorial, you have a good groundwork to continue with more complicated features. We’ve got point lights, spot lights, baked lights, emission, screen space shadows and more to get to!

However, in the next tutorial, I will pivot to transparency. We’ll learn how to create transparent shaders and how to handle their idiosyncrasies. I’ll also introduce some of URP’s powerful optimization tools.

For reference, here are the final versions of the shader files.

If you enjoyed this tutorial, consider following me here to receive an email when the next part goes live.

If you want to see this tutorial from another angle, I created a video version you can watch here.

I want to thank Crubidoobidoo for all their support, as well as all my patrons during the development of this tutorial: 42 Monkeys, Adam R. Vierra, Adoiza, Amin, Andrei Hingan, Ben Luker, Ben Wander, bgbg, Bohemian Grape, Brannon Northington, bruce li, Cameron Horst, Charlie Jiao, Christopher Ellis, Connor Wendt, Constantine Miran, Crubidoobidoo, Davide, Derek Arndt, Elmar Moelzer, Eric Bates, etto space, Evan Malmud, far few giants, FELIX, Florian Faller, gamegogojo, gleb lobach, Howard Day, Huynh Tri, Isobel Shasha, Jack Phelps, Jesse Comb, jesse herbert, John Lism Fishman, JP Lee, jpzz kim, Kyle Harrison, Leafenzo (Seclusion Tower), lexie Dostal, Lhong Lhi, Lien Dinh, Lukas Schneider, Luke Hopkins, Luke O Reilly, Mad Science, Marcin Krzeszowiec, martin.wepner, maxo, Minori Freyja, Nate Ryman, Oliver Davies, Oskar Kogut, P W, Patrick, Patrik Bergsten, Paul, Petr Škoda, Petter Henriksson, rafael ludescher, Rhi E., Richard Pieterse, roman, Ryan Smith, Sam CD-ROM, Samuel Ang, Sebastian Cai, Seoul Byun, shaochun, SHELL SHELL, Simon Jackson, starbi, Steph, Stephan Maier, teadrinker, Team 21 Studio, thearperson, Tim Hart, Tomáš Jelínek, Vincent Thémereau, Voids Adrift, Wei Suo, Wojciech Marek, Сергей Каменов, Татьяна Гайдук, 智則 安田, 이종혁.

If you would like to download all the shaders showcased in this tutorial inside a Unity project, consider joining my Patreon. You will also get early access to tutorials, voting power in topic polls, and more. Thank you!

If you have any questions, feel free to leave a comment or contact me at any of my social media links:

🔗 Tutorial list website ▶️ YouTube 🔴 Twitch 🐦 Twitter 🎮 Discord 📸 Instagram 👽 Reddit 🎶 TikTok 👑 Patreon ☕ Ko-fi 📧 E-mail: nedmakesgames gmail

Thanks so much for reading, and make games!

Changelog:

• May 29th 2023: Mention new shadow quality options available in Unity 2022.
• Unity Technologies: Shader Calibration Scene
• Martijn Vaes: DAE — Bilora Bella 46 Camera — Game Ready Asset
• tonyflanagan: Thailand Girl — Animated
• Aleksei Vlasov ⚡ CRWDE: Phonograph
• gugusheep: VR Showroom Gallery for product placement
• Andreas Mischok: Drackenstein Quarry

©️ Timothy Ned Atton 2022. All rights reserved.

All code appearing in GitHub Gists is distributed under the MIT license.

Timothy Ned Atton is a game developer and graphics engineer with ten years experience working with Unity. He is currently employed at Golf+ working on the VR golf game, Golf+. This tutorial is not affiliated with nor endorsed by Golf+, Unity Technologies, or any of the people and organizations listed above. Thanks for reading!

Hi, I’m Ned, and I make games! Would you like to start writing shaders but don’t know where to start? Or, have you encountered a limitation of URP’s Shader Graph you need to overcome? In this tutorial series, I’ll walk you through writing a fully featured, general purpose shader for Unity’s Universal Render Pipeline — exclusively in code.

This tutorial is broken into nine sections, outlined below. You’re reading the first part, where I introduce shaders and how to write them. As I publish future sections, I will update this page with links! You can also subscribe here to receive a notification when I finish another part.

1. Introduction to shaders: simple unlit shaders with textures.
2. Simple lighting and shadows: directional lights and cast shadows.
3. Transparency: blended and cut out transparency.
4. Physically based rendering: normal maps, metallic and specular workflows, and additional blend modes.
5. Advanced lighting: spot, point, and baked lights and shadows.
6. Advanced URP features: depth, depth-normals, screen space ambient occlusion, single pass VR rendering, batching and more.
7. Custom lighting models: accessing and using light data to create your own lighting algorithms.
8. Vertex animation: animating meshes in a shader.
9. Gathering data from C#: additional vertex data, global variables and procedural colors.

The examples in this tutorial were tested in Unity 2020.3, 2021.3, and 2022.3. As you follow the tutorial, you will come across many features only possible in 2021 or later. However, I have written the shaders so the same code runs in both Unity versions.

Let’s lay out some goals of this tutorial series. My aim is to teach how to write shaders. I will show several examples, writing them step by step and explaining as we go. Do not view these as ready-for-production shaders, but rather as blueprints you can customize to your game’s needs.

After completing the series, you’ll know how to write your own version of URP’s standard lit shader, as well as customize it with your own lighting algorithm and more. You’ll also know several optimization techniques and how to leverage Unity’s debugging tools to diagnose and fix rendering bugs.

There’s quite a lot to set up and understand before anything displays on screen, which can make learning shaders difficult. To speed up the process, I’ll only explain information as needed, and I might gloss over some edge cases or technicalities. Don’t worry, I’ll address them later if they become important.

To keep this series from becoming even longer, I will assume you have some general game development knowledge. You should be comfortable using Unity and its 3D game tools - models, textures, materials, and mesh renderers. And, although you need no prior experience writing shaders, you should know how to program. C# experience will definitely be useful.

With all that out of the way, let’s get started!

Project Set Up. In this series, we will use Unity’s Universal Render Pipeline. It’s one of several rendering frameworks Unity provides. I chose URP for this project due to its recency and ability to support a wide variety of platforms while remaining lightweight.

I would highly suggest creating a fresh project for this tutorial. You can either select the URP project template…

Or use the blank template, add URP manually through the package manager, and activate it in Graphics settings. In the settings object, make sure that “Depth Priming Mode” is set to “Disabled” and that the rendering mode is “Forward.”

Either way, create a new standard scene to work with.

The Anatomy of a Shader. Large shaders, like the one we will write, are made of several files. To keep things organized, create a new folder called “MyLit” to contain them all. Create a shader file by selecting “Until Shader” from the create dialog, then name it “MyLit.shader.”

If you create a material, you’ll see that your shader already shows up in the shader selection menu of the material inspector (under the Unlit submenu).

Open the shader file in your code editor of choice. Sometimes Unity doesn’t generate Visual Studio projects if there are no C# scripts present, so create an empty C# script if your shader doesn’t appear in the solution explorer.

Regardless, inside “MyLit.shader” is a lot of automatically generated code — delete it all for now. This part of a shader is written in a language called ShaderLab, and it defines meta information about the drawing code.

This first line opens a shader block and defines the shader’s name in the material inspector. Any slashes will create subsections in the selection menu — useful for organization. The block is bound by curly braces, like classes in C#.

A shader is more than just code that draws. A single shader is actually made of many — sometimes thousands — of smaller functions. Unity can choose to run any of them depending on the situation. They’re organized into several subdivisions. The top-most subdivisions are known as subshaders. Subshaders allow you to write different code for different render pipelines. Unity automatically picks the correct subshader to use.

Define a subshader with a Subshader block, and then add a Tags block to set the render pipeline. Tags blocks hold user defined metadata in a format kind of like a C# dictionary.

Tell Unity to use this subshader when the Universal Rendering Pipeline is active by setting “RenderPipeline” to “UniversalPipeline.” That’s the only subshader we’ll ever need in this tutorial.

Subshaders are just the first subdivision; below them are passes. Passes’ purpose is more abstract. Each pass has a specific job to help draw the entire scene — like calculating lighting, cast shadows, or special data for post processing effects. Unity expects all shaders to have specific passes to enable all of URP features. For now, let’s focus on the most important pass: the one that draws a material’s lit color.

To signal that this pass will draw color, add a Tags block inside. The pass type key is “LightMode”, and the value for our lit color pass is “UniversalForward.” You can also name passes, which helps a lot when debugging.

OK, we’re almost ready to write some code. URP shader code is written in a language called HLSL, which is similar to a streamlined C++. To mark a section of a shader file as containing HLSL, surround it with the HLSLPROGRAM and ENDHLSL code words.

To keep things organized, I like to keep HLSL code in a separate file from the .shader metadata. Thankfully, this is easy to do. You can’t create an HLSL file directly in Unity, but you can in Visual Studio (choose any template and change the extension to “.hlsl”) or your file system (create a text file and change the extension to “.hlsl”).

Name this new file “MyLitForwardLit.hlsl,” and open it in your code editor. I just want to mention that many code editors don’t work well with URP shaders. While working through this tutorial, ignore any errors you see in the code editor and just rely on Unity’s console.

The Graphics Pipeline. When writing shaders, you need to have a different mindset than you would working with C#. For one, there’s no “heap,” meaning most variables work like numeric primitives. You also can’t define classes or methods, or use inheritance. Structs and functions are still available to help organize your code!

If you’ve ever worked with data driven design, you will feel at home writing shaders. The focus is gathering data and transforming it from one form to another.

In the broadest sense, shaders transform meshes, materials, and orientation data into colors on the screen.

There are two standard functions which the system calls, kind of like Start and Update in MonoBehaviours. These functions are called the vertex and fragment function. Every pass must have one of each.

These both transform data from one form to another. The vertex function takes mesh and world position data and transforms it into positions on the screen. The fragment function takes those positions, as well as material settings, and produces pixel colors.

Unity’s rendering system employs something called the graphics pipeline to link together these functions and handle low level logic. The pipeline gathers and prepares your data, calls your vertex and fragment functions, and displays the final colors on the screen. It’s made of several stages, running one after another, like an assembly line.

Each stage has a specific job, transforming data for stages down the assembly line. There are two special stages, the vertex and fragment stages, which are “programmable,” running the vertex and fragment functions you write. The others are not programmable and run the same code for all shaders, although you can influence them with various settings.

Let’s take a look at each stage, starting at the beginning: the input assembler. It prepares data for the vertex stage, gathering data from meshes and packaging it in a neat struct. Structs in HLSL are very similar to C# — a pass-by-value variable containing various data fields. This struct is customizable — you can determine what data the input assembler gathers by adding fields to the struct.

What data can the input assembler access? The input assembler works with meshes, specifically mesh vertices. Each vertex has a bunch of data assigned to it, such as a position, normal vector, texture UVs, etc. Each data type is known as a “vertex data stream.” To access any stream in your input structure, you simply need to tag it and the assembler will automatically set it for you.

For example, here’s an input struct for our forward pass’s vertex function. It defines a struct called “Attributes”. It has a field called “position,” with a type called “float3.” float3 is the HLSL term for a C# Vector3, or a vector containing three float numbers.

Use semantics to tag variables — the input assembler will automatically set them to a particular vertex data stream. For example, the POSITION semantic corresponds to vertex position. Keep in mind, only the semantic determines what data the input assembler will choose — the variable name does not matter. Feel free to name variables however you wish. We’ll see more semantics later on — HLSL uses them often to help the graphics pipeline.

With that, let’s move to the vertex stage. As a programmable stage, you get to define the code that runs here.

Defining a function in HLSL is very similar to C#, with a return type — void this time — a function name, and a list of arguments. An argument’s type precede the variable name. This function only needs a single argument of Attributes type.

The vertex stage’s primary objective is to compute where mesh vertices appear on screen. However, notice that the Attributes struct only contains a single position — only data for a single vertex. The render pipeline actually calls the vertex function multiple times, passing it data for each vertex until all are placed on screen. In fact, many calls will run in parallel!

If you’ve ever programmed multi-threaded systems, you know that parallel processing can introduce a lot of complexity. Shaders bypass much of this by forbidding storage of state information. Because of this, each vertex function call is effectively isolated from all others. You cannot pass the result of one vertex function — or any data computed inside — to another. Each can only depend on data in the input struct (and other global data; more on this later).

In addition, each vertex function call only knows about data for a single vertex. This is for efficiency: the GPU doesn’t have to load an entire mesh at once.

We need to compute the screen position for a vertex described in the Attributes struct. When talking about positions, it’s important to determine the coordinate system it’s defined in: its “space.” The position vertex data stream gives values in object space, which is another name for local space that you’re accustomed to in Unity’s scene editor. If you view a mesh in a 3D modeling program, these positions are also displayed there.

Another common space is world space. This is a common space that all objects exist in. To get world space from object space, just apply an objects Transform component. Unity provides this data to shaders, as we’ll see soon.

However, a vertex’s position on screen is described using a space called “clip space.” An explanation of clip space could fill an entire tutorial, but luckily we don’t have to work with it directly. URP provides a nice function to convert an object space position into clip space. To access it we first need to access the URP shader library.

In HLSL, we can reference any other HLSL file with “#include” directives. These commands tell the shader processor to read the file located at a given location and copy its contents onto this line. If you’re curious what’s inside Lighting.hlsl, or any other URP source file, you can read it yourself in the packages folder.

Included files can themselves #include many other files, leading to a kind of tree structure. For instance, Lighting.hlsl will pull in many helpful functions from across the entire URP library.

One such function, GetVertexPositionInputs, is located in ShaderVariableFunctions.hlsl. Its source code isn’t important now, but it returns a structure containing the passed object space position converted into various other spaces. Clip space is one of them!

Note that clip space is a float4 type. If you tried to store it in a float3, Unity would give you a warning that data will be truncated — or lost. This is a common source of bugs, so always heed these warnings and use the correct vector size!

Keeping track of which space a position is in can get tricky, fast! Standard URP code adds a suffix to all position variables indicating the space. “OS” denotes object space, “CS” clip space, etc. Let’s follow this pattern as well.

Next, we must fulfill the vertex stage’s job and output the clip space position for the input vertex. To do that, define another struct, called “Interpolators,” to serve as the vertex stage’s return type. Write a float4 positionCS field inside with the SV_POSITION semantic. The semantic signals that this field contains clip space vertex positions.

Have the Vertex function return an Interpolators struct, declare a variable of Interpolators type, set the positionCS field, and return the structure.

With that, the vertex stage is complete. The next stage in the rendering pipeline is called the rasterizer. The rasterizer takes vertex screen positions and calculates which of the mesh’s triangles appear in which pixels on screen. If a triangle is entirely off screen, the renderer is smart enough to ignore it!

The rasterizer then gathers data for the next stage in the pipeline: the fragment stage.

The fragment stage is also programmable, and the fragment function runs once for every pixel the rasterizer determines contains a triangle.

The fragment function calculates and outputs the final color each pixel should display, but of course, each call only handles one pixel.

The fragment function has a form like above. It takes a struct as an argument, which contains data output from the vertex function. Naturally, the types should match.

The values inside input have been modified by the rasterizer. For instance, positionCS no longer contains clip space position, but rather this fragment’s pixel position.

You can pass other data from the vertex function to the fragment function through the Interpolators struct, a technique we’ll investigate later on.

The fragment function outputs a float4 — the color of the pixel. It may be strange to think about, but colors are just vectors as well. They contain a red, green, blue, and alpha value, each ranging from zero to one.

To let the pipeline know we’re returning the final pixel color, tag the entire function with the SV_TARGET semantic. When tagging a function with a semantic, the compiler interprets the return value as having the semantic.

So we can finally display something on screen, let’s just color all pixels white. Return a float4 with all components set to one. Note that you don’t need to write “new” in HLSL when constructing vectors — just the type name is fine.

The last stage in the graphics pipeline is the presentation stage. It takes the output of the fragment function and, together with information from the rasterizer, colors all pixels accordingly.

There’s one last thing to do to complete a functioning shader: we need to register our vertex and fragment functions to a shader pass. Open your MyLit.shader file.

Tell the compiler to read the code inside your MyLitForwardLitPass.hlsl file using a #include command. Next, register the vertex and fragment functions using a “#pragma” command. #pragma has a variety of uses relating to shader metadata, but the vertex and fragment subcommands register the corresponding functions to the containing pass.

Make sure that the function names match those in your HLSL file!

And now we’re finally ready to view your shader! Make sure your material has MyLit selected, create a sphere in your scene, and give it the material. It should now appear as a flat white circle.

If there’s any issue, check Unity’s console and the shader asset to see if there are any errors.

Adding Color with Material Properties. We have a flat white circle now — a good starting place! Let’s make the color adjustable from the material inspector. This is possible through a system Unity calls “material properties.”

Material properties are essentially HLSL variables that can be set and edited through the material inspector. They are specified per material and allow objects using the same shader to look different. If you’re wondering “What is the difference between a shader and a material?,” this is it! A material is a shader with specific property settings.

We can define properties inside the .shader file with a Properties block. The syntax for these is… inconsistent, but I will explain. To define a color property, first decide on a reference name. This is how you’ll access this property in HLSL. By convention, properties have an underscore prefix.

Follow that with a parentheses pair, like you’re writing function arguments. The first argument is a string. This is the label — how it will display in the material inspector. The next argument is the property type. There are various, but “Color” defines a color property.

Close the parentheses and set a default value. The syntax is different for each property type, but for colors, start with an equals sign and then the red-green-blue-alpha values inside parentheses.

As mentioned before, colors are just four float values, each corresponding to a color channel — red, green, blue and alpha. Each number ranges from zero to one, where white is all ones and black is all zeroes. For alpha, 1 is opaque and 0 is invisible. If you’d like more info on how these numbers combine to create a color, check this link.

You can now see your property in the material inspector!

Later, this shader will have many properties, so add a header label denoting surface options. To do that, use a Header command. Strangely, the label is not enclosed in quotation marks here.

There’s one last thing we should do. Properties can also be tagged with attributes, like classes in C#, which give the properties special features. Tag _ColorTint with [MainColor]. Now it’s possible to easily set this property from C# using Material.color.

The property is set up, but the value is not reflected on screen. Open MyLitForwardLitPass.hlsl.

Although we defined a property in ShaderLab, we also must define it in HLSL — make sure the reference names match exactly. Unity will automatically synchronize this variable with the material inspector.

Earlier, I said that vertex and fragment functions could only access data from a single vertex or fragment. While this is true, they can also access any material properties. These variables are “uniform,” meaning they don’t change while the pipeline is running. Unity sets them before the pipeline begins, and you cannot modify them from a vertex or fragment function.

With this in mind, have the fragment function return _ColorTint as the final color.

Return to the scene editor, select your material and change the color tint property. The shader should immediately reflect your choice!

Varying Colors with Textures. Flat colors are great, but I’d like to vary color across the sphere. We can do this with textures!

Shaders love working with textures. They’re just image files, but shaders think of them as 2D arrays of color data. To add a texture to a shader, first add a texture material property.

Texture Properties. Defining a texture property is much the same as a color property. Instead of listing the type as Color, set it as 2D. The syntax for default textures is strange. Following the equals sign, type “white” (with quotes) followed by a pair of curly braces. If no texture is set in the material inspector, Unity will fill this property with a small, white texture. You can also set the default color to “black,” “gray,” or “red.”

Similarly to the [MainColor] attribute, there is a [MainTexture] attribute. Tagging this property makes it easily assignable from C# using the Material.mainTexture field.

Your property should show up in the material inspector now. Notice the four numbers beside it. They allow you to set an offset and scale for this texture, which is useful for tiling.

Textures and UVs in HLSL. Now, let’s take a look at the HLSL side of things.

Defining a texture variable is a bit more complicated than colors. You must use this special syntax to define a 2D texture variable. Once again, the name must match the property reference exactly.

TEXTURE2D here is not a type but something called a “macro.” You can think of macros similarly to functions, except they run on the text making up code. You can create macros yourself using the #define command.

Before compiling, the system will search for any text matching a defined macro and replace the macro name with the text you specify. Macros can also have arguments. The system will replace any occurrences of argument names in the macro definition with whatever text you pass in.

This is a very simple overview of macros, but they can be quite useful in shader code. HLSL does not have inheritance or polymorphism, so if you want to work with any structure that has a positionOS field but you don’t necessarily know the structure type, a macro can do the trick.

They’re also great at handling platform differences, which is what Unity has done with TEXTURE2D. See, different graphics APIs (DirectX, OpenGL, etc.) use different type names for textures. To make shader code platform independent, Unity provides a variety of macros to deal with textures. That’s one less thing for us to worry about!

Moving on, there are a couple more variables Unity automatically sets when you define a texture property. Textures have a companion structure called a “sampler,” which defines how to read a texture. Options include the sampling and clamping mode you’re familiar with from the texture importer — point, bilinear etc.

Unity stores samplers in a second variable which you define with the SAMPLER macro. The name here is important; it must always have the pattern “sampler” followed by the texture reference name.

Finally, remember the tiling and offset values from the material inspector? Unity stores those in a float4 variable. The name must follow the pattern of the texture name followed by “_ST.” Inside, the X- and Y-components hold the X and Y scales while the Z- and W-components hold the X and Y offsets. (And yes, the fourth component of a float4 vector is referred to as “W” in HLSL.)

Now, we’d like to sample the texture, or read color data from it. We’ll do that in the fragment stage to apply texture colors to pixels. Use the SAMPLE_TEXTURE2D macro to get the color out of a texture at a specific location. It takes three arguments: the texture, the sampler, and the UV coordinate to sample.

First, what are UVs? UVs are texture coordinates assigned to all vertices of a mesh which define how a texture wraps around a model. Think of how cartographers try to unwrap a globe to fit on a flat map. They’re basically assigning UVs to positions on the globe.

UVs are float2 variables, where the X- and Y-coordinates define a 2D position on a texture. UVs are normalized, or independent of the texture’s dimensions. They always range from zero to one.

Interpolating Vertex Data. We can’t grab UVs out of thin air in the fragment stage — they’re another vertex data stream the input assembler needs to gather.

Add a float2 uv field to the Attributes structure with the TEXCOORD0 semantic, which is short for “texture coordinate set number zero.” Models can have many sets of UVs — Unity uses TEXCOORD1 for lightmap UVs for example, but we’ll get to that later.

The Attributes struct is not available in the fragment stage either. However, we can store data in the Interpolators struct, which will eventually make its way to the fragment stage.

Add another float2 uv field there, also using the TEXCOORD0 semantic.

In the Vertex function, pass the UV from the Attributes struct to the Interpolators struct. We can also apply UV scaling and offset here — might as well! This way we’ll only compute it once per vertex instead of once per-pixel. It’s a good idea to do as much as possible in the vertex function since it generally runs fewer times than the fragment function.

Unity provides the TRANSFORM_TEX macro to apply tiling. There are two interesting things about it. First, the double hash “##” tells the precompiler to append text to whatever is passed in as an argument. When the macro runs, you can see how it replaces name with _ColorMap, correctly referencing _ColorMap_ST.

Second, the xy and zw suffixes give easy access to a pair of components. This mechanism is called “swizzling.” You can ask for any combination of the x-, y-, z-, and w-components, in any order. The compiler will construct an appropriately sized float vector variable for you. You can also use r, g, b, and a the same way — more intuitive for colors. It’s even possible to assign values with a swizzle operator.

Anyway, now we have UV data in the fragment stage. But, let’s take a moment to really think about what’s happening here. The vertex function outputs data for each vertex. The rasterizer takes those values, places the vertices on the screen, figures out what pixels cover the formed triangle, and finally generates an input structure for each fragment function call. What value will input.uv have for each fragment?

The rasterizer will interpolate any field tagged with a TEXCOORD semantic using an algorithm called “barycentric interpolation.” You’re probably familiar with linear interpolation, where a value on a number line is expressed as a weighted average of the values at the end points.

Barycentric interpolation is the same idea except on a triangle. The value at any point inside the triangle is a weighted average of the values at each corner.

Luckily, the rasterizer handles this for us, so the algorithm is not important. To recap, the values in Interpolators are a combination of values returned by the vertex function. Specifically, for any fragment, they are a combination of values from the three vertices forming the triangle covering that fragment.

Sampling the Texture. All that for some UVs, but now we have all we need to call SAMPLE_TEXTURE2D. It returns a float4, the color of the texture at the specified UV position. Depending on the sampler’s sample mode (point, bilinear, etc), this color may be a combination of adjacent pixels, to help smooth things out.

Regardless, multiply the sample with the color tint property and return it. In HLSL, multiplying two vectors is component-wise, meaning the X-components of each vector are multiplied together, then the Y-components, etc. All arithmetic operators work like this.

In the scene editor, set a texture on your material and marvel at what you’ve accomplished!

Do note that if your texture has an alpha component, the shader doesn’t handle transparency yet. The sphere will always be opaque. Stay tuned to fix that!

I hope this whet your appetite for shader programming, because we’re just getting started! In the next part of this tutorial series, we’ll add simple lighting to finally give objects dimensionality. Then, we’ll delve into shadows and learn about adding additional passes to a shader. You’ve gotten past a lot of the theory and can now focus on the fun stuff!

For reference, here are the final versions of the shader files.

If you enjoyed this tutorial, consider following me here to receive an email when the next part goes live.

If you want to see this tutorial from another angle, I created a video version you can watch here.

I want to thank Crubidoobidoo for all their support, as well as all my patrons during the development of this tutorial: Adam R. Vierra, Alvaro LOGOTOMIA, andrew luers, Andrew Thompson, Ben Luker, Ben Wander, bgbg, Bohemian Grape, Brannon Northington, Brooke Waddington, burma, Cameron Horst, Charlie Jiao, Christopher Ellis, Connor Wendt, Danny Hayes, Danyow Ed, darkkittenfire, Davide, Derek Arndt, Eber Camacho, Electric Brain, Eric Bates, Eric Gao, Erica, etto space, Evan Malmud, Florian Faller, gamegogojo, gleb lobach, Isobel Shasha, J S, Jack Phelps, Jannik Gröger, Jesse Comb, Jessica Harvey, Jiwen Cai, JP Lee, jpzz kim, Justin Criswell, KIMIKO KAWAMORITA, Kyle Harrison, Lanting Dlapan, Leafenzo (Seclusion Tower), Lhong Lhi, Lorg, Lukas Schneider, Luke Hopkins, Lune Snowtail, Mad Science, Maks Kaniewski, Marcin Krzeszowiec, Marco Amadei, martin.wepner, Maximilian Punz, maxo, Microchasm, Minori Freyja, Nick Young, Oliver Davies, Orcs Yang, Oskar Kogut, Óttar Jónsson, Patrick, Patrik Bergsten, Paul, persia, Petter Henriksson, rafael ludescher, Rhi E., Richard Pieterse, rocinante, Rodrigo Uribe Ventura, rookie, Sam CD-ROM, Samuel Ang, Sebastian Cai, Seoul Byun, shaochun, starbi, Stefan Bruins, Steph, Stephan Maier, Stephen Sandlin, Steven Grove, svante gabriel, T, Tim Hart, Tvoyager, Vincent Thémereau, Voids Adrift, Will Tallent, 智則 安田, 이종혁

If you would like to download all the shaders showcased in this tutorial inside a Unity project, consider joining my Patreon. You will also get early access to tutorials, voting power in topic polls, and more. Thank you!

If you have any questions, feel free to leave a comment or contact me at any of my social media links:

🔗 Tutorial list website ▶️ YouTube 🔴 Twitch 🐦 Twitter 🎮 Discord 📸 Instagram 👽 Reddit 🎶 TikTok 👑 Patreon ☕ Ko-fi 📧 E-mail: nedmakesgames gmail

Thanks so much for reading, and make games!

Changelog:

• May 29th 2023: Add support for Unity 2022.
• Unity Technologies: Shader Calibration Scene
• shedmon: Wooden Slingshot
• Martijn Vaes: DAE — Bilora Bella 46 Camera — Game Ready Asset
• tonyflanagan: Thailand Girl — Animated
• Kelvin Valerio: Brown Cat with Green Eyes
• owowowsam: Mini Earth
• Tom Patterson: Natural Earth III

©️ Timothy Ned Atton 2023. All rights reserved.

All code appearing in GitHub Gists is distributed under the MIT license, unless otherwise specified.

Timothy Ned Atton is a game developer and graphics engineer with ten years experience working with Unity. He is currently employed at Golf+ working on the VR golf game, Golf+. This tutorial is not affiliated with nor endorsed by Golf+, Unity Technologies, or any of the people and organizations listed above. Thanks for reading!

Hi! I’m Ned, and I make games! In this Unity graphics programming tutorial, I’ll introduce tessellation shaders, advanced shaders which can subdivide triangles, adding details and smoothing out blocky models. Use them for automatic level of detail, procedural models, or height map based terrain. Keep watching to learn how to add tessellation to any shader yourself!

Thank you Crubidoobidoo and all my patrons for helping make this tutorial possible!

This tutorial was tested in Unity 2020.3, 2021.1 and 2021.2. I will be using Universal Render Pipeline for all examples; however, none of the techniques in this tutorial are URP specific. Furthermore, I will not use the shader graph in this tutorial, as even in HDRP it does not support all required techniques. If you’re unfamiliar with HLSL shaders in URP, I’m writing a tutorial about that, so check back soon.

This tutorial will explain what tessellation shaders are and how to write them in HLSL. I will demonstrate several methods to optimize tessellation, control the amount of subdivision per triangle, smooth a model’s geometry and silhouette, and add details with height maps and procedural techniques. This tutorial aims to explain the topic of tessellation, not so much create a finished shader. Nevertheless, I have provided an example shader here.

As mentioned, this tutorial is more advanced and will expect you to know how to write shaders in HLSL. In addition, it will make use of vector math, so brush up on vector dot and cross products, as well as vector projection and reflection.

The Structure of a Tessellation Shader

In mathematics, tessellation is the process of fitting shapes together to form a larger surface; however, in graphics programming, it usually refers to subdividing a shape into smaller pieces. Tessellation shaders do just that. Put a mesh in, and the GPU subdivides all its faces, adding many more vertices.

Why is this useful? Well, you can take these extra vertices and move them around, smoothing out jagged, low-poly edges and adding fine position details not possible otherwise. This enables a kind of reverse workflow for LoD, where you can create low poly models and use tessellation to add complexity.

Tessellation is also great for terrain. Use a flat plane mesh and tessellate it, adjusting heights with a heightmap. This allows you to adjust the shape using only a texture and render high detail only where the camera can see it. Generate a heightmap procedurally to visualize mathematical surfaces, like SDFs, or easily animate a mesh.

Keep in mind that tessellation shaders have a hefty performance cost. The good news is they’re generally cheaper and have better hardware support than their cousins, geometry shaders. Plus they allow you to keep your mesh assets simpler — which can help with batching. If you’re worried about performance, be sure to test things out before committing to tessellation.

Now, how do you add tessellation to a shader? Tessellation shaders have two additional programmable stages, similar to the vertex and fragment stages. These are called the hull and domain stages. They run in between the vertex and fragment stages, and together with an unprogrammable stage called the tessellator, control how the mesh is subdivided and refined.

The hull function receives data in the form of “patches,” which are simply lists of vertices. What relation these vertices have to one another is configurable; however, in this tutorial I will always work with triangles.

So, the patch is an array of three vertices that make up a triangle on the mesh. The array contains output data from the vertex function corresponding to each vertex.

Besides the patch, the hull function also receives an index, specifying which vertex in the patch the hull function must output data for. It runs once per vertex in the patch and can look at all vertices in the patch to produce a new data structure for later on in the chain.

The hull stage is unique in that it also has another function that runs in parallel: the patch constant function. This separate function runs once per patch, so it’s very useful to calculate data that’s shared between vertices in a triangle. It also must output tessellation factors, which determine how many times to divide the patch. We’ll talk about these extensively later on.

So to summarize, the hull stage is made up of two functions: the hull function and the patch constant function. They receive a patch, which is a collection of vertices usually forming a triangle. The hull function runs once per vertex in a patch, while the patch constant function runs once per patch and must output tessellation factors.

Next up, a non-programmable stage called the tessellator runs. This takes patch data and the tessellation factors generated during the hull stage to subdivide each patch. The tessellator generates something called barycentric coordinates for all vertices in this new mesh.

Barycentric coordinates are an easy way to describe a point inside a triangle. Any point can be calculated as a weighted average of the three corner points, and barycentric coordinates are the weights in that formula. They’re usually given as a float3 vector, and the three components always sum to one. Besides position, we can also use barycentric coordinates to calculate normals, UVs, and more for any point in terms of the triangle corners.

This brings us to the second programmable stage involved in tessellation, the domain stage. It consists of one function, the domain function, which runs for each vertex on the tessellated mesh. Its job is to output the final data for a vertex. To do so, it receives the barycentric coordinates for a vertex and it’s originating patch. This includes all data generated by the hull and patch constant functions.

The domain function is where a lot of your logic will go. Much of what you’d usually do in the vertex stage should be calculated here instead, including clip space positions. Crucially, you can reposition vertices in the domain stage, something essential for most of tessellation’s use cases.

If you have a geometry function, it would run after the domain stage. But, usually, the rasterization and fragment stages run next.

To summarize, the vertex stage runs first. The hull stage receives information about triangles on your mesh, called patches, and decides how to subdivide them. The tessellator does the heavy lifting, subdividing the mesh; while the domain stage prepares vertices in the tessellated mesh for the fragment stage, deciding where each appears on screen.

Let’s pivot to writing code! You can register hull and domain functions similarly to the other programmable stages, using a #pragma directive. Note that tessellation shaders require shader target 5.0, so adjust that or Unity will complain.

The vertex function is now pretty plain. It simply converts positions and normals to world space. The output structure will be fed into the hull stage, and can contain basically any data you’ll need later in the pipeline. Notably, the POSITION semantic is forbidden, use the INTERNALTESSPOS semantic instead.

The hull shader’s signature looks like below. It has several C#-attribute-like tags. domain determines the input patch type, while outputtopology and outputcontrolpoints determine the output patch type. I’m always going to use triangles in this tutorial, so these will remain fixed. patchconstantfunc registers the patch constant function, and partitioning tells the tessellator which algorithm to use to subdivide triangles. Keep this in mind for later.

The function itself receives the input patch using a special InputPatch construct. The vertex function output structure and number of vertices in the patch go inside the angle brackets. You can access each structure in the patch like you would an array.

The hull function also receives the vertex index with the SV_OutputControlPointID semantic. It signals which vertex in the patch to output data for. Finally, don’t forget to set the return structure type. In this example, it’s the same as the vertex output structure, but it could be unique. There are no required fields in this data, but once again, use INTERNALTESSPOS instead of POSITION.

In this example, the hull function body is extremely simple, simply returning the correct vertex inside the patch.

The patch constant function has a much simpler signature. It receives the input patch similarly to the hull function but outputs its own data structure. This structure should contain the tessellation factors specified per edge on the triangle using SV_TessFactor. Edges are arranged opposite of the vertex with the same index. So, edge zero lies between vertices one and two.

There’s also a center tessellation factor, tagged with SV_InsideTessFactor. Soon, we’ll visualize how these factors affect the final tessellation pattern, but for now, realize that an edge factor is the number of times an edge subdivides, and the inside factor squared is roughly the number of new triangles created inside the original.

The patch constant function can also output other data, but it must be tagged with a semantic like always. The special BEZIERPOS semantic is useful since it can take the form of a float3 array. Later, we’ll use it to output control points for a Bézier-curve-based smoothing algorithm, but you can use it to store anything you need.

With that, we’re done with the hull stage. Let’s move to the domain stage.

The domain function also has a domain attribute, which should match the hull function’s output topology — triangles in this case. As arguments, it receives the output of the hull function arranged into a patch, as well as the output from the patch constant function. Finally, it receives the barycentric coordinates of the vertex to work with, tagged with SV_DomainLocation.

The output structure is very similar to what you’d output from a vertex function. It should contain a clip space position (unless you’re using a geometry stage), as well as any fields the fragment function needs for lighting.

Also, notice the BARYCENTRIC_INTERPOLATE macro. It’s really handy to interpolate any property in the patch structure!

And that’s it for the general structure. Let’s take a closer look at partitioning modes and tessellation factors. I’ve created a simple tessellation shader to test this stuff out. It has a property to assign tessellation factors as well as one to switch between partitioning modes using a keyword.

Create a material for it and add it to a mesh. To visualize the tessellation, be sure to set the scene render mode to shaded wireframe. Then, play around with the factors.

You’ll see the edge factor corresponds to roughly the number of times edges will be subdivided, while the inside factor adds complexity to the center. Also notice that setting any factor to zero or less will cause the mesh to disappear. This becomes important later.

Now try setting a factor differently for each edge. When we try more complicated algorithms, It’s important that edges on adjoining triangles have the same tessellation factor. If not, you can get little holes in the mesh where vertices don’t match up. To ensure this doesn’t happen, try restricting edge factors to depend only on vertices connected to that edge.

You may have noticed some commented out properties in the shader. Uncomment those and change your patch constant function slightly. Is your mesh flickering, even with positive factors? Why?

There’s an oddity with the way the shader compiler handles tessellation factors. In a bid to speed things up, the compiler sometimes splits the patch constant function and calculates each factor in parallel. This sometimes causes weird issues. If you look in the Frame Debugger, you’ll see the compiler stripped two edge factor properties from your shader, making them always equal zero!

You can fix this by using a vector property with each component specifying one edge’s factor, so the compiler doesn’t strip properties it thinks are unused. In general, if your tessellation factors are acting strange, try rewriting this section of the patch constant function.

The partitioning modes are all interesting. The integer mode divides a number of times equal to the ceiling of the tessellation factor. It has a generally nice pattern! But, if you need tessellation factors to smoothly transition, the fractional_odd and fractional_even modes handle that. They’re so named because they only fully subdivide on either odd or even numbers, which is easier to understand seeing them in motion. A quirk of fractional even is that it always subdivides at least once, since two is the lowest factor it can handle.

The pow2 mode seems to be identical to the integer mode, at least on my machine. I would have guessed it only subdivided when a factor is a power of two. Let me know how it works for you!

Optimizing with Culling

Tessellation can be expensive! But, there are a few ways we can speed it up. Since tessellation happens before the rasterization stage, it cannot take advantage of the automatic frustum and winding culling that happens there. Thankfully, we can implement it ourselves and avoid tessellating triangles that will just be thrown out.

It’s easy to cull a triangle in the patch constant function. Just set the tessellation factors to zero, and the tessellator will ignore that patch.

Let’s tackle frustum culling, where we test each point of the triangle to see if they’re all out of view. To do that, we can use the clip space positions of the triangle corners. Be sure to calculate it in your vertex function and pass it to the hull stage.

Above the patch constant function, write this function to test if a patch should be culled, passing the clip space positions of the triangle. Return false for now.

Above that, write IsOutOfBounds to check if a point is outside the bounds defined by upper and lower vectors, and ShouldFrustumCull to calculate those bounding vectors.

In clip space, the W component contains the outer bounds of the viewing frustum (camera viewable area), so we can use that to create the bounding vectors. The logic slightly differs between graphics API, since some anchor the viewing frustum and zero and some at negative W. Luckily, Unity provides a constant with the correct value.

Returning to ShouldClipPatch, call ShouldFrustumCull on each point. If they’re all true, the triangle is entirely outside the viewing area and should be culled.

Moving on to winding culling, also known as backface culling, we need to calculate which side of the triangle is facing the camera, culling if the back side of the triangle is visible. Do that calculating a normal vector for the plane containing the triangle and testing if it’s roughly pointing towards the camera.

To find the normal vector, we need two vectors tangent to the plane — vectors pointing between two triangle corners will do nicely. Their cross product is the normal.

Since we’re working in clip space, we need to “normalize” the position and apply perspective by dividing by the W component. This gives rough screen space positions.

Use the dot product of the view direction and triangle normal to find if they’re roughly pointing in the same direction. However, since the camera points along the z axis in clip space, we can simplify everything to a comparison of the normal’s z coordinate.

I said the camera points along the Z axis, but which way? Turns out, this depends on your graphics API. Usually the view direction is in the negative z direction; however, it’s flipped in OpenGL. Use a keyword to apply the correct comparison either way.

Finally, in ShouldClipPatch, call ShouldBackFaceCull. In the patch constant function, if ShouldCullPatch returns true, set all edge factors to zero.

In Unity, you might notice the shader culls some faces of your mesh when it shouldn’t. Even if you don’t see it now, you certainly will when adding vertex displacement later on.

Add some leeway to these calculations by introducing frustum and winding cull tolerance properties. For frustum culling, add the tolerance to each bound, while for winding culling, compare with the tolerance instead of zero. Adjust these as needed while adding features!

Dynamic Tessellation Factors

Another way to optimize tessellation is to lower factors when and where a mesh doesn’t need to be subdivided. There are a few ways to go about this. Say we’re working with a mesh that has some large faces but many smaller ones — we really only need to tessellate the large faces. One way to do this is to calculate tessellation factors proportionate to edge length.

Above the patch constant function, define this function to calculate the tessellation factor for an edge bound by two vertices. Pass the world space positions of each vertex as well as a scale and bias value. Set the factor to the scale plus the bias, making sure the result is never less than one (so it doesn’t get culled). This creates constant edge factors.

Now, to add world space edge length, set the factor to the distance between the vertex positions divided by the scale. In this scheme, the edge subdivides while aiming to keep divided edge lengths roughly equal to the scale value.

Add shader properties for the scale and bias values. Back in the patch constant function, call EdgeTessellationFactor for each edge, passing in the new properties and the appropriate vertex positions. Remember, edges are arranged across from the vertex sharing it’s index in the array.

The inside factor should be the average of all edge factors. This code worked fine for me, but if you’re seeing weird or inconsistent inside edge factors, it’s probably due to the compiler. Just call EdgeTessellationFactor again instead of using the previously calculated values.

OK, neat! But maybe we can tessellate based on an edge’s length in screen space? Due to culling, we already have clip space positions, so it won’t be difficult to do.

In EdgeTessellationFactor, add arguments for each vertex’s clip space position. Then, calculate the factor using the clip space positions, making two adjustments. First, apply perspective by dividing the positions by their w component. Next, multiply by _ScreenParams.y, which contains the height of the screen in pixels. Now, we can specify scale in pixels!

In the patch constant function, pass the clip space positions along with the world space positions.

This looks good too, but sometimes not quite right. What if we used the distance to the camera?

In EdgeTessellationFactor, find the length, in world space, between the two vertices. Then, calculate the distance from the center of this edge to the camera. The camera position is different in the various render pipelines, but get it with GetCameraPositionWS in URP. Divide the length by the scale multiplied by the distance to the camera, lowering the scale when close to the screen, subdividing more. I preferred the effect with a quadratic curve, but that’s up to you.

This final approach usually gives me the best results, but your mileage may vary. Use a keyword to switch between algorithms, if you’d like!

These heuristics try to guess the appropriate tessellation factors, but if you have an idea of how the mesh should tessellate, try storing tessellation factor multipliers in the mesh’s data. This is useful if you have an area with large flat faces where you’ll never need to add detail.

For demonstration purposes, I’ll store these multipliers in the green channel of the mesh’s vertex colors, but texcoords also work well. In blender or your modeling program of choice, paint the area you don’t want to tessellate black.

In your shader, pass the vertex colors down to your hull input structure. In the patch constant function, calculate a multiplier for each edge by averaging the green channel of connecting vertices and pass it as a new argument into EdgeTessellationFactor. Multiply it into the final calculation.

Here’s another useful technique when using some type of deforming force field or SDF. In this example, I deform this plane based on proximity to the little spheres. We know that if a vertex is far enough away from all spheres, it shouldn’t deform, so we don’t need to tessellate connected triangles.

For now, ignore the actual deforming logic, we’ll come back to that later. Focus on calculating the tessellation factors.

In your patch constant function, evaluate the deformation amount for each vertex. If it results in deformation (the value is positive in this example), then pass a multiplier of one.

Silhouette Smoothing

An easy way to add detail to a mesh is through high resolution textures. For instance, normal maps vary normal vectors per-pixel which affect the apparent shape of a surface. However, this technique does not really change any geometry. Nowhere is this more apparent than on a mesh’s silhouette. Zoom up close and even 4K textures can’t hide jagged and pointy edges. In this section, I’ll describe a few algorithms to smooth mesh geometry using tessellation!

All of these strategies involve offsetting vertices in the domain function. Through simple barycentric interpolation, all new vertices are limited to the original triangle’s plane. However, what if we used the corners’ normal vectors to construct a curved triangle?

The simplest technique to achieve this is called Phong tessellation. You might have heard of Phong shading, which is the smooth shading technique of linearly interpolated normal vectors. Phong tessellation tries to recapture that simplicity and efficiency in positioning tessellated points.

It works like this. First, calculate the flat barycentrically interpolated position for a point. We’ll use (1/3, 1/3, 1/3) in this example.

Then, imagine three tangent planes emanating from each triangle corner, normal to the corner’s respective normal vector.

Next, project the flat position onto each of these planes, which is equivalent to finding the nearest point on the plane.

Finally, compute the barycentrically interpolated position again, but using the three projected points.

The math is not too complicated. We already know how to deal with barycentric coordinates. And, to project a point onto a plane, find the difference between the point and any other on the plane — the triangle corners work! Then, project that vector onto the plane’s normal vector and subtract the result from the original point. Here’s the algorithm for Phong tessellation!

Now update your domain function. Make sure to use this new adjusted position when calculating clip space.

Try it out on a model! At first, it may look a little too puffed up. We can improve it by adding a smoothing factor property. Interpolate between the flat and Phong position using this factor, which can help quite a bit.

Some models may need a little touching up as well. If your model has sharp edges, try adding edge loops very close to the sharp edge, making long, thin faces. Looking at the Phong tessellation algorithm, if the normal vectors of each vertex are very close to parallel, the Phong position will be very close to the flat position.

Another technique you can try is baking smoothing factors into your mesh’s data, for example, in the red channel of it’s vertex colors. Simply paint the red channel black in areas you don’t want to bend. Pass the vertex colors all the way down to your domain function, calculate the barycentric interpolation of the red vertex color channel, and multiply it with the smoothing factor.

Phong tessellation gives pretty good results and is also cheap, all things considered. However, if you need higher quality smoothing, there’s another option: PN Triangles. This technique constructs curved triangles similarly to Bézier curves! It’s quite a bit more expensive than the Phong method, but let’s try it out.

We can save some time by precomputing Bézier control points for use when positioning tessellated points in the domain function. Control points are constant per triangle, so the patch constant function is perfect. We’ll make use of ten control points: the triangle corners, a pair along each triangle edge, and one in the triangle center.

Let’s take a look at calculating each control point. The corners can remain as they are. They’ll help ensure the triangle never escapes its original position too much. For the edge pairs, use a similar algorithm to Phong tessellation. Take this peachy point ⅓ along the edge from corner A to B.

To calculate it’s position, first project B onto the plane defined by A’s normal.

Then, take the average of this new point and A, weighing A twice.

For the other point on this edge, do the same operation, mirroring A and B.

Continue with the other two edge pairs.

Finally, for the center point, find the average of the edge pair control points, which I’ll call E.

As well as the average of the triangle corners, T. The center control point is E plus the difference of E and T halved, which gives a nice rounded center.

Using these control points, it’s possible to compute any point on this bendy triangle using barycentric coordinates.

This is the formula — which looks similar to that of a cubic Bézier curve. Notice how the barycentric coordinates appear in terms with their corresponding corners — the center point being an even combination of each. If you’d like to learn more about Bézier curves, I’ve linked some excellent resources in the foot notes.

To program this, store the control points in the patch constant output struct, using the BEZIERPOS semantic. Tag a seven element float3 array with it in the patch constant output structure. Why only seven? The patch contains the triangle corner positions, so there’s no reason to waste the memory.

CalculateBezierControlPoints calculates Bézier control points using the algorithm described earlier. Call it in the patch constant function, but only if the triangle isn’t culled.

Calculate the final point in the domain stage. CalculateBezierPosition implements the Bézier curve calculation using the control points from the hull stage. I’ve also added an interpolation between the curved position and the flat position, like in the Phong tessellation function.

Substitute this function for the Phong tessellation function in your domain function.

In Unity, you’ll see it does give nice results, usually slightly better than Phong tessellation, especially at higher smoothing values. It’s up to you if the added complexity is worth it!

Throughout all this, we haven’t touched the normal vectors. Interpolating normal vectors linearly is usually OK, but if your mesh has many divots and inflections, shading might be improved by interpolating normals quadratically!

Use another Bézier-curve-like algorithm for this. It might seem strange to use a Bézier-curve for normal vectors, but as long as we normalize the final result, it works just fine. Quadratic Bézier curves only need three control points, so place one in the middle of each triangle edge.

Again, the triangle corners will retain their original normal vectors. To compute a control vector for the point halfway between corners A and B, follow these steps.

First, find the average normal of A and B.

Second, construct a plane perpendicular to the edge connecting A and B.

Finally, reflect the average vector across the plane.

Notice that when normals are similar but slanted relative to the triangle plane, the control normal points in the opposite direction. This creates bumpy shading, as if the surface is warping.

Calculate the control vectors for the remaining edges.

To add this to your shader, first add three more slots in the Bézier control point array. Then, call CalculateBezierNormalPoints in your patch constant function, which implements the formula explained above.

In your domain function, calculate a quadratic Bézier similarly to the position. Apply the smoothing factor to interpolate with the flat normal, and be sure to normalize the final result!

There’s one other thing to consider, the tangent vector. It must always be perpendicular to the normal, but if we change the normal vector, it might not be. To fix this, find the barycentrically interpolated tangent vector and take its cross product with the barycentrically interpolated normal. Then, take that vector’s cross product with the smoothed normal. This resulting tangent vector is once again orthogonal to the normal vector, as well as the original bitangent. This should preserve tangent space.

And that brings us to the end of this section on silhouette smoothing and Bézier triangles! This is the real magic behind tessellation and makes it a powerful tool combined with appropriately designed models. Experiment and see what you can create!

Working with Height Maps

Another of tessellation’s most common uses is adding extra geometric details to a mesh. Say you have a rough surface with many bumps. Traditionally, an artist would use a normal map to approximate the lighting such a bumpy surface would receive. The model itself is not actually bumpy, as you can clearly see if you view the surface’s profile or shadow. With tessellation, it’s possible to modify the mesh to more closely resemble a complex surface.

The most common way to do this is with a height map. Also known as bump maps, these grayscale textures encode height offsets in its color data. The idea is simple, read a height from the texture and offset vertices along their normal vectors by this height.

To implement this in a shader, add a texture property for a height map, then sample it in the domain function. Remember SAMPLE_TEXTURE2D is only available in the fragment stage, due to partial derivatives; use SAMPLE_TEXTURE2D_LOD here. Accordingly, you can turn off mipmaps for height maps used in this way.

Regardless, add the sampled value to the vertex’s world position by using it to scale the normal vector. You can combine this with the smoothing techniques discussed above, or just use the flat interpolated position and normal. Either way, it’s that simple. Add an altitude property to adjust the height!

You might notice if you use a height map without a matching normal map that the mesh will look quite flat. This is because the height map does not affect normal vectors. Although I would still recommend using a normal map, it is possible to calculate lower quality tangent space normal vectors from a height map alone.

In this case, turn mipmaps back on for your height map, since we’ll sample it for normal vectors in the fragment stage. In the shader, add a _MainTexture_TexelSize variable, which holds the size of one texel, or pixel on a texture, in UV units. Make sure the name matches a texture in your shader and Unity will “automagically” calculate and set it for you!

Write GenerateNormalFromHeightMap, which samples the height map in each neighboring pixel around a given UV coordinate. From this, we can calculate a tangent space normal with a little algebra. Divide the change in height of two pixels across from one another with the change in UV space. This gives us the slope in the U and V directions, which correspond to the X and Y components of the tangent space normal.

Multiply the XY components with a _NormalStrength scaling factor to adjust the overall strength of this improvised normal map; then normalize the final result. Convert this to world space like any other tangent space vector.

You’ll need to adjust the normal strength until you get something that looks good. Even then, you might notice these normals are not quite as detailed as a normal map. It can’t really be helped without taking more texture samples, which really start to add up. For this reason, only use this technique if you’re in a pinch. There are many free tools online which can generate normal maps from height maps anyway.

Height maps can also take the form of a function, like Perlin noise or an SDF. In these cases, evaluate the height function instead of sampling a height map. Here, we’re forced to calculate a normal vector. It can be a little tricky to figure out the math, and it differs per function, but on the plus side, they’re often mathematically exact.

In this example, I created a heightmap from Perlin noise. This has well defined partial derivatives, so I was able to calculate the normal vector like so. If you scale the noise in any way, be sure to also scale the resulting normal vector. Just remember that normals must be scaled inversely to geometry — meaning divide instead of multiply!

You could calculate the normal along with the position in the domain function and just use the interpolated value in the fragment function. However, you could also calculate the normal in the fragment function for a nicer, more detailed result.

In this next example, I created a simple SDF, or distance function, from points centered on these three spheres. When the SDF passes a threshold at a point on the mesh, I deform the point backwards. To calculate the normal in this situation, I used another trick.

Create two new points offset slightly from the original point along the tangent and bitangent vectors. Calculate the SDF at all three points and apply the offset. Then, form a triangle with these deformed points and calculate the normal vector of the plane containing it, using the cross product. Use that for lighting! This method is usually quite good for continuous functions determined solely by position!

Closing Remarks and Special Thanks

As you can see, tessellation is a complicated subject, but it opens up many doors in the world of graphics programming! Although it can be expensive, well-placed tessellation can really polish up your models and give your game that final push over the finish line!

I hope I have shown off interesting uses of tessellation, including early culling, per-triangle math, smooth silhouettes, level of detail, quadratic normal vectors, real height maps, and procedural geometry. Personally, I will be using tessellation for level of detail and wind effects in my upcoming grass system.

Once again, here is a sample tessellation shader which implements many of the algorithms featured here.

If you have any questions, feel free to contact me at any of the links at the bottom of this article.

If you want to see this tutorial from another angle, I created a video version you can watch here.

I want to thank Crubidoobidoo for all their support, as well as all my patrons over the last month: Adam R. Vierra, Alvaro LOGOTOMIA, Ben Luker, Ben Wander, Bohemian Grape, Brooke Waddington, Cameron Horst, Chris, Christopher Ellis, Connor Wendt, Crubidoobidoo, Danny Hayes, darkkittenfire, Electric Brain, Eric Gao, Erica, Evan Malmud, Isobel Shasha, Jack Phelps, Jesse Comb, JP Lee, jpzz kim, Justin Criswell, Kyle Harrison, Leafenzo (Seclusion Tower), Lhong Lhi, Lorg, Lukas Schneider, Luke Hopkins, Mad Science, Microchasm, Nick Young, Oskar Kogut, Patrik Bergsten, phanurak rubpol, rafael ludescher, rookie, Samuel Ang, Sebastian Cai, starbi, Steph, Stephen Sandlin, Steven Grove, Tvoyager, Voids Adrift, and Will Tallent. Thank you all so much!

If you would like to download all the shaders and experiments showcased in this tutorial, consider joining my Patreon. You will also get early access to tutorials, voting power in topic polls, and more. Thank you!

Thanks so much for reading, and make games!

🔗 Tutorial list website ▶️ YouTube 🔴 Twitch 🐦 Twitter 🎮 Discord 📸 Instagram 👽 Reddit 🎶 TikTok 👑 Patreon ☕ Ko-fi 📧 E-mail: nedmakesgames gmail

Credits, References and Special Thanks

• Samcro spm: 3D Sword and Shield Game Ready model
• SHULDYAKOV: 3D model Cat Low Polygon Art Farm Animal Free VR / AR / low-poly
• Lennart Demes: Fabric 060 and Rocks 022
• Iñigo Quilez: Noise — Gradient — 3D — Deriv
• Scratchapixel: Perlin Noise and Geometry
• Freya Holmér: The Beauty of Bézier Curves
• kjpargeter: Detailed wireframe terrain landscape in black and white
• OpenClipart-Vectors: Wireframe Human Head
• CatLikeCoding: Flat and Wireframe Shading, Tessellation, and Surface Displacement
• Alex Vlachos, Jörg Peter, Chas Boyd, Jason L. Mitchell: Curved PN Triangles
• Tamy Boubekeur, Marc Alexa: Phong Tessellation
• Alan Wolfe: Bézier Triangles
• Fabian Giesen: View frustum culling

All code appearing in GitHub Gist embeds is Copyright 2021 NedMakesGames, licensed under the MIT License.

Hi, I’m Ned, and I make games! In this tutorial, I’ll show how to create a foliage shader for Unity’s Universal Render Pipeline using the shader graph! It’s great for low poly trees, complex trees, fields of grass, and more! These types of things don’t look quite right using a default lit shader since it lacks important features, like two-sided normals, translucency and wind deformation.

Tested in Unity 2020.3 and Unity 2021.1

This tutorial covers creating a foliage shader with the URP shader graph. It is complete with diffuse, specular and translucency lighting. It supports all light types, their shadows, global illumination and fog. We’ll also look at wind deformation and two-sided rendering with normal mapping (for grass billboards).

This tutorial will not cover how to build any foliage models or textures. It will not show how to place grass blades around the game world or support character interactions through physics or otherwise. I have tutorials planned for all these topics in the near future!

I’ll assume you know the basics of Unity, URP, and the shader graph. You’ll also need to understand simple HLSL, the shader programming language, and what control keywords are (we’ll use both in custom functions). And, although I’ll give a general overview of lighting techniques, normal mapping, and tangent space, I’ll leave other tutorials to dive deep into them. Check out the bibliography at the end of this article for further reading.

Project set up

Get started by setting up your Unity project. You’ll want to go through my custom lighting in the shader graph tutorial, which provides the base for our shader. It covers adding light, shadow and global illumination support, as well as diffuse and specular lighting. Once you’ve finished, either duplicate or rename the completed shader files to “FoliageLighting.hlsl,” “FoliageLighting.subgraph,” and “TestFoliage.shadergraph.”

In FoliageLighting.hlsl, rename mentions of “custom” to “foliage.”

Then in the FoliageLighting subgraph, rename the custom function node name field to match.

Alright, set up a simple test scene to test the shader out on various types of common foliage meshes. Create a flat plane for the ground, to test shadows. Then, create a sphere game object to simulate simple, low poly trees. For a grass or bush billboard, create a quad game object and position it attached to the ground.

Now, to test for complex trees with many leaf cards — or double sided quads — craft something in Blender, or another 3D modeling program. Create three quads and rotate them so there’s one in each plane. Create edges to split each into quarters and merge vertices to weld the planes together.

Import this funny cube-like shape back into Unity and add it to your scene. Create three materials using the foliage shader, one for each model, and assign it.

To better prepare for grass and leaf cards, add alpha clipping support to the shader. In the TestFoliage graph, click “alpha clip” in the graph inspector. Add a float alpha clip threshold property and route it into the alpha threshold field of the master stack. Then, route the alpha output from the albedo texture sample into the alpha field of the master stack.

In GIMP, or another photo editor, create a simple texture with an alpha channel for the cut out texture. In Unity, set “alpha is transparency” to true.

Set up all your materials, making sure to add the alpha channel texture to the grass material.

To make sure everything’s working, test out a few lights. To test global illumination, set all the objects to static and make sure double sided global illumination is enabled on the grass and tree materials. Then, bake a light map. All good!

Double sided materials

You might notice the grass and tree meshes are invisible on one side! This is due to something called backface culling. For meshes like the sphere, it allows Unity to ignore triangles on the inside of the model. But for double-sided geometry, like foliage cards, we need to make some adjustments.

In TestFoliage, turn on the “two-sided” option in the graph inspector.

Now both sides are visible; however, the lighting is incorrect. The mesh’s normals point outwards from the front face, causing both sides to receive the same light. To fix this, flip the mesh’s normal vector when drawing the back face. To support normal mapping, make sure to use this flipped normal when transforming from tangent to world space.

Create a subgraph called “CalcDoubleSidedNormal.” This will take in a tangent space normal and output a world space normal. This “is front face” node returns true if rendering on the front face. Use a branch node to switch between 1 and -1 depending on this value.

The Transform node cannot be modified to use a different normal vector, so we must recreate it. Construct a “tangent to world” matrix using the modified normal and multiply it with the tangent space normal, and normalize. Again, for more information on tangent space and normal mapping, check out the links in the video description.

In the main graph, route your normal map sample through this subgraph instead of the transform node.

In the scene, lighting should look correct on both sides, but you might have to turn off shadows to tell.

Unfortunately, this shadow problem is difficult to fix within the shader graph, since we cannot modify the shadow caster pass. Try adjusting shadow bias settings on the light or URP asset. If this issue turns out to be a deal breaker, I have a solution in the text shader version of this tutorial.

“Shape” normals

One of the tricky things about foliage is that it should be translucent! Light filters through leaves, changing the way lighting and shadows affect them. Short of raytracing, we can’t have real translucency. But, we can add several techniques to approximate it — the first is a method using what I call “shape” normals.

Shape normals are separate normal vectors used exclusively for diffuse lighting. As opposed to the regular mesh normals we know and love, (which describe a face’s orientation) shape normals follow the overall shape of a plant. For instance, grass’s shape normals should follow the terrain, while a tree’s should point outward from a central location, following a sphere or cone. Using shape normals for diffuse lighting hides the fact that many foliage meshes are made of a bunch of flat planes.

You might be tempted to use shape normals for all lighting calculations. Regular normals, which I’ll refer to as “mesh normals,” are still useful for specular lighting and another technique we’ll get to later. The best thing to do is keep track of both. I’ll cover strategies to do this, but first let’s prepare the lighting algorithm.

Open FoliageLighting.hlsl. In the data structure, rename the current normalWS to meshNormalWS, which will hold the regular mesh normals. Add a new float3 shapeNormalWS field.

Go through the file renaming normalWS to the correct variable. Use the mesh normal in the reflection and fresnel calculations, shape normal in the diffuse formula, mesh normal in the specular dot product, shape and mesh for the diffuse and specular node previews, and shape normal to mix GI.

In the shader graph wrapper function, CalculateFoliageLighting_float, split the Normal argument into MeshNormal and ShapeNormal. Set them in the data structure. Then, pass ShapeNormal in the OUTPUT_SH and SAMPLE_GI macros.

In the FoliageLighting subgraph, update the custom function to match the wrapper function. Add a new shape normal property and route it into the custom function.

In TestFoliage, temporarily route the double sided normal into the shape normal.

Return to the scene. Things should be clear of errors, but everything will look the same. Now, to calculate the shape normals for each of our example meshes. For the sphere, which models a low poly tree or hedge, the shape normal is equal to the mesh normal. That’s how things are at the moment.

For the grass, we want the shape normal to point upward from the terrain. We need a vector which points upwards along the grass card. This corresponds to the mesh’s bitangent vector!

To support both shape normal options in the same shader, we can use an enumeration keyword. These allow you to change code depending on an option in the material. In the blackboard, add a new enum keyword called “ShapeNormal” (the option is under the new property menu). Set the definition to “shader feature,” the scope to “local,” and the exposed setting to checked. Add an entry for “MeshNormal” and “Bitangent.” You can now select an active entry in the material inspector.

If you drag this keyword property into the graph, Unity will create a branch node for you. It passes through the value connected to the currently selected keyword entry. Route a normal vector and bitangent vector into the correct fields, and then into the shape normal field of the lighting node.

In the scene editor, select the bitangent option in your grass material. Much better!

Create a C# script called “FoliageShaderSupport.cs.” Inside, add a list of transforms called normal foci. This script finds the closest focus to each vertex and calculates a vector pointing from the focus to the vertex. This will be the shape normal.

Back in the scene editor, add this script to your mesh game object. Create another GameObject for the normal focus and position it near the center of the tree; then, set it in the script. To test things out, create a vertex color node in your test foliage graph and route it directly to the base color output field.

Press play, and you should see colors on the tree mesh! Looking at it through the scene view, the colors should roughly correspond to the little XYZ compass in the corner.

Back in TestFoliage, remove the vertex color node and route the lighting back into the base color. Using another keyword entry, add the option to use vertex colors as shape normals.

Back in the scene editor, change the tree material to use vertex colors. Then, press play and check it out! If things look strange, try adjusting the position of the normal focus, adding more foci, or even adding more vertices to the mesh.

Translucency

Shape normals create smooth, more realistic lighting, but the meshes still look opaque. If you view a light through a foliage card, it should glow a little! We can simulate this translucency effect using a simple subsurface scattering lighting algorithm.

In my lighting formula explorer program, which you can check out here, I created a diagram detailing the algorithm. The effect is strongest when the view direction and light direction are opposite, which we can calculate mathematically by taking the dot product of the view direction and negative light direction.

This works well, but can make materials look flat. In reality, when light exits a transparent material, it changes direction slightly towards the surface’s normal vector. By adding the normal, scaled by a scattering coefficient, to the negative light direction, we can simulate this.

Let’s ignore scattering for now and add simple translucency to the lighting algorithm. In FoliageLighting.hlsl, add a float3 subsurface color variable — a tint applied to any light filtering through the mesh — and a float thinness variable — the translucent effect’s strength.

In the wrapper function, add arguments for these new fields and set them in the data structure.

In FoliageLightHandling, set the translucency light radiance, which is just the “regular” radiance tinted by the subsurface color. Calculate the translucency dot from the negative light direction and view direction. Similarly to specular highlights, tighten the dot product with a smoothness power and multiply by thinness. Finally, multiply the albedo, translucency radiance, and translucency strength together and add it to the final color.

In the FoliageLighting subgraph, add a new subsurface color and thinness custom function argument, and graph properties for each.

In TestFoliage, add subsurface color and thinness property as well.

In the scene editor, set your main light to point straight in the Z-direction and take a look at it through any of your meshes. You may or may not see a glow, depending on your shadow settings. The problem is the object’s cast shadows will attenuate translucency lighting as well.

The best solution is to remove shadow attenuation from the translucency radiance formula. This can cause translucency to shine in some places it shouldn’t, but In my experience, it’s not very noticeable. The final call is yours!

Let’s return to scattering and add it to our algorithm. In FoliageLighting.hlsl, add a new float field to the data structure.

And a corresponding argument in the wrapper function.

Then, in FoliageLightHandling, calculate the scattered light direction by adding the scaled mesh normal to the negative light direction. Normalize it and use it in the dot product formula.

Update the custom function and add properties in both graphs.

Then, in the scene editor, check out your materials.

It really adds a lot of depth!

So that takes care of most translucent effects, but it would be nice to approximate translucency from indirect lights too. Since we can’t change Unity’s lightmapper, the best way to do this is to add an ambient subsurface lighting strength, which gives foliage a constant glow.

In FoliageLighting.hlsl, add a new float field to the data structure.

And a corresponding argument in the wrapper function.

In FoliageGlobalIllumination, add a subsurface term to the indirect diffuse formula, multiplying the albedo, subsurface color, thinness and ambient strength.

Update the FoliageLighting custom function and add a property in both graphs.

Take a look in the scene editor. A little goes a long way!

Data Maps and Lighting Refinements

So far, all of these various lighting properties are constant over the mesh. It would be better to be able to read them from a texture, similarly to smoothness or occlusion maps. However, there are so many properties that putting each in individual textures would slow down the shader. We can combine four into one data texture, storing each in a color channel.

You can choose to vary any four properties and organize them in any channel order; however, for this tutorial, I will use the following layout: red contains smoothness, blue contains specular highlight strength, green contains translucency thinness, and alpha contains ambient occlusion.

The lighting algorithm is ready to handle this, except there’s no specular highlight strength. I feel that this is useful to prevent highlights in foliage creases, so let’s add it really quick. While we’re in there, let’s also add a multiplier to fade the ambient reflection rim effect, which might not be very prominent on foliage.

In FoliageLighting.hlsl, in the data structure, add a specular strength field and an environment reflection strength field.

Add variables for these in the custom function wrapper.

In FoliageGlobalIllumination, multiply the indirect specular result by the environment reflection strength and the specular strength. Then, in FoliageLightHandling, multiply the specular value by the specular strength.

Update the FoliageLighting subgraph with the new custom function arguments and add corresponding properties. Add properties to TestFoliage as well.

Then see how it affects your materials. OK, now it’s ready for a data map.

In the TestFoliage graph, add a new data map texture2D field and sample it. I like to keep around all the individual properties to use as multipliers for each channel, but you can also delete them for more minimal materials. Route and rearrange everything. Double check that everything is hooked up correctly.

Head into your texture creation program of choice and construct a simple test data texture. Draw a different pattern in each channel, preferably with soft gradients to test a variety of values.

Back in Unity, turn off sRGB and “alpha is transparency” in the texture importer and place it in your materials. This makes it really easy to see how each value affects lighting. You’re all set to create intricate plant-life!

Wind deformation

With that, we’re done with the lighting in our foliage shader; however, it’s too stiff to feel like real plant matter. Besides translucency, plants’ tendency to move with the wind is another challenge. We can animate meshes in the shader very efficiently by passing new vertex positions to the master stack, and it’s perfect for wind!

Create a subgraph called WindDeformation. This will take in a vertex position and output a new, deformed vertex position. Add a Vector3 wind direction property and a float strength property. Multiply the strength by the direction and add it to the position, returning the result.

We can vary the wind strength over time and space using a noise texture. Add a Texture2D noise texture property and sample it using a sample LOD node (it must be an LOD node, since we’ll use this during the vertex shader stage). Next, calculate a UV. World position should influence it, so use a Swizzle node to select the XZ world space position and multiply it with a new noise scale property. Similarly, multiply time by a noise frequency property.

The output of the texture sample ranges from zero to one, but that would weight the deformation on one side of the model. Use a remap node to change it to range from -1 to 1. Use a split node to grab the red channel and multiply it with the wind strength.

Plants won’t sway in a straight line, due to wind turbulence. To simulate it, add a float turbulence strength property and a cross wind direction. This “cross” direction will be perpendicular to the main direction. Multiply the turbulence strength by the wind strength (so it is proportional), the noise green channel, and finally the cross wind direction. Add the offsets together.

In test foliage, add the new WindDeformation node. Create properties for wind direction, strength, turbulence, noise texture, noise scale, and noise frequency. Route all these into the wind deformation node, as well as vertex position, in world space.

For cross direction, we need a perpendicular to the wind direction, but still looks natural (it shouldn’t point into the ground, for example). The cross product of the wind direction and the “shape normal” will do the trick. Finally, route the deformed position through a “world to object” transformation node and into the position field of the vertex stage master stack.

Open your image processor of choice and create a noise texture. Make sure it has independent noise in the red and green channels. You can use any shape you want, but I found simple cloud or Perlin noise does the trick. In Unity, make sure the texture importer has sRGB turned off. You also safely turn off mipmaps, as well as compression if the wind motion ever feels jittery.

Set up your materials! So, we have wind, but there are several problems. First off, wind causes the grass to detach from the ground! We need a way to scale wind strength over the mesh so it’s weaker near the bottom of the grass quad.

Luckily, the UV’s y-coordinate follows exactly the pattern we need.

First, in the wind deformation subgraph, add a float dampening property. Multiply it with the final offset before adding to vertex position.

In the main graph, we need to route the UV Y coordinate into this new field, but only for grass. Otherwise, dampening should be one. Another keyword will do the trick: add an enum keyword called WindStrength, with all the same settings as before. Create two entries: “Constant” and “UV Y.”

Drag it onto the graph, connect a Float node with a value of 1 into Constant, and a UV node with a Split node, to grab the Y coordinate, into UV Y. Route that into the dampening field.

In the scene editor, change the wind strength enum on your grass material to UV Y. Much better.

Let’s take a look at the tree. I see two problems. First, imagine if a leaf texture was assigned to this material. The wind would cause it to stretch and distort in unnatural ways. To fix this, we should use the same position for all vertices when sampling the wind noise. Second, parts of the mesh attached to the trunk should not move. Imagine the center vertex is anchored in this way.

We can fix both of these problems by storing custom wind noise anchors and dampening values in the mesh vertex data. Meshes can store a bunch of independent UV coordinates, and the shader graph can access four. The last set, referred to as “UV3” or “TexCoord3,” is usually unused, so we can use our C# script to store this wind data inside it.

Open FoliageShaderSupport.cs. I’ll go over this code quickly, since it’s tangential to the foliage shader. Our goal here is to set the wind noise positions to a constant position (the center of the mesh’s bounds will work), and the wind dampening values to a value proportional to distance from the closest focus. Anchors are stored in the XYZ channels of the TexCoord3 vector, while dampening in the W channel. Set the array in the mesh’s UV stream, and it’s ready to be read by the shader.

In the WindDeformation subgraph, add a new Vector3 noise position property. Use that instead of vertex position when calculating the noise UV.

In TestFoliage, add another enum keyword called WindAnchor. Add two entries: Position and TexCoord3. Drag the keyword onto the graph and route a position node, in world space, and a UV node, in UV3 channel mode, into the fields. Connect that into the noise position field of the wind deformation node.

To support precalculated wind dampening values, add a third entry to the wind strength enum keyword called TexCoord3. Use a split node to grab the W-component from another UV node in UV3 channel mode into the new option.

In the scene editor, verify your tree model has the script attached and that the TexCoord index is 3. Switch the tree material keyword modes to TexCoord3 and enter play mode, so the script runs. That’s more like it! Feel free to modify the C# script as you need — this data is highly dependent on each individual model. But for now, time to address the last problem.

If you look closely on any model — but it’s especially apparent on the sphere — you’ll notice that wind deformations don’t affect specular lighting. They should, since wind deformations change the apparent normal of the mesh. The normal vector doesn’t automatically update to match new vector positions, so we need to recalculate them — and tangents as well. It’s difficult to do perfectly, since a shader only knows the position of one vertex at a time, but we can estimate it.

The strategy is to run three points through the wind deformation algorithm — the original position, and the original position slightly offset in the tangent and bitangent directions — and see how the deformation algorithm affects them. We can construct new tangents and bitangents and thus a normal from their cross product.

Implement it in a new subgraph called “WindDeformationWithOrientation.” Inside, output a position, normal, and tangent vector, and add properties for wind direction, cross direction, strength, turbulence, noise texture, noise position, noise scale, noise frequency, and dampening. Create a WindDeformation node and route all the properties into it. Duplicate the deformation node twice, leaving everything attached.

Route world space position into the top wind deformation node. The middle node takes the position nudged a small distance in the tangent direction. The bottom node needs the position nudged along the bitangent, but due to some quirks with the way the shader graph bitangent node works, it’s safer to calculate the bitangent yourself. Route the normal and tangent through a cross product node and normalize the result.

Subtract the top node’s output from both of the other outputs and take their cross product. The order is important. Connect up the deformed position and normal outputs. For the deformed tangent, normalize the first cross vector — it’s guaranteed to be perpendicular to the normal, thanks to the cross product.

In TestFoliage, replace the WindDeformation node with a WindDeformationWithOrientation node. Route the normal and tangent vectors through a world to object transform node before connecting them to the master stack.

In the scene editor, you won’t really notice any changes. This is because we separated vertex position from the noise UV, which partially determines wind offsets. In the WindDeformationWithOrientation subgraph, add the tangent and bitangent offsets to the noise positions.

This looks great on the sphere!

But, not so much on the tree and grass. The shine seems almost random, which is an artifact of the distance between vertices skipping over and not reflecting changes in the wind noise. Adding more vertices would certainly help, but perhaps the right solution is to turn off normal recalculation when using low poly meshes.

In the main graph, add a boolean keyword called “WindDeformsNormals_On.” The “On” suffix is important to make sure it is editable in the material. Drag this on to the graph twice, connecting the deformed normal and tangent into the “on” fields. Route a normal and tangent node, both in object space, into the “off” fields. Connect these to the master stack.

In the scene editor, turn off normal deformations for the grass and tree materials. As I mentioned, it’s difficult to get normal deformation perfect without employing some costly techniques. If it is important to your game, you can continue refining the algorithm to match your model’s needs. Maybe calculate dampening based on position, or use a function instead of a noise texture (so you can calculate exact normals). Regardless, this option is available.

Wrap up

I think that’s about it for foliage in the shader graph. You can endlessly tweak things to fit your specific model. Speaking of that, I’d love to see your trees, grassy plans, or video game gardens! Feel free to send me screenshots!

For inspiration, here are the material settings I used to create the scenes in this video. The tree has a custom support script to set wind data, which finds connected pieces of the mesh, making sure each chunk has the same wind noise position.

Some effects currently not possible in the shader graph, like screen space ambient occlusion, do really improve the final look. You can add support pretty easily when 2021.2 releases, or take a look at the upcoming text shader version of this tutorial, which already supports it.

Thank you so much for reading! Foliage is really fun to create, I think, and I’ve only really scratched the surface of foliage rendering here. I have several more videos planned, including one specifically on covering terrain with fields of grass. Please keep an eye out for it!

Here is the final version of the scripts in the project, for cross referencing.

If you have any questions, feel free to contact me at any of the links at the bottom of this article.

If you want to see this tutorial from another angle, I created a video version you can watch here.

Try out my Interactive Lighting Math Explorer to visualize how diffuse, specular, translucency and other lighting calculations work: https://nedmakesgames.itch.io/lighting-explorer

I want to take a moment to thank David Cru for his support, all my patrons from the last few months for making this tutorial possible: Adam R. Vierra, Aleksandr Molchanov, Alina Matson, Alvaro LOGOTOMIA, Andre Schuch, Antonio Ripa, anzhony manrique, Ash Free, Ben Luker, Ben Wander, BM, Bohemian Grape, Brooke Waddington, Cameron Horst, Candemir, ChainsawFilms, Chris, Christopher Ellis, Connor Wendt, Danny Hayes, darkkittenfire, David Cru, Evan Malmud, Eren Aydin, Erica, FABG Team, Georg Schmidbauer, hyunsookim, Isobel Shasha, Jack Phelps, Jerzy Gab, JP Lee, jpzz kim, Justin Criswell, Karthick Gunasekaran, Kyle Harrison, Leafenzo, Lhong Lhi, Luke Hopkins, Mad Science, Mark Davies, masahito nagasaka, Matt Anderson, maxo, Mike Young, NG, nobuhiko yamakoshi, Omar Sadek, Oskar, Oskar Kogut, Pat, Patrik Bergsten, peter janosik, phanurak rubpol, Qi Zhang, Quentin Arragon, rafael ludescher, Sam Slater, Samuel Ang, Sebastian Cai, SlapChop, starbi, Steph, Stephen Sandlin, Tomasz Beneś, Tvoyager, Voids Adrift, Will Tallent, Winberry, 성진 김

If you would like to download a completed version of this tutorial and many of the files featured here, consider joining my Patreon. You will also get early access to tutorials, voting power in topic polls, and more. Thank you!

Thanks so much for reading, and make games!

🔗 Tutorial list website ▶️ YouTube 🔴 Twitch 🐦 Twitter 🎮 Discord 📸 Instagram 👽 Reddit 🎶 TikTok 👑 Patreon 📧 E-mail: nedmakesgames gmail

Credits, references, and special thanks

• Cyanilux: URP_ShaderGraphCustomLighting
• Ada_King: LowPoly Trees & Carrot & Crystal 3D model
• XfrogPlants: Curry Leaf Tree Free 3D model
• Lennart Demes: Grass 001
• Baptiste Manteau: Bark old ginko
• Render Knight: Fantasy Skybox FREE
• Alan Zucconi: Fast Subsurface Scattering in Unity
• CatLikeCoding: Rendering 6 Bumpiness
• Ben Golus: Normal Mapping for a Triplanar Shader & Generating Perfect Normal Maps for Unity (and Other Programs)
• TotallyRonja: Vertex Displacement

All code appearing in GitHub Gist embeds is Copyright 2021 NedMakesGames, licensed under the MIT License.

Hi, I’m Ned and I make games! In this tutorial, I show how to implement custom lighting in Unity’s shader graph for the Universal Render Pipeline. As of now, there are no nodes which expose light data or modify the result of the default PBR calculation. Thankfully, you can get around this and handle materials that don’t look quite right on a lit graph, like foliage or skin, or need stylized lighting, like a toon shader.

Tested Unity versions: Unity 2020.3 and Unity 2021.1.

This custom lighting implementation includes a simple lighting algorithm featuring diffuse and specular lighting. It supports lighting and shadows from the sun light and additional point and spot lights, baked lighting, light probes, and fog. Note: point light shadows are only available in Unity 2021.1 and later.

I’ll assume you know the basics of Unity, URP, and the shader graph. You should also understand simple HLSL (the shader programming language) and what control keywords are. Finally, although I’ll give a general overview of various lighting terms and techniques, I won’t explain them in detail.

Project set up

First, create a new project using the URP template or set your project up to use URP by creating a settings asset and assigning it in graphics settings. Create the following simple test scene:

Create a plane. Create a sphere floating above it. Create an unlit URP shader graph called “TestLighting.” Create a material. Assign it the TestLighting shader. Set it on both test objects. To enable easy reuse, create a shader subgraph called “CustomLighting.”

Let’s initialize the graphs to sample a texture and display it with no lighting.

Open CustomLighting. Create a float3 “Albedo” property. Change the output parameter to a float3 named “Out.” Route Albedo into Out.

Open TestLighting. Add a Texture2D “Albedo” property. Sample it. Add a CustomLighting node. Route the nodes together.

The bulk of the custom lighting algorithm must happen in a custom function node, which works best with a shader code HLSL file. You cannot create a .hlsl file directly through Unity, so open your asset folder in your operating system. Create a text file called CustomLighting and change the file extension to “.hlsl.” Open it in your script editor.

First, set up a guard keyword to prevent this file from being compiled twice. This file has three main parts: the first, CustomLightingData, is a data structure containing all data needed for the lighting calculation. The second, CalculateCustomLighting, contains and executes the lighting algorithm (right now, just returning albedo). The third, CalculateCustomLighting_float is the custom function wrapper which the shader graph can call. Note the number precision suffix. This wrapper constructs the data struct and calls the main function. Separating the wrapper from the algorithm gives you better control over data flow and also enables easy reuse from non-graph shaders, if you ever have the need.

Return to the CustomLighting subgraph. Create a CustomFunction node. Set up the input and output to match the wrapper function in CustomLighting.hlsl. Set the name to “CalculateCustomLighting” (the number precision suffix is not required) and the source to your HLSL file. Reroute the graph through your custom function.

You may see some errors while setting the function up; however, if the preview box is black, you’re good to go. If it’s magenta, an error still exists. Double check your spelling — everything is also case-sensitive. When everything is working, your test scene will have flat shading.

Diffuse Lighting

Diffuse lighting refers to the soft light that illuminates the side of an object facing a light source. It’s calculated by taking the dot product of the surface’s normal vector and the light direction. Let’s add shape to our scene by calculating diffuse lighting for the main light.

Open CustomLighting.hlsl. Add a normal vector field to CustomLightingData. Rewrite CalculateCustomLighting to call GetMainLight (from URP’s shader library), obtaining a struct containing the main light’s direction and color. Call a new CustomLightHandling function.

This function computes the color resulting from the passed light. The radiance variable contains the light’s strength — right now purely its color. Calculate the diffuse dot product, then multiply the result with the surface albedo and radiance to compute the final color.

Finally, in the custom function wrapper, add a normal argument and set it in the struct.

Back in the CustomLighting graph, you’ll get an error about no function existing. Just add a float3 “normal” input to the custom function and move it above “albedo,” so the inputs match the wrapper function once again. Now, you’ll get an error about “GetMainLight” or the “Light” structure not existing. This occurs because the shader graph doesn’t include the URP lighting library when rendering the node preview windows.

To fix this, we need to exclude sections of code from the shadergraph previews. Add an if-not-defined block around the CustomLightHandling function. Then in CalculateCustomLighting, write this estimation of diffuse lighting for the preview windows, placing the old logic in the else block.

In your subgraph, the errors should disappear. Add a vector3 “normal” attribute and route it into the custom function.

In the TestLighting graph, you can route a normal vector node into the subgraph, or, if you want to use normal maps, a normal map sample transformed into world space. Either way, check out your shaded scene!

Specular Lighting

Specular lighting models the small highlight visible on a shiny surface. It’s calculated by taking the average of the view direction and light direction, and then, taking the dot product of this “half” vector and the surface’s normal vector. Using this specular value directly sometimes leads to highlights in dark areas. Multiply with the diffuse lighting value to avoid this artifact.

Open CustomLighting.hlsl. Add a view direction field to CustomLightingData and the wrapper function. In CustomLightHandling, calculate the specular lighting dot product. Then, multiply it with “diffuse” to calculate the final specular value. Finally, to add the specular component of lighting, add “diffuse” and “specular” together in the final color calculation.

In the CustomLighting subgraph, create a view direction node, set to world space. In certain Unity versions, view direction is not normalized; route it through a normalize node. Then, update and route into the custom function.

Looking at your scene now, it will be difficult to see any highlights. We’ve neglected smoothness, which controls how focused the specular highlight is.

Open CustomLighting.hlsl. Add a float field for smoothness in CustomLightingData and update the custom function wrapper. In CustomLightHandling, tighten the specular dot by taking it to a power related to smoothness, defined by GetSmoothnessPower function. It transforms a value ranging from 0 to 1 on an exponential curve, but the math is ultimately arbitrary. You can edit it as needed. This results in a higher smoothness value shrinking the specular highlight.

Before moving on, add a specular approximation for the node preview windows to CalculateCustomLighting.

Back in the CustomLighting subgraph, add a float smoothness property to the custom function and a corresponding graph property.

Then, in the TestLighting graph, add another smoothness property. For ease of editing, set it to slider mode, ranging from zero to one. Check out your handiwork!

Shadows

Shadows are an important part of lighting, and take a bit to set up. If you move an object using custom lighting over something with a default lit material, you’ll see it does cast a shadow already! However, our custom lit shader does not receive shadows. There are a few things we need to do to fix that.

First, the programming. Open CustomLighting.hlsl. Shadows, at least for the main light, are held in textures called shadow maps. The system needs a value called a shadow coordinate to accurately read them; as well as this fragment’s world position. Add both in CustomLightingData— notice that the shadow coord is a float4.

In the custom function wrapper, only add a position argument and set the position in the structure. We can calculate the shadow coord from this position. Set up another preview keyword block. In the preview side, set the coord to zero. In the else side, calculate this fragment’s clip space position (which is related to the pixel it displays in on screen). Depending on your shadow settings, Unity might store shadow maps in different layouts, needing different coordinates. This keyword allows you to calculate the correct value.

In CalculateCustomLighting, when calling GetMainLight, pass the shadow coord and position. The third argument is something called a shadow mask, which we’ll come back to later. This let’s Unity set a field in the Light structure called shadowAttenuation, which is a multiplier to this light’s radiance due to shadows. In CustomLightHandling, multiply it with the light color when calculating radiance.

In the CustomLighting subgraph, add a position argument to the custom function and route a position node in world space into it. In the scene, you’ll notice your materials still receive no shadows. This occurs because, to save resources, Unity does not sample shadow maps unless you explicitly tell it to by using various shader keywords.

Return to the CustomLighting subgraph. Add a boolean keyword (the option is under the new property menu). The name isn’t important, but the reference must be _MAIN_LIGHT_SHADOWSexactly — underscores and capitals matter! Set the definition to “multi compile,” the scope to “global,” and the default to on.

Now in the scene, you’ll get an error about shadowcoords not existing. To fix this, open CustomLighting.hlsl and add this little snippet. Discovered by Cyanilux, it removes some unnecessary code from shaders generated by the shader graph, avoiding the error.

At this point, if you don’t see any shadows, make sure they’re enabled in your URP pipeline settings and on your camera (and if not using a fresh project, that cascade count is one).

To make them look better, add two more boolean keywords to CustomLighting, enabling shadow cascades and soft shadows. Keep the settings the same, but set the references to _MAIN_LIGHT_SHADOWS_CASCADE and _SHADOWS_SOFT. Make sure cascades and soft shadows are also enabled in your settings asset.

More Lights

There’s only so much you can do with a single light, so let’s add support for point and spot lights. We’ve got the framework ready, so it won’t be too difficult.

Open CustomLighting.hlsl. Unity stores additional light data separately from the main light in a buffer, which we need to loop through. This is the primary reason why I prefer implementing custom lighting all in one custom function, since loops are impossible in the shader graph. Anyway, Unity defines a keyword if this object is affected my additional lights, so create an if-def block for it.

Inside, call GetAdditionalLightsCount to get the number of additional lights, then loop through each. GetAdditionalLight returns a Light data structure for the specified light. It works just like GetMainLight, except it doesn’t require a shadow coord — that’s only for main light shadows. Send the light data to CustomLightHandling and add the returned color to the final color.

Unlike the main light, point and spot lights’ strength varies based on position. This is encapsulated by the distanceAttenuation field in the Light data structure. In CustomLightHandling, multiply it into the radiance calculation. distanceAttenuation is always 1 for the main light.

Back in the CustomLighting subgraph, add two more boolean keywords with the references _ADDITIONAL_LIGHTS and _ADDITIONAL_LIGHT_SHADOWS. Again, set the definition to “multi compile,” the scope to “global,” and the default to on. Then, select your URP settings asset and set additional lights to per pixel and enable cast shadows.

Create some lights to test things out! Make sure all lights are in realtime mode and that the shadow type is not “no shadows.” Turn up the intensity so things are really plain to see. Note that point light shadows are only available in Unity 2021.1 and later.

Global Illumination

Global illumination is a broad concept including baked lightmaps, light probes, global reflections, shadow masks, and spherical harmonics. We can implement them all in one fell swoop! I won’t spend much time explaining how these various techniques work or how to use them — each deserves its own tutorial. Just know they try to add a lot of inexpensive lighting to a scene.

In CustomLighting.hlsl, add two new fields into CustomLightingData: ambientOcclusion, which controls how much global lighting this fragment should receive, and bakedGI, which is the baked lighting color for this fragment.

Moving down to the wrapper function, add an argument for ambient occlusion and set it on the struct. As for baked GI, we’ll calculate it using a few special functions and macros. They require the lightmap UV, which we’ll receive as an additional argument.

In the not-preview block below, call OUTPUT_LIGHTMAP_UV to get the final lightmap UV using the lightmap scale Unity provides. OUTPUT_SH calculates the spherical harmonics for this fragment, which encode the color of the nearest light probes. Finally, resolve everything into a single baked global illumination value with SAMPLE_GI. It samples the lightmap texture, if available.

To add global light sources into our lighting algorithm, write a CustomGlobalIllumination function inside the preview-not-defined block. URP did the hard work in the custom function wrapper, so just multiply the albedo, bakedGI, and occlusion values together to calculate indirect diffuse. Return it.

In CalculateCustomLighting, initialize the color variable with CustomGlobalIllumination. But before that, we need to correct the global GI value. Under some circumstances, the main light’s shading contribution is also baked into global GI. We don’t want to include it twice, so call this URP function, MixRealtimeAndBakedGI, to remove the main light from the globalGI value, if needed.

Open your subgraph and create arguments for ambient occlusion and lightmap UV. Add a new float property for occlusion and hook it into the custom function. The lightmap UV is usually automatically stored by Unity in the second set of UVs, which is UV1. Route a UV node, in UV1 mode, into the lightmap UV field. Finally, add one more boolean keyword with LIGHTMAP_SHADOW_MIXING as the reference, which enables mixed lighting.

In the TestLighting graph, create an ambient occlusion property. It should be a slider ranging from zero to one. You can, of course, use an occlusion map if you’d prefer!

Now test things out in your scene. Create a few new lights and set them to baked mode. Set your ground plane GameObject to static so it will receive lightmaps. Create a light probe group around your floating sphere. To make things easier to see, have differently colored baked lights appear on opposite sides of the probes. Once ready, save your project and navigate to the lighting panel (Window -> Rendering -> Lighting). Select generate lighting and wait for the lightmapper to finish its work.

First, check that baked lighting appears on your plane. If you disable realtime lights, you should still see some lighting where the baked lights were. Then, test light probes by moving your sphere around. Again, it might be difficult to notice at first, so turn off realtime lights and look for slightly different coloring on your sphere.

Moving on to baked reflections. Unity creates a reflection cubemap based on the skybox, and it’s very easy to get a hold of.

In CustomLighting.hlsl, add these lines to CustomGlobalIllumination. We first need to sample the cubemap by calculating the sample normal. Visualize yourself standing at its center and looking at the pixel to sample — that’s the sample normal. In this situation, modeling a mirror, we calculate it by reflecting the view direction around the normal vector.

I found that reflections look nice around the edge of an object, an effect known as a rim or Fresnel light. It’s calculated by finding the dot product of the normal and view direction, subtracting it from one, and tightening it with an exponent (4 in this case).

Call GlossyEnvironmentReflections to sample the cubemap, passing the sample normal, a roughness value, and the occlusion. Roughness is one minus smoothness, and affects how blurry the reflections are. I’m repurposing this function from URP’s PBR rendering code, which expects something called “perceptual roughness.” Luckily, we can convert to that using RoughnessToPerceptualRoughness. Finally, multiply by fresnel and add the indirect specular result to the final calculation.

That’s it! If the effect is too strong, you can reduce reflection strength in the lighting window.

Finally, let’s add baked shadows. These are lightweight, precalculated shadows for the main light baked into a texture, like lightmaps. They’re always used for far away objects, but you can turn them on for all objects in the quality settings.

Open CustomLighting.hlsl. It’s time to tackle that shadowmask value I spoke about earlier. Add a float4 field in CustomLightingData. In the wrapper function, set the shadow mask to zero in the preview block, and call SAMPLE_SHADOWMASK at the end of the not-preview block. Then, in CalculateCustomLighting, pass the new shadowmask value as the third argument to GetMainLight and GetAdditionalLight.

In your CustomLighting subgraph, add one more boolean keyword with SHADOWS_SHADOWMASK as the reference and the same settings as always.

To test shadowmasks, add a large, static object above your plane, set your main light to mixed mode, and bake lighting again. Go to your quality settings and change the Shadow Mask mode to “Shadowmask.” You should see shadows on all static objects, like your ground plane. Note that light probes received baked shadows, so that will affect the lighting of dynamic objects.

Before moving on, change the shadowmask mode back to distance shadowmask. Now, baked shadows are only used for distant objects.

Fog

Fog is the final feature I will add in this tutorial, and it’s pretty simple. It’s a method to fade distant objects into a flat color, to help avoid pop-in.

In your hlsl file, add a fogFactor field to the data struct, which URP will use to calculate the fog strength. We’ll set it in the function wrapper. Set fogFactor to zero in the preview block. Otherwise, call ComputeFogFactor, which uses this fragment’s the clip space z-position, related to it’s depth from the camera.

In CalculateCustomLighting, call MixFog. This URP function applies fog to the final color, taking care of all fog modes for us.

Return to the scene view and test things out by turning on fog in the lighting window. Try each mode and adjust the settings. MixFog can handle them all!

Upcoming Changes

In version 2021.2, Unity is poised to release many new features to URP and the Shader Graph which will affect this project. The biggest change is the addition of custom vertex interpolators, which will allow us to support vertex lights and more efficient global illumination. They’re also adding light cookies, reflection probe blending, light layers, screen space shadows and ambient occlusion (for unlit graphs), and deferred rendering. Needless to say, expect a follow up tutorial after 2021.2 releases.

Wrap Up

Thank you so much for reading! Now you have the convenience of the Shader Graph and complete control over how your game looks. Use these techniques well and your project will really stand out! I’m currently working on a tutorial building on this framework to create a grass, leaf, and general foliage shader. Please keep an eye out for it!

Here is the final version of the script, for cross referencing.

If you have any questions, feel free to contact me at any of the links at the bottom of this article.

If you want to see this tutorial from another angle, I created a video version you can watch here: https://www.youtube.com/watch?v=GQyCPaThQnA

Try out my Interactive Lighting Math Explorer to visualize how diffuse, specular, and other lighting calculations work: https://nedmakesgames.itch.io/lighting-explorer

I want to take a moment to thank David Cru for his support, and all my patrons for making this tutorial possible: Adam R. Vierra, Aleksandr Molchanov, Alina Matson, Alvaro LOGOTOMIA, Antonio Ripa, anzhony manrique, Ben Luker, Ben Wander, BM, Bohemian Grape, Cameron Horst, Candemir, ChainsawFilms, Chris, Christopher Ellis, Connor Wendt, Danny Hayes, darkkittenfire, David Cru, Evan Malmud, Eren Aydin, FABG Team, Georg Schmidbauer, hyunsookim, Isobel Shasha, Jerzy Gab, JP Lee, jpzz kim, Karthick Gunasekaran, Kyle Harrison, Leafenzo, Lhong Lhi, Luke Hopkins, Mad Science, Mark Davies, masahito nagasaka, Matt Anderson, maxo, Mike Young, NG, Oskar Kogut, Pat, Patrik Bergsten, phanurak rubpol, Qi Zhang, Quentin Arragon, rafael ludescher, Sam Slater, Sebastian Cai, SlapChop, starbi, Steph, Stephen Sandlin, Tvoyager, Voids Adrift, Will Tallent, Winberry, 성진 김

If you would like to download a completed version of this tutorial and all the files featured here, consider joining my Patreon page. You will also get early access to tutorials, voting power in topic polls, and more. Thank you!

Thanks so much for reading, and make games!

🔗 Tutorial list website ▶️ YouTube 🔴 Twitch 🐦 Twitter 🎮 Discord 📸 Instagram 👽 Reddit 🎶 TikTok 👑 Patreon 📧 E-mail: nedmakesgames gmail

Credits, references, and special thanks:

• Cyanilux: URP_ShaderGraphCustomLighting
• Ida Faber: Lowpoly Shiba Inu Dog
• XfrogPlants: Curry Leaf Tree Free 3D model
• Lennart Demes: Grass 001
• Baptiste Manteau: Bark old ginko
• Render Knight: Fantasy Skybox FREE

All code appearing in GitHub Gist embeds is Copyright 2021 NedMakesGames, licensed under the MIT License.