Unreal Engine 4 Shaders and Effects Cookbook: Over 70 recipes for mastering post-processing effects and advanced shading techniques

Before we actually start creating our basic studio scene, we will need to download Unreal Engine 4. I've started writing this book with version 4.20.3, but don't hesitate to use the latest version at the time of reading. 

Here's how you can download it:

And that's all you need! We now have everything required to get started in Unreal Engine 4. How cool is that? A whole new game engine at our fingertips, completely free, and with a variety of tools within it that would take years to learn and master. It really is a thing of wonder! Next up, we are going to start learning about one of those tools—the materials. And in order to do so, let's start by creating our first project!

Let's start by launching the engine that we have just installed and creating a new project by taking the following steps:

Epic has recently collaborated with multiple content creators to make a multitude of different assets available to anyone using Unreal, and you can check them out at the following website: https://www.unrealengine.com/en-US/blog/new-free-content-coming-to-the-unreal-engine-marketplace?utm_source=launcher&utm_medium=chromium&utm_term=forum&utm_content=FreeContent&utm_campaign=communitytab.

The asset called BP_Light Studio is a blueprint that Epic Games has already created for us. It includes several lighting settings that will make our lives easier—instead of having to set up multiple lights and assign them different values, it automates all of that work for us so we just have to choose how we want our scene to look. Making a simple studio scene will be something very easy to do this way.

Retaining that level of control over which lights are placed and how we do that is, of course, very important, and something that we'll do later in the book, but for now this is a very powerful tool that we will use.

HDRi images are very useful for 3D artists, even though they can be tricky to create as it is usually a lengthy process. There are many websites from which you can buy them, but I like the following one that gives you free access to some very useful ones: http://www.hdrlabs.com/sibl/archive.html.

We will be using the one called Alexs Apartment, which is quite useful for interior visualization.

We should now be looking at something like the following:

With that out of the way, we can say that we've finished creating our basic studio scene. Having done that will enable us to use this level for visualization purposes, kind of like having a white canvas on which to paint. We will use this to place other models and materials as we create them, in order to correctly visualize our assets.

There are at least two different objectives that we can complete if we follow the previous set of steps—the creation of our intro scene being the first one and the second one being getting familiar with the engine. This final task is something that will continue to happen over time—but getting our hands dirty now will have hopefully accelerated that process.

Something that could also speed that up even more is a review process of what we've just done. Not only will we learn things potentially faster, but knowing why we do the things the way we do them will help us cement the knowledge we acquire—so expect to see a How it works... section after each recipe we tackle! As the first ever example of the aforementioned section, we'll briefly go over what we have just done before in order to understand how things work in Unreal.

The first step we've taken was to actually create the Unreal Engine project on which we'll be working throughout this book. We've then added the assets present in the Starter Content package that Epic Games supplies, as it contains useful 3D models and materials that we can check later on as we work on other recipes. The most important bit we've done was probably the lighting setup though, as this will be the basis of some of the next recipes. This is because having a light source is vital to visualizing the different assets that we create or add to the scene. Lighting is something that we'll explore more in some of the next recipes, but the method we've chosen in this one is a very cool technique that you can use in your own projects. We are using an asset that Unreal calls a blueprint, something that allows you to use the engine's visual scripting language to create different functionalities within the game engine without using C++ code. This is extremely useful, as you can program different behaviors across multiple types of actors to use to your advantage—turning a light on and off, opening a door, creating triggers to fire certain events, and so on. We'll explore them more as we go along, but at the moment we are just using an already available one to specify the lighting effects we want to have in our scene. This is in itself a good example of what a blueprint can do, as it allows us to set up multiple different components without having to specify each one of them individually—such as the HDRi image, the sun position, and others that you can see if you look at the Details panel. 

There's not much we need to do at this point—all thanks to having previously created the basic blank project. That's the reason we created it in the first place, so we can start working on our materials straight away. Having set up the studio scene is all we need at this point.

