Search Unity

올해 초 유니티는 Animation Rigging(애니메이션 리깅) 패키지를 출시했습니다. 이 패키지를 통해 런타임 동안 애니메이션을 변경 또는 수정하는 다양한 릭을 생성하기 위한 제약 조건들을 제공하고자 했습니다.

지금까지 이 패키지의 가능성을 폭넓게 연구하여 런타임과 제작 간의 경계를 허물어 왔습니다. 이 포스팅에서는 최근 진행한 애니메이션 리깅 실험에 대해 알려드립니다. 아래의 예시에 언급되는 상태 머신은 실험용이며, 실제 활용 가능한 제작물을 대표하지 않습니다. 현재 유니티에서는 테크니컬 애니메이터가 코드를 작성하지 않고도 상태 머신을 활용하여 제약 조건을 설정할 수 있도록 연구하고 있습니다.

이 블로그 포스팅을 통해 애니메이션 도전 과제를 해결하는 새로운 방법을 탐구하고 발견할 수 있게 되기를 바랍니다. 유니티는 실용적이고 완벽한 애니메이션 솔루션을 구축하기 위해 사용자의 의견에 항상 귀를 기울이고 있습니다.

기본 사항

릭 빌더(Rig Builder), 릭(Rig), 다양한 제약 조건(Constraint) 등 세 가지 유형의 컴포넌트에 중점을 두고 설명합니다. 위 컴포넌트에 아직 익숙하지 않다면 애니메이션 리깅에 관한 이전 블로그 게시글을 참고하시기 바랍니다.

여기에서 참고용 프로젝트를 다운로드하여 직접 사용해보면 더 빠르게 이해하실 수 있습니다.

배경

코드 변경 없이 기존 애니메이터(읽기 전용 클립이 있는 상태 머신 로직) 컨텍스트 내에서 릭 제약 조건을 애니메이션화할 수 있는 방법을 찾기로 결정하고, 상태 머신(애니메이터) 레이어에 주목했습니다.

기존 상태 머신과 애니메이션 리깅 통합

릭 및 제약 조건의 활성화와 기존 상태 머신의 읽기 전용 클립을 동기화하기 위해, 애니메이터 상태 머신 레이어를 활용했습니다.

 

레이어와 “Sync(동기화)” 기능을 사용하여 기존 이동(Locomotion) 상태 머신의 모든 상태에 릭 활성화/비활성화 클립을 추가할 수 있습니다.

예제에서는 애니메이션 창을 사용하여 릭과 제약 조건 프로퍼티를 애니메이션화하는 몇 개의 애니메이션 클립(*Rig Layer(릭 레이어)에 저장됨)을 제작했습니다. 이 단계에서는 간단히 다양한 릭과 제약 조건의 Weight및 Source Weight 프로퍼티를 애니메이션화합니다.

핸드그립을 바꾸기 위해 일부 Weight Layer 프로퍼티를 활성화 또는 비활성화하는 “Player” 스크립트도 사용했습니다. 핸드그립(Handgrip) 자세를 변경하는 Player 스크립트의 슬라이더는 위와 같습니다.

닌자의 총

닌자 릭 빌드

Rig Builder 컴포넌트는 순서를 변경하고 릭/릭 파트 간 이상적인 평가 및 솔빙(solving) 결과를 보장하는 데 필요한 Rig Layer를 제공합니다. 이로써 릭 조합과 솔브 순서에 유연성을 부여하게 됩니다. 예를 들어 닌자 예시에서 Shoulder Offset 릭의 순서를 의도적으로 다르게 설정하는 경우 어떻게 되는지 살펴보겠습니다.

Shoulder Correction 릭을 Rig Builder 평가 스택의 하단으로 옮기면 예상했던 솔빙이 해제됩니다.

 

Shoulder Correction 릭이 Rig Builder 평가 스택의 상단에 위치해야 올바른 솔빙 동작을 얻을 수 있습니다.

 

상단의 이미지에서는 Shoulder Offset이 스택 하단에 위치하여 있어 손이 잘못 정렬됩니다. 순서가 정확해야 어깨를 팔의 나머지 부분보다 먼저 솔브하기 때문에 손이 피스톨을 정확하게 잡게 됩니다. 그런 다음 UpperBody 릭 솔빙을 위해 RightArm IK에서 제공하는 수정 기능을 사용하여 Pistol 핸드그립을 조정할 수 있습니다.

 

