카메라를 활용한 게임 성능 최적화: 파트 2

카메라를 활용한 게임 성능 최적화: 파트 2를 소개합니다. 아직 파트 1을 읽지 않으셨다면 여기를 확인해 보세요. 지난번에 이어 프로파일러 결과를 심도 있게 살펴보겠습니다.

빌트인 렌더 파이프라인에서 Camera.Render 프로파일러 마커는 메인 스레드에서 각 카메라를 처리하는 데 소요되는 시간을 측정합니다.

카메라마다 Camera.Render 마커가 있으며 아래 그래프에 테스트 케이스별로 요약해 두었습니다.

로드가 높은 시나리오에서는 적절한 수준 내에서 기기별로 서로 다른 로드 요소를 선택하여 총 프레임 시간을 높였습니다. 프레임 간 성능 변동성으로 인해 카메라를 추가하는 비용이 다소 가려질 수 있으므로 로드가 지나치게 높으면 신뢰할 만한 결과가 도출되지 않습니다.

테스트 결과에 따르면 Camera.Render에서 소요되는 시간은 카메라 수에 직접적인 영향을 받습니다. 이는 네 번째 씬에 아무 것도 렌더링하지 않는 카메라를 추가하는 경우에도 마찬가지입니다.

유니버설 렌더 파이프라인(URP)의 프로파일러 타임라인 뷰에서 가장 먼저 눈에 띄는 것은 바로 대부분 막대가 초록색(렌더링)이 아닌 파란색(스크립트)이라는 점입니다. 녹색 막대는 빌트인 렌더 파이프라인에서 모든 렌더링 코드가 위치한 Unity 엔진 렌더링 코드의 C++ 측에서 소요되는 시간을 나타냅니다. URP는 스크립터블 렌더 파이프라인이며, 많은 렌더링 코드가 C#으로 변경되어 사용자가 보다 자유롭게 렌더링 과정을 커스터마이즈할 수 있도록 합니다.

Inl_UniversalRenderPipeline.RenderSingleCamera 프로파일러 마커는 메인 스레드에서 각 카메라를 처리하는 데 소요되는 시간을 측정합니다. 편리하게도 각 마커에는 해당 카메라의 이름이 접미사로 포함되어 있습니다.

그러나 빌트인 렌더 파이프라인 테스트와 같은 방식으로 카메라 마커를 요약하면 URP의 총 성능을 정확하게 파악할 수 없습니다. 위 그림에서 볼 수 있듯 Inl_Context.Submit 마커에서 소요되는 상당한 시간도 고려해야 합니다. 이는 빌트인 렌더 파이프라인의 Camera.Render 마커에 포함된 드로우 커맨드 버퍼를 생성하는 데 소요된 시간입니다. 보다 간편한 테스트를 위해 여기에서는 이 모든 것을 포함하는 RenderPipelineManager.DoRenderLoop_Internal 마커를 선택합니다.

일관성을 위해 빌트인 렌더 파이프라인 시나리오에서와 동일하게 높은 로드 요소를 사용했습니다.

이번 테스트를 통해 다시 한 번 코드 렌더링에 소요되는 시간이 카메라 수의 영향을 직접 받는다는 점을 알 수 있습니다. 빌트인 렌더 파이프라인 테스트에서와 마찬가지로, 네 번째 씬에 아무 것도 렌더링하지 않는 카메라를 추가하더라도 동일한 결과를 볼 수 있습니다.

이쯤에서 빌트인 렌더 파이프라인과 URP의 성능 특성을 자세히 비교해 보면 이상한 결과를 몇 가지 발견할 수 있습니다. 예를 들어 높은 로드 테스트를 기준으로 Galaxy S7 Edge에서는 URP가 빌트인 렌더 파이프라인보다 훨씬 효율적이었지만, iPhone 모델에서는 그렇지 않았습니다. 이번 포스팅이 너무 길어지거나 주제에서 벗어날 수 있으니 이 부분은 별도의 블로그 포스팅에서 살펴보겠습니다.

실제 환경의 카메라 사용 시나리오를 몇 가지 살펴보고 대안을 논의해 보겠습니다.

씬 뷰에서 씬 가운데에 커다란 캔버스를 두면 방해가 될 수 있습니다. 일부 사용자는 'Screen Space - Camera'로 설정된 캔버스를 렌더링하는 별도의 UI 카메라를 멀리 배치하여 이 문제를 해결하기도 합니다. Unity 2019 이후 버전에서는 계층(Hierarchy) 창에서 자식 게임 오브젝트 가시성을 전환하여 방해되는 캔버스를 숨길 수 있습니다. Unity 툴바의 Layers 드롭다운 메뉴를 사용할 수도 있습니다.

캔버스의 순서를 지정하는 데 카메라를 사용하는 사용자도 있습니다. 하지만 카메라는 이 작업에 적합한 툴이 아닙니다. 대신 캔버스의 Sort Order 또는 Plane Distance를 사용하세요. 하지만 중첩된 캔버스는 'Override Sorting' 옵션을 반드시 고려해야 합니다.