In spite of this, don't feel obliged to use the level we created in the first recipe. Any other one will do, as long as there are some lights in it that help you visualize your world. That's the advantage of the PBR workflow, that whatever we create following its principles will work across different lighting scenarios. Let's jump right in!

It's now time to take a look at how the material editor works, at the same time as we create our first material. This editor includes many different tools and functionalities within it, so there are plenty of things to take a look at!

The first important thing we will be doing is to actually create a material. Of course, this is a very trivial action and there's not much to explain—just right-click anywhere on the content browser and select the Create Basic Asset | Material option. What is important is knowing how to name and organize our contents. Even though keeping the Content Browser organized is not the main goal of this chapter, I didn't want to pass up on the opportunity to briefly talk about that.

One good way of keeping things tidy is to organize the folder structure in categories (Materials, Characters, Weapons, Environment...) and naming the different assets using Unreal's recommended syntax. You can find more about that on several discussion forums or on Epic Games' wiki:

The second important thing we want to be doing is to make sure that the layout we are looking at is the default one, just so that the images we will be including later on match what you'll be seeing in your monitor. To do that, go to Window | Reset Layout, as shown in the following screenshot:

Remember that resetting the layout to its default state can still make things not look perfectly equal between your screen and mine—that's because settings such as the screen resolution or its aspect ratio can hide panels or make them imperceptibly small. Feel free to move things around until you reach a layout that works for you!

Now that we've made sure that we are looking at the same screen, let's turn our attention to the material editor itself and the different parts that constitute it. By default, this is what we should be looking at:

Now that we've taken a look at the different parts that make up the material editor in Unreal, we can start creating our own first simple material—a plastic. I find plastics to be a very straightforward type—even though we could make them as complicated as we want to. So, let's explore how we would go about at creating it:

It's not something that you should concern yourself with at this stage, but can come in handy in the future!

At the moment, we can see that we have managed to modify the color of our material. We can now change how sharp the reflections are, as we want to go for a plastic look. In order to do so, we need to modify the Roughness parameter with another different constant. Instead of right-clicking and typing, let's choose it from the palette menu instead.

If you look at the preview viewport, you will notice that the appearance of the material has now changed. It looks like the reflections from the environment are much sharper than before. This is happening thanks to the previously created constant pin, which, using a value closer to 0 (or black), makes the reflections stand out that much more. Whiter values decrease the sharpness of those reflections or, in other words, make the surface appear much more rough.

Having done so, we are now in a position where we can finally apply this material to a model inside of our scene. Let's go back to the main level and look at the Modes panel, particularly to the Basic section. Drag and drop a cube into the main level, and assign it the following values inside of the Details panel just so we are looking at the same:

Reducing the size of the cube will make it fit better into our scene. Now head over to the Materials section of the Details panel, and click on the drop-down menu. Look for the newly created material and assign it to our cube. Finally, click on the Build icon located on the toolbar as follows:

And there it is! We now have our material applied to a simple model, being displayed on the scene we had previously created. Even though this has served as a small introduction to a much bigger world, we've now gone over most of the panels and tools that we'll be using in the material editor. See you in the next recipe!

We've used the present recipe to learn about the material editor and we've also created our first material. Knowing what each section does within the editor will help a lot in the immediate future, as what we've just done is but a prelude to our real target—creating a physically based material. Now we are in a much better position to tackle that goal, so let's look at it in the next recipe!

Before moving on though, let's check the nodes that we have used to create this simple material. From an artist's point of view, the names that the engine has given to something like a color value or a grayscale value can seem a bit confusing. It might be difficult to establish a connection between the name of the Constant3Vector node and our idea of a color. But there is a reason for all of this!

The idea behind that naming convention is that these nodes can be used beyond the color values we have just assigned them. At the end of the day, a simple constant can be used in many different scenarios—such as depicting a grayscale value, using it as a brightness multiplier, or as a parameter inside a material function. Don't worry if you haven't seen these other uses yet, we will—the point is, the names that these nodes were given tell us that there are more uses beyond the ones we've seen.

