Gyong

GameEngine에서 필수 코어 클래스란 GameObject, Resources 등을 말한다.

이 필수 코어 클래스를 관리하기 위해서는 해당되는 컨테이너를 선택해서 GameEngine의 구조를 구성해야 한다.

그 이유는 전체 게임 엔진 프로세스 중에 각각의 중요한 기능 호출에서 발생한

실제 동작(단일 항목 검색, 삽입/삭제, 트래버스)에 근거해야 한다.

먼저 엔진에서 모듈 구성과 순서는 다음과 같다.

여기서 엔진에서 렌더러 모듈로 데이터를 넘겨줘야 하는데 그것에 필요한 데이터는 무엇인가?

게임엔진에서 관리해야하는 데이터는 다음과 같다.

리소스 매니저에는 리소스, 리소스에는 데이터, 경로, 키, 타입이 존재한다.

(여기서 타입은 Mesh, Texture, Prefab을 의미한다.)

씬 매니저에는 게임 오브젝트, 게임 오브젝트에는 트랜스폼이 존재한다.

이 데이터들을 각각 어떤 컨테이너를 사용해서 구현을 해야 할지 생각해봐야 한다.

사용 할 컨테이너는 다음과 같다.

Map

Unordered_Map(Hash Map)

Vector

Map에서는 정렬은 빠르지만 속도는 느리다는 단점이 있고,

Unordered_Map에서는 속도는 빠르지만 정렬되지 않는다는 단점이 있다.

Vector는 메모리에 데이터가 순차적으로 저장되어있기 때문에 효율적으로 요소 조회가 가능하다.

• 씬 매니저와 리소스 매니저에서는 어떤 컨테이너를 사용해야 좋을까?

게임의 실행 구도를 살펴보면 씬로딩 -> 리소스 로딩 -> 렌더링처리 순으로 실행이 된다.

씬 매니저에서는 Vector를 사용해야 한다고 생각한다.

그 이유는

렌더링 처리를 하려면 처음부터 끝까지 다 돌아야 하기 때문에 성능 부분을 고려한다면

어쩔 수 없이 Vector를 사용해야 하기 때문이다. 

그렇다면 리소스 매니저는 어떤 컨테이너를 사용해야 좋을까?

어떤 게임 오브젝트가 있을 때 리소스에 대한 것은 리소스 매니저가 가지고 있다.

씬 매니저에서 Vector를 사용한다면 이 게임 오브젝트는 Vector로 관리가 되고 있기 때문에

처음부터 끝까지 순차적으로 로딩을 하게 된다.

순차적으로 로딩이 되는 과정에서 리소스 매니저는 리소스의 키값을 가지고 가서 빼오게 되는데,

이 부분에서는 따로 정렬이 될 필요가 없다고 생각해서 씬 매니저와 같이 Vector를 사용해야 한다고 생각한다.

왜냐하면 특정 아이템을 보여주는 것이 아닌 처음부터 끝까지 다 보여줘야 되는 것이기 때문이다.

따라서 리소스 매니저는 정렬이 의미가 없기 때문에 에디터 인터페이스까지 감안하면 Vector를 사용해야 좋지만,

만약 리소스를 검색하는 용도로만 사용을 하는 것이면 Unordered_Map이 더 좋다고 생각한다.

클래스와 구조체는 거의 동일한 구조와 기능을 가지고 있지만 접근 지정자 부분에서 다르다.

클래스의 경우는 접근제어 지시자를 따로 지정하지 않는 경우 private으로 선언이 되고,

구조체의 경우는 public으로 선언이 된다는 차이점이 있다.

접근 지시자의 경우 다음과 같이 세 가지가 존재한다.

public : 어디서든 접근이 가능

protected : 상속관계 일 때 접근이 가능

privatet : 클래스 내부에서만 접근이 가능

• 클래스가 아닌 구조체를 사용하는 이유는?

구조체는 값 타입이므로 클래스 사용 시 참조로 인한 시간과 비용적 낭비를 줄일 수 있다.

만약 클래스 내부에 값 타입만 담아서 사용을 하게 된다면 구조체를 사용하고,

그렇지 않다면 클래스를 사용하는 것이 좋다고 생각한다.

• Math Library에서 구조체를 사용하여 정의하는 이유는?

Math Library의 경우에도 값 타입으로만 만들어져 있기 때문에 위에서 설명한 것처럼 시간과 비용적 낭비를 줄이기 위해

구조체를 사용한다고 생각한다.

