SEED가 월드 플레이어를 어떻게 렌더링하는가, 멈추지 않고 건설하는

선수들이 무엇을 만들지 예측할 수 없습니다. SEED에서 그것이 전부이자 핵심 렌더링 과제입니다.

SEED는 Unity로 제작된 Klang Games의 영구적인 MMO 샌드박스입니다. 플레이어들이 씨앗(seedlings)이라고 불리는 자율 캐릭터를 관리하고, 집과 사업체를 짓고, 플레이어 주도 Economy 거래하며, 자신만의 역할과 법을 가진 사회를 조직하는 먼 행성에서 진행됩니다. 플레이어가 로그아웃해도 세상은 계속 돌아가고 끊임없이 성장하고 있습니다. 새로운 집, 웹숍, 나무, 묘목 하나하나가 최고급 PC부터 휴대폰까지의 하드웨어 전반에 걸쳐 Unity 렌더링 성능에 더 많은 부담을 줍니다.

시뮬레이션 자체는 클랑 게임즈의 서버에서 실행됩니다. Unity 클라이언트의 임무는 서버가 스트리밍하는 모든 상태를 렌더링하는 것이므로, 그 작업량은 팀이 계획한 것이 아니라 플레이어들이 무엇을 건설했는지에 따라 달라집니다.

" SEED가 완전히 서버 권한의 게임이기 때문에, 클라이언트는 주로 상태를 읽고 렌더링하며 클릭이나 카메라 이동과 같은 플레이어 상호작용을 전달합니다."라고 Klang Games의 그래픽 엔지니어인 Artem Dyadichkin이 말합니다.

저희는 시니어 게임 엔지니어인 Dyadichkin 및 Nikita Fetisov와 유니버설 렌더 파이프라인(URP)을 사용하여 플레이어가 구축한 사회를 렌더링하고, 수천 개의 작은 객체를 저렴하게 유지하며, PC 및 모바일에서 실제 플레이어 데이터를 사용하여 병목 현상을 찾는 것에 대해 이야기했습니다.

작은 조각들로 만들어진 세상

SEED의 아트 스타일은 코드가 실행되기 전에 많은 스케일링 작업을 수행합니다. 게임은 양식화되어 있고 로우 폴리이며, 텍스처에 의존하는 대신 표면 데이터의 대부분을 지오메트리에 저장합니다.

"저희 색상 데이터의 대부분은 사실 정점 데이터 내에 저장되어 있습니다."라고 Dyadichkin이 말합니다. 버텍스 데이터는 자신이 어떤 색인지, 어떤 재질 정의를 가지고 있는지(금속인지, 매끄러운지 등) 알고 있습니다. 그 모든 것들은 메시 자체에 내장되어 있습니다."

그것은 쉐이딩과 메모리 대역폭을 절약해주는데, 이는 모바일에서 가장 중요합니다.

건물들은 극단적인 접근 방식을 취합니다. SEED는 각 구조물을 하나의 큰 메시로 취급하는 대신, 1미터 격자에서 벽, 바닥, 지붕 모서리, 모서리 등 많은 작은 벽돌 모양 모듈로 건물을 구성합니다. 플레이어들은 거친 건축 블록(복셀)을 배치하고, 게임은 각 블록을 약 15개의 모듈로 확장하며, 이 중 절반 정도는 건물의 외관을 형성하고 나머지 절반은 플레이어가 안을 들여다볼 때만 생성되는 내부를 형성합니다. SEED의 가장 번화한 섬 중 하나에 있는 가장 큰 사회는 약 12,500개의 복셀 또는 190,000개의 모듈로 구성된 172개의 건물을 가지고 있습니다.

"저희는 BatchRendererGroup을 사용하여 렌더링하고 함께 배치하며, 이 배치들은 작업을 통해 처리합니다."라고 Dyadichkin이 말합니다. "렌더링해야 할 모듈이 매우 많음에도 불구하고, 건물 자체는 순수 렌더링 성능 측면에서 결코 병목 현상을 일으킨 적이 없습니다."