참고: 릭 및 제약 조건 설정에 관한 다음 설명은 위 이미지에 나타난 순서와 다를 수 있습니다. 

Shoulder Correction 릭

Shoulder Correction 릭은 Right Arm Two Bone IK 제약 조건과 결합하여 우측 어깨 뼈대의 자세가 Assault Rifle Idle 애니메이션과 Pistol Idle Pose 사이의 포즈 델타에 일치하도록 수정합니다.

또한 RightShoulder(Transform)의 Pivot 모드에서 Override Transform을 사용하여 Y 및 Z 트랜스폼에 회전 값을 추가했습니다. Position Weight를 0으로 설정함으로써 Rotation에만 영향을 주고 있다는 점에 유의하세요.

Assault Rifle 릭

Hips Constraint GameObject와 자식 오브젝트를 확인해 보겠습니다. Hips(골반) 뼈대에 영향을 주기 위해 Pivot 모드에서 Hips Ctrl을 Override Transform의 소스로 사용하면 전체 닌자 계층을 오프셋할 수 있습니다. 다음으로 제약 조건의 조합(Multi-Aim과 Override Transform)을 사용하여 척추 부분과 골반에 영향을 주는 상체의 목표 릭을 생성했습니다. 목표 릭마다 서로 다른 제한 조건 가중치를 설정(Multi Aim Constraint > Source Objects에서 각 Spine 0.35, Chest 0.5, Upper Chest 0.75, Head 1.0으로 설정)하면 모든 척추 이펙터에 걸쳐 회전 분포를 변경할 수 있습니다. 이렇게 하면 Target GameObject를 다양한 각도로 조정하여 효과를 만들 수 있습니다.

Weapon 릭

Weapon Rig GameObject는 Override Transform을 통해 Weapon Bone 애니메이션 스트림을 가로챈 후 소스 오브젝트(Weapon Ctrl)를 사용하여 이를 리디렉트할 수 있도록 해 줍니다.

그런 다음 동일한 소스 오브젝트를 Multi-referential Constraint의 레퍼런스로 사용하여 멀티 피벗 조작을 할 수 있습니다. Multi Referential Constraint > Driving에서 값을 여러 가지로 변경하여 실행 결과를 확인해 보시기 바랍니다.

UpperBody IK 릭

Two Bone IK는 두 팔 골격 모두에서 IK 솔빙을 제공합니다. Multi-Parent Constraint를 사용하여 Weapon_Bone의 자식오브젝트인 IK Target Game Object(AR_LHIK_Target 및 AR_RHIK_Target)에 RHIK 및 LHIK 이펙터를 연결합니다.

 

Pistol 릭

대기 상태의 원본 애니메이션을 피스톨 자세로 전환하려면 여러 애니메이션 리깅 제약 조건을 사용합니다. Pivot 모드 옵션에서 Override Transform을 사용하여 Pistol Ctrl 이펙터에서 Weapon Bone으로 오는 데이터를 오프셋합니다. 다음으로 Multi-Parent Constraint의 Maintain Offset에서 Position and Rotation을 활용하여 소스(Weapon Bone)와 타겟(Pistol Offset) 게임 오브젝트 간 전역 좌표의 불일치를 해소합니다.

Weapons Source 릭

Assault Rifle(AR)과 Pistol 골격을 다른 앵커 지점에 연결하려면 Multi-Parent Constraint의 멀티 소스 기능을 활용합니다.

Assault Rifle Attach 릭은 Multi-Parent Constraint의 멀티 소스 기능을 유용하게 활용합니다. AR-Holster 소스를 1로 설정(Weapon-Bone 소스는 0)하면 AR_Grip_Bone이 AR-Holster에 연결됩니다.

 

Assault Rifle(AR_ Grip_Bone)이 Weapon-Bone을 따르게 하려면 Weapon_Bone 소스를 1로 설정(AR_Holster 소스는 0으로 설정)하면 됩니다.

어떤 제약 조건이라도 대부분의 프로퍼티를 키프레임할 수 있으며 본 예시의 경우에는 각 Multi-Parent Source Weight 프로퍼티를 키프레임하여 원하는 결과를 얻을 수 있습니다.

