치킨 날다

Matrix(행렬)

Row(행)과 Column(열)로 이루어진 실수들의 사각 배열.

Row와 Column의 갯수에 따라 m×n Matrix라고 부른다.

이 때, m×n은 Matrix의 Dimension(차원)이라 부른다.

Square Matrix(정방 행렬)

Row와 Column의 수가 같은 Matrix.

Inverse Matrix(역행렬)이 존재한다.

Entry(성분)

Matrix를 구성하는 각각의 수들을 지칭. Element(원소)라고도 한다.

Matrix의 Entry를 지칭 할 때는 Matrix 이름에 아래첨자로 Column과 Row의 번호를 지정한다.

Row Vector(행 백터)
Matrix의 Column이 하나인 Matrix.

Vector라 부르는 이유는 이런 Matrix는 주로 Vector를 표현할 때 사용되기 때문이다.

반대로 Row가 하나인 Matrix는 Column Vector(열 벡터)라고 부른다.

이러한 Row/Column Vector를 지칭할 때는 아래첨자 하나만 사용한다.

간혹 Matrix의 Column이나 Row를 Vector로 간주하는 경우가 있다.

이 때 각 Row Vector나 Column Vector를 지칭 할 때는 Column 번호나 Row 번호를 지칭 할 수 없다.

때문에 이 때는 '*'를 적어준다.

Matrix의 연산

기본적으로 Matrix간의 연산은 두 Matrix의 Column과 Row 수가 동일해야 한다.

Matrix간의 연산(=, +, -)는 같은 Element끼리 연산하기 때문이다.

Matrix와 Scalar간의 연산은 모든 Element에 동일하게 적용된다.

Matrix에 적용되는 연산법칙

• 덧셈의 교환법칙
• 덧셈의 결합법칙
• Matrix에 대한 스칼라 값의 분배법칙
• 스칼라들에 대한 Matrix의 분배법칙

Matrix간의 곱셈

두 Matrix A(m × n)와 B(n × p)가 있을 때, 이 두 Matrix의 곱은 AB로 정의된다.

Matrix AB를 C라고 정의 했을 때, C는 m × p Matrix이고,

이의 ij번째 성분은 Matrix A의 i번째 Row Vector와 B의 j번째 Column Vector의 Inner Production을 한 결과이다.

따라서 Matrix들 간에 곱 연산이 성립하기 위해서는 Matrix A의 Row 수와 Matrix B의 Column 수가 일치해야 한다.

다른 말로, A의 Row Vector의 Dimension과 B의 Column Vector의 Dimension이 일치해야 한다.

이 둘이 일치하지 않으면 두 Vector간의 Inner Production이 성립하지 않는다.

다음 Vector와 Matrix의 곱 연산을 보자.

uA가 1 × 3 Row Vector로 평가됨을 주목하며 다음 연산을 보자.

따라서

이 관계가 성립한다.

이는 Linear Combination(선형 결합)의 한 예로,

Vector·Matrix 연산인 uA가 Matrix A의 Row들의 Linear Combination에

Vector u에서 비롯된 Scalar x, y, z가 적용된 것임을 말해준다.

이는 어떤 1 × n Row Vector u와 n × m Matrix A 에해 항상 성립한다.

이 외에 Matrix간의 곱셈에서는 배분법칙과 결합법칙이 만족한다.

때문에 Matrix 곱 연산을 할 때에는 순서를 적절히 선택할 수 있다.

Transpose(전치)

Transpose Matrix는 주어진 Matrix의 행과 열을 맞바꾼 것을 말한다.

Transpose Matrix는 Matrix 이름에 윗첨자로 T를 붙인다.

Identity Matrix(단위행렬)

Main Diagonal Element(좌상에서 우하로의 주된 대각선에 있는 성분)이 모두 1이고,

나머지 Element들은 0인 Square Matrix.

Identity Matrix는 그 이름에서 알 수 있듯이 Matrix간의 곱셈에서 Identy Element(항등원) 역할을 한다.