해당 작업들은 C# Job System에서 실행되며, 팀은 Burst compiler로 이를 컴파일합니다. Dyadichkin은 SEED’의 클라이언트 코드에서 거의 항상 함께 간다고 말합니다.

URP에서 기본 경로를 유지하기

SEED는 URP를 사용하여 PC와 모바일에서 확장하며, Klang Games는 Unity의 기본 설정에 의도적으로 가깝게 유지합니다.

"우리는 Unity 기본 솔루션을 고수하려고 노력합니다. 그래야 다음 업데이트가 나올 때마다 항상 커버될 수 있기 때문입니다."라고 Dyadichkin이 말합니다.

그것이 중요한 이유는 팀이 Unity를 일 년에 한두 번 정도 업그레이드하기 때문입니다. SEED는 현재 Unity 6.3으로 실행되고 있으며, 프로젝트가 성장함에 따라 새로운 렌더링 기능을 채택하고 있습니다. 게임에 커스텀이 필요한 부분은 팀이 URP를 교체하기보다는 확장하여 게임별 효과 및 상호작용을 위해 커스텀 렌더러 기능을 사용합니다.

그들의 Shader Graph 사용도 같은 원칙을 따릅니다. 네이처 에셋은 기본 Lit shader를 사용하고, 캐릭터와 오브젝트는 사용자 지정 조명 패스를 사용하는 Unlit 셰이더를 사용합니다. 어느 쪽이든 팀은 URP의 성능 기능을 손상시킬 걱정을 할 필요가 없습니다.

"Shader Graph 생성하면 SRP스크립터블 렌더 파이프라인) 배칭을 깨뜨리지 않을 것이고, GPU Resident Drawer도 깨뜨리지 않을 것이라고 확신할 수 있다"고 Dyadichkin이 말합니다. "모든 URP 핵심 기능이 여전히 지원되고 있으면서도 셰이더 원하는 대로 커스터마이징할 공간이 남아 있다는 것은 매우 강력합니다."

플레이어가 디자이너가 아닌 클라이언트가 얼마나 그려야 하는지를 결정하는 세상에서 안전망은 중요합니다.

수천 개의 객체와 상호 작용하기

플레이어가 더 밀집될수록 사회를 렌더링하고 그 어떤 부분에도 클릭 수 만드는 것이 더 어려워집니다.

플레이어가 확대되었을 때, SEED는 픽셀 단위의 선택을 사용합니다. 사용자 지정 렌더러 기능은 객체를 별도의 렌더 타겟, 즉 GPU가 화면 대신 렌더링하는 오프스크린 텍스처에 그립니다. 각 객체는 CPU와 GPU 모두 읽을 수 있는 고유 ID로 인코딩됩니다. 클라이언트는 커서 아래의 픽셀을 읽어 플레이어가 정확히 어떤 객체 위에 마우스를 올리고 있는지 찾습니다.

모바일에서는 손가락 끝이 커서보다 훨씬 덜 정밀하기 때문에 클라이언트도 각 탭 주변의 픽셀을 확인합니다. 주변에 객체가 하나 이상 감지되면, 플레이어에게 선택할 목록을 보여주어 밀집된 지역에서 작은 객체를 선택하기 쉽게 만듭니다.

플레이어가 줌 아웃할 때, GPU 피킹은 넓은 시야에 걸쳐 확장하기 어렵기 때문에 클라이언트는 물리 레이캐스트로 다시 전환됩니다.

그 레이캐스트 뒤에는 엄청나게 많은 충돌체들이 있습니다. SEED는 시뮬레이션이 아닌, 이들을 빠르게 부트스트랩하고 쿼리하기 위해 Unity Physics를 사용합니다.

