[번역]천애명월도 모바일 게임 엔진 책임자: 최고 수준의 그래픽을 구현하기 위해 해결한 과제는 무엇인가요?

역자의 말.
최근... 아니 사실 거의 10년 전부터 텐센트 북극광의 엔지니어링 기술은 일본을 제외 하고는 아시아에서 원탑에 속하고 있었습니다. 워낙 국내에서 중국에 관심이 없을 시절 그러니까 2015년도에 그냥 우리가 몰랐을 뿐이죠. 엄격히 말하면 텐센트가 UBISOFT 의 리드 및 시니어 엔지니어들을 영입하기 시작한 것은 2009년 후반 부터였습니다. 원래 천애명월도는 2012년도에 첫 출시를 했지만 그다지 좋지않은 그래픽 품질과 렌더링 품질 그리고 여러가지 전형적인 중국회사의 기술문제를 그대로 갖고 있었습니다. 상해에 본진을 두고 있는 북극광(오로라 스튜디오)는 텐센트 IEG 그룹의 1급 스튜디오 중의 하나입니다. 2012년 이후부터 UBISOFT 등에서 영입한 렌더링 프로그래머와 터레인 관련 프로그래머 및 해외 콘솔게임 개발 협업 경험이 있는 다수의 중국인 인재들을 영입 했습니다. ( 이후 그 핵심맴버들이 다시 넥스트 스튜디오를 설립 하죠. )
천애명월도 PC 버전 출시 이후 5년이 좀 넘을 무렵 천애명월도 모바일이 출시하게 되는데요. 출시 이후 2020년 텐센트 TGDC 에서 천애명월도 모바일 개발과 유니티 엔진 커스텀 튠에 대한 강연이 있었습니다. 중국 내에서도 다수의 게임엔지니어링 부서에서 GPU 드리븐에 대한 많은 관심과 노력을 하던 시기로 기억합니다. 그래서 당시 발표 된 강연 자료를 찾아서 번역을 해 보며 복기 하는 시간을 갖도록 하려 합니다.

---

 
 
 

 
원문

天刀手游引擎负责人：顶级画面背后，我们解决了哪些难题？

4일간 진행된 텐센트 게임 개발자 컨퍼런스(줄여서 TGDC)가 12월 7일에 온라인으로 공식 개최되었습니다.

어젯밤 기조 연설에서 텐센트 인터랙티브 엔터테인먼트 천애명월도M 개발 엔진 담당자 류 빙샤오 (Liu Bingxiao)는 "기술을 사용하여 중국풍 스타일의 시각적 로맨스의 귀환을 해석하다" 천애명월도M 개발 과정을 주제로 천애명월도M의 화질, 프레임 속도 및 전력 소비의 균형을 조정하여 중국풍 스타일의 시각적 로맨스를 해석하는 방법을 공유했습니다.

다음은 연설 대본의 일부이며, 읽기 경험을 향상시키기 위해 전체 발표 내용의 일부는 삭제 및 조정되었습니다:

안녕하세요, 저는 천애명월도M 개발 엔진 담당 기술 담당자 인 Liu Bingxiao입니다. 이번에는 주로 천애명월도M 개발 과정에서 몇 가지 핵심 포인트에 대한 기술적 결정과 공개 경험을 공유하겠습니다.

1. 모바일 게임 엔진 개발 세 가지 요소

모바일 게임 엔진 개발에는 몇 가지 중요한 요소를 고려해야 합니다.

첫째, 화질입니다. 멀리 있는 풍경을 강조할 것인지, 가까이 있는 풍경을 강조할 것인지 등 몇 가지를 선택할 수 있습니다. 실내에서 더 뛰어난 화질을 원하나요, 아니면 실외에서 더 뛰어난 화질을 원하나요? 전체적인 렌더링 효과를 생동감 있게 만들까요, 아니면 더 자연스럽게 만들까요? 빛의 표현을 우선시할까요, 아니면 그림자 효과를 우선시할까요?

두 번째는 프레임 속도입니다. 천애명월도와 같이 인터랙티브한 MMORPG의 경우 빠르고 안정적인 프레임 속도가 필요합니다.