때문에 Square Matrix와 Identy Matrix간의 곱셈은 교환법칙이 성립한다.

Determinant(행렬식)

Square Matrix를 받아서 실수 값을 산출하는 특별한 함수.

Square Matrix A의 determinant는 det A로 표기한다.

기하학적으로 2-Dimension Matrix의 Determinant는 넓이를, 3 Dimension Matrix의 Determinant는 부피를 나타낸다.

이를 이용해 Linear Transform 연산 하에 부피가 변하는 방식에 대한 정보를 제공함을 증명하는 것이 가능하다.

이에 대해서는 자세히 작성 된 링크로 대체한다.

https://twlab.tistory.com/44

또한 Determinant는 Cramer's rule(크라메의 법칙)을 이용해 1차 연립방정식을 푸는 데에도 사용된다.

Cramer's rule와 이를 이용한 1차 연립방정식을 푸는 방법 또한 링크로 대체한다.

https://twlab.tistory.com/43?category=668741

http://www.mesacc.edu/~scotz47781/mat150/notes/cramers_rule/Cramers_Rule_3_by_3_Notes.pdf

하지만 우리가 지금 Determinant를 보는 이유는 Inver Matrix를 구할 때 쓰이기 때문이다.

Determinant를 이용하면 다음 명제를 증명하는 것도 가능하다.

Square MAtrix A는 오직 detA ≠ 0일 때에만 Invertible 하다.

이 명제를 이용하면 주어진 Matrix가 Invertible 한지 쉽게 알 수 있다.

Matrix Minor(부분행렬, 소행렬)

Determinant를 설명하기 위해서는 Matrix Minor가 요구되므로 짚고 넘어가겠다.

n × n Matrix A가 주어졌을 때, 특정 번호의 Row와 Column을 삭제한 (n - 1) × (n - 1) Matrix를 말한다.

Determinant의 Definition

Determinant는 재귀적으로 정의된다.

예를 들어 4 × 4 Matrix의 Determinant는 3 × 3 Matrix의 Determinant를 항으로 하여 정의된다.

3 × 3 Matrix의 Determinant는 2 × 2 Matrix의 Determinant로,

2 × 2 Matrix의 Determinant는 1 × 1 Matrix의 Determinant로 정의된다.

(1 × 1 Matrix의 Determinant는 그 Element의 값과 동일하다.)

n × n Matrix의 Determinant는 다음과 같이 정의된다.

Adjoint Matrix(딸림행렬, 수반행렬)

이를 설명하기 위해서는 몇가지 선행 정의가 필요하다.

n × n Matrix A에 대해, 각 Element들은 Cofactor(여인수)가 존재한다.

이 때 Matrix A의 각 Element들을 Cofactor로 대체 해서 만든 Matrix를 A의 Cofactor Matrix(여인수행렬)이라 부른다.

Adjoint Matrix는 이 Cofactor Matrix의 Tranpose Matrix이다.

뒤에 나오지만, Adjoint Matrix를 이용하면 Inverse Matrix를 구하는 공식을 구할 수 있다.

Inverse Matrix(역행렬)

Matrix간에는 나눗셈 연산은 없지만, Inverse에 대한 정의는 존재한다.

1. 오직 Square Matrix만이 Inverse Matrix를 가진다.
   때문에 Inverse Matrix를 논의 할 때는 항상 Square Matrix라는 가정이 깔려 있다.
2. n × n Matrix M의 Inverse Matrix 역시 n × n 이며, Matrix 이름에 윗첨자로 -1을 적어서 표기한다.
3. 모든 Square Matrix에 Inverse Matrix가 존재하는 것은 아니다.
   Inverse Matrix가 존재하는 Matrix를 가르켜 Invertible Matrix(가역행렬)이라 부른다.
   반대로 Inverse Matrix가 존재하지 않으면 Singular Matrix(특이행렬)이라 부른다.
4. Inverse Matrix가 존재할 경우, 그 Inverse Matrix는 고유하다.
5. 어떤 Matrix M과 그의 Inverse Matrix를 곱하면 Identity Matrix가 나온다.
   이 연산은 교환법칙이 성립한다.

