KGC2010 김주복, 김충효 - M2 프로젝트의 절차적 리깅 시스템

Ⓒ 2010 NEXON Corporation & devCAT Studio. All Rights ReservedM2 team, Game Development Team for Project W in devCAT (The 3rd Development Division in NEXON Corp.). M2 team Director is Kim, Dungeon | Project W is produced by Kim, Dungeon

M2 프로젝트의

절차적캐릭터리깅시스템

NEXON devCAT 김주복, 김충효

김주복애니메이션프로그래밍10년차2001

2001

2003

2005

2006

2008

2009

2010

무선사업팀 도트디자이너마비노기팀 리드 프로그래머마비노기 프로그래밍팀 팀장그룹웨 어 개발 팀 팀 장W 팀 테 크 니 컬 디 렉 터개 발 3 본 부 3 실 실 장마비노기 2 개발 디렉터신규개발3본부 1실 실장

twitter.com/eiaserinnys

Ⓒ 2010 NEXON Corporation & devCAT Studio. All Rights ReservedM2 team, Game Development Team for Project W in The 3rd Development Division in NEXON Corp. M2 team Director is Kim, Dungeon | Project W is produced by Kim, Dungeon

넥슨 신규개발 3본부

김충효

2001년 입사 / 마비노기1 프로젝트 합류

2006년 마비노기2 프로젝트 합류

2010년 현재 M2팀 팀장 / 넥슨 아트 직군장

Ⓒ 2010 NEXON Corporation & devCAT Studio. All Rights ReservedM2 team, Game Development Team for Project W in The 3rd Development Division in NEXON Corp. M2 team Director is Kim, Dungeon | Project W is produced by Kim, Dungeon

모델링애니메이팅리깅스크립팅…

캐릭터의Deformation

시간의 흐름에 따른

실루엣의 변화가바로 애니메이션이다라고 해도 과언이 아님…

3D 캐릭터를애니메이션 시킨다는 것은

표면의 Vertex를움직인다는 것이다어떤 수단을 사용해도 상관 없다.버텍스를 움직여서 표면 실루엣을 변화시키는 모든 방법이캐릭터를 애니메이션 시키는 방법이 된다.

캐릭터 디포메이션의 방법캐릭터 애니메이션의 방법

일반적인 3D 캐릭터

Skeletal Animation골격 구조의 뼈대를 움직여서 캐릭터를 변형시킨다.

물론 뼈 없이애니메이션을 시킬 수있지만…Vertex Morph 를 활용한 방법이 대표적하지만 이것만 가지고는캐릭터 전체를 움직이기 힘들다.

일반적인 게임 캐릭터에는

(보통)뼈! 만 있다…Runtime 으로 변형이 일어나야 하기도 하고애니메이션 데이터가 무한정 커질 수 없기 때문에

일반적인 게임 캐릭터는 Skeletal Animation 을 한다.뼈대를 다양하게 활용해서 캐릭터의 미세한 변형을 표현하는 것이현 시대의 일반적인 표현 방법이다.

Surface Model + Skeletal Animation

지긋지긋한…

Skinning !!Vertex 의 위치가 관절의 위치와 방향을 따라간다.Skinning 과정을 통해서 어떤 관절에 어느 정도로 따라가게 될 지 결정됨

현 세대 캐릭터의표현수준

만들기 난해하다차세대 수준의 캐릭터가 요구하는 표현 수준이 너무 높다.노말맵을 비롯한 여러 가지 맵소스도 만들어야 하고폴리곤의 수도 엄청 많아야 한다.

요즘의 플레이어들은자비가 없다과거에는 기술적 한계로 인해 용납되던 것 들이지금은 결점으로 받아들여진다.요구 퀄리티가 엄청나게 높아졌다.

적은 수의 관절은한계가 있다실루엣의 변형은 거의 전적으로 관절의 움직임에 의존함

원하는 수준으로 실루엣을 변형 시키려면과거처럼 관절을 아껴서 쓸 수 없다!!

과거와 같은 수준의 관절로는더 이상 무리ex) Candy Wrap 현상

어떻게 문제를해결해 왔는가?

가장 일반적인 방법은

보조 관절의 사용문제가 일어나는 부분, 혹은 더 잘 표현하고 싶은 부분에임의로 관절을 더 설치한다.

해당 관절을 수동으로 움직이거나,주요 관절의 움직임에 자동으로 반응하게 해서더 좋은 퀄리티의 실루엣을 얻는다.

