Привет! Выхожу из спячки. У меня есть ещё целая неделя чтобы пописать что нить интересное.

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

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

Далее я попробую объяснить в чем же разница, но вместо декомпозиции непосредственно Unreal логики я постараюсь дать вам понимание того что всё таки решает Unreal проведя сравнение с стандартным DCC приложениям будь то MAYA, MAX или Blender. Примеры будут показаны, само собой в MAYA, но так как принципы ригинга не менялись до UE все будет точно так же актуально и в других софтах.

Что же такое Контрл риг в UE? Ответ находится прям в названии. Чтобы понять это давайте разберем что из себя ригинг в целом представляет с моей точки зрения:

Есть графики кинематики а так же есть графики деформации. Граф кинематики это зафиксированные значения каналов трансформов которые символизирует какое то движение, другими словами это таблица визуализирующая анимацию в виде кривых. Деформ граф это тоже таблица. Эта таблица управляет геометрией:

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

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

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

Чтобы стало чуточку понятней давайте я попытаюсь объяснить на двух языках. На языке MAYA и на языке UE:

В MAYA мы создаем интерфейсы аниматора, другими словами контроллеры, которые собраны определенным образом так чтобы манипулировать костями по средствам каких то операций, эти операции и позволяют нам получать нужный тип движения. Такие операции операции называются "солверами". Эти солверы управляются контроллерами и производят матрицы которые в свою очередь и будут драйвить кости, а кости в свою очередь будут драйвить скинкластер + геометрию персонажа.

В UE кости называются Skeleton, а SkinCluster + Geometry - называется Skeletal Mesh. Контроллеры и солверы называются Controll Rig и в лучших традициях UE все эти вещи ОТЛИЧНО СУЩЕСТВУЮТ САМИ ПО СЕБЕ, что позволяет всё, кроме "родительского" Skeleton, независимо менять\обновлять\модифицировать.

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

Первое ключевое отличие это тип графа. В UE - он компилированный. Что это означает? Это означает то что всё что мы создали в виде солверов и контроллеров "запекается" по тем же принципам что все остальные виды логики в UE, т.е созданное становится участником Reflection System, подхватывается многопоточность и.т.д.

Например если у нас есть граф, который контролирует IK (Inverse Kinematics), то вместо того, чтобы каждый кадр проходить через десятки визуальных нод (как в MAYA), компиляция объединяет их в оптимальный процесс, который просто выполняет нужные вычисления.

Второе ключевое отличие заключается в концепции Event Stack. Что это такое? Event Stack работает иной от той же MAYA логикой, к примеру в MAYA не рекомендуется создавать логическую петлю:

Под петлей я подразумеваю следующий сценарий. К примеру мы хотим драйвить B от A и после того как мы получили значение B я хочу чтобы B драйвило A. В MAYA мы так сделать не можем, мы получим цикл.

UE же важен лишь порядок действий, так как в его конецпции Event Stack вычисления происходят один за другим:

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

Но это ещё не все! Есть ещё очень крутые штуки которые сильно отличают UE шный риг от DCC.

Set up Event - это событие, которое используется для выполнения настроек рига до выполнения основной анимации или расчётов графа. Оно предназначено для выполнения любых единоразовых или предварительных операций, необходимых для правильной работы рига. Для чего это нужно? Ну например, если у нас сложный скелет, применить правильные смещения между костями в рамках одного скелета, или объявить какие то переменные, или же сделать так что ваш контр риг будет настолько модульным что сможет автоматически адаптироваться к любому новому скелету, и пример этого мы чуть позже увидим.

Backward Solve - это то что в зарубежной индустрии называется Mocap Remap Rig:

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

Variables - переменные Controll Rig работает точно так же как и все переменные в UE, мы можем как получать так и хранить так и передавать эти переменные в блюпринты и совершать с ними различные действия что позволяет делать очень крутые штуки если в это вдуматься.

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