Inverse Matrix는 Matrix Equation을 풀 때 유용하다.

Inverse Matrix는 Adjoint Matrix와 Determinant로 구할 수 있다.

마지막으로 Matrix 곱 연산의 Inverse 에 대한 유용한 대수적 속성을 하나 소개하겠다.

오늘은 Climb 상태 해제를 모든 조건에서 적용하고, 3개의 Trigger에 대한 Climb 상태 변화를 적용하였습니다.

우선 Climb 상태에서 다시 한번 상호작용을 하여 Climb 상태에서 벗어나는 작업은

동시에 처리해줘야 하는 Parameter 중 한가지가 누락되어 작동하지 않았습니다.

이를 적용해주자, 정상적으로 해결되었습니다.

이를 두어번 테스트 하는 도중, 공중에 떠있는 Climb를 오를 때 정상적으로 작동하지 않는 것을 확인했습니다.

이벤트 함수에서 문제가 발생하는거라 debug point가 정상작동하지 않아 log에 의지해서 debug 해야 했습니다.

꽤 오랜 시간이 걸렸지만, 알아본 결과 Interaction Key Released Event 부분에서 임시로 넣어 둔

Parameter 해제 코드가 문제였습니다.

또한 이를 해결하더라도 3개의 Trigger가 공유하는 Critical Section이 있어 같은 문제가 다시 발생할 여지가 있었습니다.

그래서 Parameter 해제 코드를 제거하고, Trigger가 공유하는 Parameter가 정확한 상황에서 바뀌도록 개선했습니다.

세번째로 각 Trigger의 Start/End Overlap, On Interaction Pressed 이벤트에 분포되어 있던 Climb 관련 기능들에

Trigger Parameter 값에 따른 상태 변화를 적용하였습니다.

이를 통해 Character가 Climb중 점프를 하거나, 재 상호작용을 통해서 Climb 상태를 해제하는 것뿐만 아니라

Climb의 정상이나 바닥에 닿았을 때에도 자동으로 Climb 상태가 해제되도록 하였습니다.

이후 이 부분에 적절한 Animation이 재생되면서, Character의 중심이 이동하면 완벽한 Climb 기능이 완성됩니다.

마지막으로 AnimInstance와 Character간의 Parameter Synchronize를 개선했습니다.
이전에는 Character에 각 Parameter별로 get 함수를 두고 있었습니다.

하지만 구조상 AnimInstance 내에서 Character 객체를 가지면서 어쩔수 없이 Coupling이 발생합니다.

때문에 반드시 Character 객체를 가지고 있기 때문에 Character 내부에 public으로 Synchronize 함수를 두었습니다.

공유해야 할 Parameter들이 많아 Category별로 3개의 함수로 분리하였습니다.

이 외에 구현중이거나, 발견한 버그들도 있었습니다.

첫번째. Puzzle에서 버그가 발생했습니다.

Attach Puzzle에서 Interaction을 할 때, 범위와 관계없이 가장 마지막에 Interaction한 Object가 반응합니다.

또한 Key를 Submit 할 때 Attach 위치가 원하는대로 되지 않고 있습니다.

Break Puzzle에서는 주먹을 휘두르는 걸로 파괴가 되지 않고 직접 부딛쳐야 파괴가 됩니다.

두번째. Multiplay 상에서 문제가 발생했습니다.

우선 Character의 Interaction, Melee Attack 애니메이션이 재생되지 않습니다.

변수명을 바꾸었는데 그 때문인지, 더 큰 문제가 있는지 확신이 없습니다.

다만 이 때문에 Break Puzzle에서 주먹이 나가지 않는 문제가 발생한 것 같습니다.

Climb에서도 문제가 발생했습니다.

Host가 Climb 할 때에는 테스트 할때와 같이 정상적으로 움직이는 반면,

Client가 Climb 할 때에는 가만히 멈춰있습니다.

Parameter 중 몇가지가 Replicated 안될 때 비슷한 현상이 있던 걸로 기억하는데,

