Документирование технических стандартов производства графики
Новый художник пришёл в команду, посмотрел на существующие ассеты и спросил: «У вас полигональный бюджет на персонажа — сколько?» Тимлид ответил: «Ну, примерно от 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-стандарты: tile размер, допустимое UV-overlapping для lightmap UV (только LOD0, UV channel 2), требования по seam placement (не на видных кромках, не на суставах).
Процедуры экспорта из каждого инструмента: 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 дней |
Стоимость рассчитывается после аудита текущих практик команды и целевых платформ проекта.