이전 글에서는 Local 좌표와 World 좌표가 무엇인지,
그리고 왜 게임 엔진들이 부모 기준 좌표와 월드 기준 좌표를 함께 사용하는지를 정리했습니다.
게임 안의 객체들은 단순히 독립적으로 존재하는 것이 아니라,
서로 관계를 가지며 움직이는 경우가 굉장히 많다는 점도 함께 살펴봤습니다.
- 캐릭터 손에 장착된 무기
- 플레이어를 따라다니는 카메라
- 자동차에 연결된 바퀴
- 부모 UI를 따라 움직이는 자식 UI
그런데 이런 구조를 공부하다 보면 자연스럽게 등장하는 개념이 하나 있습니다.
바로 Parent/Child 개념입니다. 그리고 이 관계를 Scene Graph라고 부릅니다.
그리고 대부분의 게임 엔진들이 결국 비슷한 계층 구조를 사용합니다.
이번 글에서는 왜 게임 엔진들이 Scene Graph 구조를 사용하는지,
그리고 왜 게임 공간을 “계층 구조” 형태로 관리하기 시작했는지를 정리해보려고 합니다.
게임 객체들은 서로 연결되는 경우가 굉장히 많다
게임 엔진을 공부할 때 객체들을 독립적으로 생각하는 경우가 많습니다.
- 플레이어 객체
- 몬스터 객체
- 카메라 객체
각각 따로 존재한다고 느낄 수 있습니다.
하지만 실제 게임에서는 객체들이 서로 연결되는 경우도 많습니다.
예를 들어 플레이어가 이동하면, 다양한 객체들이 함께 따라가야하는 경우입니다.
예를 들어 플레이어가 이동하면
- 손에 들고 있는 무기도 함께 움직여야 하고
- 플레이어를 따라가는 카메라도 함께 이동해야 하며
- 특정 이펙트 역시 플레이어 위치를 따라가야 할 수도 있습니다.
즉, 게임 안의 객체들은 단순한 독립 객체라기보다, 서로 관계를 가진 구조에 훨씬 가깝습니다.
이런 관계를 관리하기 위해 등장한 구조가 바로 Scene Graph입니다.
Scene Graph는 객체를 계층 구조로 관리한다
Scene Graph는 이름 그대로 Scene를 그래프 형태로 관리하는 구조입니다.
하지만 실제 게임 엔진에서는 보통 트리(Tree) 구조에 가까운 형태로 사용됩니다.
예를 들어 아래와 같은 구조를 생각해볼 수 있습니다.
Player ├─ Camera ├─ Weapon └─ Effect
여기서 Player는 부모 객체 Camera/Weapon/Effect는 자식 객체가 됩니다.
즉, 객체들 사이의 관계를 계층 구조로 표현하는 방식입니다.
왜 굳이 계층 구조를 사용할까?
이런 생각이 들 수도 있습니다.
“그냥 모든 객체를 따로 관리하면 되는 것 아닌가?”
하지만 실제 게임에서는 부모 객체가 움직일 때 자식 객체도 함께 움직여야 하는 경우가 굉장히 많습니다.
예를 들어 플레이어가 이동하면,
카메라 위치도 변경되어야 하고,
무기 위치도 따라가야 하며,
캐릭터 주변 이펙트도 함께 이동해야 합니다.
만약 이런 객체들을 모두 독립적으로 관리한다면, 매 프레임 위치를 계속 직접 계산해야 할 수도 있습니다.
하지만 계층 구조를 사용하면, 부모 객체 Transform이 변경되었을 때,
자식 객체들도 자연스럽게 함께 이동할 수 있습니다.
즉, 객체 관계를 훨씬 효율적으로 관리할 수 있게 됩니다.
Scene Graph는 Transform 구조와 깊게 연결된다
Scene Graph는 Transform과 굉장히 깊게 연결되어 있습니다.
아래와 같이 Player와 Weapon 두 객체가 있고, Weapon은 Player의 하위 객체라고 생각해 봅시다.
Player Position = { 100, 0, 0 }
Weapon Local Position = { 10, 0, 0 }
이 경우 Weapon의 실제 World Position은 ( 110, 0, 0 ) 이 됩니다.
부모 객체인 Player의 위치 ( 100, 0, 0 )에서 Weapon의 Local 위치 ( 10, 0, 0 )을 더한 위치입니다.
즉, 자식 객체는 부모 객체 기준(Local 기준)으로 위치를 저장하고, 최종 위치는 부모 Transform을 기반으로 계산됩니다.
그리고 이런 계산이 계층적으로 계속 이어질 수 있습니다.
즉, Scene Graph는 결국 Transform 관계를 관리하는 구조라고 볼 수도 있습니다.
유니티와 언리얼 엔진도 결국 같은 구조를 사용한다
유니티와 언리얼 엔진 역시 비슷한 구조를 사용합니다.
유니티에서는 GameObject들이 Parent / Child 관계를 가질 수 있습니다.
Hierarchy 창을 보면 실제로 트리 구조 형태로 관리되는 것을 확인할 수 있습니다.
Player ├─ Camera ├─ Weapon └─ Effect
언리얼 엔진 역시 비슷합니다. SceneComponent 구조를 기반으로 부모/자식 관계를 구성할 수 있습니다.
즉, 엔진마다 이름이나 구현은 조금 다를 수 있지만, 객체를 계층 구조로 관리한다는 핵심 개념은 거의 동일합니다.
Scene Graph는 단순 위치 관리에서 끝나지 않는다
Scene Graph가 단순히 위치 계산만을 위한 구조는 아닙니다.
실제로 Scene Graph는 다양한 시스템과 연결되어 있습니다.
- 렌더링 관리
- 업데이트 순서
- 가시성 처리
- UI 구조
예를 들어 UI 시스템 역시 계층 구조를 굉장히 많이 사용합니다.
부모 UI가 숨겨지면 자식 UI도 함께 사라지고, 부모 UI가 이동하면 자식 UI도 함께 움직입니다.
즉, 계층 구조는 게임 엔진 전반에서 굉장히 자연스럽고 강력한 구조입니다.
하지만 계층 구조가 무조건 좋은 것만은 아니다
물론 여기서 중요한 부분이 있습니다.
Scene Graph 구조가 항상 완벽한 것은 아닙니다.
예를 들어 계층 구조가 너무 깊어지면, Transform 계산 비용이 증가할 수도 있습니다.
특히, 부모 객체가 움직일 때, 모든 자식 객체들의 World Transform도 다시 계산해야 할 수도 있습니다.
예를 들어, 아래와 같이 계층 구조체 계속 이어진다면 Transform 계산 역시 계속 전파됩니다.
- 부모
- 자식
- 손자
- 증손자
따라서 계층 구조는 굉장히 편리하지만, 동시에 관리 비용도 함께 증가할 수 있다는 점을 명심해야 합니다.
최근 엔진들은 Transform 계산 최적화를 중요하게 보기 시작했다
최근 게임 엔진들은 여기에서 한 단계 더 나아갑니다.
최근 게임들의 규모가 상당히 커졌기 때문입니다.
- 수많은 객체
- 복잡한 계층 구조
- 대규모 Scene
그리고 이 과정에서 Transform 계산 비용이 점점 더 중요해지기 시작했습니다.
그래서 최근 엔진 구조는 Cache 효율, ECS, Data Oriented Design 같은 흐름과 연결되면서,
Transform 계산 자체를 더 효율적으로 처리하기 시작했습니다.
최근 게임 엔진 구조는 점점 “객체를 어떻게 연결할 것인가”뿐만 아니라,
“계층 구조 계산을 어떻게 더 효율적으로 처리할 것인가”도 중요하게 보기 시작했습니다.
결국 게임 엔진은 관계를 관리하는 프로그램이다
Scene Graph를 조금 더 깊게 들여다보면, 게임 엔진은 단순히 객체들을 나열하는 프로그램이 아니라,
객체들 사이의 관계를 관리하는 프로그램이라는 것을 알게됩니다.
플레이어와 무기의 관계, 카메라와 캐릭터의 관계, UI와 자식 UI의 관계 같은 구조들이 계속 등장합니다.
게임 공간은 독립된 객체들의 집합이라기보다, 서로 연결된 관계 구조가 표현되는 공간입니다.
그리고 Scene Graph는 이런 관계를 표현하기 위해 등장한 핵심 구조 중 하나라고 볼 수 있습니다.
마무리
게임 엔진을 공부하다 보면, Scene Graph, Parent / Child 구조, Hierarchy 같은 개념들을 정말 자주 접하게 됩니다.
단순 트리 구조처럼 느껴질 수도 있습니다.
하지만 조금 더 깊게 들여다보면, 결국 게임 엔진이 객체들 사이의 관계를 어떻게 표현하고 관리하는지가 이 구조 안에 담겨 있다는 것을 알게됩니다.
그리고 이런 흐름을 이해하기 시작하면, 대부분의 게임 엔진들이 계층 구조 기반으로 Scene을 관리하는 이유를 이해할 수 있습니다.
다음 글에서는, 행렬(Matrix)은 왜 필요한지,
그리고 왜 게임 엔진에서 Matrix 개념이 등장하기 시작했는지도 이어서 정리해보려고 합니다.
👉 게임 엔진 구조를 더 깊이 이해하고 싶다면
아래 강의를 통해 직접 구현해보는 것을 추천드립니다.
👉 C++로 만드는 게임 엔진 프레임워크 강의 바로가기