만약 이게 아니라면 Climb 부분 기능을 다 뜯어 고치는 불상사가 발생할 것 같습니다.

개인적으로 Climb 기능을 금주 내에 구현하여 영상을 찍고,

이를 포트폴리오에 담아 일요일까지 마감인 회사 지원서에 포함하려 했습니다.

하지만 남은 일정으로 보아 하루 이틀 더 무리해서 하지 않는 한 시간 안에 마무리하지 못할 것 같습니다.

그래서 토요일에는 우선 Animation 문제부터 해결하여 기존에 구현했던 기능들에 대한 문제부터 해결하고,

Climb 부분은 그 뒤에 구현할 예정입니다.

그리고 일요일에도 쉬는 날 없이 개발을 하여 최대한 Climb 기능을 시연 가능할 정도로 구현해볼 예정입니다.

제출 날짜가 정확히 21일까지니, 토요일에 Animation 버그를 수정하여 최소한의 영상들을 촬영.

일요일에 자기소개서를 정리하고 남은 시간은 Climb 기능 구현에 투자하여 20일까지 최대한 개발을 해볼 생각입니다.

그리고 20일에 구현이 된다면, 영상을 촬영하고 그대로 제출. 

그렇지 못한다면 그대로 제출을 할 생각입니다.

오늘은 Climb 상태에서 이동 Climb 상태 해제 부분을 구현하였습니다.

이 부분도 알아본 결과 굉장히 사소한 실수로 인해 구현에 실패를 한 것이었습니다.

Climb 상태를 판단하는데에는 4가지 트리거가 요구됩니다.

MovementComponent 안의 MovementMode.

Character 안에 IdleType, MovementType, InteractionType.

MovementMode는 현재 Character의 이동이 어떤 이동인지를 내부적으로 판단합니다.

IdleType은 현재 Character가 어느 이동이 가능한 상태인지 외부적으로 판단합니다.

MovementType은 Character가 이동 중임과 어느 상태에서 이동중인지 판단합니다.

InteractionType은 이동과 관계가 있지는 않고 상호작용 종류와 상태와 관계 있지만,

Climb 상태가 상호작용으로 이루어지므로 반드시  필요합니다.

Clmib 상태 판단이 안되던 것은 이 중 IdleType 값을 바꿔주지 않아서였습니다.

이를 적용해주자, 이동과 관련된 모든 문제가 말끔히 해결되었습니다.

그리고 나서 한 작업은 Climb 상태 해제입니다.

Climb 상태 해제는 두가지 조건이 있습니다.

Climb 중 점프를 하는 것과 상호작용을 하는 것.

이 두가지를 모두 구현하였으나, 이 중 재 상호작용 부분은 정상적으로 작동하지 않았습니다.

내일은 이 재 상호작용을 통한 Climb 상태 해제를 구현하고,

Climb 속도 조절과 중력 상태 해제를 통해 정지 시 가만히 멈춰있도록 구현할 예정입니다.

Animation 부분은 쉽게 구현이 되나, Exit이나 Ledge 부분에서 자동으로 Character가

올라가는 부분 구현 방법을 아직 몰라 조금 시간이 오래 걸릴 것 같아 이 뒤에 구현 할 예정입니다.

https://www.acmicpc.net/contest/view/116

오늘은 저번 주에 풀던 [꿍의 여친 만들기] 문제를 해결하고, [Virus] 문제를 시도했습니다.

[꿍의 여친 만들기]는 여성의 이상형 리스트를 받아 그 중 가장 성취하기 쉬운 매력도에 대한 cost를 구하는 문제입니다.

풀이 자체는 어렵지 않습니다.

이상형들 중 가장 얻기 힘든 매력의 cost들을 비교하여 가장 낮은 것을 출력하면 됩니다.

하지만 입력받은 data를 가공하는 작업이 다른 문제들에 비해 난이도나 양이 조금 높았습니다.

그 부분에서 저번 주에 문제가 있었고, 이번주에도 많은 시간을 낭비하였습니다.