예시) 트위스트 관절Candy Wrap 현상을 막는 대표적인 방법보통 손이나 발목 관절 등의 회전에 따라 자동으로 동작한다.

예시) 상완 이두근 관절

선택의 여지 없음보조 관절을 사용하지 않고5000 tri 이상의 차세대급 캐릭터를원하는 대로 아름답게 표현할 방법이 없다.

그 동안문제가 없었을까?

보조 관절의 증가는?

애니메이션데이터 규모의 증가보조 관절이 많으면그만큼 많은 데이터를 익스포트 해야 한다.

또한, Pre-Baked 라는 것은

데이터의 유연성 감소프레임워크의 변화에 유연하게 대응하기 힘들고절차적인 애니메이션에 반응하기 어렵다.

끔찍한 경우 1

보조 관절의 동작이변했다면?트위스트 관절이나기타 근육을 표현하는 관절의 동작이만족스럽지 않아서

동작을 조금 고쳤어요…

끔찍한 경우 2

보조 관절의 수가늘어났다면?아무래도 어깨 표현이잘 안 되는 것 같은 판단이 들어서

어깨 부분에 보조 관절을추가했어요…

물론 캐릭터 메시 스키닝도 다시했지요…

끔찍한 경우 3

의상 별로서로 다른 보조 관절을써야 한다면?MMORPG 이니까 코스튬 퀄리티가 중요함.

의상마다최상의 퀄리티를 유지할 필요 있음.

각각의 의상에 특화된보조 관절을 사용하게 된다면?

프로그래머 입장에서는…

보조 관절을 사용하는캐릭터가 Rag Doll 처리된다면?Rag doll 혹은 IK 처리 등으로 인해서미리 구워진 애니메이션과 다른 동작을 하게 되면보조 관절은 어떻게 동작해야 하는 거지?

보조 관절과 Pre-Baked Animation

애니메이션 데이터의증가 뿐만 아니라,프레임워크 데이터를변경하기 힘들어짐을의미한다


프레임워크가다른 의상 마다모든 애니메이션을따로 준비해야 한다솔직히 이건 말도 안 되는 선택지이다.


말하자면,

애니메이션 데이터가프레임워크 종속적이된다는 것이다캐릭터 릭의 개선을 통해서퀄리티를 계속 높여가는 것에커다란 장애 요소가 된다.

결국…3D 아티스트로서내가 갖고자 했던 것

Needs:

미리 구워내지 않아도

클라이언트에서DCC툴과 동일하게 동작하는 보조관절이 필요애니메이션 데이터의 크기 감소와작업 파이프라인의 유연성의 확보 및절차적 애니메이션에의 반응성 확보

Objective:

절차적 보조 관절 구현!클라이언트에서3ds max 에서 구현한 것과완전히 동일하게 동작하는 관절을 구현해야 한다!!

목표의 구체화 과정

프로그래머 입장에서는

무엇을 구현해야DCC툴에서와 같은퀄리티를 낼 수 있는지알 수 없다프로그래머들에게는3ds max는 거대한 블랙박스와 같다.

(아티스트가 칭얼거려서…)

니즈는 확보했는데…

궁극적인 골은 어디?구체적으로 어떤 것 들을 구현해야 하는지 결정해야 했다.니즈를 찾았으니,문제를 구체화 하고 목표를 설정해야 함

일단!

아티스트가 원하는최적의 상태를3ds max로 만들자캐릭터의 누드 메시가DCC툴에서 최적의 상태로 나올 수 있도록프레임워크 세팅을 진행

고심 결과,작업 진행은 당연히

여성 캐릭터로…여성 캐릭터의 누드를 아름답게 연출할 수 있을 정도면남자는 손쉽게 할 수 있을 것이다.의욕 문제도 있고…

최종적으로우리가 원하는 상태는

무엇인가?

그런데…

내가 원하는 상태?

나도 잘 모르겠다만…

어디가 어려운지는 안다나도 근육 같은 것 세팅해본 경험 별로 없다…경험적으로 어떤 부분의 스키닝이 잘 안 되는지는 알고 있다.

나를 항상 괴롭혀온…

전통적으로 어려운 곳

매력 포인트라서…

더 잘 해보고 싶은 곳

스키닝 방식이 바뀌지 않는 한…

트위스트가 필요한 곳

어렵지는 않지만…

후속 조치가 필요한 곳

특히 어깨!!! 부분은Candy Wrap 현상이가장 심하게 일어난다

3축으로자유도를 갖는 관절은스키닝하기 까다롭다

