East Agent's Blog

이 포스트는 floh님의블로그에 포스팅된 Nebula3 관련 내용을 번역한 글입니다. Nebula3는 Nebula2의 기본적인 아키텍쳐를 계승하지만구현에서는 이전과 비교해 보면 여러 면에서 많이 다릅니다. 특히 세개의 레이어로 구성되어 있는 점이 가장 큰 특징 중의 하나인데이것은 이전의 망갈로(Mangalore)가 게임 엔진에 포함되었기 때문입니다. 그래서 이 세 개의 레이어에 대한 이해를 위해서 관련된 포스트들만 먼저 번역해서 올립니다.

Nebula3 Graphics subsystem

http://flohofwoe.blogspot.com/2007/08/nebula3-render-layer-graphics.html

그래픽스(Graphics) 서브시스템은 렌더링 시스템에서 최상위 그래픽 관련 서브시스템으로 이전 망갈로의 그래픽스 시스템의 다음 버전에 해당한다. 이전 버전과 비교하면 새로운 버전은 Nebula 엔진에 통합되어 있으며 저수준(low level)의 렌더링 코드와 더욱 밀접하게 연결되어 있다.

기본적인 아이디어는 바깥 세계와 최소한의 커뮤니케이션만 하면서 자동화된 모델 엔티티, 광원 엔티티 그리고 카메라 엔티티를 포함하는 그래픽스 세계(Graphics Worlds)를 만드는 것이다. 그래픽스 세계의 주된 처리는 엔티티를 그 세계에 추가하거나 삭제하는 일과 이들의 위치 정보를 갱신하는 일이다.

Nebula3에서는 Mangalore의 그래픽스 서브시스템과 Nebula의 장면(Scene) 서브시스템 사이의 경계를 없앤 덕분에 훨씬 더 적은 양의 코드와 줄어든 커뮤니케이션 오버헤드로 동일한 컨셉의 구현이 가능해졌다.

그래픽스 서브시스템은 멀티 쓰레드를 이용한 비동기 렌더링을 지원하기 위해서 그래픽스와 모든 저수준의 렌더링 서브시스템은 별도의 팻-쓰레드로 구동된다. Nebula3 레이어 모델에서 꽤 고수준의 위치이지만 내가 이 위치를 선택한 이유는 게임 플레이와 관련된 코드와 그래픽 관련 코드 간에 가장 적은 회수의 커뮤니케이션 요구가 발생하는 곳이기 때문이다. 비록 실용적인지에 대한 여부는 실제 경험을 통해 결정해야 하는 문제이긴 하지만 그래픽 코드의 "built-in autonomy"(역주: ??  ^^;)와 함께 완전히 다른 프레임 레이트로 게임 코드를 실행하는 것이 가능해야 한다. 이것은 명확히 시도해 봐야 할 것 중의 하나이다. 왜냐하면 게임 플레이 코드를 초당 10 프레임 이상 실행할 이유가 없기 때문이다.(버츄어 파이터의 팬들은 동의하지 않겠지만 말이다)

중요한 그래픽스 서브시스템의 공용 클래스는 다음과 같다.

• ModelEntity

• CameraEntity

• LightEntity

CameraEntity는 그래픽스 세계의 뷰-볼륨을 나타내는 것으로 렌더링을 위한 뷰, 프로젝션 행렬을 제공한다.

LightEntity는 동적인 광원을 나타낸다.

Stage와 View는 Nebula3에서 처음 등장한 새로운 컨셉이다. Mangalore에서 그래픽 엔티티들은 Level이라는 클래스에 포함이 되어 있었고 한번에 하나의 활성화된 카메라 엔티티와 레벨만이 존재할 수 있었다.

Nebula3에서는 Stage와 View를 사용하여 그 문제에 대한 훨씬 더 명확한 답을 제시하고 있다. Stage는 그래픽 엔티티를 위한 컨테이너로 작은 그래픽스 세계를 표현한다. 동시에 여러 개의 Stage가 존재할 수 있지만 이들은 분리되어 있다. 엔티티는 한번에 하나의 Stage에만 연결된다.  엔티티를 그래픽스 세계로 그룹 처리하는 것 외에 Stage의 중요한 일은 엔티티들 간의 공간 관련도를 이용해서 엔티티들을 구성함으로써 이들에 대한 가시성 질의를 빠르게 처리 할 수 있도록 하는 일이다. (그리고 필요에따라)애플리케이션에서는 Stage 클래스를 상속하여 완전히 다른 가시성 질의 정책을 구현할 수도 있다.

