Documentation of Graphics Production Technical Standards
A new artist joined the team, looked at existing assets and asked: "What's your polygon budget for a character — how much?" The team lead answered: "Well, roughly from 5 to 15 thousand, depends on importance". That's not a standard. That's an oral agreement that everyone understands differently, and which breaks with every new employee or contractor.
Tech Art Bible or Graphics Production Standards — a document that translates informal agreements into specific numbers, formats, and procedures.
Why "obvious" standards need documentation
The gap between what's considered "self-evident" within a team and what artists actually do is enormous. Examples of real discrepancies:
Texture resolutions: one artist makes 2K for background objects, another — 4K. In VRAM this is immediately visible — profiling shows Texture Memory 800 MB instead of planned 400. Yet the document only says "use reasonable resolutions".
Naming: hero_body_d.png, Hero_Body_Albedo.png, character_1_diffuse_final.png — three textures of the same type from three artists in one project. AssetDatabase.FindAssets by pattern doesn't work, automatic import by suffix doesn't work, CI naming convention checks don't work.
Pivot points in FBX: one Blender artist exports with pivot in geometric center, another — at World Origin. Developer gets an object that rotates around an unexpected point when transform.Rotate() is called.
What's included in Tech Art Bible
Polygon budgets — table by object categories with breakdown by platforms:
| Category | PC (LOD0) | Mobile (LOD0) | Mobile (LOD1) |
|---|---|---|---|
| Main character | 10,000–15,000 | 5,000–8,000 | 1,500–3,000 |
| Secondary NPC | 5,000–8,000 | 2,000–4,000 | 500–1,000 |
| Large prop | 3,000–5,000 | 1,000–2,000 | 200–500 |
| Small prop | 500–1,500 | 200–500 | 50–150 |
Texture standards: resolutions by category, formats (PNG for sources, TGA for normal maps on Unity import — not PNG, BC7 as target compression for PC, ASTC for Android/iOS), mandatory channels (Albedo, Normal, Metallic/Roughness, AO — separate or packed).
Naming convention: with examples. For textures — {object}_{part}_{type}_{resolution}.ext, for example hero_body_albedo_2k.png. For meshes — {category}_{name}_{LOD}.fbx. Important: document not just the rule, but why it's that way — this reduces resistance during implementation.
UV standards: tile size, allowable UV-overlapping for lightmap UV (LOD0 only, UV channel 2), seam placement requirements (not on visible edges, not on joints).
Export procedures from each tool: Blender FBX export settings (Apply Transform, Forward axis, Units), Substance Painter export template for Unity (with which channels in which slots), Maya export checklist.
How to develop the document
Start with auditing existing assets: what's already used in the project, what de facto values are applied. Document should reflect reality + improvements, not ideal standard from scratch — otherwise the team will ignore it.
Interviews with artists: which questions are asked most often, where conflicts arise during asset reviews, what gets remade. This is the best source for determining document priorities.
Format: Confluence or Notion — interactive, support nested tables and screenshots. Not PDF — nobody reads PDF in six months. Structure: table of contents with anchor links, "Quick Reference" on first page (most needed data), full sections below.
Document versioning — date of last update and changelog. Standard without version loses credibility: "is this current for our platform?"
CI integration of standards
Document doesn't work without automatic checks. Unity Editor scripts for validation:
- Check imported textures for naming convention compliance via
AssetPostprocessor.OnPreprocessTexture() - Check max resolution on import: if texture > 4096 for background category — Warning in console
- Mesh validator via
AssetPostprocessor.OnPostprocessModel(): check polycount by category name from filename
This is not a document replacement, but real-time feedback when standards are violated — before code review.
Timeline
| Document Scale | Timeline |
|---|---|
| Basic standard (naming + budgets + export) | 1–2 weeks |
| Full Tech Art Bible + CI validators | 3–6 weeks |
| Update existing document for new platform | 3–7 days |
Cost is calculated after auditing current practices and target platforms.