현실에서의 어깨 표면이어떤 식으로 움직이는지연구 진행피부의 변형을 이해하는 것은관절의 움직임을 이해하는 것 과는 또 다른 영역이다.궁극적으로 피부 실루엣의 변형을 묘사해야 함

피부접히는부분의특이한형태에도주목

연구 결과를 바탕으로…

어깨 관절 리깅

스키닝을 하지는 않지만

올바르게 동작하는 데필요한 관절도 있다…피부를 변형시키는 데 직접 관여하지는 않지만관절들의 최종 위치를 계산하기 위해서는나름대로 동작을 할 필요가 있는 관절들

리깅에 사용된3ds max의 주요 기능

주요 기능

ExposeTMExpose Transform Matrix (Helper)특정 관절의 현재 상태를 알아낼 수 있다.

Local/World Position (관절의 위치)Local/World Euler Angle (관절의 회전)Distance (두 관절 사이의 거리)

:

주요 기능

Position Constraint특정 관절의 위치를 그대로 따라가거나,둘 이상의 관절들의 위치를적당히 내분하는 지점에 위치하게 된다.

주요 기능

LookAt Constraint이름 그대로…특정 관절(들)의 위치를 계속 쳐다본다.Upnode 를 잘 활용해야 함.

주요 기능

Rotation List둘 이상의 Rotation Controller 의 계산 결과를특정 비율로 나눠서 적용할 수 있다.

주요 기능

Reaction ControllerMaster 가 되는 “무엇”의 변화에 따라Slave 가 되는 “무엇”의 상태를 결정할 수 있다.

Master

Slave

리깅 사례

핵심 관절

Shoulder 1Shoulder 2삼각근의 다양한 변형 및 부풀어 오름에 대응하기 위한 관절

핵심 관절

Shoulder 1Shoulder 2삼각근의 다양한 변형 및 부풀어 오름에 대응하기 위한 관절

Shoulder 동작의기본 아이디어팔의 회전이 어떤 상태이냐에 따라어깨의 위치와 방향이 결정된다.

Shoulder 1 의 동작

팔관절 Shoulder 1Local Rotation

ExposeTMPosition

Reaction Controller

RotationLookAt Constraint

Up Node

Up Node

Position

Reaction Controller

Shoulder 2 의 동작

팔관절Local Rotation

Shoulder 2Position

Reaction Controller

Rotation

ExposeTM

Reaction Controller

승모근

Trapezius아름다운 목 라인과 어깨 라인을 서포트

승모근 동작의기본 아이디어어깨와 목을 연결한 선 위에 위치한다.어깨 쪽을 계속 바라보고 있다.척추 방향으로 정렬되어있다.

상박 트위스트 관절의기본 아이디어항상 Upper Arm 관절의 길이 방향으로 정렬되어 있다.Upper Arm 관절의 회전 정도와Shoulder 관절의 회전 정도를 적당히 분배한다.

상박 트위스트 관절의동작Upper Arm 의 Upnode 방향과Shoulder 의 Upnode 방향을일정 비율로 섞었다.

흉근과 견갑골 동작의기본 아이디어LookAt Constraint를 활용한 단순한 동작.대신 부모 관절의 움직임으로 인해 복잡한 움직임을 보임.

흉근 견갑골

DCC툴에서의최종 리깅 결과

최종 어깨 실루엣



절차적 리깅 시스템으로…

새로운 아이디어를 실현

간단한

구현 방법ExposeTM 으로 측정하고,Reaction Controller 로 결정한다.

여성 누드 캐릭터가충분히 만족스러운 상황이라고 판단!!

대략적인 구현 목표 추출Reaction ControllerLookAt ConstraintPosition ConstraintOrientation ConstraintExpression ControllerWire ParameterExposeTM

:

조금 많은가?

목록이 많다 어쩌다 해도

결국 다 구현하긴 했다Reaction ControllerLookAt ConstraintPosition ConstraintOrientation ConstraintExpression ControllerWire ParameterExposeTM

:

시연

Ⓒ 2008-2010 NEXON Corporation & devCAT Studio. All Rights ReservedM2 team, Game Development Team for Mabinogi in devCAT (The 3rd Development Division in NEXON Corp.). M2 team Director is Kim, Dong-Gun | Project W is produced by Kim, Dong-Gun

devCAT Engine team, Engine Development Team for Project W and more. Engine Team Technical Director is Jeon, Hyeong-Kyu

절차적 리깅 시스템의 구현

