DESIGN DOCUMENT

For improving shader design, we first need to figure out the problems we are trying to resolve. After discussing with Art, Rendering, And System. We identified three problematic areas we want to address with the design.

We have a large amount of track shaders.
- The number of shaders confuse artists.
- It is hard to adjust and update features with different variations for the tech art team.
- It is hard for rendering to understand each shader due to the shader amount.

We are having disadvantage for a pure node-based shader system.
- Node Graph based shaders are naturally hard to read and debug once they become complex.
- Limited optimization at the shader creation stage. It is harder to get advice from the rendering team since it is harder to read compared to HLSL code.

We have a large number of unique textures.
- Number of textures causing memory issues which downgrade the visual quality with low resolution textures.
- Hard to do a global quality update for unique textures.
- Long sync for the texture folder due to the number of textures we have.

After we identified the problematic areas, we spent time analyzing the root cause of them.

Those shaders are created due to:
- The shader naming is not informative. It is hard for artists to know the difference between _001 and _002.
- Lack of documentation to inform artists about the functions of each shader.
- Lack of a reviewing process for shader change and creation workflow. Many shaders were created for unnecessary reasons.

Node-based shader also has advantages:
- Fast for prototyping.
- Artist friendly and it helps us to communicate with artists.
- It is a good solution for smaller scale shaders like VFX shaders since the node-based shader is easy to read with small scale graphs.

Unique textures are created due to:
- Lack of texture/material library to inform artists about the reuseable texture/materials.
- Lack of review process/guideline for which model needs to use unique textures, and which model needs to use reuseable textures.
- Lack of ability to adjust reusable texture output in shader parameters force artists to create unique textures.

Finally, we discussed with multiple first party studios and learnt about their approaches. Here are the solutions we found suitable for our situation:

For large amount of track shaders problem:
- Reducing the number of shaders. Combine shaders with overlapping functions.
- Having a more informative naming structure for shaders.
- Having an up to date on boarding document for each shader.
- Having a review and sign off process between rendering and TA.

For node-based shader system problem:
- Cutting node-based shader as a whole is a BIG NO NO since it has the advantages.
- Switch to a hybrid between node base shader and pure HLSL shader.
- The ratio is about 90% HLSL shader and 10% Node Graph shader.

For large number of unique textures problem:
- Updating texture/material library to inform artists what texture/material we have and what they could use.
- Updating material zoo for artists to have a clear in game reference for the value of textures.
- Having a process/guideline for communicating with artists and vendors about when we need unique textures.
- Expanding variation float usage, expanding the decal usage.

MAIN SHADER DESIGN

For the main HLSL shader design, we are aiming to achieve minimum unique texture usage and maximum control for the artist.

The key design is the two mask system.

The first mask is a material mask. We break one grayscale mask into four layers. The default range for the layers are:

Layer1 0 - 0.25
Layer2 0.25 - 0.5
Layer3 0.5 - 0.75
Layer4 0.75 - 1

Artists have the freedom to change the range to get different gradients but they can not skip the layer.

Artists can give each layer different color control and we use mad() to affect the final color output.

Artists can also offset Roughness, Metallic, and Normal for each layer.

This mask should be a shareable noise pattern in the shared library, but artists are allowed to create a unique texture if needed. One BC4 grayscale mask will always be cheaper than a substance packed texture set.

This set up allows us to use one set of textures to create many variations without creating new textures. We will be building material presets, so artists will always have a good base to work on.

The second mask is a grunge mask. It has the same setup with the material mask but it only has one layer. It allows this mask to have better gradient and fading, so we can use this mask for larger variations.

Since we switch to HLSL for this shader, we can pack all the offset value to a float3 and we only need to do the lerp operation once for each layer.

SHADER PERFORMANCE

Once the shader creation is finished. We collaborated with the artists and did some performance and memory A/B tests. The result is very positive.

GPU render timer difference:

The old node graph shader with way less feature:

The new HLSL shader with the two masks setup

We found the new shader's GPU cost is nearly identical with the old basic node graph shader. This means we can have higher detail for all the content without worry about adding GPU cost.

We also asked artists to create two identical sets of objects. One is using an old shader, one is using a new HLSL shader. The memory saving is also visible. with small set of objects, the memory usage dropped from 144.72MB to 95.44MB

Old

New

Overall, this is a pretty successful project. Artists are happy, Render Engineers are happy, System Engineers are happy. Me also happy.

NAMING AND DIRECTORY

The design for the naming directory is aiming for clear communication. We want internal artists and external vendors to understand what to use quickly to save the onboarding time. We have restricted shader and material directory but we give freedom to the artists for texture creation and model creation since most of the variation needed are in these spaces.

This allows us to have a central control for shader and material update without fully limiting the art creation process.

ARTIST WORKFLOW

The focus of artist workflow is using as many shareable textures as possible to align with the whole shader workflow design. We removed some freedom for the texture creation side, but we provided the freedom in the material editor. This will allow us to have less memory footprint to ship high quality content on consoles with low memory budget and handheld devices.