보통 PC용으로 개발할 때는 두 가지 측면만 고려하면 되는데, 먼저 화질 성능에 도달한 다음 최적화를 통해 프레임 속도를 계속 개선하고, 프레임 속도가 목표 지점에 도달한 후에는 더 나은 화질 성능을 도입할 방법을 생각한 다음 두 가지를 계속 반복하는 것이죠.

모바일 게임의 경우 전력 소비라는 세 번째 문제가 추가 되었습니다. 이는 휴대폰에서 매우 중요한 요소로, 열을 발생시킬 뿐만 아니라 한 세션에서 플레이하는 시간에도 영향을 미칩니다.

이 세 가지 맥락 중 하나라도 증가하면 다른 두 가지 맥락에 영향을 미칩니다.

2. 모바일 게임 최적화

천애명월도M 게임의 최적화를 위해 개발 엔진 팀은 더 나은 최적화 결과를 얻기 위해 다양한 기술을 사용했습니다:

멀티 스레드 렌더링 엔진을 최적화하여 애니메이션, 옷감 시뮬레이션 등 병렬로 처리할 수 있는 대부분의 작업을 다른 스레드에 배치하여 실행합니다;

ISPC를 사용하여 NeonSIMD용 코드를 자동으로 생성하여 CPU 실행 효율을 개선했습니다;

GPU 및 CPU 오클루전 컬링에서 서로 다른 세분성을 가진 오클루전 컬링 알고리즘을 사용했습니다;

GPU 메모리를 더 세밀하게 관리할 수 있는 Vulkan API를 먼저 활성화합니다;

GPU 기반 렌더링 파이프라인 구현;

컴퓨터 지원 최적화를 통한 다양한 렌더링 기법 최적화;

그래픽에 PBR 머티리얼과 실제 물리 단위 조명을 사용합니다.

각 테스트에서 중요한 최적화에 들어갔습니다.

첫 번째 테스트에서 우리는 렌더링 스레드와 commit threads 를 마스터 스레드에서 떼어내는 다중 스레드의 프레임워크를 변경했습니다.모바일 게임의 개발 환경에서 주요 스레드의 지속적인 작동은 휴대폰 칩의 출력을 증가시켜 더 심각한 발열을 유발할 수 있기 때문입니다.

두 번째 테스트에서는 GLES보다 더 가볍고 더 나은 호출을 제공하는 Vulkan API를 도입했습니다. 테스트 결과 커밋 스레드에서 CPU 효율성이 30% 향상되었습니다.

세 번째 테스트에서는 GPU 기반 기술을 도입했습니다. 이를 통해 CPU에서 수행하던 대부분의 작업을 GPU로 전송하여 실행할 수 있어 GPU의 효율성이 향상될 뿐만 아니라 GPU에서 CPU로 전달되는 다양한 패스의 대역폭도 줄일 수 있습니다. 이 기술은 주로 지형, 초목 및 주택 시스템에서 사용됩니다.

베타 3에서는 전반적인 조명 표현을 수정 및 개선하고, 자동 노출을 도입하고, 톤 매핑 효과를 개선했으며, 실제 물리적 단위 도입으로 인해 다양한 조명 환경에서 조명에서 일부 디테일의 색 손실 문제를 해결했습니다.

sky lighting 를 재정의하여 전체 장면의 야외 성능을 더욱 풍부하고 대조적으로 만들었습니다.

3. GPU 기반 기술 최적화 포인트
다음으로 GPU 구동 기술을 활용한 렌더링 기술 최적화의 핵심 포인트를 공유하고자 합니다.

개발 과정에서 우리는 멀티스레딩 최적화를 검토하던 중 모바일 플랫폼에서 최적화를 위한 최적의 지점을 발견했는데, 바로 휴대폰이 훨씬 일찍 멀티코어화되었다는 사실입니다. 현재 많은 안드로이드 휴대폰은 이전 세대의 콘솔 플랫폼에서 보았던 것과 같은 4+4 멀티코어 아키텍처를 채택하고 있으며, 이러한 아키텍처에서는 개발자가 이러한 보조 연산 장치를 더 많이 활용하여 연산 효율성을 개선할 수 있습니다.