3DS MAX컨트롤러의 구현 사례

디펜던시와 계산 순서 문제

최 적 화 관 련 이 슈월드 트랜스폼 문제 | 스케일을 가 진 트랜스폼 문제 | 실 수 계산 성능

퍼포먼스 및 장단점 분석 , 결론









// 실제 인터페이스와 일치하지 않는 것에 주의class IReactor {public:

virtual void Preprocess() = 0;

virtual void Process(const ProcessOption&) =0;

virtual const ReactorResult& GetResult() const = 0;};

3DS MAX의 컨트롤러는 IReactor란 이름으로 구현되어 있다

공통 인터페이스

PositionConstraint는 본을 타겟 본들의 가중 평균에 놓는다

위치를 블렌딩한다

<어른의 인형 놀이> 중M2 PSM, 한상원

아들이 아버지와 어머니,어느 쪽에도 치우치지 않는

중간적인 위치를 견지하고 있다

void PositionConstraint::Process(/* 생략 */){

위치 컨스트레인트 타겟 위치를 가중치 합산

[월드 공간]→[부모 공간] 변환의 트랜스폼 T를 계산

T를 이용, 합산 결과를 부모의 로컬 공간으로 이동

계산된 결과를 저장}

첫번째로 접하는 컨트롤러이니만큼 구현이…

너무나 쉬운 컨트롤러






컨스트레인트 타겟의 위치를 블렌딩한다

1. 목표 지점을 계산






블렌딩된 위치를 포지션 컨스트레인트가 걸려 있는 본의

2. 로컬 좌표로 변환

슈도 코드 뿐만 아니라…

실제 코드도 간단

롤 아웃에 있는 뭔가

수상한 옵션은?

Keep Initial Offset 옵션은 포지션 컨트스트레인트 계산 결과와

초기의 어긋남을 보존

PositionAtConstraint가걸려 있는 본의바인드 포즈의 위치

Keep initial offset옵션에 의해서이동된 위치

