Layered Material Renderer

The art team needed layered surfaces that could be iterated by look-development artists rather than hard-coded per asset. The old approach duplicated masks and material functions across scenes, which made small visual changes expensive to validate.

Audience

Environment artists author the look; rendering engineers review the budget; production needs a stable surface that can survive asset scale-up.

The system had to expose enough control to make the material useful without turning the inspector into a list of implementation details. The original prototype could look correct on one hero asset but gave artists no way to diagnose why a layer disappeared on another asset.

• One material variant for the common path; no per-asset shader forks.
• A predictable mobile and console fallback path.
• Debug output must explain inputs without requiring a capture session.
• The visual language must remain coherent across hard-surface and organic test assets.

I owned the material function graph, the HLSL include that held shared evaluation logic, the debug channel design, the inspector naming pass, and the capture checklist used for review.

The solution separates authoring inputs from shading evaluation. Artists see layer intent, breakup, and preview channels; the shader receives packed parameters with a single normalization step before lighting.

struct MaterialDebug { float3 normal; float depth; float mask; float2 uv; };
MaterialDebug BuildDebug(float3 n, float d, float m, float2 uv)
{
  return (MaterialDebug) { n, d, m, uv };
}

The intended content range is hundreds of authored materials across multiple environment sets. The target budget was one additional texture sample for the detail layer and a bounded branch count in the forward path.

Validation sample

The test corpus includes 48 materials, three lighting conditions, two quality tiers, and a capture on both an integrated GPU and a desktop GPU.

Decision: shared material evaluation

I separated authoring inputs from shading evaluation so one material variant could serve the common path without hiding layer intent from artists.

float layerWeight = saturate(curvature * _WearBreakup + thickness * _LayerBlend);
float3 blendedNormal = normalize(lerp(baseNormal, detailNormal, layerWeight));
return EvaluateMaterial(albedo, blendedNormal, roughness);

Debug contract

Final, normal, depth, mask, UV, roughness, and metallic each answer a review question; they are not decorative display modes.

The final model made the material readable to artists and reviewable by rendering. The strongest result is not a single image: it is the shorter feedback loop from ?the layer is wrong? to ?this input or stage is wrong.?

Observed impact

A representative look-dev pass moved from repeated shader edits to parameter iteration, while the debug channels made the remaining implementation issues visible in captures.

What I did not optimize

I did not pursue bespoke per-asset shader forks or a richer hero effect. Both could produce a more expressive single image, but they would weaken consistency and make the review contract harder to maintain.

Why this trade-off is acceptable

The shared path is easier to hand off, profile, and debug. I accepted the lower ceiling on bespoke visual expression because predictable performance and artist comprehension were the stronger production constraints.