또한 StringStream 초기화 부분에서 문제가 발생하기도 했습니다.

여러 객체를 생성하지 않고 하나의 StringStream 객체를 생성해서 사용하는데, 

StringStream 객체를 clear 하거나 flush 해도 안의 내용이 남아 있었습니다.

이에 대해 해결 방안을 찾다가 다음 블로그에서 해답을 찾았습니다,

http://egloos.zum.com/mcchae/v/11130705

"Clear 함수는 안의 내용을 실질적으로 지우지 않고 rdbuf라는 플래그만 0으로 초기화 한다"는 내용입니다.

이를 해결하기 위해서는 stringstream 안에 담긴 string을 blank string으로 덮어씌워주고,

rdbuf를 초기화 하여 앞에서부터 다시 담을 수 있도록 해야합니다.

오늘 해결하다가 만 [Virus]는 생화학폭탄의 폭파까지 걸리는 시간을 출력하는 문제입니다.

폭탄 안에는 N개의 바이러스가 있고, 각 바이러스는 N개 미만의 바이러스와 1개의 성분을 생성하며 자가분해합니다.

이 중 중성자(정확히는 삼중수소)의 갯수가 한도를 넘어가면 폭탄이 폭파합니다.

이 문제는 입력 받은 데이터를 정리하고, 대략적인 문제 푸는 방식을 세우는 것까지 완료하였습니다.

주어진 바이러스 공식을 하나씩 적용하면서 조건을 맞춰보면 될 것으로 예상합니다.

몇가지 걱정거리가 있다면, 입력된 바이러스의 변이가 일관적이지 못해 한번 정리를 해야 한다는 점.

바이러스 중 발생하지 않는 바이러스가 존재 할 수 있다는 점.

순환 발생 체크나 폭탄이 폭파하지 않는 조건 판단 등.

그리고 영어 문제라서 문제 해석이 느린 점도 앞으로의 개선 사항이라 생각합니다.

문제를 풀면서 독해 능력이 조금은 늘었으면 싶습니다.

오늘은 늦잠을 자기도 했고, 최근 체중 감량을 위해 운동 시간을 늘리기도 했고,

컨디션도 안좋아서 늦게까지 해서야 겨우 할당량을 채웠습니다.

오늘은 Interaction 상에서 Character가 Flying 상태로 움직이도록 해보았습니다.

하는 과정에서 하나의 함수로 처리 했던 Climb Trigger 초기화 함수와 각 Trigger에 대한 overlap 이벤트들이

각자 다른 작업을 해야 복잡하게 이루어져야 한다는 점을 깨달았습니다.

이전에 작성해놓았던 트리거 작동 방식을 보면 알 수 있었지만,
이전 코드를 지우면서 새 코드를 넣는 복잡한 과정에서 인지를 못한 것 같습니다.

그래서 이 부분을 각기 다른 코드들로 분리를 하고, 동작을 확인했습니다.

그리고 Interaction 상 Climb 상태로의 변화는 생각한 것은 구현 하였으나, 
의도한대로 움직이지 않았습니다.

좌우 이동을 막고, 전후 이동은 상하이동으로 해놓았으나 정상적으로 작동하지 않았습니다.

어쩌면 중력이 적용 했을수도 있고, 코드가 빌드가 꼬여서 적용이 안된 것일 수도 있을 것 같습니다.

좀 더 이 부분은 시도를 해봐야 할 것 같습니다.

번외로 오늘 몇몇 Customized Log Category를 수정 하였는데 코드가 문제 없이 잘 작동하였습니다.

그래서 위 작업을 마무리 하고 commit 한 뒤, Log Category 수정을 해보았습니다.

그 결과 정상적으로 작동을 하여, 뒤로 미루었던 작업 중 하나은 Log 정리를 완료하였습니다.

오늘은 Climb를 판단하는데 사용되는 3개의 Trigger의 Start/End Overlap 시 호출되는 함수의 내용물을 채워넣고,
이전 Climb 구현에서 사용 했던 불필요한 함수나 변수들을 일부 제거하였습니다.

