Качественное производство анимационных 3-д проектов предполагает как налаженное взаимодействие различных отделов, так и их комфортное внутреннее функционирование. Например, сотрудникам отдела рендера обычно не очень понятно - зачем им в сцене анимационный риг на две тысячи нод, который всё тормозит и порой ломается? Или аниматоры с недоверием смотрят на шейдинг и прочие шаманские атрибуты рендер-отдела, который зачем-то определен во все ассеты сцены, а она ведь и без них еле шевелится! Но самое интересное начинается когда вдруг (а случается такое очень часто), сцена вернулась после рендера на правку анимации, а возвращается в таких случаях именно финальная рендер-сцена. И рендерщик, взяв в охапку свою сцену, в которой он долго и мучительно ставил свет, настраивал семплинг и душу, можно сказать, в неё вложил, бежит к аниматору и начинает рассказывать, что дышать ему теперь нельзя, моргать тоже и eсли он тут своими кривульками всё поломает, то жизни ему больше не видать. И как бы смешно и нелепо это не звучало, но так оно и есть. Такие ситуации, а они, повторюсь, возникают достаточно часто, как правило приводят к большому количеству лишней работы с обеих сторон и очень напряжённой атмосфере между отделами. Что, безусловно, сильно вредит производству в целом.

Чтобы этого избежать, одни из основных веток шотного производства на проекте - анимация и визуализация, должны быть разделены буфером, который позволил бы обновлять анимацию и содержимое сцены, не вызывая паники у сотрудников рендер-отдела, честно говоря - вполне оправданной. Буфером, который бы работал молча, как часы. И таким буфером является процесс кеширования сцены, о котором мы и поговорим.

---

Но для начала давайте определимся с самим понятием кеширования. По сути это процесс сохранения тех или иных промежуточных результатов различных вычислений, с возможностью их дальнейшего использования в качестве источника данных. Кеширование не ограничивается одной лишь геомертией в 3-д пакетах или, например, изображений на композе. Кешировать можно почти всё, что вычисляется. Мы будем кешировать анимацию.

Но с какой стороны подойти?

Используя пакет Maya, можно выделить два совершенно разных подхода для передачи анимации на рендер.

1) Запечь анимацию (тут мы поговорим о стандарте atom). По сути кешировать предлагается анимационные кривые. С этого метода мы и начнём.

2) Запечь геометрию (рассмотрим формат alembic, как самый распространённый и универсальный).

Кеширование анимационных кривых.

Как правило всё, что анимируется, управляется контролами, и если анимация сделана чисто, то при переносе запечённых анимационных кривых в сцену с нужными объектами она должна полностью совпасть. Этот же подход по сути используется при создании анимационных библиотек. Единственной проблемой данного метода являются констреины, их лучше делать только через парент-группы, либо запекать перед кешированием. Данный метод трудоёмок в ручном режиме, но очень хорошо автоматизируется.

Как делать? Выделяем контролы которые хотим запечь, определяемся с параметрами и выгружаем.

Для загрузки анимации в сцену, нужно просто выделить те же самые контролы и загрузить анимацию из atom файла. Причём, как видно из настроек импорта, процесс этот достаточно гибкий.

Сама выгрузка происходит моментально, так как выгружаются только анимационные кривые, которые уже сформированы и никаких дополнительный просчётов не требуют. Но тут кроется подвох. Если выгружать анимацию, не запекая предварительно кривые, можно получить проблемы с их интерполяцией. Как правильно расхождения незначительны, но они есть и этого следует избегать.

Если вы планируете использовать Motion Blur (всё равно, на рендере или композе), то лучше ставить шаг 0.5.

Также стоит упомянуть о двух часто встречающихся ошибках анимации, связанных именно с Motion Blur, причём это не зависит от метода кэширования и от его наличия в целом.

1) Аниматоры должны следить чтобы в межкадровом интервале не было резких перемещений объектов. Это бывает, например, при FK/IK переключениях, когда между кадрами персонаж или объект пролетает большое расстояние. При работе вы этого не видите, но Motion Blur при этом выдаст вам очень странный результат. Если анимация уже так сделала и править нет времени, то можно просто запекать её с шагом в 1 кадр, и тогда все будет чисто, но Motion Blur будет более линейным.

2) Анимация должна заканчиваться не на последнем кадре шота, а на следующем после него. То есть если шот имеет диапазон 1-20, то 21-й кадр должен быть с анимацией, иначе при активном движении на последнем кадре ваш Motion Blur встанет колом. Такой эффект, как правило, очень сильно бросается в глаза.

Если у вам много объектов анимации, с которых вы хотите выгружать в atom, то лучше для всех их контролов сразу запечь анимацию, а потом уже выгружать. Это будет быстрее всего.

И ещё, формат atom работает с именами объектов и их неймспейсами. Это очень важно понимать. Если вы используете неймспейсы для референсов, object_rig, то выгрузив анимацию контролов этого объекта, вы сможете загрузить её только на объект с таким же неймспейсом. То есть если у вас для рендера использается референс с неймспейсом object_shade, анимация на него не сядет. Для решения этой проблемы можно перед выгрузкой анимации переименовать неймспейс вашего объекта, изменив его на тот, который будет использоваться в дальнейшем.

И того, к плюсам этого метода можно отнести:

1) Шейдинг делается на основе риг-файла, вам не нужно следить за обновлениями, если вы используете его как референс.

