A reliable PBR pipeline does not mean every artist makes the same aesthetic choice. It means the team can explain how a material was made, rebuild the technical parts, and tell whether a new export obeys the project contract.
The useful unit is not "the texture." It is a material package: source, scale, maps, parameters, export target, and validation evidence.
Write a material contract before writing automation
A material contract is a short specification for what each file means. It should answer:
- Which shader model is the target?
- Which maps are required and optional?
- Which channels hold roughness, metallic, AO, or smoothness?
- Which files are sRGB color and which are linear data?
- Which tangent-space normal convention is expected?
- What suffixes, bit depths, and source resolutions are allowed?
The glTF metallic-roughness material is one valid contract: base color, metallic-roughness, normal, occlusion, and emissive textures have defined roles and channel layouts. A studio may use a different contract, but it should be equally explicit.
Give every asset a source record
The source record does not need to become a new software product. A JSON file, database row, or well-structured asset panel can record the essentials:
{
"material": "painted_factory_floor",
"physical_tile_m": 2,
"source": "photo_set_014",
"generator_preset": "floor_derivation_v3",
"export_preset": "unreal_orm_dx_v2",
"approved_files": ["basecolor", "normal", "orm"],
"engine_test": "review/painted_factory_floor_ue.png"
}
For a generative service, also record the prompt, reference asset, model name or version when exposed, seed when exposed, and the chosen output. If the service cannot guarantee identical regeneration, preserve the approved source file. Repeatability then means the team can reproduce the production package from the approved source, not that a remote model will redraw the same pixels forever.
Turn corrections into presets
When an artist fixes the same issue three times, the pipeline has found a preset. Examples include normal strength ranges, roughness remapping, channel packing, file suffixes, and engine import defaults.
Version presets instead of silently editing them. An asset built with unity_urp_masks_v2 should not change underneath the team when v3 adopts a new channel layout. Migration can be deliberate rather than accidental.
Validate meaning before appearance
Automated checks catch inexpensive mistakes:
| Check | Example failure | Possible automation |
| File set | Missing normal map | Required suffix check |
| Dimensions | One map is 2048x1024 | Image metadata check |
| Color treatment | Roughness imported as sRGB | Engine import preset or asset rule |
| Value range | Metalness is gray noise on plaster | Histogram warning plus review |
| Normal orientation | Green channel inverted | Preset declaration plus reference test |
| Naming | Unknown packed-map layout | Pattern validation |
Automation can detect structure. It cannot decide whether a worn edge tells the right story or whether a stylized roughness response fits the art direction. Keep those judgments in a visual review.
Use one studio test scene
A shared test scene makes reviews comparable. Include a plane for tiling, a sphere for reflections, a beveled object for edge response, a scale reference, a hard movable light, and at least one broad environment. Capture the same views for each candidate.
The engine screenshot is part of the review evidence. It records the renderer, shader, tone mapping, and compression that a web preview cannot reproduce exactly.
Record exceptions instead of banning them
A hero prop may need 4K maps while background props use 1K. A stylized material may deliberately push roughness outside the usual reference range. A decal may bake lighting by design. Those are valid exceptions when the asset record states why they exist.
The dangerous exception is the invisible one: a manually inverted normal, an undocumented smoothness channel, or a one-off export that nobody can identify six months later.
A practical definition of deterministic
Use the word deterministic narrowly. A deterministic processing step returns the same result from the same recorded inputs and versioned settings. Do not extend that promise to a hosted model that does not expose or freeze its implementation.
A studio does not need every creative step to be deterministic. It needs the approved inputs to be preserved and the technical transformations to be traceable. That is enough to replace guesswork with a pipeline the team can actually maintain.