With that in mind, it might be better to think of those elements we've been using in more mathematical terms. For instance, think of a color as an Red Green Blue (RGB) value, which is what we are defining with that previous Constant3Vector node. If you want to use an RGB value alongside an alpha one, why not use the Constant4Vector, which allows for a fourth input? Even though we are at a very early stage, it is always good to familiarize ourselves with the different expressions the engine uses.

We don't need a lot in order to start working on this recipe—just the project we have previously created so we don't have to start from scratch. You can continue using the previous section's materials or create new ones, whatever works best for you! Something that would be helpful to have is the scene from the previous recipe open, for instance—that way we already have a 3D model in it that we can use to show our materials on.

Let's start our journey into the PBR pipeline by creating a new material and looking at the different attributes that define it:

The settings you see here are the default ones for most materials in Unreal, and they follow the PBR pipeline very closely. The first option, the Material Domain, is currently set to Surface. That tells us that the material we are creating is meant to be used on a 3D model. Blend Mode, which has a value of Opaque, indicates that it is not a translucent material like glass. Finally, the shading model is set to Default Lit, which is the default one for most materials.

This configuration is the default one for most common materials, and the one that we'll need to use to define materials such as metal, plastic, wood, or concrete, to name a few.

The Metallic attribute defines whether we are creating a metal or a non-metal material. We should use a value of 1 to define metallic surfaces and a value of 0 for non-metals—or we can leave this attribute unconnected, which would be the same as using a zero. Values between 0 and 1 should only be used in special circumstances, such as when dealing with metals that have been treated—corroded or painted metals and the like.

The attribute we are controlling through the previous constant defines how rough the surface of a given material should be. Higher values, such as 1, simulate the micro details that make light scatter in all directions—which means we are looking at a matte surface where reflections are not clear. Values closer to zero result in those imperfections being removed, allowing a clear reflection of the incoming light rays and a much clearer reflected image.

Through the previous steps, we have taken a look at some of the most important material attributes used to define a PBR material. We've done so by creating a metal, which can be a good example for some of the previous properties. However, it will be good to create another quick material that is not a metallic one—this is because some of the other properties of the PBR workflow, like the specular material attribute, are meant to be used in such cases.

Right-click anywhere inside of the main graph for our newly created material and search for TextureSample, like in the next screenshot:

With that done, it's time to be looking at another material attribute—the Specular parameter. Unlike roughness, this node controls how much light is being reflected by the material and not how clear those reflections are. We therefore tend to modify the specular level when we have small-scale occlusion or small shadows happening across a surface, similar to what would be happening for the texture that we chose before.

You might be wondering why we are using the red channel of the wood texture to drive the specular parameter. The simple answer is that even though we could create a custom black and white image to achieve the same effect, any of the original textures' channels are black and white values that contain the information that we are after. Because seams are going to contain darker pixels than other areas, the end result we achieve is still very similar if we use the red channel of the original texture. You can see in the next image our source asset and the red channel by its side:

Nice job, right? The new nodes we've used, both the specular and the normal ones, contribute to the added details we can see in the preceding screenshot. The specular node diminishes the light that is being reflected in the seams between the wood planks, and the normal map modifies the direction in which the light bounces from the surface. The combined effect is that our model, a flat plane, looks as if it has much more geometrical detail than it really has.

Remember how we were talking about each renderer having its own implementation of a PBR workflow? Well, we have just taken a look at how Epic has chosen to set up theirs!

As we have already said, efficiency and speed are at the heart of any real-time application. These are two factors that have heavily influenced the path that the engineers at Epic have chosen when coding their physical approach at rendering. That being the case, the parameters that we have tweaked are the most important ones when it comes to how Unreal deals with the interaction between light and 3D models. The base color gives us the overall appearance of the material, whilst roughness indicates how sharp or blurry the reflections are. Metallic enables us to specify whether an object is made out of metal, and the specular node lets us influence how intense those reflections are. Finally, using normal maps allows for the modification of the direction in which the light gets reflected—a useful technique for adding details without actually using more polygons.

