WHAT IS PBR?

PBR, or Physically Based Rendering, is a rendering method used in games to simulate how real-world materials interact with light. It allows for realistic visuals while remaining efficient enough to run in real-time at high frame rates, which is crucial for games!  It was really popularised with the adoption of Unreal Engine 4 back in 2014.

One of the biggest advantages of PBR is consistency. Before PBR, lighting information was often baked into textures, making materials look inconsistent under different lighting conditions. With PBR, textures and lighting are treated separately, meaning materials behave naturally in any environment.

It’s important to remember that PBR stands for Physically Based Rendering, meaning that it’s an approximation of real-world materials, not a perfect recreation. This gives artists some flexibility in how they create materials, while still grounding the materials with a sense of realism. This sense of realism becomes even more important when designing materials for fantastical settings, like alien planets. When dealing with unfamiliar or fictional materials, artists can push the boundaries of PBR while still following its core principles to maintain believability.

Let’s break down what this looks like in practice!

‍PHYSICALLY BASED PRINCIPLES

‍

Since PBR is based on the laws of physics—specifically how light interacts with different materials—it follows a few key principles. Don’t worry, you won’t need to do any complex math, but understanding these ideas will help you make more realistic materials:

As artists, we don’t need to worry about the technical details—these principles are already built into the shaders we use. Luckily, we won’t be expected to create them from scratch! The way that we interact with these shaders is by giving it our own inputs and then manipulating the end results through those inputs.

One of these inputs that form the core of this system are the textures that we create.

‍WHAT ARE TEXTURES?

‍

As artists, our job is to translate these principles into our textures which can then be read and processed by our game engine through the use of shaders essentially bits of code in our rendering engine. These determine how they appear on screen. Giving us artists a lot of creative control over how our materials look since we’re the ones providing the texture or input data that drives their final appearance.

These 2D textures then get applied through our UV’s, allowing us to translate 3D space to 2D space, going from our models to our textures. See it as wrapping a piece of candy in a wrapper. The wrapper are our textures where as the candy is our model. This allows us to make our object more visually interesting and detailed compared to only using geometry.

‍COMMON TEXTURES

‍

About 90% of PBR-based materials use the same core set of texture types. These textures define how a material looks and reacts to light:

While the example image above shows each texture individually, there are techniques to combine multiple individual textures into one for  in-engine optimization purposes! This is called texture packing. You can explore that topic in our {{LINK TO TEXTURE PACKING LESSON}}!

Let’s take a deeper look at what each individual texture is and does.

‍BASE COLOR

‍

The Base Color (often is abbreviated as BC) texture stores the inherent color value of the material, without including any lighting information for an engine to process, like shadows or highlights!
There are execptions to this, for example, traditional handpainted workflows often times still add dedicated lighting information in their textures.

To get the most out of this texture, we store the color data in a lossless format, like 16-bit RGB, these can store colors at a higher range, allowing us to preserve all the color information.
Common file types used for this are PNG, TIFF, or other lossless image formats.

Note: While a Base Color texture might not include lighting information for an engine, that doesn’t mean that a Base Color can’t include light or dark color details! For example, edges that show wear may be lighter in color!

‍METALLIC

‍

The Metallic or “Metalness” (often abbreviated as M, particularly as a suffix)  texture defines whether a material is metallic or non-metallic. It's a simple black and white map — white for metallic, black for non-metallic and grey for potential cases in between. We need this map to let the game engine know how the reflections should behave, particularly the specular highlight which the bright spot of the light that appears on shiny objects. Essentially, this texture type adjusts how a material should react to light based on its conductivity.

Why conductivity?

‍ROUGHNESS

‍

The Roughness texture (often abbreviated as R, particularly as a suffix) determines how smooth or dull a surface looks, changing the reflection to be sharper or diffuse. Imagine the surface as being made up of tiny, uneven bumps. The smoother the surface, the less light is scattered in random directions. The rougher or bumpier the surface, the more the light is scattered on contact with the surface.

This texture plays a huge role in how we perceive the realism of a material since we subconsciously know how shiny a surface is from taking in real world data. So authoring the roughness map and how light interacts with the surface, has the biggest impact in making it feel more or less realistic. If we get this texture looking good, that means that we make the material look convincing.

‍NORMAL

‍

The Normal (often abbreviated as N, particularly as a suffix) texture is probably the weirdest looking map! This map stores directional data, telling an engine how light is supposed to interact with a surface. This gives the illusion of extra detail, even on flat meshes, by simulating the way light would bounce off real-world textures.

This map is super useful when we want to add high density detail to low-poly objects without increasing the geometry or polycount, through a process called "baking." It allows us to take the fine details of a highpoly object and transfer them to a simpler model, the lowpoly.

