Intro to Materials
🛑⚠️🚧Content not yet finished 🚧⚠️🛑
Everything below represents notes for Sepha to finish the YouTube vid and article with.
A note before we begin.
When making game art, we will actually use very little of Blenders Material and Shader capabilities. This is because we want our art to be rendered in real time, utilizing features that the major game engines use.
It's fine to make something good in our DCC, but if you can't make it look good in the engine, then it doesn't count.
Materials
Materials hold the data that we will use to determine what the surfaces of our objects will look like when rendered. Textures, PBR settings, light and shadow settings, colors, etc, will all be defined and held within the Material.
To fully explain Materials, we need to touch on two other neighboring concepts.
Shaders
Textures
Shaders
A shader as far as we're concerned right now is a program which is executed on the Graphics Card, which determines how our mesh renders to the screen.
It will take the textures, colors, etc that are defined in the Material, and actually draw the object into the pixels of our frame, rendering the final image.
Sometimes these shaders will be programed via nodes, instead of direct text:
Textures
Textures as far as you're concerned are two dimensional images which contain color (and other) data, that we can wrap around our objects. We use our UV's to map these two dimensional images onto the surface of our three dimensional objects.
We will focus on Textures and Shaders in a later chapter.
Materials
Ok so if we have a Shader program that renders our object, and a texture that's going to color it in - then how do we actually APPLY that information to our model? What do we do or create to do this?
We use a material.
Settings, and data.
You can regard a material as the collection of settings and data that are handed off to a shader. The shader will then take it from there and draw the object fully.
These for example, are three Unity Materials (files suffixed with .mat) that will render an object they are applied to as either red, blue, or green, with a bit of secularity (that surface shininess you can see):
Materials continued
Here are the material settings for the above blue material:
There are a lot of settings here, but three in particular stand out:
The Shader used to render the Mesh with this Materials data
Unitys default shader will be some form of "PBR Lit" shader. This term "PBR" will be explored later.
The Base Map Color
Which is where our object gets its blue value from
The Smoothness.
Which determines how "Shiny" our object looks.
If I modify the M_Red material, I can tweak some of these settings, to make it look more Metalic, like so:
Notice how:
The Shader has stayed the same as the blue shader -
We're not changing the "program" that is going to render this sphere, merely the settings and data that we wish to render it with (the material).
The color is different
As we want it to be reddish / orangy
The smoothness is different
I've modified the material to be a touch smoother
The Metalic Map value is now has gone from zero in the blue object, to 0.833 in the red object.
This is the resulting sphere when rendered:
Compared to the blue Sphere:
The key insight.
The material file itself is JUST the "visual settings" of our object. The color we want, the textures we will use, how smooth we want the object to look, etc.
Ok, but what about Blender?
Because Blender is a DCC package with the purpose of giving maximum control to the artist, our Materials are a lot more complicated, with many dozens of available settings:
In Unity and Unreal (programs that need to run at above 60 fps to be interactive), we DONT wan't this much control. We want things to be rigid, and defined, re-using shaders and materials as often as we can.
In our DCC, the opposite is true.
In Blender, you have so much control over the "Material", that the line between "Shader" and "Material" becomes very blurred, and inside of blender the two are often synonymous.
There's a catch however.
When creating video games, our game engine, not our DCC, will be doing the final rendering of our objects.
We will completely lose all complex material and shader information from Blender when we move from Blender to Engine. Womp womp.
So why are Materials important?
In Blender, we assign material ID's to specific polygons, and then in Unreal or Unity, we create shaders, and material definitions, to render those surfaces how we want them to look.
This is the key insight - as far as you are concerned, materials are only an id we use to tell our game engine which surface to render with what engine material data.
What Information do we get to keep then?
We can assign a "Material ID" to each face of our model in our DCC:
We can control the NAME of the Material, but not the order of the meshes material list.
When we assign a Material to a Face, we are assigning a Material ID, to that face.
In Engine, we can apply a custom Engine created Material to any Material ID in our mesh:
We can transfer only trivially simple Material Information from our DCC to our Game Engine.
Base Color, Metalness, Roughness, etc. The simplest data.
How does this effect our workflow?
Ensure your objects always have at least one material assigned to them.
Use as few Materials as is reasonable for the given asset. Most assets will only need one material.
Ensure the material is named in a human readable way, for example: M_Alien_Masculine_B
Expect to create and configure Materials and Shaders in Engine, not the DCC.
Do not expect the Engine to respect the ordering of your meshes material list.
It will respect their names and face assignments.
Last updated