"모든 나무에는 충돌기가 있고, 모든 물체와 잠재적으로 모든 벽돌에는 충돌기가 있을 수 있으며, 캐릭터와 묘목도 마찬가지입니다."라고 Dyadichkin이 말합니다. "우리는 이 방대한 양의 충돌체를 매우 빠르게 부트스트랩하고, 그런 다음 배치 확인 및 기타 상호 작용을 위해 그들에 대해 쿼리를 수행할 수 있습니다."

플레이어가 건물을 열면 내부가 나타나고, 클라이언트는 층을 이동하고 개별 방을 검사하면서 추적해야 할 것이 더 많아집니다. 지속적으로 실행되는 작업은 각 객체가 건물 내부에 있는지 외부에 있는지, 그리고 어느 방과 층을 차지하는지 결정합니다.

"이를 통해 우리는 GameObjects 오브젝트를 비활성화하거나 활성화하거나, 조명 상황을 제어하기 위해 올바른 렌더링 레이어를 설정하는 등 온갖 종류의 작업을 할 수 있습니다."라고 Dyadichkin이 설명합니다.

세계 선수들이 실제로 구축한 프로파일링

플레이어가 구축한 세계를 최적화하는 가장 어려운 부분은 현실적인 데이터를 얻는 것입니다. 클랑 게임즈는 라이브 게임에서 그것을 얻습니다.

팀은 재해 복구를 위해 서버 스냅샷을 보관하며, 플레이어들이 충분히 큰 사회를 구축하면 그 스냅샷들은 테스트 케이스가 됩니다.

"우리는 플레이어들이 실제로 구축한 것을 복원하고 그것을 성능 테스트 및 대규모 기능 테스트에 사용할 수 있습니다."라고 페티소프가 말합니다. "우리는 처음부터 시작하거나 데이터를 직접 시뮬레이션하려고 하기보다는 이러한 구축된 사회들을 활용할 수 있습니다."

대도시 스냅샷을 로컬로 로드하는 과정에서 PC에서 예상치 못한 CPU 렌더링 병목 현상이 발생했습니다.

"저희 게임은 대부분 GPU 병목 현상이 아니라 CPU 병목 현상입니다."라고 Dyadichkin이 말합니다. "그것은 텍스처가 거의 없는 매우 양식화되고 로우 폴리 게임입니다."

Unity Profiler를 사용하여 Dyadichkin은 렌더링 스레드가 예상보다 많은 시간을 드로우 콜 제출에 소비하고 있음을 발견했습니다. 팀은 GPU Resident Drawer를 사용하므로 Dyadichkin은 해당 객체들을 인스턴스화할 것으로 예상했습니다. 프레임 디버거는 다르게 보여주었다.

"우리는 여전히 하이브리드 배치 대신 SRP 배치를 기본값으로 사용하고 있었다"고 Dyadichkin이 말합니다. "GPU Resident Drawer가 이 모든 객체를 캡처하지 못했던 이유는 저희 프리팹 대부분에 LOD 그룹이 있기 때문이었습니다."

SEED의 규모에서는 그 차이가 중요합니다. SRP Batcher는 각 드로우 콜 설정에 드는 CPU 비용을 줄이지만, 여전히 객체당 하나를 제출합니다. GPU Resident Drawer는 메시와 재질을 공유하는 객체들을 인스턴스화된 드로우로 그룹화하여 더 나아가며, 프레임 디버거 이를 하이브리드 배치로 표시합니다. 수천 개의 작은 객체들이 있다는 것이 많은 가벼운 드로우 콜과 몇 개의 큰 드로우 콜 사이의 차이점입니다.

누락된 객체의 원인은 애니메이션 LOD 크로스페이딩이었습니다. 효과는 더 좋아 보였지만, 객체들을 GPU 레지던트 드로어 경로에서 벗어나게 했습니다.

애니메이션 부분을 비활성화했습니다. "우리는 여전히 크로스페이딩을 가지고 있지만, 이제는 수동으로 설정한 전환을 가지고 있습니다."라고 그는 말합니다. 이제 드로우 콜이 다시 인스턴스화되어 CPU 렌더링 스레드의 부하가 줄었습니다.