엔진에서 예로 들면 유니티나 언리얼 엔진 내의 Math Library에서도 구조체를 사용하고 있다.

• 유니티와 언리얼을 비교하자면 C#과 C++의 Struct의 차이점은 무엇인가?

C++에서는 클래스와 구조체는 거의 동일하다고 볼 수 있지만 C#에서는 용도 자체가 다르다.

C#의 구조체는 상속을 지원하지 않으며 명시적 기본생성자를 지원하지 않는다.

또 하나 다른 점으로는 기본 접근제어 지시자도 다르다.

C++에서 클래스의 기본 접근제어 지시자는 "private", 구조체는 "public" 으로 선언 되지만,

C#에서는 클래스와 구조체 둘 다 "private" 으로 선언된다.

C#에서 클래스는 항상 힙 영역에 생성이된다.

하지만 구조체는 항상 스택에 생성되는 것이 아니고 초기화를 해줘야 힙에 생성하게된다.

• Cohen-Sutherland Line Clipping Algorithm?
  
  이 알고리즘은 화면에 보이는 선이 화면 밖으로 나갔을 때 화면 밖의 선은 연산을 안하도록 막아줄 때
  사용하는 알고리즘으로 1967년에 개발이 되었다고 한다.

알고리즘은 다음 여부에 따라 행을 포함, 제외 또는 부분적으로 포함 된다.

• 두 끝 점이 모두 화면 영역에 있을 때
• 두 끝 점이 모두 보이지 않는 영역을 하나 이상 공유하므로 선이 보이는 영역을 넘어 가지 않는다.
• 두 끝 점은 서로 다른 지역에 있고, 이런 상황의 경우 알고리즘은 화면 영역 외부에 있는 두 지점 중 하나를 찾는다.
  그런 다음 바깥 점과 확장 된 화면 경계의 교차가 계산되고 이 새로운 점이 바깥 점을 대체하게 된다.

아래 그림의 숫자를 "아웃 코드"라고 한다.

라인의 두 지점 각각에 대해 아웃 코드가 계산이 되고, 아웃 코드는 2차원 클리핑을 위해 4bit, 또는 3차원인 경우에
6 비트를 가질 것이다. 점이 화면 밖에 있으면 첫 번째 bit는 1로 설정이된다.
2D 출력 코드의 비트는 상단, 하단, 오른쪽, 왼쪽을 나타낸다. 예를 들어,
아웃 코드 (1010)는 화면의 우측 상단을 가리킨다.

클리핑이 발생한 후 각 반복에서 끝 점에 대한 아웃 코드를 다시 계산 해야 한다.

그리고 Cohen–Sutherland 알고리즘은 직사각형 "클립 창"에서만 사용할 수 있다고 한다.

• 선은 두 개의 점으로 만들어진 것인데 왜 1-Simplex 인가?
  
  이유는 계수가 1이기 때문이다.
  
  왜냐하면 선은 "a + b = 1"이라는 조건이 들어가기 때문에 선을 만들 때는 계수가 두 개가 들어가는 것이 아닌 한 개가 들어가게 된다.
  
  
  
• 3-Simplex는 어째서 Tetrahedron(사면체, 삼각뿔)이 되는가?

먼저 두 점이 있는데 이것을 아핀 조합을 하면 선이 만들어진다.

다음과 같이 선에 점이 일직선 상으로 세 개가 있다고 가정하고 이런 경우엔 삼각형이 만들어질까?

결과는 만들어지지 않는다. 왜냐하면 이런 경우에는 선형 독립이 아닌 선형 의존이기 때문이다.

위에 그림을 보면 아핀 조합을 통해서 가운데 위치한 점을 만들 수 있기 때문에 가운데 점은 있을 필요가 없다.

점과 점 사이에는 다른 선형성이 있어야 한다. 그래야지 어떤 조합을 할 수 있는 근거가 되기 때문이다.

위와 같이 삼각형에서 점을 하나 추가했을 경우에도 아핀 조합을 통해서 평면이 만들어지기 때문에 선형 의존이 된다.

그렇다면 선형독립이 되려면 어떻게 해야할까?

새로운 점의 위치가 평면 위의 3차원 공간 어딘가에 있어야 한다. 평면 위에 점을 추가할 경우

다음과 같이 평면이 아닌 정삼각뿔 형태가 만들어지기 때문에 선형 의존이 아닌 선형 독립이 된다.

따라서 3-Simplex가 Tetrahedron(사면체, 삼각뿔)이 되는 이유는 선형 독립이기 때문이다.