The previous parameters are quite common in real-time renderers, but not every program uses the same ones. For instance, offline suites such as VRay use other types of calculations to generate the final output—physically based in their nature, but using other techniques. This shows us that, at the end of the day, the PBR workflow that Epic uses is specific to the engine and we need to be aware of its possibilities and the limitations.

Throughout the current recipe, we have managed to take a look at some of the most important nodes that affect how the physically based rendering gets tackled in Unreal Engine 4. Base color, roughness, specularity, ambient occlusion, normal maps, and the metallic attribute all constitute the basics of the PBR workflow.

Having seen all of them, we are now ready to start looking into how to build more complex materials and effects. And even though we still need to understand some of the other areas that affect our pipeline, we can do so with the certainty that the basics are covered.

In order to start this recipe, you are not going to need a lot of anything. The sample Unreal project we have previously created will serve us fine, but feel free to create a new one if you are starting in this section of the book. It is completely fine to use standard assets, such as the ones included with the engine, but I've also prepared a few of them that you can download if you want to closely follow this book.

The first example that we are going to create is going to be some simple glass. As before, right-click in the appropriate subfolder of your Content Browser and create a new material. Here's how we go about it:

If you hover over each of the options inside of the Lighting Mode drop-down menu, you should be able to take a look at their description. You'll note that some of the options are meant to be used with particles, while others are meant for 3D models. That's the reason why some of the material attributes were previously grayed out— some options don't make sense to be used if we are going to be applying the material to a particle, for example, so these are left out.

Now that we have our material correctly set up, let's apply it to the model in our scene. If you've opened the level that I've set up for you, 01_ 04_ TranslucentMaterials_ Intro, you'll see that we have an object called SM_ Glass. If you are creating things on your own project, just create a model in which we can apply this newly created material. In any case, the scene should look something like this after you apply the new material:

Simple but effective! In the future, we'll be taking a look at how to properly set up a more complex translucent material, with reflections, refractions, and other interesting effects. But for now, we've taken one of the most important steps in that path—actually starting to walk!

Translucent materials are really tricky to tackle in real-time renderers—and we are starting to see why. One hint that you might have been able to spot is that we aren't using a different shading model to create glasses. Instead, we are just using a different blend mode. So what are the differences between both of these concepts, and how is driving translucent materials through the latter indicative of their render complexity?

First of all, a shading model is a combination of mathematical expressions and logic that determines how models are shaded or painted with light. One such model will describe how light behaves when it comes into contact with a material that uses said shading method. We use as many different models as we need in order to describe the different materials we see on our daily lives—for example, the way light scatters through our skin or the way it does the same on a wooden surface. We need to be able to describe that situation in a way that our computer programs can tackle that problem.

With that in mind, you could think that we should have a different shading model to describe translucent materials. However, things are a bit more complex in real-time renderers as the calculations that we would need to have to realistically simulate that model are too expensive performance-wise. Being always on the lookout for efficiency and speed, the way that Unreal has decided to tackle this issue is by creating a different blend mode. But what is that?

You can think of blend modes as the way that the renderer combines the material that we have applied to a model on the foreground over what is happening on the background. Up until now, we've seen two different types— opaque and the translucent ones.

The opaque blend mode is the easiest one to comprehend: having an object in front of another will hide the second one. This is what happens with opaque materials in real life— wood, concrete, bricks, and so on. The translucent mode, however, lets the previously hidden object to be partially visible according to the opacity value that we feed into the appropriate slot.

This is a neat way of implementing translucency, but there are some caveats that the system introduces we have to be aware of. One such issue is that this blend mode doesn't support specularity, meaning that seeing reflections across the surface is a tricky effect that we will have to overcome later on. But don't worry, we'll definitely get there!