Since normal maps rely on color data, we use an RGB texture to store this info.

Depending on the game engine there are two different ways of storing normal information. Different engines work with different coordinate systems (meaning which way is up, forward, etc…) So this also has an effect on the Normal map, since it also stores directional data. This can lead to a phenomenom called “flipped normals” where your normal map looks off because it interprets surfaces that are supposed to go up and going down and vice versa.

‍AMBIENT OCCLUSIONS (AO)

‍

An Ambient Occlusion texture (often abbreviated as AO, particularly as a suffix) is a texture that’s used for adding subtle shadows in areas where direct light doesn’t naturally reach. It helps ground objects and props in a scene, making them feel more realistic by creating depth and interaction between surfaces.

In an AO map, black areas represent where shadows are most prominent, and white areas indicate where light can easily reach. The map interacts directly with lighting in the game engine, becoming less noticeable or disappearing completely when exposed to direct light.

The lighting and shadow information stored in this texture are smooth and subtle, created by ambient light, which diffuses softly and gently between objects. Since it’s not concerned with color, the data in the AO map is stored in grayscale, simplifying the information it holds.

While Ambient Occlusion is typically stored in PBR-based object textures, some engines use techniques like Screen Space Ambient Occlusion (SSAO), which generates AO data from the scene rather than individual objects. However, SSAO is expensive to use, can come with artefacts, and doesn’t always have the same accuracy as baked AO textures. Baked AO is often the safer bet!

Refence: https://www.youtube.com/watch?v=65cgc3jbNlg

TEXTURE SETS
Small little section here, but these textures usually come in sets that make a whole set, so when we mention a “Texture Set” we usually refer to a Basecolor, Roughness, Metallic, Normal map combined.

‍PRACTICAL TIPS

‍

Now that we know what all the different textures are that are needed, let’s have a look at some high level concepts that are crucial to getting to a better output of these textures when authoring them inside of our texturing programs.

‍REAL WORLD VALUES

‍

PBR is about getting close to something that get’s seen as realistic. So the benchmark to use are real world values or get as close to them as possible. As artists we don’t have to stick to this 1 to 1 but if you feel that there is something off about your textures, checking real world surfaces and what values they use can be a good benchmark.

Looking at scanned surface data such as the ones we get from Megascans, textures.com and other available sources can be a great inspiration.
When looking at some sources we can find out that for example the basecolor of coal, which we assume is black, is actually around the sRGB range of 50 on the scale from 0 to 255, which is nowhere near as close to the blackest of black as we assume it is.

‍PBR SAFE VALUES

‍

Linked to the previous topic of getting reference is that there is a limit to the range of colors we can use. These safe ranges are common in game production, and can be measured with a tools like a “PBR validation node” in Substance Painter that will highlight area’s that are outside this range in red.

BASE COLOR VALUE RANGE
NORMAL RANGE: (30 - 240 sRGB (normal Range))
‍STRICT RANGE: 50 - 249 sRGB (Strict Range))

‍

So you can see that even the values we brought up before, like the one from coal, is not as far down the spectrum as we perceive them to be. This is because on the extreme range of the spectrum we can not add shadows to black surfaces or highlights to white surfaces.

‍

‍DIFFERENT WORKFLOWS

‍

Up until this point of the lesson we’ve focused on the Metallic/Glossiness workflow since it’s the most commonly used one. But sometimes we might run into another workflow referred to as the “Specular-Glossiness” (Spec-Gloss for short) which may be relevant to certain projects, game engines or studios. The main difference is in the way we author our textures and what needs to be in them.

This workflow is less common, but if you want some other information on that topic it’s right here: {{SPEC GLOSS WORKFLOW LESSON}}

‍TESTING VALUES

‍

Finally, a common pitfall is that people assume that the textures and detail you see in Substance Painter is the final result, however, lighting, environment and texture setup has an influence on the final result. So making sure we check this result is in the program where you are going to be presentation is crucial, and some smaller tweaks might be needed to make it look the best it can.

‍

Often times when we want to focus on accurate values we use something called a “Neutral lit Scene” to measure the textures and surfaces of our meshes more accurately.

NEUTRAL LIT SCENE:
Sometimes to get as close to comparable result between our game engine and our texturing program we make use of a neutral-lit scene so we can verify the differences and make sure it’s not affected by any lighting information which may be distracting us.

‍

‍

ALIGN RENDERING PROGRAMS

• talk about aligning substanc painter with unreal engine

‍LESSON RECAP

‍

For more in depth tutorial feel free to check out {{LINK TO PRB GUIDE BY SUBSTANCE DESIGNER}}

‍🔹RESOURCES

‍

Add any additional resources that you personally have used or have been vetted by yourself to add to the lesson.