모바일 메모리 내 성숙한 사회 렌더링

모바일에서 SEED의 렌더링이 다른 제약 사항에 부딪혔습니다. 페티소프는 "모바일 쪽에서는 CPU 바운드가 아니라 메모리 바운드입니다"라고 말합니다. 그것이 우리 프로젝트의 주된 골칫거리입니다.

성숙한 사회는 엄청난 수의 건물, 야외 물체, 캐릭터 및 메쉬를 포함할 수 있습니다. 클라이언트가 렌더링하는 모든 메시와 재질은 먼저 메모리에 들어가야 합니다. Klang Games는 메모리가 어디로 가는지 추적하기 위해 Memory Profiler와 memory snapshot comparisons에 크게 의존합니다. 팀은 깨진 참조로 인해 텍스처가 세 번 저장되었고, 동일한 머티리얼을 중복하는 Addressables 종속성, 그리고 필요 이상으로 큰 C# 컬렉션 때문에 이를 발견했습니다.

"데스크톱에서는 괜찮아서 사람들이 별로 눈치채지 못했지만, 모바일에서는 큰 문제였다"고 페티소프가 말합니다. "저희는 Unity Memory Profiler 상당히 의존했는데, 특히 [메모리] 스냅샷 차이 분석을 많이 사용했습니다."

텍스처가 없더라도 지오메트리는 쌓입니다.

"일부 메시는 꽤 두꺼웠는데, 특히 나무들이 그랬어요."라고 페티소프가 말합니다. "모든 LOD를 로드하면 단일 나무가 메가바이트의 메모리를 차지할 수 있고, 우리는 많은 나무 변형을 가지고 있습니다."

팀이 플랫폼별로 Addressables를 빌드하기 때문에, 게임 코드를 변경하지 않고도 모바일로 간소화된 트리를 배포할 수 있습니다. "데스크톱에서 의자를 로드하는 것과 동일한 코드가 모바일에서도 의자를 로드합니다."라고 페티소프가 설명합니다. "하지만 Addressables 자체는 모바일에 최적화된 에셋일 수 있습니다."

더 큰 변화는 모바일에서 LOD 그룹을 완전히 대체한 것입니다. 클래식 LOD는 객체 유형별로 여러 메시를 메모리에 저장하는 것을 의미했는데, 이는 페티소프가 나무에 대해 설명하는 것과 동일한 비용입니다. Unity 6.2에서 도입된 Mesh LOD는 모든 레벨의 디테일을 단일 메시 내에 저장하며, SEED의 모바일 변형은 이제 이를 독점적으로 사용합니다. 또한 클랑 게임즈의 소규모 아트 팀의 업무 부담을 줄여주었습니다.

"LOD에서 메시 LOD로 전환한 것은 모바일 장치에서 게임 세계를 렌더링할 수 있게 만든 중요한 단계였다"고 페티소프가 말합니다.

플레이어가 다음에 무엇을 만들지 염두에 두고 설계하기

SEED의 핵심 렌더링 문제는 사라지지 않고 있습니다: 플레이어들은 클라이언트가 무엇을 그릴지 결정하고, 그들은 결코 구축을 멈추지 않습니다. "이는 플레이어가 만든 세계에 대해 우리가 구상하는 시각적 충실도와 저사양 기기에서의 안정적인 프레임 속도 사이의 끊임없는 균형입니다."라고 Dyadichkin이 말합니다.

클랑 게임즈는 플레이어가 다음에 무엇을 지을지 예측할 수는 없지만, 이미 지은 것을 테스트할 수는 있습니다.

"첫날부터 목표 규모에 맞춰 설계하고, 구축하고, 테스트하세요"라고 페티소프가 말합니다. "초기에 현실적인 부하에 대해 프로파일링하고 계속하세요."

SEED가 얼리 액세스로 이용 가능합니다. Unity 개발자들의 더 많은 이야기를 Unity Blog와 Resource Hub에서 확인하세요.