A presentation at 넥슨 개발자 컨퍼런스 2009 in June 2009 in Seoul, South Korea by Jubok Kim
NDC2009 | 김주복 M 2 프 로 젝 트 의 절차적리깅시스템 Ⓒ 2008-2009 NEXON Corporation & devCAT Studio. All Rights Reserved M2 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
r i ggi n g 리깅? <Automatic Rigging and Animation of 3D Characters> SIGGRAPH2007, Ilya Baran & Jovan Popović
p r o c e d u r a l 절차적? <절차적 지형 생성 방식 트렌드 리뷰 : 크기와 품질> NDC2007, 김주복
p r o c e d u r a l r iggi n g 절차적 리깅?
2개의 본으로 셋업된 간단한 메시 선형 스키닝에 의한 꼬임의 결과 아마도 아티스트가 원했을 결과
사탕 봉지 묶어놓은 것 같다고 해서 붙여진 이름? CANDY WRAP OF • ex) Candy Wrap 현상 DEATH
단순히 본 애니메이션 측면으로 접근해서는 커버할 수 없는 선형 블렌딩의 한계 이 세상의 모든 애니메이터와 모델러가 싫어하는 포즈(라고 함)
그런데 이렇게 깨지는 거 자주 본 기억이 없는데…
급격하게 스키닝 값이 변하지 않도록 모델러나 애니메이터가 보조 본을 통해서 해결
프로그래머는 몰라도 됐던 영역의 문제 10
프로그래머가 아무 것도 안 했는데 모르는 사이에 게임에서 손목이 깨~끗하게 나오고 있었다면~ 베이킹 100푸롭니다!
그런데 게임 그래픽 개발 환경은 계속해서 발전해가고 있다 캐릭터 표현의 복잡화 15000 4 0 0 0 2 0 0 0 H A L O , 2 0 X B O X 0 1 Metal Gear Solid 3, P S 2 2 0 0 5 7 0 0 0 V ir t ua Fight er 4, PS2 2 0 0 2 8 3 2 3 H a l f - L i f e 2 , 2 0 0 P C 4 Gears of War, XBOX360, 2 0 0 6
뼈는 물론 근육의 움직임까지 표현 <Crysis> Crytek
애니메이터가 잡은 본의 움직임을 기반으로 계산된 움직임을 수행하는 절차적 리깅으로 접근 <Character Pipeline Advances for Next-Gen Games> GDC2007, Christopher Evans
관심 있으신 분들은 연강으로 이어지니 모쪼록 많은 관심…
모델링이나 쉐이딩 테크닉이 복잡해지는 만큼… 애니메이션 역시 복잡화 <차세대 애니메이션 기법을 MMORPG에 적용하기> NDC2008, 김주복
문제는 절차적 애니메이션
절차적으로 리깅된 본의 움직임은???? 지금까지 베이킹해서 익스포트했었는데…
…왜 안 좋은 예감은 항상 딱 들어맞는 걸까… 20
게임엔진이 실시간으로 계산해주는 수 밖에…
그래서 이 강의에서는… 실시간 절차적 리깅의 구현 과정을 소개 3DS MAX의 컨트롤러 소개 구현의 모사 과정 문제점과 해결책 성능 이슈 고려점
강의 대상 애니메이션 프로그래머 본 애니메이션에 대한 사전 지식이 있으면 대략 감은 잡으실 듯 리깅 관련 테크니컬 아티스트 이런 걸 실시간으로 구현하는 게 춈 어렵구나 알아주시면 감사
이쯤에서 뜬금없이 강사소개 김주복 애니메이션프로그래밍9년차 2001 2001 2003 2005 2006 2008 2009 무선사업팀 도트디자이너 마비노기팀 리드 프로그래머 마비노기 프로그래밍팀 팀장 그룹웨어 개발팀 팀장 W팀 테크니컬 디렉터 3 실 실 장 마비노기 2 개발 디렉터
절 차 적 리 깅 개 념 소 개 3DS MAX 절차적 리깅 기본 개념 각 컨트롤러의 동작과 구현 포지션 컨스트레인트 | 룩앳 컨스트레인트 | 오리엔테이션 컨스트레인트 리액션 컨트롤러 | 수식 컨트롤러 & 플롯 와이어 | XYZ & 리스트 시리즈 디펜던시와 계산 순서 문제 최 적 화 관 련 이 슈 월드 트랜스폼 문제 | 스케일을 가진 트랜스폼 문제 | 실수 계산 성능 데모 퍼포먼스 및 장단점 분석, 결론 Ⓒ 2008-2009 NEXON Corporation & devCAT Studio. All Rights Reserved M2 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
트랜슬레이션, 회전, 스케일 채널 별로 본의 움직임을 계산
더 설명할까 했는데 자리에 맥스도 없고… 이어지는 강의에서 자세히 설명할 거예요??
이후의 컨트롤러는 모두 유사한 형태를 갖고 있다 공통 인터페이스 // 실제 인터페이스와 일치하지 않는 것에 주의 class IReactor { public: virtual void Preprocess() = 0; virtual void Process(const ProcessOption&) =0; virtual const ReactorResult& GetResult() const = 0; };
절 차 적 리 깅 개 념 소 개 3DS MAX 절차적 리깅 기본 개념 각 컨트롤러의 동작과 구현 포지션 컨스트레인트 | 룩앳 컨스트레인트 | 오리엔테이션 컨스트레인트 리액션 컨트롤러 | 수식 컨트롤러 & 플롯 와이어 | XYZ & 리스트 시리즈 디펜던시와 계산 순서 문제 최 적 화 관 련 이 슈 월드 트랜스폼 문제 | 스케일을 가진 트랜스폼 문제 | 실수 계산 성능 데모 퍼포먼스 및 장단점 분석, 결론 Ⓒ 2008-2009 NEXON Corporation & devCAT Studio. All Rights Reserved M2 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 30
PositionConstraint는 본을 타겟 본들의 가중 평균에 놓는다 위치를 블렌딩한다
아들이 아버지와 어머니, 어느 쪽에도 치우치지 않는 중간적인 위치를 견지하고 있다 <어른의 인형 놀이> 중 M2 PSM, 한상원
첫번째로 접하는 컨트롤러이니만큼 구현이… 너무나 쉬운 컨트롤러 void PositionConstraint::Process(/* 생략 */) { 위치 컨스트레인트 타겟 위치를 가중치 합산 [월드 공간]→[부모 공간] 변환의 트랜스폼 T를 계산 T를 이용, 합산 결과를 부모의 로컬 공간으로 이동 계산된 결과를 저장 }
컨스트레인트 타겟의 위치를 블렌딩한다
블렌딩된 위치를 포지션 컨스트레인트가 걸려 있는 본의 2. 로컬 좌표로 변환 void PositionConstraint::Process(/* 생략 */) { 위치 컨스트레인트 타겟 위치를 가중치 합산 [월드 공간]→[부모 공간] 변환의 트랜스폼 T를 계산 T를 이용, 합산 결과를 부모의 로컬 공간으로 이동 계산된 결과를 저장 }
슈도 코드 뿐만 아니라… 실제 코드도 간단
롤 아웃에 있는 뭔가 수상한 옵션은?
Keep Initial Offset 옵션은 포지션 컨트스트레인트 계산 결과와 초기의 어긋남을 보존 PositionAtConstraint가 걸려 있는 본의 바인드 포즈의 위치 Keep initial offset 옵션에 의해서 이동된 위치
Keep Initial Offset 옵션을 포함하는 옵셋을 반영한 슈도코드 void PositionConstraint::Preprocess() { keep initial offset이 켜진 경우, 포지션 컨스트레인트의 계산 결과와 바인드 포즈의 차이를 [옵셋]으로 보존해둔다 } void PositionConstraint::Process(/* 생략 */) { 위치 컨스트레인트 타겟 위치를 가중치 합산 [월드 공간]→[부모 공간] 변환의 트랜스폼 T를 계산 T를 이용, 합산 결과를 부모의 로컬 공간으로 이동 keep initial offset이 켜진 경우, 계산 결과에 [옵셋]을 더한다 계산된 결과를 저장 } 40
LookAtConstraint, 이름 그대로 본이 특정 위치를… 쳐다보도록 만든다
아버지와 어머니는 아들만 바라보고 할아버지는 멀리서 가족 모두를 지그시 바라볼 뿐, 노령 인구의 소외는 현대 한국 사회의 심각한 사회 문제로 떠오르고 있다 <어른의 인형 놀이> 중 M2 PSM, 한상원
기능 설명이 명료하기 때문에 상대적으로 구현이 비교적 쉬운 컨트롤러? void LookAtConstraint::Process(/* 생략 */) { [월드 공간]→[부모 공간] 변환의 트랜스폼 T를 계산 자신의 위치를 T를 사용해서 부모 공간으로 변환 쳐다보기 타겟의 위치를 가중치 합산 T를 사용, 부모의 로컬 공간으로 이동시켜서 쳐다볼 방향을 계산 위쪽 방향 타겟을 T를 사용, 업 벡터를 계산 앞과 위로 트랜스폼을 구성한 뒤 쿼터니언으로 변환해서 저장 }
자신의 위치를 부모 본의 로컬 공간으로 가져간다 1~2. 원점 계산 void LookAtConstraint::Process(/* 생략 */) { [월드 공간]→[부모 공간] 변환의 트랜스폼 T를 계산 자신의 위치를 T를 사용해서 부모 공간으로 변환 쳐다보기 타겟의 위치를 가중치 합산 T를 사용, 부모의 로컬 공간으로 이동시켜서 쳐다볼 방향을 계산 위쪽 방향 타겟을 T를 사용, 업 벡터를 계산 앞과 위로 트랜스폼을 구성한 뒤 쿼터니언으로 변환해서 저장 }
타겟을 월드 상에서 가중치 합산한 후에 부모 본의 공간으로 가져간다 3. 앞 방향 계산 void LookAtConstraint::Process(/* 생략 */) { [월드 공간]→[부모 공간] 변환의 트랜스폼 T를 계산 자신의 위치를 T를 사용해서 부모 공간으로 변환 쳐다보기 타겟의 위치를 가중치 합산 T를 사용, 부모의 로컬 공간으로 이동시켜서 쳐다볼 방향을 계산 위쪽 방향 타겟을 T를 사용, 업 벡터를 계산 앞과 위로 트랜스폼을 구성한 뒤 쿼터니언으로 변환해서 저장 }
간단할 것처럼 보이는… 4. 위 방향 계산 void LookAtConstraint::Process(/* 생략 */) { [월드 공간]→[부모 공간] 변환의 트랜스폼 T를 계산 자신의 위치를 T를 사용해서 부모 공간으로 변환 쳐다보기 타겟의 위치를 가중치 합산 T를 사용, 부모의 로컬 공간으로 이동시켜서 쳐다볼 방향을 계산 위쪽 방향 타겟을 T를 사용, 업 벡터를 계산 앞과 위로 트랜스폼을 구성한 뒤 쿼터니언으로 변환해서 저장 }
3DS MAX의 업 노드 옵션이 (쓸데없이) 다양하기 때문에 신경 쓸 것이 많다
앞과 위를 구했으니 옆은 외적으로 간단히 계산할 수 있을 거고, 5. 회전으로 만들면 끝? void LookAtConstraint::Process(/* 생략 */) { [월드 공간]→[부모 공간] 변환의 트랜스폼 T를 계산 자신의 위치를 T를 사용해서 부모 공간으로 변환 쳐다보기 타겟의 위치를 가중치 합산 T를 사용, 부모의 로컬 공간으로 이동시켜서 쳐다볼 방향을 계산 위쪽 방향 타겟을 T를 사용, 업 벡터를 계산 앞과 위로 트랜스폼을 구성한 뒤 쿼터니언으로 변환해서 저장 }
이 정도면 다 된 것 같은데 롤 아웃에 아직도 남아있는 뭔가 수상한 옵션들은? 50
Keep Initial Offset 옵션은 쳐다보기 계산 결과와 초기의 어긋남을 보존 LookAtConstraint가 걸려 있는 본
Keep Initial Offset 옵션을 포함하는 최종 슈도 코드 void LookAtConstraint::Preprocess() { keep initial offset이 켜진 경우, 룩 앳 컨스트레인트의 계산 결과와 바인드 포즈의 차이를 [회전 옵셋]으로 보존 } void LookAtConstraint::Process(/* 생략 /) { / 전략 */ keep initial offset이 켜진 경우, 계산 결과에 [회전 옵셋]을 더한다 앞과 위로 트랜스폼을 구성한 뒤 쿼터니언으로 변환해서 저장 }
OrientationConstraint, 본이 컨스트레인트 타겟들의 회전의 평균을 취한다
할아버지의 회전에 따라서 온 가족이 영향을 받는 것을 알 수 있다 가족 모델로서 핵가족의 장단에 대해서 고민해봐야 하는 시점이 아닐까 <어른의 인형 놀이> 서플먼트 무비 M2 PSM, 한상원
룩앳보다 어떤 의미에서는 제일 간단한 컨트롤러? void OrientationConstraint::Process(/* 생략 */) { 컨스트레인트 타겟의 로컬 회전 리스트를 얻는다 가중치 합산하여 계산하고 기록한다 }|
월드 공간 오리엔테이션 블렌딩 모드가 있기 때문에 그럴 리가 없다… void OrientationConstraint::Preprocess() { keep initial offset이 켜진 경우, 오리엔테이션 컨스트레인트의 계산 결과와 바인드 포즈의 차이를 [회전 옵셋]으로 보존해둔다 } void OrientationConstraint::Process(/* 생략 */) { if (로컬 공간 보간 모드) 컨스트레인트 타겟의 로컬 회전을 기록 else // 월드 공간 보간 모드 컨스트레인트 타겟을 부모 본의 로컬 공간으로 옮겨서 기록 가중치 합산하여 회전을 계산한다 keep initial offset이 켜진 경우, 계산 결과에 [회전 옵셋]을 더한다 계산 결과를 저장 }
일단 귀찮지만 LookAtConstraint와 옵셋 보존 계산은 동일 void OrientationConstraint::Preprocess() { keep initial offset이 켜진 경우, 오리엔테이션 컨스트레인트의 계산 결과와 바인드 포즈의 차이를 [회전 옵셋]으로 보존해둔다 } void OrientationConstraint::Process(/* 생략 */) { if (로컬 공간 보간 모드) 컨스트레인트 타겟의 로컬 회전을 기록 else // 월드 공간 보간 모드 컨스트레인트 타겟을 부모 본의 로컬 공간으로 옮겨서 기록 가중치 합산하여 회전을 계산한다 keep initial offset이 켜진 경우, 계산 결과에 [회전 옵셋]을 더한다 계산 결과를 저장 }
프로그래머의 기대를 여지없이 배반해버리는 트랜스폼 규칙 void OrientationConstraint::Preprocess() { keep initial offset이 켜진 경우, 오리엔테이션 컨스트레인트의 계산 결과와 바인드 포즈의 차이를 [회전 옵셋]으로 보존해둔다 } void OrientationConstraint::Process(/* 생략 */) { if (로컬 공간 보간 모드) 컨스트레인트 타겟의 로컬 회전을 기록 else // 월드 공간 보간 모드 컨스트레인트 타겟을 부모 본의 로컬 공간으로 옮겨서 기록 가중치 합산하여 회전을 계산한다 keep initial offset이 켜진 경우, 계산 결과에 [회전 옵셋]을 더한다 계산 결과를 저장 } 60
계층 구조가 서로 무관한 본의 회전을 블렌딩하기 위해서 필요 ‘보이는 대로’ 블렌딩 로컬+15도 회전 (최종 30도) 자식 부모 Local→Local인 경우 (15 + 15) / 2 = 15도 World→World인 경우 (15 + 30) / 2 = 22.5도, World→World로 OrientationConstraint 가 걸려있는 본 로컬+15도 회전
*ReactionManager의 기본적인 개념은 입력→그래프→출력 때려주고 싶은 마음이 가슴 깊은 곳부터 샘솟아 오르는 비 직관적인 UI
*ReactionManager 구현의 어려운 점은… 입력의 종류가 많다 Local Rotation X/Y/Z World Rotation X/Y/Z Local Position X/Y/Z World Position X/Y/Z Distance
핵심적인 기능은 float→그래프→출력이므로 먼저 입력을 추상화 DistanceEvaluator PositionEvaluator RotationEvaluator
LocalPosition X/Y/Z, WorldPosition X/Y/Z를 처리하는 PositionEvaluator const float PositionEvaluator::Process(/* 생략 */) { if (로컬 공간 값을 요구) if (부모를 기준으로) return 로컬 트랜슬레이션[지정된 채널] else if (레퍼런스 본을 기준으로) 레퍼런스 본 트랜스폼 공간으로 변환 return 변환된 결과값[지정된 채널] else // 레퍼런스가 undefined == 월드 기준 return 월드 트랜슬레이션[지정된 채널] else return 월드 트랜슬레이션[지정된 채널] }
로컬/월드라고 하면 간단할 것 같은데 특이한 부분? const float PositionEvaluator::Process(/* 생략 */) { if (로컬 공간 값을 요구) if (부모를 기준으로) return 로컬 트랜슬레이션[지정된 채널] else if (레퍼런스 본을 기준으로) 레퍼런스 본 트랜스폼 공간으로 변환 return 변환된 결과값[지정된 채널] else // 레퍼런스가 undefined == 월드 기준 return 월드 트랜슬레이션[지정된 채널] else return 월드 트랜슬레이션[지정된 채널] }
프로그래머가 상상하기 어려운 동작을 요구하는 헬퍼 본 인터페이스
LocalRotation X/Y/Z, WorldRotation X/Y/Z를 처리하는 RotationEvaluator const float RotationEvaluator::Process(/* 생략 */) { if (로컬 공간 값을 요구) if (부모를 기준으로) return 로컬 회전값[지정된 채널] else if (레퍼런스 본을 기준으로) 레퍼런스 본 트랜스폼 공간으로 변환 return 변환된 회전값[지정된 채널] else // 레퍼런스가 undefined == 월드 기준 return 월드 회전값[지정된 채널] else return 월드 회전값[지정된 채널] }
PositionEvaluator와 동일하지만… 쿼터니언→오일러 XYZ 70 쿼터니언 → 매트릭스 변환 식과 매트릭스 → 오일러 XYZ 분해를 결합해서 유도 가능
Distance를 처리하는 DistanceEvaluator const float DistanceEvaluator::Process(/* 생략 */) { if (레퍼런스 본이 유효) return 기준 본과 레퍼런스 본의 거리 else return 기준 본과 월드 원점의 거리 }
마스터 입력 이후의 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 (컨트롤러가 있다면) 컨트롤러를 계산한다 }
끝
…
(계산을)
컨트롤러들도 항상 부모에서 자식 순으로 계산된다고 보장할 수 없다 참조 본의 계산 순서? 0 1 8 2 3 5 4 6 9 7 11 10 12 13 14
따라서 안전한 결과를 보장하는 계산 순서를 알아낼 필요가 있다 어떻게 계산할 것인가?
좋은 방법이 떠오르지 않으니 일단… 개별 컨트롤러가 계산? void PositionConstraint::Process(/* 생략 */) { [월드 공간]→[부모 공간] 변환의 트랜스폼 T를 계산 위치 컨스트레인트 타겟 위치를 가중치 합산 T를 이용, 합산 결과를 부모의 로컬 공간으로 이동 keep initial offset이 켜진 경우, 계산 결과에 [옵셋]을 더한다 계산된 결과를 저장 } void PositionConstraint::GetDependancy(vector<int>& dependancies) { dependancies에 위치 컨스트레인트 타겟들을 추가한다 } 90
이 방법이 그렇게 쉽지가 않다 구현에 따라서 복잡 void LookAtConstraint::Process(/* 생략 */) { [월드 공간]→[부모 공간] 변환의 트랜스폼 T를 계산 자신의 위치를 T를 사용해서 부모 공간으로 변환 쳐다보기 타겟의 위치를 가중치 합산 T를 사용, 부모의 로컬 공간으로 이동시켜서 쳐다볼 방향을 계산 위쪽 방향 타겟을 T를 사용, 업 벡터를 계산 앞과 위로 트랜스폼을 구성한 뒤 쿼터니언으로 변환해서 저장 } void LookAtConstraint::GetDependancy(vector<int>& dependancies) { dependancies에 쳐다보기 타겟들을 추가한다 dependancies에 업 노드를 추가한다 }
컨트롤러 타입에 따라서 점점 더 복잡해지고 ReactionController? const ReactorResult ReactionControllerBase::Process(/* 생략 */) { 정렬된 마스터/슬레이브 리액션 리스트에서 주어진 마스터 값을 넘지 않으면서 가장 큰 마스터/슬레이브 인덱스를 찾는다 찾아낸 리액션과 다음 리액션을 보간하여 반환한다 } void ReactionControllerBase::GetDependancy(vector<int>& dependancies) { foreach (마스터 값 m에 대해서) m.GetDependancy(dependancies); } void IReactorExprIDHandler::GetDependancy(vector<int>& dependancies) { 익스포즈 노드를 dependancies에 추가한다 레퍼런스 노드를 dependancies에 추가한다 }
감당해야 할 필요가 없는 복잡한 작업을 감당해야 하는 상황에 이른다 수식에서는…??? class ReactorExpressionBinary { void GetDependancy(std::vector<int>& }; class ReactorExpressionID { void GetDependancy(std::vector<int>& }; class ReactorExpressionFunction { void GetDependancy(std::vector<int>& }; class ReactorExpressionConstant { void GetDependancy(std::vector<int>& }; class ReactorExpressionList { void GetDependancy(std::vector<int>& }; class ReactorExpressionFunction { void GetDependancy(std::vector<int>& }; dependancies); dependancies); dependancies); dependancies); dependancies); dependancies);
타이핑도 많아지고 근본적으로 실수하기가 쉽다 저절로 계산할 수 없나?
더미 연산을 통해 리액터가 트랜스폼 데이터를 요구하는 것을 가로채자 후킹을 통한 접근 PositionConstraint LookAtConstraint OrientationConstraint PositionReactionController RotationReactionController ScaleReactionConstraint FloatWireConstraint IReactorPoseSource GetWorldTranslation(int boneIndex) GetWorldRotation(int boneIndex) GetWorldScale(int boneIndex) GetLocalTranslation(int boneIndex) GetLocalRotation(int boneIndex) GetLocalScale(int boneIndex) GetWorldTransform(int boneIndex) …
0~10번까지 트랜슬레이션, 회전, 스케일을 순서대로 순회한 결과 PositionConstraint 9, 10 OrientationConstraint 12 ScaleXYZ bone11 public IReactorPoseSource PositionXYZ LookAtConstraint 24 ScaleXYZ bone12 ReactorTraversalBuilder : … 10
PositionConstraint 9, 10 OrientationConstraint 12 ScaleXYZ bone11 public IReactorPoseSource PositionXYZ LookAtConstraint 24 ScaleXYZ bone12 ReactorTraversalBuilder : … 10
PositionConstraint 9, 10 OrientationConstraint 12 ScaleXYZ bone11 public IReactorPoseSource PositionXYZ LookAtConstraint 24 ScaleXYZ bone12 100 ReactorTraversalBuilder : … 10
PositionConstraint 9, 10 OrientationConstraint 12 ScaleXYZ bone11 public IReactorPoseSource PositionXYZ LookAtConstraint 24 ScaleXYZ bone12 ReactorTraversalBuilder : … 10 24
PositionConstraint 9, 10 OrientationConstraint 12 ScaleXYZ bone11 public IReactorPoseSource PositionXYZ LookAtConstraint 24 ScaleXYZ bone12 ReactorTraversalBuilder : … 10 24 12
PositionConstraint 9, 10 OrientationConstraint 12 ScaleXYZ bone11 public IReactorPoseSource PositionXYZ LookAtConstraint 24 ScaleXYZ bone12 ReactorTraversalBuilder : … 10 24 12 11
자동으로 계산 순서를 구축하기 때문에, 기능을 확장하더라도 안전, 정확한 순서 보장
거의 대부분의 컨트롤러의 계산 과정에서 월드 트랜스폼을 요구 void OrientationConstraint::Preprocess() { keep initial offset이 켜진 경우, 오리엔테이션 컨스트레인트의 계산 결과와 바인드 포즈의 차이를 [회전 옵셋]으로 보존해둔다 } void OrientationConstraint::Process(/* 생략 */) { if (로컬 공간 보간 모드) 컨스트레인트 타겟의 로컬 회전을 기록 else // 월드 공간 보간 모드 컨스트레인트 타겟을 부모 본의 로컬 공간으로 옮겨서 기록 가중치 합산하여 회전을 계산한다 keep initial offset이 켜진 경우, 계산 결과에 [회전 옵셋]을 더한다 계산 결과를 저장 }
문제는 컨트롤러 계산 결과가 적용되는 과정에서 서브 트리가 무효화
본 수가 무지막지하게 많기 때문에 모든 월드 트랜스폼을 업데이트하는 것은 치명적 성능 문제의 원인 110
최소한으로 월드 트랜스폼을 재계산하기 위해서 조상/후손 리스트 관리 0 0 234567 01 34 012 3 1 2 3 4 5 6 7 8 9 10 11 12 13 14 1 8 2 5 4 6 0 9 10 11 12 13 14 9 7 10 12 11 13 08 13 14 14 0 8 12
특정 본이 재설정되면 후손 리스트의 월드 트랜스폼만 무효화한다 최소 범위 무효화 0 0 234567 01 34 012 3 1 2 3 4 5 6 7 8 9 10 11 12 13 14 1 8 2 5 4 6 0 9 10 11 12 13 14 9 7 10 12 11 13 08 13 14 14 0 8 12
특정 본의 월드 트랜스폼이 필요하면 조상 리스트만 검색한다 최소 범위 재계산 0 0 234567 01 34 012 3 1 2 3 4 5 6 7 8 9 10 11 12 13 14 1 8 2 5 4 6 0 9 10 11 12 13 14 9 7 10 12 11 13 08 13 14 14 0 8 12
메모리 상에서 캐시 관리 문제로 기대보다는 성능 향상이 낮지만 전체 재계산 회피 가능
거의 대부분의 컨트롤러의 계산 과정에서 부모의 역트랜스폼 요구 void OrientationConstraint::Preprocess() { keep initial offset이 켜진 경우, 오리엔테이션 컨스트레인트의 계산 결과와 바인드 포즈의 차이를 [회전 옵셋]으로 보존해둔다 } void OrientationConstraint::Process(/* 생략 */) { if (로컬 공간 보간 모드) 컨스트레인트 타겟의 로컬 회전을 기록 else // 월드 공간 보간 모드 컨스트레인트 타겟을 부모 본의 로컬 공간으로 옮겨서 기록 가중치 합산하여 회전을 계산한다 keep initial offset이 켜진 경우, 계산 결과에 [회전 옵셋]을 더한다 계산 결과를 저장 }
또한 많은 회전 컨트롤러의 계산 결과로 트랜스폼 → SRT 요구 void LookAtConstraint::Process(/* 생략 */) { [월드 공간]→[부모 공간] 변환의 트랜스폼 T를 계산 자신의 위치를 T를 사용해서 부모 공간으로 변환 쳐다보기 타겟의 위치를 가중치 합산 T를 사용, 부모의 로컬 공간으로 이동시켜서 쳐다볼 방향을 계산 위쪽 방향 타겟을 T를 사용, 업 벡터를 계산 앞과 위로 트랜스폼을 구성한 뒤 쿼터니언으로 변환해서 저장 }
매트릭스의 역을 구하는 연산과 SRT (스케일/회전/트랜슬레이션) 분해 두 연산 모두 비싸다 함수 길이만으로도 쌀 수가 없는 인버스 트랜스폼 PolarDecompose와 SpectralDecompose의 비싼 두 함수를 거치는 SRT 분해
연산이 복잡해지는 근본적인 원인은 스케일
T R (스케일이 없으면) 120
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 물리 시뮬레이션 등, 절차적 애니메이션에 대응이 자유롭다 전체적인 애니메이션 파이프라인의 유연성이 증대된다 기계나 갑옷 등의 움직임을 묘사하는데 매우 유리하다 cons MMORPG에서 대량의 캐릭터에 사용하기엔 성능 부담이 있다 모델러 혹은 애니메이터가 활용하기 위해 기반 지식이 많이 필요하다 LOD를 고려하면 스키닝이나 프레임워크 설계가 까다롭다
pros 물리 시뮬레이션 등, 절차적 애니메이션에 대응이 자유롭다 전체적인 애니메이션 파이프라인의 유연성이 증대된다 표현 영역을 확장하는 측면에서cons 접근 기계나 갑옷 등의 움직임을 묘사하는데 매우 유리하다 MMORPG에서 대량의 캐릭터에 사용하기엔 성능 부담이 있다 모델러 혹은 애니메이터가 활용하기 위해 기반 지식이 많이 필요하다 LOD를 고려하면 스키닝이나 프레임워크 설계가 까다롭다
절 차 적 리 깅 개 념 소 개 3DS MAX 절차적 리깅 기본 개념 각 컨트롤러의 동작과 구현 포지션 컨스트레인트 | 룩앳 컨스트레인트 | 오리엔테이션 컨스트레인트 리액션 컨트롤러 | 수식 컨트롤러 & 플롯 와이어 | XYZ & 리스트 시리즈 디펜던시와 계산 순서 문제 최 적 화 관 련 이 슈 월드 트랜스폼 문제 | 스케일을 가진 트랜스폼 문제 | 실수 계산 성능 데모 퍼포먼스 및 장단점 분석, 결론 Ⓒ 2008-2009 NEXON Corporation & devCAT Studio. All Rights Reserved M2 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 14
실시간 절차적 리깅 기술은 기술의 발전의 귀결 캐릭터 표현의 복잡화 → 실시간 절차적 리깅 절차적 애니메이션
3DS MAX의 절차적 리깅의 복제는 비교적 쉽다
미리미리 준비하여 선진조국 이룩하자
절 차 적 리 깅 개 념 소 개 3DS MAX 절차적 리깅 기본 개념 각 컨트롤러의 동작과 구현 포지션 컨스트레인트 | 룩앳 컨스트레인트 | 오리엔테이션 컨스트레인트 리액션 컨트롤러 | 수식 컨트롤러 & 플롯 와이어 | XYZ & 리스트 시리즈 디펜던시와 계산 순서 문제 최 적 화 관 련 이 슈 월드 트랜스폼 문제 | 스케일을 가진 트랜스폼 문제 | 실수 계산 성능 QA? 데모 퍼포먼스 및 장단점 분석, 결론 Ⓒ 2008-2009 NEXON Corporation & devCAT Studio. All Rights Reserved M2 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
View M2 프로젝트의 절차적 리깅 시스템 on Notist.
Dismiss
리타게팅, IK, 랙돌 등, 절차적 애니메이션에 대응하기 위해서는 리깅에 사용하는 트위스트 본 등의 애니메이션을 베이킹하는 게 아니라 실시간으로 계산할 필요가 있습니다. 3DS MAX에서 리깅에 자주 사용하는 컨트롤러들을 복제 구현하는 방식으로 이 문제에 대응하는 방법을 소개합니다.