이 글에서는, 에픽의 테크니컬 아티스트와 엔지니어들이 포트나이트 배틀로얄(FNBR)의 건설 및 파괴 요소를 어떤 플랫폼에서든 똑같은 모양으로 플레이할 수 있도록 해준 독창적 솔루션을 개발한 방법을 알아봅니다.
일관성이 핵심이다
꿈의 요새 건설에 드는 자원 채취를 위해 자동차를 파괴하거나, 날아오는 총알을 막기 위해 미친듯이 벽을 건설하거나, 오브젝트의 건설과 파괴는 FNBR 플레이에 정말 중요한 요소입니다.
크로스플레이를 구현할 때 가장 중요하게 생각한 것은, 모든 플레이어에게 게임에 승리할 수 있는 기회를 플랫폼에 상관없이 공평하게 주는 것이었습니다. 이를 위해 포트나이트 팀은 FNBR 의 가장 중요한 메커니즘인 오브젝트의 건설과 파괴로 인해 발생할 수 있는 퍼포먼스 문제 극복을 위해 드로 콜 수를 줄이거나 한 화면에 표시되는 오브젝트 수를 줄이는 방안을 찾아야 했습니다.
모듈형 월드 구성하기
플레이어가 일으킨 파괴로 인해 발생할 수 있는 문제를 더 잘 이해하려면, 먼저 FNBR의 건물 구성 방식을 알아야 합니다. FNBR에서 볼 수 있는 각 건물은 모듈식 조각 시리즈를 빠르게 "끌어 붙여" 필요한 구조물을 조립하는 식으로 구성했습니다. 건물을 이렇게 모듈형으로 만들면 필요한 고유 애셋 수가 줄어 메모리와 같은 귀중한 리소스를 절약할 수 있습니다. 머티리얼과 텍스처가 제각각인 다양한 모듈형 조각을 여러가지 방법으로 재사용하면, 메모리에 추가 오브젝트를 로드하지 않고도 건물에 무한대의 다양성을 부여할 수 있기 때문입니다. 아래 이미지에서 모듈형 구조물을 사용해 얻을 수 있는 결과 유형의 예를 살펴볼 수 있습니다.
다양한 내부 장식과 소품을 제외하고, 상단 이미지 왼쪽의 건물을 구성한 것은 오른쪽에 보이는 스태틱 메시 액터 9 개뿐입니다. 이런 방법으로 건물을 구성하면 플레이어가 일으킨 파괴를 표시하기도 매우 수월해지는데, 파괴된 조각의 렌더링과 콜리전만 비활성화하면 되기 때문입니다. 이런 식의 파괴 표시가 PC와 콘솔에서는 괜찮지만, 모바일 디바이스처럼 성능이 떨어지는 플랫폼에서는 몇 가지 문제가 발생합니다. 그 이유는 FNBR 건물을 구성하는 개별 조각 350 ~ 400 개를 그리는 렌더링 비용도 만만치 않기 때문입니다. 다음 GIF에서 전형적인 건물 하나를 이루는 조각 수를 볼 수 있습니다.
이는 PC나 콘솔에서 문제가 되지 않지만, 전체 씬을 1,000 개 미만의 조각으로 구성해야 하는 스마트폰과 같은 플랫폼에서는 문제가 됩니다.
이제 전체적인 건물 생성 방식을 약간 이해했으니, 각 구성요소를 만드는 방식을 살펴보겠습니다. 파괴를 표시하는 방식에도 영향을 미치기 때문입니다. 다음 순서도를 통해 이 문서에서 알아볼 내용을 파악할 수 있습니다.
단순할수록 좋다 (최적화)
FNBR에서 사용하는 모듈형 구성으로도, 한 화면에 담을 수 있는 오브젝트 수는 결국 물리적 한계에 걸리게 됩니다. 이 물리적 한계를 일명 드로 콜이라고 하며, FNBR을 플레이할 수 있는 플랫폼마다 한 번에 표시할 수 있는 드로 콜의 양이 다르다는 큰 문제가 생깁니다. FNBR이 모든 플랫폼에서 부드럽고 안정적인 프레임으로 실행되도록, FNBR 의 스태틱 메시마다 레벨 오브 디테일(LOD) 스태틱 메시가 여럿 포함되어 있습니다. LOD는 자주 사용되는 비디오 게임 최적화 기법으로, 스태틱 메시가 카메라에서 일정 거리 이상 멀어질 경우 트라이앵글 수가 낮은 버전으로 대체하는 기능입니다.
위 이미지는 FNBR에서 볼 수 있는 다양한 건물을 만드는데 사용한 여러가지 모듈형 벽 스태틱 메시 중 하나입니다. 벽에 아주 가까이 있을 때는 이미지 맨 왼쪽에 있는 스태틱 메시가 보입니다. 카메라가 벽에서 점점 더 멀어질수록, 다음 GIF처럼 다른 LOD를 표시합니다.
이 기법을 전체 건물에 적용할 경우, 다음과 같은 결과물을 얻을 수 있습니다.
위 이미지의 왼쪽에는 건물의 원래 모습을, 오른쪽에서는 마지막 LOD만을 사용한 건물의 모습을 확인할 수 있습니다. 오른쪽 버전의 건물이 바로 우리가 원하는 결과물이긴 하지만, 아직도 일부 플랫폼에서 효율적으로 렌더링하기에는 너무 많은 조각으로 구성되어 있습니다. 이런 문제를 해결하면서 플레이어가 일으킨 파괴도 표시하려면, 몇 가지 새로운 툴과 "전통적인" 스태틱 메시 제작 기법을 사용해야 합니다.
"전통적으로" 만들다
플레이어에 의한 파괴를 표시하는 방법을 자세히 살펴보기 전에, 먼저 모듈형 스태틱 메시의 마지막 LOD를 살펴봐야 합니다. 만든 방식이 특별하기 때문입니다. 언리얼 엔진 4 스태틱 메시 에디터로 모듈형 건물 조각 중 하나를 열고 마지막 LOD를 강제로 표시하면, 다음 이미지와 같은 결과물이 나옵니다.
일반적인 스태틱 메시처럼 보일 수는 있지만, 트라이앵글 수 12 에 버텍스 수 18 에 주목합니다. 낮아보이는 수치이며, 실제로도 디지털 콘텐츠 제작 툴(DCC)로 크기와 모양이 똑같은 큐브를 만들었을 때 얻을 수 있는 결과물보다 작은 수치입니다. 다음 이미지는 동일한 모듈형 건물 조각을 DCC로 만들어서 언리얼 엔진 4로 익스포트한 결과물입니다. 크기와 모양은 완전 똑같지만, 이 스태틱 메시의 경우 버텍스 수가 6 개 많습니다.
버텍스 6 개 많은 것이 대수롭지 않게 들릴 수 있지만, 이 수는 빠르게 증가할 수 있습니다. 예를 들어 위 조각이 건물 하나에 30 번만 사용된다 쳐도, 벌써 한 건물에 추가되는 버텍스가 약 180 개입니다. 이런 건물이 100 채 있다면, 불필요하게 렌더링되는 추가 버텍스가 18,000 개나 되는 것입니다. 이런 추가 버텍스를 없애기 위해, 모듈형 스태틱 메시를 다음과 같은 방법으로 조정했습니다.
- 첫째, 모듈식 조각이 Smoothing Group (스무딩 그룹)을 지원해도 사용하지 않도록 강제 설정했습니다.
- 다음으로, 스태틱 메시의 UV는 가급적 UV Island(아일랜드)가 적도록 구성했습니다. 이 모듈형 조각의 경우, 박스의 앞면과 뒷면이 0부터 1의 UV 공간 전체에 매핑되어 있습니다. 그리고 옆 부위는 모두 결합하여 모듈형 조각의 현재 구성에 맞게 스케일 조절했습니다.
- 마지막으로 노멀은 수직면에 스무딩 부작용이 최대한 완화되도록 수정했습니다.
모든 작업이 끝나면, 새롭게 수정한 모듈형 조각을 익스포트한 뒤 기존 조각 위에 임포트했습니다. 그리고 같은 프로세스를 FNBR에 있는 모든 스태틱 메시의 마지막 LOD에 적용했습니다.
다음에는 플레이어가 일으킨 파괴를 표시하기 위해 이 모든 작업을 한 이유를 설명합니다.
지오메트리로 '무엇'을 했다고?
이제 건물을 구성하는 모든 모듈형 부위에는 트라이앵글 수가 최소인 상태의 LOD 가 있으니, HLOD (Hierarchical Level of Detail, 계층형 레벨 오브 디테일) 툴을 사용해 새로운 버전의 건물을 생성했습니다.
새 버전의 건물은 Medium HLOD (중간 HLOD), 줄여서 MHLOD 라 하며, 제일 마지막 LOD 전부를 하나의 스태틱 메시와 텍스처로 합칩니다. 이렇게 하니 건물을 표시하는 데 필요한 트라이앵글 수가 50,820 개에서 2,880 개로 크게 줄어듭니다. 이는 특히 스마트폰 같은 저사양 디바이스에서 엄청난 향상입니다. 이 새로운 버전의 건물은 저사양 디바이스에서 플레이어와 건물의 거리가 약 30 미터 이상일 때만 표시합니다. 또한 건물이 사용하는 머티리얼 수를 줄이는 데도 도움이 되어, 건물 렌더링에 필요한 리소스를 한 층 더 줄여줍니다.
끝까지 간다
다음은 플레이어가 일으킨 파괴와 관련은 없지만, 알아두면 좋은 정보입니다. FNBR을 플레이하는 동안, 먼 거리의 건물에는 파괴가 나타나지 않는 것을 보신 분도 있을 것입니다. 그때 보인 마지막 LOD는 프록시 지오메트리 툴(Proxy Geometry Tool)을 사용해서 생성했기 때문입니다. 프록시 지오메트리 툴은 심플리곤(Simplygon)을 대체하기 위해 자체 개발한 새로운 툴로, MHLOD 버전 건물의 트라이앵글 수를 더욱 줄일 수 있습니다. 이 버전의 건물은 플레이어가 일으킨 파괴를 표시하지는 못하지만, 카메라에서 정말 멀리 떨어진 건물의 렌더링 비용을 줄이는 데 도움이 되기 때문에 중요합니다. 이 예제에 사용된 건물의 MHLOD 버전에 프시 지오메트리 툴을 실행하니, 건물의 트라이앵글 수가 2,880 개 단 412 개로 줄었습니다. 이제 아래 이미지에서 볼 수 있듯이, 건물에 사용된 트라이앵글 수가 겨우 412 개라 멋져 보이지는 않습니다.
참고로 트라이앵글 412개 버전의 건물은 아주 멀리 떨어져 있을 때만 보이므로, 플레이어가 위 이미지처럼 인식하기는 매우 힘들 것입니다. 이 모든 것을 합쳤을 때 어떻게 되는지는, 다음 GIF를 확인하세요. 플레이어가 게임을 플레이하면서 보게 되는 건물의 트라이앵글 수가 최대인 버전에서 최소인 버전으로 바뀌고 있습니다.
건물의 구성 방식과 툴의 사용 방식 및 그 이유를 조금 더 자세히 알아봤으니, 이제 그 모든 아이디어를 제작에 사용할 수 있는 툴로 만들기까지의 과정을 살펴보겠습니다.
구원자 테크니컬 아티스트
이제 건물의 구성 방식에 대해 어느정도 더 알게 되었으므로, MHLOD 메시가 시야에 있을 때도 건물이 파괴되는 게 보일 수 있게끔 파괴 효과를 적용하는 방법에 대해 살펴볼 필요가 있습니다. 여기서 가장 중요한 문제 중 하나는 MHLOD 건물에 어떤 변화도 주지 않으면서 플레이어가 일으킨 파괴를 보여주어야 한다는 점입니다. 그 이유는 플레이어가 일으킨 파괴를 보여주기 위해 조각을 변경하거나 대체하면, 건물의 MHLOD 버전을 만든 이유가 없어지기 때문입니다. 이 문제는 해결하기가 다소 복잡하므로, 특별한 개발자를 찾아 도움을 청하겠습니다. 바로 테크니컬 아티스트(TA)입니다.
TA가 뭐하는 사람인지 잘 모르는 분들을 위해 설명드리자면, 아티스트, 코더, 디자이너를 합쳐놓은 사람입니다. TA는 복잡한 머티리얼 문제 해결부터 블루프린트 디버깅까지, 개발 과정에서 발생할 수 있는 많은 문제를 해결할 수 있습니다. 그래서 TA 는 자주 복잡한 문제 해결을 위한 솔루션 개발을 맡게 되는데, 일반적으로 비디오 게임을 만드는데 필요한 모든 시스템과 툴이 상호 연결되어 작동하는 원리를 잘 알고 있기 때문입니다. 이번 작업에는 단순하면서도 안정적인 솔루션을 만들 수 있도록 문제를 아주 세부적으로 분석하는 데 도움을 줄 수 있는 TA가 필요합니다.
문제 분석
이런 문제에 대한 솔루션을 찾으려 할 때는, 먼저 문제를 아주 기본적인 부분까지 분석해야 합니다. 그래야 관련된 모든 부분에 대한 이해도가 높아지고 작게나가 성공적인 진전을 이뤄낼 수 있습니다. 이런 부분을 고려하여, TA는 MHLOD 건물의 파괴 표시와 관련된 문제를 다음과 같은 구성요소로 분석하였습니다.
- 우선 모든 건물이 사용하는 BuildingWall 클래스에 HLODDestructionIndex 라는 새 프로퍼티를 추가해야 합니다.
- 그러면 HLOD를 만들 때, 건물이 사용하는 각 액터에는 순서에 종속되지 않는 인덱스가 지정됩니다.
- 다음으로, 각 건물의 토대는 파괴 가능한 조각당 1 텍셀을 담기에 충분한 렌더 타겟이 필요합니다.
- 완료 후에는, HLOD가 메시 병합(Mesh Merging)을 하는 방식을 수정하여 Max LOD를 복사하고 새로 생성된 스태틱 메시에 커스텀 버텍스 컬러를 적용하는 기능을 추가해야 합니다.
- 참고로 R, G, B 를 사용해서 넉넉하게 65k 값을 사용할 수 있는 것처럼 버텍스 컬러는 양자화해야 합니다.
- 이제 벽이나 바닥같은 건물 조각이 파괴될 때마다, HLODDestructionIndex 값을 읽은 뒤 할당된 텍셀에 검은색을 씁니다. 그러면 건물 조각은 정상적으로 파괴되고 HLOD 메시는 상태 변화가 없지만 파괴된 것처럼 보일텐데, 해준 작업이라고는 파괴 이벤트당 1픽셀을 포함한 Draw 이벤트를 실행했을 뿐입니다.
- 마지막으로 머티리얼에서, 버텍스 컬러에 패킹된 ID를 가져와 이를 통해 파괴 텍스처를 룩업하여, 텍셀 읽기가 0 (파괴된 섹션)이면 버텍스를 원점으로 축소(스케일을 0 으로)합니다.
이제 TA가 계획을 세웠으니, UE4 안에서 프로토타입을 만들어 보면 이 아이디어가 통할지 계획 수정 단계로 돌아갈지 알 수 있습니다.
다행히 위 접근 방식은 마술처럼 통해서, 다음 GIF 에서 보실 수 있는 것과 같이 렌더링 오버헤드 추가 없이 MHLOD 스태틱 메시를 파괴했습니다.
TA 의 프로토타입이 잘 되니, 툴 프로그래머에게 넘겨 실제 제작 툴로 만들면 됩니다.
재구축
여러 번의 빌드, 테스트, 재작업을 거치면서 프로토타입을 원래 아이디어와 구분하기도 어려우니, 그냥 툴 프로그래머에게 넘겨 C++로 다시 만들도록 합니다. C++로 다시 만들려는 이유는 최대한의 실행 속도와 최적화를 위해서입니다. C++로 이 툴을 다시 만들면서 필요한 프로퍼티를 기존 UI 의 합당한 위치에 그룹으로 묶을 수도 있습니다. 모든 작업이 끝난 후에는, 다음 영상처럼 이 기능을 게임 내에서 시험해볼 수 있습니다.
사용할 수 있는 도구
결론적으로, 크로스플레이 도입에 따라 발생한 파괴 문제를 저희 에픽의 TA 와 엔지니어가 해결한 방법이 여러분께도 도움이 되기를 바랍니다. 그 기발한 솔루션이 없었다면, FNBR에서 플레이어들이 울리는 파괴의 교향곡은 없었을 것입니다.
무엇보다도 이 블로그 글에 언급된 툴은 언리얼 엔진 4.20 릴리즈에서 찾을 수 있습니다. 언리얼 엔진 개발자 커뮤니티가 이 툴을 어떻게 활용할지 정말 기대가 큽니다.
이 툴 관련 자세한 내용은 아래 링크를 참조하세요.
프록시 지오메트리 툴 - 언리얼 엔진 4 프로젝트의 비주얼 퀄리티는 유지하면서 퍼포먼스를 향상시키기 위해 개발한 툴입니다.
계층형 레벨 오브 디테일 - 씬에 렌더링해야 하는 액터 수를 줄이는 기능으로, 프레임당 드로 콜 수를 줄여 퍼포먼스를 향상시킵니다.