저희는 엔진 그룹에서 두 가지 방향으로 나아갔습니다. 하나는 메인 스레드에서 최대한 많은 연산을 제거하고 다른 스레드로 분산하여 연산 효율성을 개선하는 것이고, 다른 하나는 최신 렌더링 프레임워크의 근간에 해당하는 GPU 컴퓨팅으로 연산을 전환하는 것으로, GPU 프로세싱의 래스터화 부분 외에도 GPU 렌더링 프로세스에서 많은 수의 연산을 수행할 수 있습니다.

컴퓨트 렌더링 언어는 로컬 데이터 스토리지 메커니즘, 스레드 그룹 및 스레드 활용 개념과 같은 GPU 자체 하드웨어와 완벽하게 호환된다는 점에 주목할 필요가 있습니다.

또 다른 한 가지는 컴퓨트를 사용하면 GPU의 동기화를 매우 잘 제어할 수 있기 때문에 벌칸의 잠재력을 더 많이 활용할 수 있다는 점입니다.

컴퓨팅은 별도의 유닛으로, GPU의 나머지 연산과 병렬 처리하는 데 매우 유용하게 사용할 수 있습니다. 또한 컴퓨트는 별도의 대기열로, 전체 파이프라인인 vs 및 ps에 비해 매우 단순화된 단위이며 어디에나 쉽게 배치할 수 있습니다.

컴퓨트를 사용하면 GPU 구동 및 Bindless를 위한 더 넓은 최적화 공간을 확보할 수 있으며, 비동기 컴퓨트를 사용하여 컴퓨트와 GPU 유닛을 더욱 병렬화할 수 있습니다.

천애명월도M의 경우 컴퓨팅을 개방하는 핵심 혁신 포인트는 GPU 기반 지형 시스템입니다.

그 전에 CPU 지형에 대한 일반적인 알고리즘을 소개하겠습니다. 지난 버전에서 사용한 지형 알고리즘은 CPU 측의 지오메트리 클립맵 알고리즘으로 뷰콘 클리핑 컬링 방식을 사용하며, GPU 구동 방식에 비해 깊이 컬링이 적고, LOD를 계산하는 방식이 거리를 기반으로 하는 반면 GPU 구동 방식은 거리와 지형 블록의 복잡도에 따라 계산할 수 있습니다.

클립맵 방식에 공급되는 버텍스에는 두 개의 패스가 있고 그 중 하나는 가상 텍스처를 통해 사용되므로 210,000 x 2 고정 포인트가 필요합니다. 반면 GPU 구동 방식에서는 더 나은 컬링 결과를 얻을 수 있기 때문에 86,000개의 버텍스만 필요합니다.

GPU 시간을 다시 살펴봅시다. GPU 구동의 경우 iPhone 8Plus에서 2.9밀리초의 시간 오버헤드를 얻을 수 있으며, 이는 CPU를 거칠 때보다 거의 4분의 1에 해당하는 비용 절감 효과이며, CPU 측면에서는 제출 및 렌더 스레드 각각에서 5밀리초 이상의 시간 절감 효과를 얻을 수 있어 훨씬 더 큰 이득을 얻을 수 있습니다.

GPU 기반 프로세스는 GPU 기반과 가상 텍스처의 두 가지 알고리즘으로 구성되며, 구현 방식이 서로 교차하므로 간단하게 설명하기 위해 GPU 기반에 대해서만 설명하겠습니다.

먼저 뎁스 밉 생성, 알고리즘의 이 부분은 컴퓨트 내부에서 구현됩니다;

둘째, GPU 오클루전 컬링은 주로 들어오는 패치의 크기를 계산하여 어느 레벨의 뎁스 버퍼에 있는지 확인한 다음, 이 레벨의 뎁스 버퍼의 깊이와 사용자의 깊이를 비교하여 깊이별로 컬링할지 여부를 결정하는 연산에서 구현됩니다;

이 과정을 통해 보이는 패치 수를 구할 수 있고, 그에 따라 계산을 통해 간접적으로 Arguments 버퍼 생성을 할 수 있습니다;

마지막으로 이렇게 준비된 간접 버퍼를 끌어내는 것이 전체 터레인 GPU 기반 렌더링 프로세스입니다.