처음에는 호출되는 함수에서 상호작용되는 Climb에 따라 MovementMode를 변경해 주었습니다.

하지만 테스트를 해보니, 사다리 근처에 닿기만 해도 사다리를 타는 모양세가 되었습니다.

그래서 MovementMode 값은 상호작용쪽에서 수정하도록 주석으로만 처리를 하고, 
Overlap 함수에서는 어떤 Climb와 상호작용이 가능한지 저장하는 변수와, ClimbTrigger만 영향을 받도록 하였습니다.

이 과정에서 3개로 분리되어 있던 Overlap 함수는 다시 하나로 합쳐졌고, 
기능을 테스트 한 뒤 이전에 Climb를 구현하다가 실패했을 때 사용했던 함수, 변수들을 삭제하였습니다.

그리고 Climb가 Rope, Ladder, Wall이 있었는데,
Wall은 Trap에서 MovementComponent 적용을 하면서 구현을 해두었습니다.

그러다보니 Wall은 THObjectBase 하위 클래스이고, Rope, Ladder는 THClimbBase의 하위 클래스로 구현되어 있습니다.

오늘 확인해본 결과 THWallBase와 THClimbBase이 구현상 충돌나는 부분이 없어
THWallBase를 THClimbBase의 하위 클래스로 변경하였습니다.

이를 통해 상호작용 가능한 Climb 값을 저장하는 것이 일관성 있어졌습니다.

월요일에는 상호작용 시 Climb가 가능한 상태로 만들려고 합니다.

아마 이동 자체를 하루만에 구현할수는 없겠지만, 등반 상태로의 변화와 해제는 구현할 것으로 예상합니다.

원래는 5월 말까지 느긋하게 구현하려 했으나, 최근 인턴쉽을 모집하는 회사가 있어 기한을 조금 당기려 합니다.

다음주 목요일까지 등반 기능을 구현한 뒤 조금 이르지만 기능 영상 촬영을 하고자 합니다.

그리고 이를 기반으로 포트폴리오를 개선하고, 지원서에 넣을 예정입니다.

책에서 제시하는 몇 가지 수학 개념들이 있다.

Vector, Matrix, Transform이 있는데 학교에서 흔히 접하는 내용들이기는 하나, 

용어적인 부분에서 낯설 수 있다.

때문에 여기서는 매우매우 기초적인 개념을 제외한 부분들을 용어 설명 위주로 풀어나가고자 한다.

Coordinate System(좌표계)

Left-handed Coordinate System(왼손 좌표계) - 왼손 엄지, 검지, 중지 손가락이 서로 수직이 되도록 폈을 때,
엄지 손가락이 X축, 검지 손가락이 Y축, 중지 손가락이 Z축을 가르킨다.

Right-Handed Coordinate System(오른손 좌표계) - 왼손 엄지, 검지, 중지 손가락이 서로 수직이 되도록 폈을 때, 
엄지 손가락이 X축, 검지 손가락이 Y축, 중지 손가락이 Z축을 가르킨다.

Unit Vector(단위 벡터) - 주어진 Vector를 크기(Magnitude)를 1로 맞춘 Vector.

Vector의 순수한 방향을 나타내는 용도로 사용된다.

반대로 Vector u의 크기를 나타낼 때는 ||u||라고 표시한다.

Normalization(정규화) - Vector를 Unit Vector로 만드는 작업.

Dot Product(= Inner Product, Scalar Product)(내적) - 동일한 차원에 존재하는 두 Vector의 성분들을 곱한 뒤 합산.
Dot Product 한 값은 두 Vector의 크기와 그 사이 각의 cos 값의 곱과 동일하다.

때문에 사이각을 구하는 데에 매우 유용하게 사용된다.

Orthogonal Projection(직교투영, 정사영) - 어떤 Vector에서 특정 Vector 성분을 분리하는 작업.

위 식에서, P는 Vector V에 대해 Vector n 성분. 즉, n과 같은 방향(Direction)을 가진 Vector를 나타낸 것이다.