뷰 객체는 카메라 엔티티를 통해서 뷰를 스테이지로 렌더링 한다.(역자 주: CameraEntity가 잡은 뷰는 RenderTarget에 그려지고 이것이 Stage로 보내진다는 의미) 임의의 스테이지는 여러 개의 뷰를 가질 수 있고 또 뷰가 다른 뷰에 연결되어 있을 수도 있다. 이것은 임의의 뷰를 갱신하기 위해서는 다른 연결된 뷰를 먼저 강제로 갱신해야 (this is handy when oneView's rendering process requires the content of another View's rendertarget as a texture)/ 뷰 객체는 자신의 렌더링 루프를 사용하여 처리된다. 애플리케이션에서는 View를 서브클래싱해서 원하는 대로 렌더링 처리를 하는 것이 가능하다. 예를 들어 광원당 하나의 패스만 가지거나 아니면 패스당 여러 개의 광원(multiple lights per pass)를 가지던가 혹은 큐브 맵에 렌더링(render to cubemap)하는 등의다양한 렌더링 처리가 가능하다.

요약하면 Stage는 가시성 질의에 대한 처리를 담당하고 View는 렌더링 프로세스를 처리한다.

그래픽스 서브시스템의 주된 처리 중 하나는 엔티티들 간의 가시성 판단을 통해서 이들의 실제 렌더링 여부를 판단하는 일이다. 가시성 질의를 통해서 엔티티들 간의 상호 가시성 연결(visibility link)를 확인할 수 있다. 가시성 연결은 두 가지가 있는데 바로 카메라 링크와 광원 링크이다. 카메라 링크는 자신의 뷰 볼륨내 모델에 (카메라를) 연결시킨다. 가시성 연결은 양방향이기 때문에 카메라는 자신의 뷰 볼륨 내의 모든 모델들을 알고 있으며 모델들 역시 보이는 모든 카메라를 알고 있다. 광원 연결도 카메라 연결과 같이 모델과 광원 사이의 연결을 확인한다. 광원은 자신이 영향을 미치는 모든 모델들을 알고 있으며 모델 역시자신에게 영향을 주는 모든 광원을 알고 있다.

가시성 질의의 속도를 높이기 위한 가장 중요한 클래스는 내부의 Cell 클래스로 이것은 엔티티와 자식 셀을 위한 컨테이너의 역할을 한다. Cell은 반드시 다음의 두 가지 간단한 규칙을 준수해야 한다.

• 임의의 셀이 완전히 보이는 경우, 해당 셀의 엔티티들과 셀의 자식 셀도 모두 보인다.
• 임의의 셀이 전혀 보이지 않는 경우, 해당 셀의 엔티티들과 셀의 자식 셀도 모두 렌더링하지 않는다.
  

Cell은 Stage에 부착되며 최상위 Cell로부터 시작하여 계층을 형성한다. 기본 Cell 클래스는 쿼드 트리나 옥트리와 같은 공간분할 방법을 가지는데 사용자가 포탈(portal)과 같은 다른 공간 분할 알고리즘을 사용하고자 하는 경우에는 Cell을 상속한 서브클래스를 작성해야 한다. 이 서브클래스의 가시성 판단과 관련한 제한사항은 위에서 언급한 두가지 규칙을 준수하는 것이다.

그래픽스 엔티티가 Stage에 부착될 때 이 엔티티를 수락하는(일반적으로 완전히 포함하는) 가장 낮은 레벨의 Cell에 부착된다. 그래픽스 엔티티의 변환이나 바운딩 볼륨을 갱신을 할 때 필요한 경우 Cell에서의 자신의 위치를 변경한다.

Stage는 StageBuilder 클래스에 의해서 생성된다. 애플리케이션에서는 Stage의 초기 상태를 생성할 수 있도록StageBuilder를 상속하는 클래스를 작성해야 한다. Cell과 엔티티들은 Stage의 초기 상태를 생성할 때 추가되게된다.  Nebula3는 대부분의 응용 프로그램에 적합한 표준 StageBuilder 클래스들을 제공한다.(SimpleStageBuilder와 QuadtreeStageBuilder)

이상으로 간단하게 그래픽스 서브시스템에 대해서 알아 보았다. 현재로서는 아주 간단한 구현만 된 상태이기 때문에 다음 몇 주간에 걸쳐 많은 변화가 있을 수도 있다.