MATERIAL GUIDELINES
155
DEVELOPMENT TIME
In an unmanaged material development environment, materials are created in isolation, without proper visibility to other team members. Multiple developers then sink nontrivial amounts of time hunting for and failing to find suitable materials. They end up recreating material functionality that already exists elsewhere, unknown to them. Similar functionality gets partially and inconsistently duplicated across multiple materials. This not only wastes valuable development time, but ends up with redundancies, inefficiencies, inconsistencies and considerable maintenance overhead. It also perpetuates disorganization.
MAINTENANCE
Materials can and should be built in a parametrized way to allow for instancing, where possible. Most materials should serve as general templates, with the more specialized versions of those materials instanced hierarchically. Having a centralized set of templates allows for quick functionality updates: additions to one parent material will automatically propagate to all material instances, and their referencers. This saves developers from reimplementing the same functionality in multiple materials, reducing human error, and saving time. Changes at the material template level always come up. Design, Art or Programming may change at any point in production, and you should be prepared. New engine features may come online late in the project’s lifetime, long after content creation has started. For example:
● Adding lit particle support to all particle materials ● Adding fade out support to all decal materials ● Updating skin tinting functionality of all playable character materials ● Adding detail normal tiling support to all phong masked materials ● Reworking all terrain materials to leverage a new engine technology Propagating such changes to all the necessary game content suddenly becomes a huge undertaking if your materials are scattered and not set up hierarchically.
PERFORMANCE
The fancier the material, the heavier the performance overhead. If material usage is not managed in a scene, GPU performance can quickly become an issue. It usually falls of Tech Art to investigate and optimize GPU related performance hot spots. To minimize reactive optimization, it can pay off to have some measure of preemptive optimization. Here are some performance considerations: ● It is very common for artists to have “corrective” shader math that can be trivially applied to the source texture for free. For example: Multiply, Power, Clamp... If the instruction count of a shader is a bottleneck, such math can be stripped out of the shader, and applied to the texture. ● It is very common for artists to have multiple textures, each having a single channel being sampled. If the texture lookup time of a shader is a bottleneck, such channels can be packed into a single texture, reducing the number of texture lookups. ● GPU efficiency is especially important for particle materials, which often involve a lot of overdraw. Persistent particles such as fire, smoke, mist, etc... stay on screen longer, and can stack up in long view lines. Such materials should be optimized more aggressively than nonpersistent particle materials. ● Depending on your engine, similar materials will result in redundant shaders. Switching between redundant shaders while rendering incurs unnecessary performance overhead. With Tech Artists overseeing the material library, they can ensure that most materials are free of performance inefficiencies. They can also educate artists to avoid inefficiencies in the future. If a particularly expensive material is needed for a scene, Tech Art can work with the artists to balance the scene’s material usage, keeping it within the overall performance budget.
VERTEX