이와 같이 Vector V에 대해서 Vector n에 대한 성분인 Vector P를 구하는 것을 Orthogonal Proejction이라 한다.

V에서 P를 뺀 나머지. 즉 P와 수직인 V의 성분은 Prep(Perpendicular[수직의])으로 표현한다.

Orthonomal(직교의) - 주어진 Vector들이 서로 수직인 상태를 가르킨다.

Orthonomal group(정규집교 집합) - 어떤 Vector group에 속한 모든 Vector들이 서로 Orthonomal한 상태.

흔히 볼 수 있는 Orthonomal group은 어떤 Vector를 X, Y, Z축에 대해 Orthogonal Projection 한 결과들의 집합이다.

Orthogonalization(직교화) - Orthonomal 하지 않은 Vector group을 Orthonomal group으로 만드는 과정.

Gram-Schmidt Orthogonalization(그람-슈미트 직교화) - n개의 Vector group을 Orthogonalization 하는 방법

Cross Product(=Outer Product)(외적) - 두 Vector에 대해서 모두 직교인 Vector를 구하는 작업.

이 연산은 두 개의 축을 알고 있을 때 나머지 하나의 축을 구하는데 매우 유용하다.

Cross Product는 연산한 Vector 순서에 따라 적용되는 Coordinate System의 방향을 따라 간다.

즉, Left-Handed라면 Cross Product 결과도 Left-Handed, Right-Handed라면 Product 결과 역시 Right-Handed이다.
2차원에서는 Cross Product가 존재하지 않는다.

하지만 유사 외적을 통해 어떤 Vector에 대한 수직 Vector를 구할 수는 있다.

Position Vector(위치 벡터) - 3차원 공간 안의 한 위치를 나타내는 Vector.
본 책에서는 Dot(점)과 Position Vector(위치 벡터)를 같은 의미로 사용한다.

Dot을 Position Vector로 사용했을 때 한 가지 부차적인 효과를 얻는다.

바로 Dot에 대해서는 의미가 없는 Vector 연산이 가능하다는 점이다.

예를 들어, p(dot) + v(vector) = q(vector)는 p+v라는 vector를 q로 표현한 것이기도 하지만,
p를 v만큼 옮겼을 때의 점의 위치 q이기도 하다.

현재 Visual Studio 2019 Community를 사용하고 있습니다.

제가 가지고 있는 [DirectX 11을 이용한 3D 게임 프로그래밍 입문] 책에서는 라이브러리를 따로 설치하고
.h, .lib 파일을 프로젝트 단위로 추가하는 복잡한 과정을 거치고 있습니다.

하지만 검색을 통해 알아본 결과, 상당히 편리하게 Template를 제공하는 것을 발견했습니다.

https://docs.microsoft.com/ko-kr/windows/uwp/gaming/user-interface

이를 기반으로 프로젝트 세팅 방식을 간단하게 정리하겠습니다.

저는 예전에 DirectX11 공부를 위해 생성한 프로젝트가 있어서 그것을 재사용 하였습니다.

이전에 만든 DirectX11 Template Project는 동작을 하지 않았습니다.

때문에 Project를 다 제거하였습니다.

위 화면은 Solution 우클릭 >> Add >> new Project를 한 화면입니다.

다양한 Template들이 제공되는데, 위에 Search for templates라고 적힌 검색창에서 DirectX를 검색해봅시다.

그럼 이렇게 3가지가 검색됩니다.

제가 하고자 하는 DirectX 12는 한가지 Template 밖에 없고, DirectX 11로는 일반 App과 XAML을 쓰는 App이 있습니다.

https://ko.wikipedia.org/wiki/XAML

위에 올린 template 관련 링크에서 XAML을 사용하면 조금 더 편리하지만 성능이 저하된다는 점.

그리고 DirectX 12에서는 XAML을 사용하는 template이 없다는 점으로 미루어 보아
사용하는 것에 크게 신경쓰지 않아도 될 것 같습니다.

DirectX 12 App (Universal Windows - C++/CX)를 선택해줍시다.

Project 이름을 작성하는 공간입니다.