매우 중요한 최적화 중 하나는 컴퓨팅에서 스레드 공유 메모리를 사용하는 것으로, CPU에서 GPU로의 디스패치 횟수를 줄이고 바인딩 메모리 핑퐁 작업도 줄일 수 있습니다.

주로 필터를 수행하기 위한 버퍼의 범위에 적용될 수 있으며, 예를 들어 렌더링 파이프라인에서 자주 언급하는 블룸, 가우시안 블러, 자동 노출, 필터 작업 영역에 대한 이러한 방법을 사용하여 이러한 방법의 최적화를 얻을 수 있습니다.

천애명월도M에서는 첫 번째 디스패치를 수행하여 16 * 16 스레드 그룹, 각 스레드 그룹 128 개를 생성하고이 128 개의 스레드는 깊이를 읽은 다음 밉에 넣습니다. 두 번째 단계는 방법의 동기화를 통해 네 점에 인접한 마지막 밉 레벨을 꺼내고 병합하여 가장 깊은 단위를 선택하고 밉의 두 번째 레벨에 쓰는 등 4 레벨을 완료하는 것입니다. 두 번째 디스패치에서는 두 번째 레벨 밉에 네 점을 씁니다.

두 번째 디스패치에서는 동일한 방법을 사용하여 스레드 그룹인 128개의 스레드를 디스패치하고 뒷면 32 * 16 밉을 작성하여 완료합니다.

최적화를 위한 또 다른 메커니즘이 있는데, 바로 LOD 시스템입니다.

FarCry의 구현에서는 주로 CPU 쿼드트리 접근 방식을 사용하여 LOD 패치를 구성하고, 거리에 따라 쿼드트리의 노드를 업데이트한 다음, 카메라 거리에 따라 해당 노드를 선택하여 간접 버퍼 및 GPU 컬링을 위해 GPU에 공급합니다.

대신 천애명월도M 핸들러는 이 패치 정보를 먼저 오프라인으로 베이크 아웃합니다. 각 카메라 위치가 변경되면 베이크 아웃 정보를 업데이트하고, 이 정보에 따라 변경된 패치를 필터링한 다음 새로운 INDIRECT 버퍼를 생성합니다.

GPU 구동 지형을 완성한 후 엔진 팀은 모든 프로세스를 다시 거친 다음, 이렇게 분류된 프로세스를 기반으로 GPU 구동으로 적용할 수 있는 다른 렌더링 모듈을 선택합니다.

가장 중요한 렌더링 모듈 중 하나는 씬의 식생 관리입니다. 숙련된 렌더링 프로그래머라면 풀의 지오메트리와 지형의 패치 또는 섹터 관리가 매우 유사한 개념이며 둘 다 LOD가 있고 지오메트리의 표현 방식이 다르다는 것을 바로 알 수 있을 것입니다. 이러한 지오메트리 LOD를 그릴 때 가장 좋은 방법은 멀티 드로우 인스턴스드 간접 방식을 사용하는 것입니다.

또 다른 요점은 각 잔디 유형의 텍스처가 실제로는 지형에 대한 가상 텍스처 메커니즘에 가깝기 때문에 바인딩 없는 방식으로 바인딩할 수 있다는 것입니다.

하지만 벌칸 1.0 플랫폼에서는 멀티 드로우 인스턴스 또는 바인드리스라는 두 가지 API가 더 나은 지원을 받을 수 없습니다. 따라서 천애명월도M 구현에서는 각 잔디 유형에 대해 GPU 구동 컬링과 구동 간접 버퍼 생성을 한 번만 완료할 수 있습니다.

천애명월도M 게임 내에서 GPU 기반에 더 적합한 또 다른 장면은 홈 월드 렌더링입니다. 홈 월드 모드에서는 플레이어가 집 전체의 지형, 표면, 벽, 바닥, 오브젝트 등을 최대한 커스터마이징할 수 있으므로 매우 많은 지오메트리 유형이 필요하며, 커스텀 공간이 128m*128m로 비교적 작기 때문에 오클루전 컬링이 매우 잘 수행되어야 합니다. 이 두 가지 점을 결합하면 GPU 기반이 적합합니다.

