Техническая проверка рига перед производством анимации
Аниматор открывает файл, начинает делать walk cycle — и на третьем часу работы обнаруживает, что root bone смещён относительно центра масс, skin weights на колене покрашены с артефактами, а IK chain для ног ссылается на кости с неправильным именованием. Всё это уже зафиксировано в десятках ключей. Переделывать — дорого. Это стандартная ситуация, когда риг ушёл в анимацию без проверки.
Технический валидационный аудит рига — это не «посмотреть глазами». Это конкретный чеклист, покрывающий иерархию скелета, bind pose, weight distribution, controller naming, space switching и совместимость с целевым движком.
Что реально ломается без проверки рига
Самая распространённая проблема — несоответствие bind pose и rest pose. В Maya или Blender риг выглядит корректно, но при экспорте в FBX и импорте в Unity компонент Animator получает меш с уже применёнными трансформами, которые сдвигают вершины относительно bone origins. Это проявляется как «разлетающиеся» части меша при воспроизведении анимации через Animator Controller. Фикс после начала анимационного производства требует пересборки всего skin binding.
Второй класс проблем — naming conventions и иерархия под конкретный движок. Unity's Humanoid rig configuration в Mecanim очень чувствительна к именованию: если spine chain содержит четыре кости вместо ожидаемых трёх, или если UpperArm/LowerArm не совпадают с маппингом Humanoid Definition, ретаргетинг анимаций сломается. Avatar Configuration покажет красные маркеры, но не скажет, что именно не так в иерархии.
Отдельная тема — контроллеры и вспомогательные кости, которые не должны попасть в экспорт. В Maya нередко оставляют locator-based control rig поверх deform skeleton, и если артист экспортирует сцену целиком вместо выбранного deform skeleton, в FBX попадают сотни лишних нод. Unity молча их импортирует, Animator начинает тратить ресурсы на обновление transform hierarchy размером в 300+ объектов вместо 60.
Проблемы с stretch bones и non-uniform scaling — отдельный разговор. Когда контроллер использует scale для эффекта растяжки конечностей, это часто приводит к shear transformation, которую движок либо интерпретирует неправильно, либо полностью игнорирует при импорте. Animation Rigging package в Unity поддерживает stretch через специальные constraints, а не через bone scale — и это нужно прописать в техзадании до начала работ.
Как строится процесс валидации
Аудит рига разбит на несколько уровней, которые проверяются последовательно. Пропускать нельзя — каждый уровень выявляет ошибки, невидимые на предыдущем.
Структурная проверка скелета: подсчёт костей, анализ иерархии, проверка parent-child отношений. Для Humanoid рига — сверка с Mecanim bone mapping таблицей. Для Generic рига — проверка корректности root motion bone и наличия единственного root.
Bind pose и T-pose/A-pose: восстановление bind pose и визуальная проверка, что все суставы находятся в нейтральном положении без остаточных ротаций. Нулевые значения rotation в joint transform — стандарт. Любые ненулевые значения в bind pose → проблема при экспорте.
Skin weights: анализ vertex influence counts. Стандарт для мобильных платформ — не более 2-4 influences на вершину. Для PC/console — до 8. Проверка на unweighted vertices (вершины без influence = они не двигаются), на weight normalization (сумма influences = 1.0). В Maya используется Component Editor, в Blender — Weight Paint mode с Vertex Group Weights display.
Controller rig vs deform skeleton: проверка разделения контрольного рига и деформирующего скелета. Контроллеры не должны попадать в экспорт. Тест: экспорт → импорт в Unity → подсчёт костей в Hierarchy.
Naming conventions и символы: пробелы, кириллица, спецсимволы в именах костей — всё это источники проблем при экспорте FBX и импорте. Проверка регулярным выражением на допустимые символы.
После валидации выдаётся отчёт с конкретным списком issue по категориям: критические (блокируют анимацию), значимые (ухудшают качество), рекомендации (best practice). Аниматор получает чистый риг и техдокументацию, которая описывает, что именно было исправлено.
Кейс: риг персонажа для мобильной RPG
Пришёл проект — персонаж с готовым ригом, около 80 костей, rig сделан в Blender, планировался импорт в Unity 2022 LTS с Humanoid Avatar. Визуально риг выглядел нормально.
После аудита обнаружили: spine chain из 5 костей вместо 3 (Mecanim не может автоматически замапить), non-zero rotation в rest pose у плечевых костей (экспортный rotation offset ~15 градусов), два auxiliary bones для volume preservation (не нужны для мобильного, добавляют draw cost), и — самое неприятное — skin на кисти руки с 6 influences при требовании mobile skinning 2-influence max.
После фиксов, повторного skin painting на руке с ограничением до 2 influences и пересборки spine chain аватар сконфигурировался корректно. На итоговом тесте ретаргетинга Motion Capture анимации из Mixamo сработал без артефактов.
Без этой проверки аниматор потерял бы несколько дней, переделывая bind weights после того, как IK контроллеры уже сломались бы из-за rotation offset.
Ориентиры по срокам
| Масштаб проекта | Срок |
|---|---|
| Один персонаж, generic rig, до 80 костей | 4–8 часов |
| Один персонаж, humanoid rig с контрольным ригом | 1–2 дня |
| Пакет из 5–10 персонажей (общий стандарт рига) | 3–5 дней |
| Полный технический аудит + документация + фикс | от 1 недели |
Стоимость рассчитывается индивидуально после получения файлов рига и описания целевого движка и платформы.
Что нужно подготовить для аудита
Без этих данных анализ будет неполным:
- исходный файл рига (.ma, .blend, .max, .fbx)
- описание целевого движка и версии (Unity 2022.3, Unreal 5.x и т.д.)
- тип рига: Humanoid, Generic, Custom с описанием
- целевая платформа (mobile, PC, console — влияет на лимиты skin influences)
- есть ли существующие анимации, которые нужно сохранить
- планируется ли ретаргетинг (Mixamo, Mocap library, Mecanim)
Чем точнее ТЗ, тем конкретнее и быстрее пройдёт аудит. Риги, сделанные без документации и под неизвестный движок, требуют вдвое больше времени на обратную разработку требований.