void PositionConstraint::Preprocess(){

keep initial offset이 켜진 경우, 포지션 컨스트레인트의계산 결과와 바인드 포즈의 차이를 [옵셋]으로 보존해둔다

}void PositionConstraint::Process(/* 생략 */){




keep initial offset이 켜진 경우, 계산 결과에 [옵셋]을 더한다


Keep Initial Offset 옵션을 포함하는

옵셋을 반영한 슈도코드

40

다른 컨트롤러의 구현 방법에 관련된 사항은

추가 노트에 수록







전통적인 애니메이션 프로그래밍에서 트랜스폼은 순서대로 계산

인덱스 순서대로?0

1 8

52

3 4 6 7

109

11 12 13 14

하지만 보조 본들은 순서대로 계산된다고 보장할 수 없다

다른 본을 참조하면?0

1 8

52

3 4 6 7

109

11 12 13 14

좋은 방법이 떠오르지 않으니 일단…

개별 컨트롤러가 계산?void PositionConstraint::Process(/* 생략 */){




keep initial offset이 켜진 경우, 계산 결과에 [옵셋]을 더한다

계산된 결과를 저장}void PositionConstraint::GetDependancy(vector<int>& dependancies){

dependancies에 위치 컨스트레인트 타겟들을 추가한다}

90

이 방법이 그렇게 쉽지가 않다

구현에 따라서 복잡void LookAtConstraint::Process(/* 생략 */){


자신의 위치를 T를 사용해서 부모 공간으로 변환

쳐다보기 타겟의 위치를 가중치 합산T를 사용, 부모의 로컬 공간으로 이동시켜서 쳐다볼 방향을 계산

위쪽 방향 타겟을 T를 사용, 업 벡터를 계산

앞과 위로 트랜스폼을 구성한 뒤 쿼터니언으로 변환해서 저장}void LookAtConstraint::GetDependancy(vector<int>& dependancies){

dependancies에 쳐다보기 타겟들을 추가한다dependancies에 업 노드를 추가한다

}

const ReactorResultReactionControllerBase::Process(/* 생략 */)

{정렬된 마스터/슬레이브 리액션 리스트에서 주어진 마스터 값을 넘지 않으면서가장 큰 마스터/슬레이브 인덱스를 찾는다

찾아낸 리액션과 다음 리액션을 보간하여 반환한다}void ReactionControllerBase::GetDependancy(vector<int>& dependancies){

foreach (마스터 값 m에 대해서)m.GetDependancy(dependancies);

}void IReactorExprIDHandler::GetDependancy(vector<int>& dependancies){

익스포즈 노드를 dependancies에 추가한다레퍼런스 노드를 dependancies에 추가한다

}

컨트롤러 타입에 따라서 점점 더 복잡해지고

ReactionController?

class ReactorExpressionBinary {void GetDependancy(std::vector<int>& dependancies);

};class ReactorExpressionID {

void GetDependancy(std::vector<int>& dependancies);};class ReactorExpressionFunction {

void GetDependancy(std::vector<int>& dependancies);};class ReactorExpressionConstant {

void GetDependancy(std::vector<int>& dependancies);};class ReactorExpressionList {

void GetDependancy(std::vector<int>& dependancies);};class ReactorExpressionFunction {

void GetDependancy(std::vector<int>& dependancies);};

감당해야 할 필요가 없는 복잡한 작업을 감당해야 하는 상황에 이른다

수식에서는…???

타이핑도 많아지고 근본적으로 실수하기가 쉽다

저절로 계산할 수 없나?

더미 연산을 통해 리액터가 트랜스폼 데이터를 요구하는 것을 가로채자

후킹을 통한 접근PositionConstraint

LookAtConstraint

OrientationConstraint

PositionReactionController

RotationReactionController

ScaleReactionConstraint

FloatWireConstraint

IReactorPoseSourceGetWorldTranslation(int boneIndex)GetWorldRotation(int boneIndex)GetWorldScale(int boneIndex)GetLocalTranslation(int boneIndex)GetLocalRotation(int boneIndex)GetLocalScale(int boneIndex)GetWorldTransform(int boneIndex)…

bone11

PositionConstraint9, 10

ReactorTraversalBuilder :public IReactorPoseSource

OrientationConstraint12

ScaleXYZ

bone12

PositionXYZ

LookAtConstraint24

ScaleXYZ

… 10

0~10번까지 트랜슬레이션, 회전, 스케일을 순서대로 순회한 결과

bone11




ScaleXYZ

bone12

PositionXYZ

LookAtConstraint24

ScaleXYZ

… 10

bone11




ScaleXYZ

bone12

PositionXYZ

LookAtConstraint24

ScaleXYZ

… 10

bone11




ScaleXYZ

bone12

PositionXYZ

LookAtConstraint24

ScaleXYZ

… 10

100

bone11




ScaleXYZ

bone12

PositionXYZ

LookAtConstraint24

ScaleXYZ

… 10 24

bone11




ScaleXYZ

bone12

PositionXYZ

LookAtConstraint24

ScaleXYZ

… 10 24 12

bone11



ScaleXYZ

bone12

PositionXYZ

LookAtConstraint24

ScaleXYZ

… 10 24 12


bone11




ScaleXYZ

bone12

PositionXYZ

LookAtConstraint24

ScaleXYZ

… 10 24 12 11

자동으로 계산 순서를 구축하기 때문에, 기능을 확장하더라도

안전, 정확한 순서 보장







void OrientationConstraint::Preprocess(){

keep initial offset이 켜진 경우, 오리엔테이션 컨스트레인트의계산 결과와 바인드 포즈의 차이를 [회전 옵셋]으로 보존해둔다

}void OrientationConstraint::Process(/* 생략 */){

if (로컬 공간 보간 모드)컨스트레인트 타겟의 로컬 회전을 기록

else // 월드 공간 보간 모드컨스트레인트 타겟을 부모 본의 로컬 공간으로 옮겨서 기록

가중치 합산하여 회전을 계산한다

keep initial offset이 켜진 경우, 계산 결과에 [회전 옵셋]을 더한다

계산 결과를 저장}

거의 대부분의 컨트롤러의 계산 과정에서

월드 트랜스폼을 요구

문제는 컨트롤러 계산 결과가 적용되는 과정에서

서브 트리가 무효화

본 수가 무지막지하게 많기 때문에모든 월드 트랜스폼을 업데이트하는 것은

치명적 성능문제의 원인

110

0

1 8

52

3 4 6 7

129

10 11 13 14

1 2 3 4 5 6 7 8 9 10 11 12 13 14

2 3 4 5 6 7

0

3 4

0 1

0 1 2

9 10 11 12 13 14

0

13 14

0 8

0 8 12

최소한으로 월드 트랜스폼을 재계산하기 위해서

조상/후손 리스트 관리

0

1 8

52

3 4 6 7

129

10 11 13 14

1 2 3 4 5 6 7 8 9 10 11 12 13 14

2 3 4 5 6 7

0

3 4

0 1

0 1 2

9 10 11 12 13 14

0

13 14

0 8

0 8 12

특정 본이 재설정되면 후손 리스트의 월드 트랜스폼만 무효화한다

최소 범위 무효화

0

1 8

52

3 4 6 7

129

10 11 13 14

1 2 3 4 5 6 7 8 9 10 11 12 13 14

2 3 4 5 6 7

0

3 4

0 1

0 1 2

9 10 11 12 13 14

0

13 14

0 8

0 8 12

특정 본의 월드 트랜스폼이 필요하면 조상 리스트만 검색한다

최소 범위 재계산

메모리 상에서 캐시 관리 문제로 기대보다는 성능 향상이 낮지만

전체 재계산 회피 가능

…이라고 2009년 상반기엔 생각했었으나…

그때그때 계산하면 L2 캐시 미스로 인해 효율이 낮음

산발적인 접근이 문제

랜덤한 위치의 SRT와트랜스폼을여러 단계 찾아가게 됨= L2 캐시 미스

접근하는 메모리 공간이 시간 상에서 연속하도록

재계산을 모아줄 필요

1. 월드 트랜스폼을 재계산하는 순서를 계산

↓

2. 개별 리액터 계산에 앞서 모아서 연산

포즈가 월드 트랜스폼을 재계산하는 것을 가로채 기록해두자

후킹을 통한 접근 (2)일반 버전의UpdateBoneWorldTransform

템플릿 특화 버전의UpdateBoneWorldTransform















거의 대부분의 컨트롤러의 계산 과정에서

부모의 역트랜스폼 요구

또한 많은 회전 컨트롤러의 계산 결과로

트랜스폼 → SRT 요구void LookAtConstraint::Process(/* 생략 */){





앞과 위로 트랜스폼을 구성한 뒤 쿼터니언으로 변환해서 저장}

매트릭스의 역을 구하는 연산과 SRT (스케일/회전/트랜슬레이션) 분해

두 연산 모두 비싸다

함수 길이만으로도쌀 수가 없는인버스 트랜스폼

PolarDecompose와SpectralDecompose의비싼 두 함수를 거치는

SRT 분해

연산이 복잡해지는 근본적인 원인은

스케일

(스케일이 없으면)

R-1 = RT

SRT(M) ={

(1, 1, 1), QuaternionFromMatrix(M), (M[3][1], M[3][2], M[3][3]

}(스케일이 없으면)

스케일안 쓰면되잖아!!!!

아 진짜 애니메이터 여러분 부탁입니다

월드 트랜스폼 무효화와 유사한 형태로

스케일 여부를 관리

애니메이션 플레이어부터 대대적인 수정이 필요하지만

계산량 대폭 절약 가능

부모 본의 월드 트랜스폼에스케일이 없는 경우엔

아예 인버스를 구하지 않고수식을 풀어서 결과만 계산한다







포지션/로테이션/스케일 컨트롤러 계산 과정에서

대량의 실수 연산 요구

특히 심각한 성능상의 영향을 미치는 것은 놀랍게도…

1/sqrt(x)

벡터의 노말라이즈를 비롯, 쿼터니언→매트릭스 변환 등,

많은 곳에서 사용한다

QuaternionFromMatrix

‘힘내! 너는 이미 이런 상황을 해결할 방법을 알고 있어!’

‘네, 저도 이젠 손에 잡힐 듯이 보여요! 강중약약…’

130

이런 상황에서 믿을 수 있는 것은…

Quake III Arena 매직

위키피디아에도등재되어 있다

치명적인 성능 페널티를 피할 수 있는 것은 사실이지만

수식 최적화를 우선해야







벡터의 노말라이즈를 비롯, 쿼터니언→매트릭스 변환 등,

퍼포먼스 차트

pros물리 시뮬레이션 등, 절차적 애니메이션에 대응이 자유롭다

전체적인 애니메이션 파이프라인의 유연성이 증대된다

기계나 갑옷 등의 움직임을 묘사하는데 매우 유리하다

consMMORPG에서 대량의 캐릭터에 사용하기엔 성능 부담이 있다

모델러 혹은 애니메이터가 활용하기 위해 기반 지식이 많이 필요하다

LOD를 고려하면 스키닝이나 프레임워크 설계가 까다롭다













표현 영역을확장하는 측면에서 접근

기술의 발전의 귀결

캐릭터 표현의 복잡화절 차 적 애 니 메 이 션 → 실시간 절차적 리깅

실시간 절차적 리깅 기술은

3DS MAX의 절차적리깅의 복제는 비교적 쉽다

미리미리 준비하여선진조국 이룩하자







QA?

3DS MAX 컨트롤러의 동작과 구현



룩 앳 컨 스 트 레 인 트 | 오 리 엔 테 이 션 컨 스 트 레 인 트리액션 컨트롤러 | 수식 컨트롤러 & 플롯 와이어 | X Y Z & 리스트 시리즈

추가 노트





추가 노트

LookAtConstraint, 이름 그대로 본이 특정 위치를…

쳐다보도록 만든다

아버지와 어머니는 아들만 바라보고할아버지는 멀리서 가족 모두를 지그시 바라볼 뿐,

노령 인구의 소외는 현대 한국 사회의심각한 사회 문제로 떠오르고 있다

<어른의 인형 놀이> 중M2 PSM, 한상원

기능 설명이 명료하기 때문에 상대적으로 구현이

비교적 쉬운 컨트롤러?void LookAtConstraint::Process(/* 생략 */){






void LookAtConstraint::Process(/* 생략 */){






자신의 위치를 부모 본의 로컬 공간으로 가져간다

1~2. 원점 계산







타겟을 월드 상에서 가중치 합산한 후에 부모 본의 공간으로 가져간다

3. 앞 방향 계산

간단할 것처럼 보이는…

4. 위 방향 계산void LookAtConstraint::Process(/* 생략 */){






3DS MAX의 업 노드 옵션이 (쓸데없이) 다양하기 때문에

신경 쓸 것이 많다

앞과 위를 구했으니 옆은 외적으로 간단히 계산할 수 있을 거고,

5. 회전으로 만들면 끝?void LookAtConstraint::Process(/* 생략 */){






이 정도면 다 된 것 같은데 롤 아웃에 아직도 남아있는 뭔가

수상한 옵션들은?

50

Keep Initial Offset 옵션은 쳐다보기 계산 결과와

초기의 어긋남을 보존

LookAtConstraint가걸려 있는 본

void LookAtConstraint::Preprocess(){

keep initial offset이 켜진 경우, 룩 앳 컨스트레인트의계산 결과와 바인드 포즈의 차이를 [회전 옵셋]으로 보존

}


/* 전략 */



Keep Initial Offset 옵션을 포함하는

최종 슈도 코드





추가 노트

OrientationConstraint, 본이 컨스트레인트 타겟들의

회전의 평균을 취한다

<어른의 인형 놀이>서플먼트 무비

M2 PSM, 한상원

할아버지의 회전에 따라서온 가족이 영향을 받는 것을 알 수 있다가족 모델로서 핵가족의 장단에 대해서

고민해봐야 하는 시점이 아닐까

void OrientationConstraint::Process(/* 생략 */){

컨스트레인트 타겟의 로컬 회전 리스트를 얻는다

가중치 합산하여 계산하고 기록한다}|

룩앳보다 어떤 의미에서는

제일 간단한 컨트롤러?









월드 공간 오리엔테이션 블렌딩 모드가 있기 때문에

그럴 리가 없다…









일단 귀찮지만 LookAtConstraint와

옵셋 보존 계산은 동일









프로그래머의 기대를 여지없이 배반해버리는

트랜스폼 규칙

60

계층 구조가 서로 무관한 본의 회전을 블렌딩하기 위해서 필요

‘보이는 대로’ 블렌딩

World→World로OrientationConstraint가걸려있는 본부모

자식

로컬+15도회전

로컬+15도회전

(최종 30도)

Local→Local인 경우(15 + 15) / 2 = 15도World→World인 경우(15 + 30) / 2 = 22.5도,





추가 노트

*ReactionManager의 기본적인 개념은

입력→그래프→출력

때려주고 싶은 마음이가슴 깊은 곳부터 샘솟아 오르는

비 직관적인 UI

*ReactionManager 구현의 어려운 점은…

입력의 종류가 많다Local Rotation X/Y/ZWorld Rotation X/Y/ZLocal Position X/Y/ZWorld Position X/Y/Z

Distance

핵심적인 기능은 float→그래프→출력이므로

먼저 입력을 추상화

PositionEvaluatorRotationEvaluator

DistanceEvaluator

LocalPosition X/Y/Z, WorldPosition X/Y/Z를 처리하는

PositionEvaluatorconst float PositionEvaluator::Process(/* 생략 */){

if (로컬 공간 값을 요구)if (부모를 기준으로)

return 로컬 트랜슬레이션[지정된 채널]else if (레퍼런스 본을 기준으로)

레퍼런스 본 트랜스폼 공간으로 변환return 변환된 결과값[지정된 채널]

else // 레퍼런스가 undefined == 월드 기준return 월드 트랜슬레이션[지정된 채널]

elsereturn 월드 트랜슬레이션[지정된 채널]

}

로컬/월드라고 하면 간단할 것 같은데

특이한 부분?const float PositionEvaluator::Process(/* 생략 */){


return 로컬 트랜슬레이션[지정된 채널]else if (레퍼런스 본을 기준으로)

레퍼런스 본 트랜스폼 공간으로 변환return 변환된 결과값[지정된 채널]

else // 레퍼런스가 undefined == 월드 기준return 월드 트랜슬레이션[지정된 채널]

elsereturn 월드 트랜슬레이션[지정된 채널]

}

프로그래머가 상상하기 어려운 동작을 요구하는

헬퍼 본 인터페이스

LocalRotation X/Y/Z, WorldRotation X/Y/Z를 처리하는

RotationEvaluatorconst float RotationEvaluator::Process(/* 생략 */){


return 로컬 회전값[지정된 채널]else if (레퍼런스 본을 기준으로)

레퍼런스 본 트랜스폼 공간으로 변환return 변환된 회전값[지정된 채널]

else // 레퍼런스가 undefined == 월드 기준return 월드 회전값[지정된 채널]

elsereturn 월드 회전값[지정된 채널]

}

PositionEvaluator와 동일하지만…

쿼터니언→오일러 XYZ

쿼터니언 → 매트릭스 변환 식과매트릭스 → 오일러 XYZ 분해를

결합해서 유도 가능70

Distance를 처리하는

DistanceEvaluator

const float DistanceEvaluator::Process(/* 생략 */){

if (레퍼런스 본이 유효)return 기준 본과 레퍼런스 본의 거리

elsereturn 기준 본과 월드 원점의 거리

}

마스터 입력 이후의 float→그래프→출력 처리는 공통

키 프레임 애니메이션재생과 동일const ReactorResult

ReactionControllerBase::Process(/* 생략 */){

정렬된 마스터/슬레이브 리액션 리스트에서주어진 마스터 값을 넘지 않으면서가장 큰 마스터/슬레이브 인덱스를 찾는다

찾아낸 리액션과 다음 리액션을 보간하여 반환한다}





추가 노트

FloatWire와 *ExpressionControl은 최후의 수단

수식 계산값을 사용

수식을 사용하는 것 외에는 리액션 컨트롤러와 유사한 난이도

파싱만 하면 간단

매번 인터프리터 방식으로 계산하면성능 문제가 있으므로 AST 구축이 필요

자세한 구현은 이 강의의 범위를벗어나므로 생략

수식에 사용되는 ID의 값은 리액션 컨트롤의 마스터와 거의 동일하다

구현의 재활용 가능

RotationEvaluator,PositionEvaluator를

수식 계산에 그대로다시 사용할 수 있다





추가 노트

PositionXYZ, EulerXYZ, ScaleXYZ은

Float 컨트롤러의 묶음

특별한 구현이 필요하지 않을 것 같은데?

기본값과 변환을 처리void EulerXYZ::Process(/* 생략 */){

if (상수인가)기본값을 보존foreach (X/Y/Z 각 축의 컨트롤러에 대해서)

결과값[축] = float 컨트롤러를 계산if (컨트롤러가 FloatReactionControl)

결과값[축]을 라디안으로 변환결과값을 쿼터니언으로 변환

else기본값을 저장

}

PositionList, RotationList, ScaleList은

컨트롤러의 묶음

80

특별한 구현이 필요하지 않을 것 같은데?

순서대로 누적을 처리

void RotationList::Process(/* 생략 */){

foreach (리스트의 컨트롤러에 대해서)[현재] = 컨트롤러의 회전 계산 결과if 컨트롤러가 *Constraint이면

[누적] = Slerp([누적], [현재], [가중치])else

[누적] = [누적] * [현재]}

복제 구현을 마쳤으니…

이제 계산만 하면 된다

void ReactorProcessor::Process(){

foreach (모든 본에 대해서)if (컨트롤러가 있다면)

컨트롤러를 계산한다}

Technology

KGC2010 김주복, 김충효 - M2 프로젝트의 절차적 리깅 시스템