따라서 이제 새로운 애니메이션 클립을 “동기화된” 애니메이터 컨트롤러 레이어 상태에서 사용하면 기존의 이동(Locomotion) (또는 다른) 상태 머신의 특정 상태에 있는 릭 상태를 적용할 수 있습니다.

다음 예시는 런타임에서 Multi-Parent Constraint가 3가지 소스(Pistol_Holster, Pistol Offset, RightHand_PistolGrip)와 함께 어떻게 활용되는지 보여줍니다.

다수의 State Machine Layer에서 두 개의 애니메이션 클립, 즉 Pistol_Equip(Base Layer에서 재생되는 읽기 전용 fbx 파일)과 Rig_Pistol_Equip(Rig Pistol Layer에서 재생되는 네이티브 Unity 애니메이션 클립)을 동기화함으로써 이러한 결과를 얻을 수 있습니다.

 

Legs IK 릭

.fbx Ninja에는 Skeleton Feet 애니메이션에 일치하도록 DCC로 애니메이션화된 LeftFootIK 및 RightFootIK 오브젝트(둘 다 LowerBody GO의 자식)가 포함되어 있습니다.

Multi-Parent Constraint를 사용하여 Feet IK 이펙터를 Leg IK 릭에서 LeftFoot IK와 RightFootIK 게임 오브젝트로 연결합니다. 이렇게 하면 두 발을 Root 높이에 고정하여 하체가 지면 아래로 꺼지지 않고 골반을 조작할 수 있습니다.

 

마지막으로, Two Bone IK 제약 조건은 하체(발 및 골반 위치) 애니메이션 보정을 위한 IK 솔브를 제공합니다.

 

발 설정

풋 릭(Foot Rig)에 Multi-Referential Constraint를 사용하는 과정에서 새로운 기능을 발견했습니다. 멀티 피벗 풋 컨트롤 릭을 생성하여 IK 이펙터를 조작할 수 있게 되었으며, 향후 애니메이션 제작 솔루션으로 제공할 수 있을 것으로 예상합니다.

LeftHandGrip 릭

Left-Hand Game Object 계층을 복제하여 다른 핸드그립 자세를 생성했습니다. 릭 컴포넌트의 Weight 슬라이더를 통해 로컬 모드에서 다수의 Override Transform 제약 조건(손가락 게임 오브젝트별로 하나씩)을 활성화/비활성화하여 손가락별로 로컬 회전을 오버라이드할 수 있습니다.

 

 

LHIK 이펙터를 AR_LHIK_Target_B 게임 오브젝트에 정렬하기 위해 AR_LHIK_Target의 Weight를 0으로 설정하고, AR_LHIK_Target_B의 Weight를 1로 설정합니다.

그런 다음 MonoBehaviour 스크립트를 사용하여 LeftHandGrip Rig의 Weight 프로퍼티와 LeftArm IK/Multi-Parent Constraint Sources의 Weight 프로퍼티(AR_LHIK_Target & AR_LHIK_Target_B)를 동기화하여 Left-Hand Grip 자세와 무기의 위치를 변경합니다.

Twist Correction 릭

Twist Correction 릭은 절차적 변형 릭 역할을 하여 각 팔의 윗부분과 아랫부분, 각 다리의 윗부분을 조정합니다. 이를 통해 손목 뼈대의 롤 회전을 추출한 후 특정 가중치 값에 따라 각 Twist Bone의 로컬 X축을 따라 분포시킵니다.

본 예시에서는 Twist Correction이 Rig Builder Rig Layer의 하단에 위치합니다. 따라서 Twist Correction은 이전의 리깅 제약 조건으로 인한 변경 사항을 활용할 수 있습니다.

기타 주의 사항

제약 조건 프로퍼티(플로트 가중치) 실행에는 애니메이터 상태 머신이 사용되므로 프로퍼티는 애니메이터 상태 머신과 함께 제공되는 전환 및 블렌딩 효과를 상속하게 됩니다(예: 블렌딩이 완료되기 전에는 절대치가 아닌 0.998과 같은 값으로 나타날 수 있음). 이런 문제를 방지하기 위해서는 블렌딩이 끝난 후 가중된 제약 조건 애니메이션이 시작되어야 합니다.