You can use the scene we created at the beginning of the book, where we set up a studio environment. We took some time aside in the introduction to this book to set it up just so we could place several objects and visualize them. At that point, we just wanted to create something quick and useful, and one of the things we did was to use one of the already available resources of the Starter Content: the BP_Light Studio blueprint. Through that, we've already had access to HDRi lighting, the topic that we are going to be covering in this recipe.

With that in mind, we are now going to explore how to use this type of lighting to its full potential and create a realistic scene through it.

We will start this recipe by placing a reflective object in our default scene and looking at how certain aspects of the environment can be seen reflected in its surface. Take the following steps:

You can see that I've applied a material to the model, named M_Chrome. This is a copy of the material we created in our third recipe, named M_PBR_Metal, where we've modified the base color and the roughness value to make it more chrome-looking. Thanks to its reflective properties, we can see the environment clearly. This is happening thanks to the HDRi image we are using. We are now going to replicate this effect without using the blueprint that was already set up for us, and we will instead create our own.

One of the things that we want to move away from in the setup we are going to create is having the environment image visible at all times. You could be thinking that the metal ball is reflecting the image you see in the preceding screenshot and not the actual light—and that would be only natural as you are seeing that image in the background. This is, however, just a visual cue that the blueprint uses to better visualize from where the environment lighting is hitting an object. Having said so, let's start working with the basic building blocks and not with pre-made tools to better understand how things work.

As you can see, going from a static type of light to a dynamic one gets us the reflections back. This is due to the fact that static lights only exist during the light baking process—that is, when we click on the Build button. In order to use HDRis to their full extent, we should be aiming for a dynamic or stationary type of light.

Let's focus once again on the metallic ball under this new dynamic skylight that we now have. There might be a bit of a problem, if we look closely:

You can see that there's a black edge going on across the surface of the ball, which is happening because the skylight is by default only using half of a sphere to project the selected texture. This is happening because objects are usually not lit from underneath, and we might be fine with that sometimes. However we can solve that by selecting the next option:

However useful having a full spherical HDRi skylight lighting our scene might be, it can also introduce some undesired effects that we don't want to see. For instance, we might want to use the actual geometry of our level to affect the lower part of the chrome ball and not the HDRi. If that's the case, tick again the Lower Hemisphere Is Solid setting and let's try something different.

With that done, you should now be looking at your recently created planes in the reflections of the chrome ball as follows:

Throughout the current recipe, we've had the opportunity to work with HDRi lighting. The lights that make use of this technique are usually of the Skylight type in Unreal Engine 4, a particular kind that allows for the input of the necessary textures that contain the photon information.

As we've said before, HDRi images capture the lighting state of a particular scene in order to be able to use that information in a 3D environment. The way they do this is by sampling the same environment multiple times under different exposure settings. Taking multiple pictures this way allows for their combination at a post process stage, where the differences in lighting can be interpolated to better understand how the scene is being lit.

What's important to us it that we need to be on the lookout for the right type of textures. HDRi images need to be in a 32-bit format, such as .EXR or .HDRi, as each pixel contains multiple layers of information condensed into itself. You might find HDRi images in a non-32-bit format, but these don't contain as much lighting information as the real ones because of the format they use.

Another parameter to take into consideration is the number of f-stops that a given HDRi image is composed of. This number indicates the amount of different pictures that were taken under different exposures to be able to compose the HDRi. A value of five means that the HDRi was created out of five interpolated images, and a value of seven indicates that said number was instead used. More pictures mean a wider range of values and the consequent increase of information. It is a case of the more, the better, as seen in the next screenshot:

These photographs are a sequence of different images that make up an HDRi. HDRi by HDRi labs.

In this recipe, we've taken a look at several key concepts in the PBR workflow—image-based lighting, reflections, and the different mobility types a light can belong to. These elements, while not a part of the material pipeline themselves, are an essential part of the whole physically based approach at rendering that Unreal has at its core. They work hand-in-hand with the materials we create, expanding their capabilities and complementing the base properties we define them to have. Think about it—there's not much use having a highly reflective material if we don't tell the engine how to treat those reflections. Hope you found this useful!

