Документування технічних стандартів виробництва графіки
Новий художник прийшов до команди, подивився на існуючі ассети та запитав: «У вас є бюджет полігонів на персонажа — скільки?» Тімлід відповів: «Ну, приблизно від 5 до 15 тисяч, залежить від важливості». Це не стандарт. Це усна угода, яку кожен розуміє по-своєму, і яка ламається при кожному новому співробітнику або підрядчику.
Tech Art Bible або Graphics Production Standards — документ, який перетворює неформальні домовленості на конкретні числа, формати та процедури.
Чому «очевидні» стандарти потрібно документувати
Розрив між тим, що вважається «само собою зрозуміло» всередину команди, та тим, що насправді роблять художники — величезний. Приклади реальних розбіжностей:
Роздільна здатність текстур: один художник робить 2K для фонових об'єктів, інший — 4K. У VRAM це одразу видно — профілювання показує Texture Memory 800 МБ замість планових 400. Але в документі написано тільки «використовуй розумні роздільні здатності».
Найменування: hero_body_d.png, Hero_Body_Albedo.png, character_1_diffuse_final.png — три текстури одного типу від трьох художників в одному проекті. AssetDatabase.FindAssets за паттерном не працює, автоматичний імпорт за суфіксом не працює, CI-перевірки на naming convention не працюють.
Pivot points у FBX: один Blender-художник експортує з піватом в геометричному центрі, інший — в Origin світу. Розробник отримує об'єкт, який при transform.Rotate() обертається навколо неочікуваної точки.
Що входить до Tech Art Bible
Бюджети полігонів — таблиця за категоріями об'єктів з розбивкою за платформами:
| Категорія | PC (LOD0) | Mobile (LOD0) | Mobile (LOD1) |
|---|---|---|---|
| Головний персонаж | 10 000–15 000 | 5 000–8 000 | 1 500–3 000 |
| NPC другого плану | 5 000–8 000 | 2 000–4 000 | 500–1 000 |
| Крупний prop | 3 000–5 000 | 1 000–2 000 | 200–500 |
| Дрібний prop | 500–1 500 | 200–500 | 50–150 |
Стандарти текстур: роздільні здатності за категоріями, формати (PNG для вихідників, TGA для normal maps при імпорті у Unity — не PNG, BC7 як цільовий формат компресії для PC, ASTC для Android/iOS), обов'язкові канали (Albedo, Normal, Metallic/Roughness, AO — окремо або упаковані).
Система найменування: конвенція з прикладами. Для текстур — {object}_{part}_{type}_{resolution}.ext, наприклад hero_body_albedo_2k.png. Для мешів — {category}_{name}_{LOD}.fbx. Важливо: документуємо не тільки правило, але й чому воно таке — це знижує опір при впровадженні.
UV-стандарти: розмір плитки, допустиме UV-перекриття для lightmap UV (тільки LOD0, UV channel 2), вимоги до розміщення шва (не на видимих кромках, не на суглобах).
Процедури експорту з кожного інструменту: Blender FBX export settings (Apply Transform, Forward axis, Units), Substance Painter export template для Unity (з якими каналами в які слоти), Maya export checklist.
Як розробляємо документ
Починаємо з аудиту існуючих ассетів: що вже використовується в проекті, які де-факто застосовуються значення. Документ повинен відображати реальність + вдосконалення, а не ідеальний стандарт з нуля — інакше команда його проігнорує.
Інтерв'ю з художниками: які питання задаються найчастіше, де виникають конфлікти при ревю ассетів, що переробляється. Це найкращий джерело для визначення пріоритетів в документі.
Формат: Confluence або Notion — інтерактивні, підтримують вкладені таблиці та скріншоти. Не PDF — PDF ніхто не читає через пів року. Структура: змістовна таблиця з якорями посилань, «Quick Reference» на першій сторінці (найбільш потрібні дані), повні розділи нижче.
Версіонування документа — дата останнього оновлення та changelog. Стандарт без версії втрачає довіру: «а це актуально для нашої поточної платформи?»
CI-інтеграція стандартів
Документ не працює без автоматичних перевірок. Unity Editor-скрипти для валідації:
- Перевірка імпортованих текстур на відповідність naming convention через
AssetPostprocessor.OnPreprocessTexture() - Перевірка max resolution при імпорті: якщо текстура > 4096 для категорії background — Warning у консолі
- Mesh validator через
AssetPostprocessor.OnPostprocessModel(): перевірка polycount за найменуванням категорії з імені файлу
Це не заміна документу, але зворотній зв'язок в реальному часі при порушенні стандартів — до code review.
Терміни
| Масштаб документа | Термін |
|---|---|
| Базовий стандарт (найменування + бюджети + експорт) | 1–2 тижня |
| Повна Tech Art Bible + CI-валідатори | 3–6 тижнів |
| Оновлення існуючого документа під нову платформу | 3–7 днів |
Вартість розраховується після аудиту поточних практик команди та цільових платформ.