2) Выгрузка кеша кривых происходит очень быстро, и он почти не занимает места на сервере, счёт идёт на десятки килобайт.

Но есть и минусы:

1) Необходимо очень внимательно следить за констрейнами, лучше их делать через парент-группы. Также категорически запрещено двигать пивоты, ибо они не кешируются в atom.

2) Так как шейдинг делается на основе рига, то весь сетап, который порой доходит до нескольких тысяч нод, тянется в рендер-сцену и тормозит её, а порой и ломается.

Кеширование геометрии.

Тут всё совсем иначе. Выгружая кеш в виде alembic-файла, вы выгружаете геометрию с её анимацией (сам формат прекрасно передаёт и кривые и локаторы). Причём в каком виде придёт к вам эта анимация, вы узнаете только после её загрузки, но об этом чуть позже. Выглядит окно экспорта вот так.

Как видите, набор параметров внушительный. Не буду их перечислять и описывать, это можно найти в хелпе, отдельно только стоит упомянуть о возможности выгружать дополнительные атрибуты.

Это даёт возможность переносить те или иные параметры объектов из анимационной сцены. Например, если персонаж имеет несколько состояний и разный шейдинг, эту информацию можно легко передать, чтобы обработать в дальнейшем.

Если с выгрузкой тут всё просто, то загрузка алембика в сцену - штука интересная.

Вот окно импорта. Тут я выставил режим загрузки в качестве pointCache, это когда кэш цепляется на имеющуюся геометрию. Так же можно добавить кеш как шейп в режиме Add. Либо загрузить кеш, создав новые объекты (режим по умолчанию).

Как я уже писал выше, вы не знаете, в каком виде как придёт кеш. Поясню. Алембик, это формат который способен передавать не только кеш геометрический, но и кеш трансформационный. То есть по сути он может работать как формат atom, перенося анимацию кривых. Причём вы не контролируете этот процесс, он сам всё решает. Например у вас есть персонаж, с когтями, глазами или каким-то элементом одежды, пуговицами, бляшкой ремня, которые не деформируются ригом, с просто перемещаются за констрейнами. Такие объекты, скорее всего, будут выгружены как геометрия с анимацией трансформации. Выглядит это так.

Как видите, анимация из ноды алембика идёт в ноду трансформа объекта. Ноды unitConversion создаются для передачи вращения. Перемещение и масштабирование подключаются напрямую.

А вот кеш тела персонажа, которое деформируется, будет выглядеть вот так.

Тут кеш с ноды алембика идёт напрямую в шейп геометрии во вход inMesh.

Но! Возможен и третий вариант, когда эти методы объединяются. Это происходит в случае, когда, например, ваш объект сначала просто перемещается в пространстве, а в какой-то момент начинает деформироваться.

Пытаться прогнозировать, как поведёт себя кеш в конкретном случае - дело не благодарное, его алгоритм пытается минимизировать геометрический кеш, и обходится трансформацией объектов везде где только можно. Это позволяет сильно экономить на объёме файлов.

Как использовать алембик, по большому счёту - дело каждого. Я предпочитаю загружать в сцену всё целиком и анализируя ноду алембика с созданными при импорте объектами воссоздавать нужные связи с нужной мне геометрией самому (скриптами). В этом случае процесс получается максимально контролируемым и предсказуемым. А также есть поле для манёвра.

Вот так выглядит нода алембик кеша персонажа в развёрнутом виде.

У метода кеширования геометрии есть свои плюсы:

1) Надёжен, никакие констрейны, пивоты и прочие действия аниматоров его не сломают. Только не забывайте, что по умолчанию алембик кешируется в локальных координатах. И тут важно понимать, как вы будете использовать его в дальнейшем. Я предпочитаю выгружать всё в мировых координатах. Но случаи бывают разные.

2) Работает значительно быстрее персонажного рига, так как не тянет за собой ничего лишнего. Только не используйте сглаживание во вьюпорте для алембика, это очень сильно тормозит.

Но есть и недостатки:

1) Очень медленно выгружается по сравнению с atom. И если в случае с atom можно запечь всю анимацию за один проход, а потом быстро выгрузить для каждого объекта, то в случае с алембиком так не получится.

2) Если будете выгружать всё подряд, то место на сервере быстро закончится.

Заключение.

В статье описаны диаметрально разные подходы для кеширования сцены. Но какой из них лучше использовать, ведь у каждого есть сильные и слабые стороны?

Ответ прост, надо использовать оба!

Например, для локации, которая состоит из огромного количества статичных, либо простых свободно-анимированных объектов, хорошо подходит выгрузка анимационных кривых. Это быстро, а так как такие объекты аниматорам особо не интересны, как правило, ничего и не ломается.

А вот для персонажей, и любых объектов взаимодействующих с чем-либо, лучше использовать кеширование геометрии. Просто потому что только так вы будете уверены в результате. Ведь пути аниматора неисповедимы, и не надо ему мешать.

P.S. Наверное, самым технологичным и надёжным методом является сцена не на основе референсов, с их проблемами и недостатками, а иная схема, полученная путём выгрузки различных данных о геометрии и шейдинге с их последующей сборкой. Такой подход даёт чрезвычайную гибкость и стабильность, но тесно связан с рендером, который вы используете, и от его возможностей очень сильно зависит успех вашего мероприятия. Но об этом как-нибудь в следующий раз.

Артур Малхасян,

руководитель R&D отдела "Alians-CG"