이 접근 방식은 기본 값/상태로 돌아가지 않도록 하기 위해 이전 상태의 프로퍼티를 입력해야 한다는 단점이 있습니다. 특히 상태의 동기화된 레이어에 클립이 없는 경우에 유의해야 합니다.

지금은 위 문제점을 모두 해결하여 유용한 솔루션이 완성되었습니다.

마무리하며

이번 실험 결과를 참고하여 Animation Rigging 패키지를 사용해 보시고 편하게 의견을 공유해주시기 바랍니다.

Animation Rigging Advanced Character Interaction 프로젝트는 GitHub에서 다운로드하실 수 있습니다.

사용 후에 애니메이션 리깅 패키지 포럼에 의견을 남겨주시기 바랍니다!

리깅에 대해 학습하려면 Unity Learn Premium에서 온라인 교육 및 튜토리얼을 확인하시기 바랍니다.

도움을 주신 Yang-Hai Eakes, Simon Bouvier-Zappa, Olivier Dionne, Dave Hunt, Sven Santema 님께 감사의 인사를 전합니다.

18 replies on “고급 애니메이션 리깅: 캐릭터와 프랍 상호작용”

Are you guys going to make available for download this project or at least the rigged ninja? It was mentioned in the comments in the previous article in the comments (in May) it would be later this year.

You guys have done a great job explaining despite this being a particularly tricky subject. Someone else has done some interesting design work in this area too:

https://forum.unity.com/threads/freeform-animation-modular-rigging.648088/#post-4880768

That thread should really be looked through carefully. The author has put a lot of work into devising some interesting ideas and solutions to these tricky design issues while still being flexible and not requiring code. Particularly the modularity of the rig being swappable is necessary, and I think your current design makes that difficult. You can’t use separate “modules” (like in the thread I linked) for different parts of the rig if you are overlaying on top of the old AnimationController. It simply isn’t designed for that.

Have you guys looked into incorporating any of the ideas from that topic yet? What about using curves to animate from one position to the next? For example, I like the idea of using an oscillating AnimationCurve as a parameter that animates across a set length of time on a particular layer (or against some physics-based input in a logic-based state-machine type solution). That guy from that thread goes way out of his way to avoid having to use large number of keyframes by aiming at the logic-based approach you guys seem to be going for with constraints.

Are you planning anything like this with the new DOTS-based approach?

Because Animation Rigging is closely related to other features that are still in development, like Freeform Animation and DOTS Animation, it is difficult to say for sure at the moment. A year (for 2020 LTS) is not unreasonable but it could be longer so it would be imprudent to commit to a date yet. This will really depend on the feedback we get and the complexities of the fully verified implementation. Rest assured that we are actively working on Animation Rigging and that we will share every step of the development with the community.

Thanks!

I am just wondering why create so many layers per object instead of creating a generic “Prop” one and then using AnimatorOverrideControllers? I am asking because I’m rebuilding our game’s main character with override controllers to fasten the integration of new equipables, and wonder if there is a reason why you avoided using them?

For instance, a rifle and a pistol both have the same behaviour in term of animation graph, so I don’t see why this isn’t reused.

We are using the animation rigging constraints to insert an additive correction on top of the animator output. For example, It allows us to repurpose the whole rifle locomotion and modify it (using rig constraints) to match the desired pistol locomotion pose. Using Animation override controller seems like a valuable solution but might requiered an extra set of animation clips. Using the animation rigging package would help you streamline your animation library by sharing the same basic animation through different props (that probably required a different posing) that could potentially help you better manage your animation memory budget.

I hope this would help clarify the subject and, maybe, be helpful for your production.

Thank you

Jean-Sebastien Campagna

Very cool! Wondering how this fit in with DOTS , will Unity have its own rigging system that runs on DOTS. Another key feature for rigging is PDS. Can we get a PSD system for deformations

Yes our goal is to provide an extensible rigging system that runs on DOTS and was actually the intent from the start. In regards to a PSD, we certainly would like to eventually ship an out-of-the-box solution in the future.

DOTS performed rigs would be fantastic. Keeping rigs at 30fps is really challenging with some rig having to evaluate 50k nodes.

Comments are closed.