원하는 이름을 작성합시다.

저는 예시로 만들어 본 프로젝트이니 ExampleCreation이라 이름 붙였습니다.

간혹 이렇게 책에 있는 예시를 따라 할 때마다 Solution째로 새로 만드는 사람이 있습니다.

저도 예전에는 그렇게 하였는데, Solution에는 여러 Project를 넣을 수 있습니다.

또한 Solution Properties >> Common Properties >> Startup Project에서 빌드 될 Project를 지정할 수 있습니다.

여기서 Current selection을 선택하면 현재 자신이 열고 있는 Project를 우선적으로 빌드 합니다.

이를 이용해 여러 개의 Project를 하나의 Solution으로 편리하게 관리할 수 있습니다.

책의 예시는 한 곳에서 모아놓고 보는 것이 편리한 면이 있기에 이 방법을 추천합니다.

다음은 Windows 지원 버전을 선택하는 것입니다.

실제 게임을 개발할 때에는 중요하지만, 우리는 연습문제나 예시코드를 작성할 것이니 대충 선택합시다.

이 부분이 DirectX12 Template로 생성한 Project에서 제공하는 기본 코드입니다.

이에 대해서는 나중에 코드 분석을 따로 할 예정입니다.

DirectX12 Template Project의 기본 결과물입니다.

무지개빛 Cube가 회전하고 있습니다.

제가 마지막으로 DirectX를 공부하려 했을 때가 1년하고 수개월도 더 전이었습니다.

그때는 이정도로 친절한 문서들이 없었는데, 요즘에는 정말 친절한 문서가 많은 것 같습니다.

그래도 영문 문서나 글로만 되어 있는 문서가 아니라 한글과 사진이 같이 있는 문서를 찾는 분들은 늘 존재해왔습니다.

그런 분들이 참고할 수 있도록 최대한 자세하게 작성해보도록 하겠습니다.

원래는 [DirectX 12을 이용한 3D 게임 프로그래밍 입문] 책을 구매한 뒤 그 내용을 정리할 생각이었습니다.

하지만 집에 [DirectX 11을 이용한 3D 게임 프로그래밍 입문] 책이 있기도 하고, 

제가 알기로는 책에 적힌 DirectX 예시코드나 프로젝트 세팅이 지금과 많이 차이가 나는 것으로 알고 있습니다.

그래서 이론적인 부분은 가지고 있는 책으로 정리를 하고, 예시 코드는 DirectX 12로 구현하고자 합니다.

간간히 코드 분석도 추가하여 그럭저럭 볼만한 보조자료 느낌으로 글을 작성하고자 합니다.

오늘도 대부분의 시간을 Overlap Event와의 씨름으로 보냈습니다.

결론을 적자면, 함수 길이 축소나 Event에 부착하는 위치는 전혀 문제가 해결되지 않았습니다.

하지만 의외의 부분에서 해결의 실마리를 찾았습니다.

이전에 Log Category Customize를 하면서 새로 정리할 Category들을 선언해두었습니다.

나중에 할 일을 줄이기 위해, 이 이후에 호출하는 Log는 모두 새로 만든 Category들을 쓰고 있습니다.

혹시 이 부분이 문제인가 싶어서 이를 예전에 선언한 Category로 선언을 하였더니, Crash가 났습니다.

빌드상에 문제가 있나 싶어 프로젝트 재생성을 한 뒤 빌드를 하였으나, 여전히 crash가 났습니다.

때문에 아예 함수를 새로 작성하고 Event에 함수를 부착하는 작업을 초기화 함수 내부로 옮겼더니 정상 작동하였습니다.

함수 내부 내용은 거의 변하지 않았습니다.

그저 새로 생성 했을 뿐인데....

마가 꼈다고 밖에 설명이 되지 않은 것 같습니다.

오늘은 이 문제 해결에 너무 많은 정신력을 쏟아부었습니다.

각 함수 내에 구현해야 할 부분은 다 메모했으니, 토요일에는 그 부분을 우선적으로 구현 할 것입니다.