또 다른 케이스로는 UI 화면의 가시성 전환을 위해 컬링 마스크로 게임 UI의 서로 다른 부분을 렌더링하는 별도의 카메라를 사용하는 경우가 있습니다. 이를 적절하게 수행하려면 게임 오브젝트를 활성화하거나 캔버스 컴포넌트의 활성화 플래그를 사용해야 합니다.

UI와 관계가 없는 마지막 사례는 시점 간 전환을 위해 여러 카메라를 사용하는 경우입니다. 이때 모든 카메라가 활성화되고 표시할 카메라를 제어하기 위해 카메라 렌더링 순서, 즉 Depth 속성이 사용되면 최악의 시나리오가 발생합니다. 이 경우 모든 카메라를 완전히 렌더링하게 되어 매우 많은 비용이 발생합니다. 사용하지 않는 카메라를 비활성화하면 이러한 비용을 없앨 수 있지만, 카메라는 하나만 사용하고 항상 현재 활성 상태인 시점에 배치하는 것이 가장 좋습니다. 이렇게 하면 실수로 여러 대의 카메라를 활성화하지 않게 되며 카메라 관리 과정도 간소화됩니다.

카메라를 불필요하게 여러 대 사용하는 상황을 방지해야 하지만, 때로는 이것이 최적이거나 유일한 방법인 경우도 있습니다. 일반적으로 다음과 같은 경우에는 다중 카메라가 적합한 선택일 가능성이 높습니다.

• 카메라 출력. 여기에는 렌더링 표면(Display, RenderTexture)과 뷰포트 직사각형이 포함됩니다.
• 해상도. 카메라의 출력에는 하나의 해상도만 사용할 수 있습니다. 하지만 카메라에 사용되는 렌더링 파이프라인 내부의 중간 결과물은 임의의 해상도로 렌더링하여 카메라 출력을 생성하는 데 사용될 수 있습니다. 이러한 사례 중 하나는 HDRP의 Low-Resolution Transparent 패스입니다.
• 시야각, 포지션 및 방향. 이러한 파라미터는 컬링 절두체를 직접 정의합니다. 이에 대한 예외로는 Unity에서 카메라를 서로 매우 가깝게 붙여서 두 눈을 속이는 XR이 있습니다.

다중 카메라를 사용하는 유효한 사례 몇 가지를 소개합니다.

디스플레이 해상도가 매우 높은 최신 (모바일) 장치의 GPU 성능을 높이는 일반적인 방법은 씬을 낮은 해상도로 렌더링한 다음 최종 해상도로 업스케일하는 것입니다. 이 시나리오에서 최소한 UI의 일부를 업스케일된 씬이 아닌 원래 해상도로 렌더링하여 더 정교한 UI 스프라이트와 이미지를 얻으려는 게임도 많습니다. 이러한 유형의 렌더링 구성에는 서로 다른 두 가지 해상도가 사용되기 때문에 별도의 카메라가 필요합니다.

카메라의 위치 또는 해상도가 서로 다른 다중 하위 디스플레이에도 여러 대의 카메라가 필요합니다. 예를 들어 분할 화면 게임에서는 각 플레이어가 시점을 독립적으로 움직일 수 있습니다.

두 번째 시점에서 씬의 일부를 표시하는 동적 광고판에는 자체 텍스처로 RenderTexture가 필요합니다. RenderTexture를 생성하기 위해서는 별도의 카메라가 필요합니다.

이번 포스팅 시리즈에서는 Unity의 빌트인 렌더링 파이프라인과 유니버설 렌더 파이프라인에서 카메라를 추가했을 때 드는 비용을 측정해 봤습니다. 측정 결과, 씬의 불필요한 카메라는 비용을 유발하며, 이를 간단하게 방지하여 성능상의 이점을 얻을 수 있음을 확인했습니다.

마지막으로, 아무것도 렌더링하지 않는 카메라가 왜 성능에 큰 영향을 미치는지 의문을 가질 수 있습니다. 첫 번째 주된 이유는 Unity가 카메라에 실제로 아무것도 포함되어 있지 않은지 파악하려면 상당한 양의 작업을 처리해야 하기 때문입니다. 두 번째 이유는 솔직히 말해 Unity가 차선의 카메라 설정에 최적화되어 있지 않기 때문입니다. 이러한 설정을 기준으로 엔진을 최적화하면 잘 구성된 게임의 속도가 느려지고 더 많은 메모리를 사용해 바람직하지 않을 수 있습니다.

Accelerate Solutions Games 팀에 관한 자세한 내용과 게임 개발 과정에서 지원 사항이 궁금하다면 유니티 홈페이지를 방문하거나 유니티 세일즈 담당자에게 문의하여 다음 프로젝트의 생산성을 향상시키는 방안을 알아보세요.

Accelerate Success 콘텐츠 시리즈가 마음에 드셨다면, 팀 리드인 Andrea와 Sebastian이 제공하는 최신 Accelerate Success 웨비나: Unity UI makeover의 녹화본도 확인해보세요. 이 데모에서 Andrea와 Sebastian은 잘못 설계된 UI를 없애고 게임이 더 빠르고 효율적으로 실행되도록 UI를 개선하는 방법과 베스트 프랙티스를 알려 드립니다.