문제는 홈 월드의 이러한 오브젝트가 실제로 잔디 유형과 마찬가지로 멀티 드로우 인스턴스드 간접 및 바인드리스라는 두 가지 API의 구현에 매우 의존적이라는 것입니다.

천애명월도M의 경우 차선책으로 터레인 단계에서 계산된 HiZ 버퍼를 사용하여 오클루전 컬링을 수행하고, 오클루전 컬링 버퍼를 수행하기 위한 콘텐츠 세트를 입력하고, 이 버퍼의 오클루전 컬링 결과를 CPU에서 READBACK 방식으로 가져온 다음, CPU 측에서 가능한 한 많은 인스턴스 오브젝트를 구성하는 방법밖에 없습니다.

Q&A

1. 성능 최적화의 기술적 어려움은 무엇인가요? 더 낮은 사양으로 더 높은 기준을 달성할 수 있다고 들었는데 어떻게 구현했나요?

저희는 구현할 때 고사양과 저사양에 특별히 신경 쓰지 않고 일반적으로 기준을 설정한 다음 그 위에서 어느 정도 균형을 찾습니다. 예를 들어 앞서 언급한 라이팅이나 그림자 표현의 경우, 그림자 표현이 라이팅 효과보다 약하다고 생각하기 때문에 여전히 전통적인 라이트맵을 사용하여 그림자를 굽고 큰 월드에서는 리얼타임 섀도를 사용하지 않습니다.

사실 밸런스 문제는 게임 자체에 따라 기술적 포인트를 견디고, 우선순위를 정하고, 궁극적으로 게임의 요구 사항에 맞는 기술적 접근 방식에 도달하는 데 더 가깝습니다.
 
2."천애명월도"와 같이 게임 말미에서 고전 IP의 모바일 게임에 이식 된 게임 말미에서 엔진 기술 관점에서 게임 품질의 끝을 더 잘 복원하는 방법은 무엇입니까?

이 질문은 두 가지 측면에서 답변해야합니다.

한편으로는 최종 게임의 어떤 기능을 복원해야하는지 명확합니다. 첫째, 비전의 성능에 더 많은 주의를 기울여야 하고, 둘째, 더 나은 캐릭터 성능을 가져야 합니다.

반면에 위의 내용을 바탕으로 최종 게임에서 모바 게임으로 화면 기술 포인트 중 일부를 복원하고, 예를 들어 최종 게임의 PBR 파이프 라인을 계속 유지하지만 조명 접근 방식의 물리적 조명 단위를 기반으로 최종 게임보다 더 나은 것을 사용하여 어두운 빛 환경 상황이나 전력 상황들의 다양한 변수등을 생각하면서 모바일 게임을 매우 좋게 만드는 등 핵심 기술 요소를 개발할 것입니다.

오늘은 여기까지만 공유하겠습니다.

---

역자의 마무리 말.
천애명월도M 개발 당시 저 역시 거인 네트웍스에서 유니티 엔진을 사용한 오픈월드 모바일 RPG 를 개발 중이었는데요... 월드 크기도 천애명월도M 의 10배 크기에 가까웠고 낮은 추파수 형식의 GI 베이크만 사용했으며 모든 그림자 처리는 실시간 그림자로 처리 했었습니다. 엄격히 말하면 400 미터 후방의 그림자는 Texture array 를 사용한 쉐도우 케시였구요. 실시간 그림자는 Variable Shadow map 이라는 방식을 사용했습니다. 실루엣 정밀도가 좀 미흡하지만 성능 측면에서는 이득이 있었으니까요. 250억원 예산의 프로젝트였지만 CEO 가 바뀌면서 2년동안 노력했던 프로젝트가 종료 되서 매우 아쉬웠던 기억이 다시 마음속에 들어오는 시간이네요.
다음에는 ARM 에서 발표한 Hi-z culling 의 기술적인 자료를 번역 해서 공유하도록 하겠습니다.
Bindless 에 대해서 더 알고 싶다면 예전 번역 자료를 참조 해 주세요.

[번역]GPU DRIVEN RENDERING OVERVIE