After entering my work in the Rookies, I was given the awesome opportunity of working on the world art team at Monolith Productions on their upcoming title Middle Earth: Shadow of War. It was an exciting and educational experience. In this two-part article on surviving your first year in a games company, I’ll share with you some of the new techniques and insights that I’ve picked up.
Outside of their own proprietary software, there are three main tools everyone commonly uses at Monolith. These can basically be categorized as project wiki software, issue tracking software, and version control software.
Project Wiki Software
Monolith uses software called Confluence. It is a type of wiki software that is used to store documentation for the game engine in an easily accessible place.
As an example, Allegorithmic uses Confluence for documentation of their Substance tools.
Screenshot of Substance Painter documentation page.
Issue Tracking Software
Monolith uses Jira, an issue tracking software that keeps track of tasks and bugs. Typically, a producer will assign tasks to the artists with time estimates. Artists will then log how long they spend on any of their current tasks on a daily basis.Doing this helps everyone in budgeting their time so the production remains on schedule.
Doing this helps everyone in budgeting their time so the production remains on schedule.
Software like Jira often contains a Kanban Board. There are three basic columns: To Do, Doing, and Done. You can click and drag your tasks to these different columns to help keep track of what you’re working on.
At Monolith, we also have a pause for review section to put tasks that need to be reviewed by the art director or game designers before calling them complete. Having a visual of all your tasks and their progress through something like a Kanban Board helps a lot in staying organized and setting priorities with your work.
Version Control Software
Monolith uses Perforce. Perforce is a revision control system that’s essential in managing files for collaborative projects. For instance, when working on a game, all of the project’s files would be stored on a server. If an artist wanted to edit a model from the game, he or she would check out the file in Perforce. When something is checked out, no one else can edit it, preventing everyone from unintentionally overwriting each other’s work.
After an artist is done editing something, he or she can check the file back in, after which everyone on the team will have access to the new file. In addition to this, all of the previous versions of the file are still stored on the server, making it easy to go back to earlier revisions. At Monolith, artists typically do a check in review with someone else on the team before submitting a file to Perforce. This is a great idea, as there are a variety of easy to miss mistakes that could affect gameplay or performance.
It’s very important to constantly be aware of the overall value of the textures you make.
It’s also a good idea to have Perforce integrated with your game engine so files automatically get checked out while you’re working on them. This helps prevent you from unintentionally working on an older file and overriding newer work when you check it in.
Unreal Engine has this integration built in for example. You can find more info here: LINK
Overall an accessible place to store documentation, issue tracking software, and a file management and backup system are three major tools that help keep game development organized and running smoothly.
Physically Based Rendering
While working at Monolith, I learned about some key things to keep in mind when creating work for a game engine using physically based rendering.
Texture Value Range
Typically, the base color texture of a PBR material should be within a certain value range, usually somewhere in between 50 and 243. Going outside of this range can make the material difficult to light. Here is a simple example:
This scene is very dark. Many shadow areas in the image are going to pure black. The issue isn’t the lighting though, it’s the texture.
The darkness of this texture is preventing much light from bouncing through the scene. You can check if a texture is getting too dark by using the histogram tool in Photoshop.
Typically, you should look at the mean value, which gives the overall value range of the image. Again, when working in PBR, you usually want to have an overall value somewhere between 50 and 243. With a mean of 49.66, this concrete texture is definitely too low. I ended up raising it to have a mean of 177.
Even things that are very dark like coal or really bright like snow don’t use a pure black or white value.
For textures that will cover large surfaces like walls and floors, it’s usually a good idea to get them to a relatively light value so they will bounce more light throughout the scene.
Without making any changes to the lighting, the scene looks much more natural now that the texture is within the recommended value range.
It’s very important to constantly be aware of the overall value of the textures you make. Looking at it in the game engine and checking its mean value with the histogram tool helps in avoiding potential lighting issues.
Here’s a basic value scale that I hope can help reinforce this idea. Even things that are very dark like coal or really bright like snow don’t use a pure black or white value. Generally, avoiding the more extreme values outlined in red on the chart will make lighting your scene easier.
SRGB and Linear Color Space
Usually, PBR rendering engines do their calculations in linear color space. In this color space, all values are computed in a 0 to 1 range, where 0 is black and 1 is white. Monitors don’t display colors in this way though, because our eyes tend to have greater sensitivity to dark values than light values. To compensate for this, most monitors use SRGB color space, which raises input values to around the power of 2.2. This makes them darker and skews the 0 to 1 range to display more dark values than light values.
Related link: Surviving Your First Year in a Games Company – Part 2
Since textures are usually created in SRGB color space, pbr game engines convert them to be linear. This works for textures that visually show up in the game, such as base color, but can cause issues with textures that are supposed to represent numerical values, such as a roughness mask.
Here’s a simple example.
In Substance Painter, the roughness is set to around .2, giving it a fairly blurry reflection. Meanwhile, here’s what this looks like by default when imported into Unreal Engine 4.
The reflection is much less blurry and doesn’t match up with what Substance Painter was showing.
The reason for this is because the game engine is trying to convert the roughness texture from sRGB to linear values. This essentially raises these values to the power of 2.2, making them darker and giving a different roughness.
In cases like this, it’s a good idea to disable this conversion so the values that you choose will match up in the engine. You can do this in Unreal Engine 4 by unchecking sRGB in the texture settings.
Checking Directions on Normal Maps
Another useful thing I’ve learned to look out for is if the directions of a normal map match up with the rendering engine. For example, Unreal Engine 4 reads normal maps through X+ Y- Z+. You can check if your normal matches up with this by looking at the rgb channels and imagining a light shining from one of the edges of the image. A minus means the light should be coming from left/down and a plus means it should be coming from right/up.
At Monolith, artists commonly make use of layered materials when texturing assets. In a layered material, one uses grayscale masks to control the blending of up to 4 tiling materials on an object rather than creating a specific 0-1 texture for every object. Some of the key benefits of using them include:
- Saving texture memory
- Saving time
- Ensuring visual consistency
In this example, a layered material is used on this stove to blend iron, raw metal, rust, and dust. Instead of making a specific set of textures for this model, a single texture mask can be used to blend some pre-existing materials across the model. You could then use these same materials on a variety of different objects, only requiring a mask texture for each of them.
Here’s a basic example of how a layered material can be reused across a variety of assets. All of these assets use the same textures, but the blending is done on a per asset basis using some small 128×128 masks. Using these small masks for a shared material can save a lot of texture memory as opposed to making separate 0-1 sets of textures for each asset.
You can find some more information about material layering on Allegorithmic’s website here: LINK
Substance Painter also has a built in shader for previewing layered materials that you can learn more about in this video: LINK
Related link: Surviving Your First Year in a Games Company – Part 2