All we need to do before starting this recipe is to load up the map called 01_ 06_ The Cost Of Materials. As you can see, it's just the usual scene we have been working with up until now, except that it now has a couple more models in it. Feel free to bring your own meshes and materials, as we are going to be checking them out from a technical point of view. All we care about at this point is having multiple elements that we can take a look at, so having materials that use different blend modes is great in that we will be able to see the difference in performance between them.

No matter if you've opened the level provided with this book or one of your own, we are going to be looking at the rendering cost that materials incur when being displayed. To do so, we'll be taking a look at several different indicators that can help us understand our scenes a little bit better. Take the following steps:

I've included four different objects with their respective materials applied, which should help us understand the cost to performance that each one of them has.

The values we see in there can give us an approximation to how expensive the material is to render. You can see that this M_ReflectiveSphere has 115 instructions for the base pass shader, 135 if we are using static lighting, and 191 if we use movable lights. The numbers themselves will be useful if we compare them to other materials.

As you can see, the instruction count is much higher than in the last example we saw. This is due to the fact that the complexity of translucent materials is higher than that of opaque ones, and we can see that in here.

This is a more visually appealing way of looking at the shader complexity. However, it is one that is not 100% accurate, as Unreal only takes the instruction count as a reference to calculate the gradient you are seeing in the preceding image and not the complexity of the material's nodes themselves.

You might see similar values for two different materials that are really not equal in terms of their complexity—for instance, a material that is made out of several textures versus one that uses simple constants might show a similar complexity in this viewmode when in reality using the first is more demanding on the Graphics Processing Unit (GPU).

Now that we've seen one of the optimization viewmodes, why stop with just that one? All of them are useful for understanding how our scene is working from different technical points of view. Let's go over them in a quick way to see how they can help us.

There are a couple more viewmodes that we haven't talked about, but they deal with the amount of polygons that a model comprises and are not related to the materials we are using. You can take a look at them in the same panel we saw before, and they are called Quad Overdraw and Shader Complexity and Quads. They can be very useful in order to diagnose our scenes, especially when we have many high poly meshes or semi-transparent models—so keep them on your radar in case you ever need them!

As we've seen in previous recipes, materials are not homogeneous entities. And we are not even talking about the ones in real life, but, of course, the ones we have created within Unreal. The mathematics and functions used to describe the different shading and blend modes carry a weight with them that vary from one type to the next. Knowing how heavy each of them is can be a complicated task to burden oneself with, but having an overall idea is key to running a well-oiled application.

In the previous pages, we've taken a look at some examples, which included an opaque material and a translucent one—examples that we've worked on in the past. However, we need to keep in mind that there are more types we can—and will—encounter in the future. Unreal includes the following different shading models, which I will list now in order of how costly they are to render:

(The other shading models—hair and eye—are very specific to characters and we will cover them in the appropriate section.)

Of course, the actual cost of a material depends on how complex we make the graphs for each of them, but that previous order applies to base materials with nothing more applied to them. On top of that, there are options within each type that can make them more or less expensive to render: having a material being two-sided or use a particular type of translucency can increase the cost to the GPU, for example.

On top of this, there are other things to be considered in terms of efficiency that we might want to keep in mind. Epic has created some performance guidelines for artists that highlight where we should be focusing our attention in order to keep our applications running well. You can take a look at them at the following link: https://docs.unrealengine.com/en-us/Engine/Performance/Guidelines.

We've used this recipe to take a look at how fast Unreal can process different types of shaders. We've done so by comparing an opaque material against a translucent one, which gives us a good idea about how instruction counts vary and how efficient some shaders are compared to others. Not only that, we've also had the opportunity to see what optimization tools are available for anyone using the engine. All in all, there is a wide variety of options that give the user control over how well their application runs, and now we are in a position in which we know how to use them.