nsight-graphics 란?

https://developer.nvidia.com/nsight-graphics

Nsight Graphics는 NVIDIA에서 제공하는 그래픽 디버깅 및 프로파일링 툴로, 게임 개발이나 그래픽 애플리케이션 개발에서 성능 최적화와 문제 해결을 돕는 도구입니다.

• 프레임 분석: 개별 프레임을 세밀하게 분석하여 렌더링 파이프라인의 각 단계에서 발생하는 성능 병목을 파악할 수 있습니다.
• 셰이더 디버깅: 셰이더 코드를 실시간으로 디버깅하고 성능을 분석할 수 있어, 비효율적인 셰이더나 그래픽 문제를 빠르게 찾아 해결할 수 있습니다.
• GPU 성능 분석: GPU 사용량과 자원 분배를 분석해 성능 병목을 파악하고, 멀티스레딩 및 CPU와 GPU 간의 효율적인 작업 분배를 돕습니다.
• 메모리 분석: GPU 메모리와 VRAM 사용을 추적하여 메모리 누수나 과도한 사용을 발견하고, 리소스 최적화를 지원합니다.
• API 호출 추적: DirectX, Vulkan, OpenGL 등 다양한 그래픽 API 호출을 추적하여 비효율적인 패턴을 찾고 수정할 수 있습니다.
• 프레임 리플레이: 문제가 있는 프레임을 저장하고 나중에 재생하여, 렌더링 오류나 크래시 문제를 효과적으로 디버깅할 수 있습니다.
• 실시간 성능 모니터링: 게임 실행 중 HUD와 성능 그래프를 통해 성능 상태를 실시간으로 확인하고 최적화 포인트를 찾을 수 있습니다.

nsight-graphics으로 분석할 수 있는 것

홈페이지에서 소개하고 있는 내용을 먼저 살펴보겠습니다.

Track GPU Performance
최소한의 오버헤드로 GPU 처리량과 사용률을 분석하여 편향되지 않은 활동 데이터를 수집합니다.
캡처된 타임라인에서 중요한 성능 마커를 세부적으로 분석하고, 하드웨어 유닛의 처리량, 캐시 적중률, 메모리 처리량 등을 검사할 수 있습니다.

Analyze GPU Traces
Nsight Graphics는 캡처된 GPU 추적에 대한 자동 성능 분석을 지원합니다.
스트리밍 멀티프로세서(SM) 성능에 대한 심층 프로파일링은 여러 프레임에 걸친 셰이더 실행을 자동으로 추적하여 이루어집니다.

Debug Ray-Tracing and Shaders
레이 트레이싱 API 호출을 디버깅하고 상태를 검사할 수 있습니다. Ray Tracing Inspector는 가속 구조를 노출하여 씬의 지오메트리와 레이의 교차를 최적화하는 데 도움을 줍니다.
또한 레이 트레이싱의 효율성을 확인하여 레이 탐색 속도가 높은지 확인할 수 있습니다.

Vulkan 셰이더 디버거를 통해 셰이더 코드를 디버깅할 수 있으며, 이를 통해 렌더 파이프라인에서 실시간으로 셰이더 소스를 확인하고 직접 수정할 수 있습니다.

Profile Ray-Tracing Shaders
Nsight Graphics의 셰이더 프로파일러는 셰이더 데이터를 노출하여, 정체 현상과 그 원인을 파악할 수 있게 합니다.
실시간 셰이더 프로파일러는 실시간으로 가장 비용이 많이 드는 셰이더를 확인할 수 있습니다.
셰이더 타이밍 히트맵은 픽셀별로 셰이더 처리 시간 지연이 발생한 부분을 씬에 겹쳐 시각화합니다.

레이 트레이싱 셰이더의 프로파일링은 GPU에 대한 광범위한 지식을 요구하는 복잡한 작업이지만, 이러한 기능을 통해 프로파일링 과정을 간소화하고 직관적으로 만들 수 있습니다.

Export C++ Capture
CPU 부하가 적은 환경에서 프레임 분석을 수행할 수 있는 독립된 C++ 프로젝트를 생성합니다.
이를 통해 원래의 애플리케이션에 구속되지 않고 반복 가능한 고립된 분석을 수행할 수 있으며, 최적화 실험을 안전하게 진행할 수 있는 보호된 환경을 제공합니다.

요약해보면… 아래 정도겠군요.
“GPU 성능 분석, 셰이더 및 레이 트레이싱 디버깅, 실시간 프로파일링을 통해 게임 및 그래픽 애플리케이션 개발에서 최적화와 문제 해결을 돕는 도구”

살짝 사용해본 경험

• 테스트해볼 테스트 프로그램을 찾고 실행하는데 까지 뭔가 어렵다는 느낌은 있었습니다만 실행은 해보았어요.
• Nsight Graphics를 실행 -> Start Activity 할때 사용할 프로그램을 선택하고 실행하면 알아서 프로파일링 툴이 프로그램에 붙습니다.
• 프레임 디버깅을 실행했을 때, 렌더링 이벤트에 따라 어떤 API들이 호출되는지 디버깅할 수 있네요. (사실 봐도 어떤 내용인지 모르겠음)
• Draw, Command 실행 등 눈에 띄는 이벤트나 API들을 확인할 수 있었습니다.

Nvidia 예시로는 이렇게도 다 볼 수 있다는데… 툴 창에서 이것저것 더 만져봤어야하나봅니다 😂

Nvidia 그래픽카드에서 동작할 경우 그래픽스 디버깅에 사용할 수 있는 툴로 사용해볼 수 있겠네요.
(AMD 그래픽카드에서 사용할 수 있는지는 모르겠군요)
엔비디아가 하드웨어 레이 트레이싱을 밀고 있어서 이 툴에도 레이 트레이싱 디버깅과 관련한 기능이 좀 있다는 생각도 들었습니다.

짧게 살펴보고 이만 마치겠습니다 😁

가이드 문서, 자료

• NVIDIA Nsight videos: https://www.nvidia.com/en-us/on-demand/playlist/playList-c9450de5-2ffd-4ea9-8a1b-24aeeaf49d4e/

다른 그래픽스 분석 툴

• RenderDoc: https://renderdoc.org/
• Intel Graphics Performance Analyzers: https://www.intel.com/content/www/us/en/developer/tools/graphics-performance-analyzers/overview.html

언리얼 엔진 5 소식

소개: https://www.unrealengine.com/ko/blog/unreal-engine-5-4-is-now-available?tags=games
상세 릴리스 노트: https://dev.epicgames.com/documentation/ko-kr/unreal-engine/unreal-engine-5.4-release-notes

지난 4월, 언리얼엔진 5.4 출시 이후 내용 정리는 다소 늦은 감이 있지만 공부차원에서 정리해봅니다.

주요하게 다룬 내용은 다음과 같습니다. 영상도 참고해보시면 좋을 것 같아요.
https://youtu.be/1vsb7egA7LQ?si=s1uLgP_NpQo59atK

1. 나나이트 테셀레이션과 렌더링 개선: 나나이트 테크놀로지를 통해 실시간으로 영화 수준의 3D 퀄리티를 제공하며, 데이터 사이즈 최적화와 함께 다양한 디테일 생성이 가능해졌습니다.
2. 렌더러 병렬성 향상: 렌더링 시간과 GPU 사용 시간 감소로 인한 컨텐츠 렌더링 부분에서의 큰 최적화로, 엔진만 업데이트해도 프레임 속도가 향상됩니다.
3. 생동감 있는 환경 및 캐릭터: 애니메이션과 관련된 다양한 기능이 추가되어, 특히 모션 매칭 기능을 통해 자연스러운 캐릭터 이동 및 애니메이션이 가능해졌습니다.
4. 애니메이션 데이터 및 메타 휴먼 호환: 500개 이상의 애니메이션 클립 준비 중이며, 메타 휴먼과의 호환을 통해 다양한 캐릭터 모션 제작이 가능해집니다.
5. 사운드와 물리 엔진 개선: 메타 사운드 기능과 더불어, 물리 엔진 관련 기능의 개선을 통해 더 자연스러운 게임 환경 구현이 가능해졌습니다.
6. 프로시저러 콘텐츠 생성(PCG) 툴의 개선: 대규모 맵 생성을 위한 PCG 기능이 향상되어, 넓은 영역을 퀄리티 저하 없이 절차적으로 채울 수 있게 되었습니다.
7. 생산성 향상 도구: 애니메이션, 캐릭터 제작, 키프레임 작업의 유용성 향상과 함께, 컨트롤 리그와 스켈레탈 편집 기능의 강화로 생산성이 크게 개선되었습니다.
8. 클라우드 기반 개발 지원 강화: 언리얼 클라우드 서비스와 분산 빌드 시스템을 통해 팀워크와 협업이 강화되었습니다.

나나이트 테셀레이션

나나이트는 원래 고해상도 메쉬를 효율적으로 처리하여 성능을 유지하면서도 세밀한 디테일을 제공하는 기술인데
5.4 버전에서 추가된 테셀레이션 기능은 이를 기반으로 더욱 세밀하게 폴리곤을 동적으로 추가하여, 특히 멀리서 보거나 낮은 LOD 단계에서도 자연스럽고 부드러운 표면을 유지하도록 합니다.

주요하게는 실시간 렌더링 성능 향상 항목으로 “기존의 테셀레이션 방식은 높은 성능을 요구했지만, 나나이트 테셀레이션은 이러한 성능 부담을 나나이트 엔진의 효율적인 처리 메커니즘을 통해 경감시킵니다.”
테셀레이션 기술을 나나이트에서 지원해서 더 고해상도 메쉬를 잘 처리해보겠다는 것으로 이해했습니다.

컴퓨터 그래픽스에서 테셀레이션이란?
GPU 파이프라인이 처리하는 기하적인 개체를 프리미티브(Primitive)라고 하는데, 하나의 프리미티브를 여러 개의 작은 프리미티브로 잘게 나누는 것을 “테셀레이션(Tessellation)”이라고 한다.
**테셀레이션(Tessellation)**은 기본적으로 3D 모델을 구성하는 폴리곤(주로 삼각형)을 더 작은 단위로 세분화하여 더욱 세밀한 디테일을 표현하는 기술. 이 과정은 그래픽 하드웨어(GPU)에 의해 수행되며, 더 정교한 모델을 만들거나 실시간 렌더링 시 고해상도 그래픽을 구현할 때 주로 사용됨.
좋은 참고 블로그 링크: https://choi-dan-di.github.io/computer-graphics/surface-tessellation/

-> 아무튼 정리해보면 나나이트를 이용할 때에 더 고해상도의 메쉬를 보여주는 업데이트

생동감 있는 환경 및 캐릭터

“이전 버전에서 실험단계 기능으로 도입되었던 모션 매칭이 이제 정식 버전으로 제공됩니다. 이 기능은 포트나이트 배틀 로얄에서 철저한 테스트를 거쳐 모바일부터 콘솔까지 모든 플랫폼에서 100개 이상의 캐릭터와 NPC에 적용되었습니다.”

이번 5.4 버전 부터 모션 매칭이 들어가면서 더 자연스러운 애니메이션 연결 동작을 구현할 수 있게되었네요.
에픽에서는 애니메이터에게 친화적인 툴세트를 만드는게 중점이었다고 합니다.

프로시저러 콘텐츠 생성(PCG) 툴의 개선

PCG 노드 그래프의 UX 개선 및 노드, 연산자 추가 등 툴 개선이 이뤄졌네요. 주요하게는…

1. 향상된 노드 기반 그래프 시스템
PCG 툴은 기본적으로 노드 기반 그래프 시스템을 사용해 콘텐츠를 절차적으로 생성합니다.
이번 업데이트에서는 노드 인터페이스가 더욱 직관적이고 효율적으로 개선되었습니다.
개발자들은 노드를 연결하고 콘텐츠의 흐름을 정의하는 작업을 더 빠르고 쉽게 할 수 있게 되었습니다.

• 새로운 노드 추가: 더 다양한 절차적 생성 작업을 수행할 수 있는 새로운 노드가 추가되었습니다.
  • 이를 통해 지형 생성, 오브젝트 배치 등의 작업을 더 복잡하고 정교하게 구성할 수 있습니다.
• 개선된 노드 미리보기 기능: PCG 그래프 내에서 각각의 노드가 어떻게 작동할지를 실시간으로 미리 볼 수 있는 기능이 개선되었습니다.
  • 이를 통해 생성 과정 중 오류를 줄이고, 수정 사항을 즉각적으로 확인할 수 있습니다.

2. 속도 및 성능 향상
PCG 툴의 성능이 대폭 향상되었습니다. 복잡한 절차적 콘텐츠를 생성하는 작업에서도 이전보다 더 빠르고 효율적으로 처리할 수 있게 되었습니다.
특히 대규모 맵에서 많은 오브젝트를 절차적으로 배치할 때 성능 이슈가 크게 줄어들었습니다.

• 멀티스레딩 최적화: PCG 시스템이 멀티스레딩을 더 효율적으로 사용하도록 최적화되어, 콘텐츠 생성 속도가 향상되었습니다.
  • 대규모 오브젝트를 생성하거나 배치할 때도 퍼포먼스 저하 없이 작업할 수 있습니다.

3. 블루프린트 및 데이터와의 통합 강화
PCG 툴은 이제 블루프린트 및 데이터 자산과 더 긴밀하게 통합되어, 개발자들이 절차적 콘텐츠를 더 유연하게 제어할 수 있게 되었습니다.
이를 통해 다양한 외부 데이터나 게임 로직을 PCG 프로세스에 쉽게 적용할 수 있습니다.

• 블루프린트와의 상호작용: PCG에서 생성된 콘텐츠가 블루프린트를 통해 더 세밀하게 제어될 수 있으며, 이를 통해 동적으로 변화하는 콘텐츠를 게임 내에서 쉽게 적용할 수 있습니다.
• 데이터 에셋 기반 생성: 데이터 에셋을 기반으로 콘텐츠를 생성할 수 있어, 게임 내 데이터에 맞춘 유동적인 콘텐츠 생성을 구현할 수 있습니다.

4. 더 나은 디버깅 및 프로파일링 도구
절차적 생성의 복잡성을 해결하기 위한 디버깅 및 프로파일링 도구가 강화되었습니다.
개발자는 생성된 콘텐츠의 흐름을 시각적으로 확인할 수 있으며, 특정 절차가 어떻게 실행되고 있는지 더 명확하게 분석할 수 있습니다.

• 실시간 디버깅: 생성 과정에서 발생할 수 있는 오류나 비효율성을 실시간으로 확인할 수 있습니다.
• 프로파일링 도구 개선: PCG 작업의 성능을 분석하고, 어디에서 병목이 발생하는지 쉽게 파악할 수 있도록 도구가 업데이트되었습니다.

5. 배치 시스템 개선
PCG 툴의 배치 시스템이 더욱 정교해졌습니다.
특히 랜드스케이프나 지형 위에 절차적으로 오브젝트를 배치하는 과정에서, 더 자연스럽고 현실적인 배치가 가능해졌습니다.

• 랜드스케이프와의 통합 강화: 랜드스케이프(지형)와의 상호작용이 개선되어, 지형 위에 오브젝트를 절차적으로 배치할 때 더 정교한 배치가 가능합니다.
• 배치 규칙 추가: 지형의 높이, 기울기, 텍스처 등을 기준으로 오브젝트를 배치할 수 있는 더 많은 규칙들이 추가되었습니다.

PCG에서 주요한 것은 콘텐츠를 얼마나 생산성을 올릴 수 있는가,
절차적 생성을 통해 여러가지 에셋을 만들고 반복적인 작업을 덜어낼 수 있는가에 있는 것 같네요.
지금도 PCG를 하는중에 디버깅이 어렵거나 원하는 방향대로 안되는 경우가 많을거라 지속 개선이 필요하기도 합니다.

클라우드 기반 개발 지원 강화

이번 업데이트에는 클라우드 기반의 DDC(파생 데이터 캐시) 호스팅 시스템 등 개발 생산성, 관리 효율을 올리는 업데이트가 많았던 것 같습니다.

추가로 언리얼 빌드 액셀러레이터(Unreal Build Accelerator, UBA)를 선보여 분산 빌드 솔루션도 생겼네요.
그동안은 인크레디빌드나 SN-DBS를 쓰는 개발사가 많았는데 얼마나 사용하게 될지 궁금해집니다.

짧은 개발 공부 - 디터미니스틱 패키징, 디터미니스틱 쿠킹

언리얼 한정 이슈인지는 모르겠으나 빌드를 생성한 뒤에 패치할 때 변경된 내역에 따라 발생하는 업데이트/패치 사이즈와 연관된 내용입니다.

빌드 생성시 패키징할 때마다 애셋이 변경되지 않아도 패키지가 변경되는 경우가 있습니다.

이런 경우에 패키지가 In-deterministic(인디터미니스틱, 해석: 비결정론적)하다고 표현하고 Deterministic(해석: 결정론적)할 수 있도록 패키징 중에 어떤 일이 일어나는지 분석, 수정합니다.

패키지가 Deterministic하다면 매 업데이트 마다 빌드의 변경 내역이 줄어들고 패치 사이즈가 줄어들겠죠.

디터미니스틱(결정론적이라는 표현보다는 이렇게 표현하는게 더 좋은 것 같네요) 패키징이 안되는 이유, 인디터미니스틱하게 패키징이 되는 원인은 주로 어떤 것이 있을지 살짝 살펴보면..

(주요 원인) 매 빌드, 패키징마다 애셋, 애셋과 연관된 데이터들이 변경된다

• 레퍼런스가 변경되었으나 패키징 과정에서 경로 해석에 따라 변경
• 데이터테이블 데이터 중 파일 경로를 사용하는 경우, 입력된 파일 경로와 실제 파일 경로가 다르지만 대소문자 정도의 차이일 경우 해석에 따라 패키징 타임에 해석되어 패키징될 경우 변경

언리얼 커뮤니티 아티클

https://dev.epicgames.com/community/learning/knowledge-base/oDGP/unreal-engine-deterministic-builds-and-cooking

아티클에서는 Non deterministic이라는 표현을 쓰고 있는데 동일하게 패키지를 하면서 바뀌는 것의 설명이라 동일하다고 볼 수 있을 것 같네요.

에픽 게임즈가 해결해야하는 부분과 개발사가 해결해야하는 문제를 나눠서 볼 수 있는데 개발사 해결해야하는 내용 중심으로 보겠습니다.

One issue we have seen in the past is that some third party tools can cause deterministic cooking errors. One example was a code integration from a third party that added a globally unique identifier (GUID) to Primitive Components, but regenerated it each time. This caused level files to have deterministic cooking problems, and patch sizes to increase dramatically.

써드 파티 툴에 의해서 컴포넌트에 ID가 변경되는 케이스가 있었고 그에 따라 패키지가 변경되는 케이스가 있었다고 하네요.
툴, 플러그인을 사용할 경우 주의해야하는 영역이겠네요.

다른 하나가 더 있는데 항목이 길어서 요약해보면..

프로젝트 측 로직으로 인해 비결정적 쿠킹 문제가 발생할 수 있습니다. 예를 들어, C++에서 직렬화된 변수에 결과가 저장되는 비결정적 행동을 가진 블루프린트 노드를 정의하고, 이를 블루프린트 구성 스크립트에서 호출하는 경우가 있습니다. 이러한 스크립트는 쿠킹 과정 중에 실행되므로, 주의를 기울이지 않으면 각 쿠킹마다 행동이 달라질 수 있고, 결과적으로 자산이 달라지며 패치 크기가 인위적으로 증가할 수 있습니다. 이를 피하기 위해, 구성 스크립트에서 호출할 필요가 없는 블루프린트 노드를 구성 스크립트에 배치하지 않도록 표시할 수 있습니다. C++에서 구성 스크립트 호출 가능 노드를 정의할 때는 신중하게 접근해야 합니다.

요약해도 긴 내용이네요. 스크립트에 랜덤한 로직이 있을 경우 패키징하는 과정에서 달라질 수 있으니 주의해야한다는 내용이겠습니다.
(랜덤 seed를 사용하는 스크립트라거나 패키징 과정에서 변경될 수 있는 값을 참조하는 변수가 있거나..)

짧은 공부 정리

• 디터미니스틱한 패키지, 빌드를 만들고 싶다면 빌드 과정에서 랜덤 요소나 변경될 요소를 없애야 한다.
• 패키지 변경 사항은 패키지를 만들고 비교하고 변경된 패키지에서 어떤 부분에 변경이 있었는지 분석, 수정한다.
• 프로젝트 에셋에 대부분 문제 원인이 있겠지만 엔진이나 툴에도 원인이 있을 수 있다. (플러그인 GUID 변경 케이스)

FileOpenLog, FileOpenOrder

참고 문서: https://docs.unrealengine.com/4.27/ko/Basics/Projects/Packaging/

언리얼 엔진에서 패키지 생성 및 로딩하는 것과 연관이 있는 내용입니다.

참고 문서에서 언급한 내용으로는 아래와 같습니다.

“로드 시간 단축을 위해서는 .pak 파일 순서를 잘 지정하는 것이 중요합니다. .pak 파일 최적의 순서를 지정하는 데 도움을 드리기 위해, UE4 에서는 데이터 애셋의 필요 순서를 알아내어 더욱 빠른 로딩 패키지를 제작하기 위한 툴 세트가 제공됩니다. 개념적으로, 이 프로세스는 프로파일 주도형 최적화와 비슷합니다.”

언리얼 서밋 세션도 있어서 참고해보면,
https://youtu.be/KJUVH_KzLj8?si=QRG7h2Mim5f0KGOD&t=2135

테스트 빌드를 실행할 때에 -fileopenlog 파라미터를 적용해서 실행하고 로그 파일을 빌드시 사용하는 것 입니다. (파일은 {project}/Build/WindowsNoEditor/FileOpenOrder/ 에 위치함)

이 최적화는 Disk보다는 Flash Drive에서 효과적이라고 하네요.
(예시: Disk=HDD, Flash Drive=SSD, USB 드라이브)

언리얼 서밋 세션에서 공유한 예시 수치로는 5.9s → 4.6s, 약 23%가 감소한 수치를 보여줬습니다.
로그를 얻기 위해 실제 유저가 플레이하는 것 처럼 플레이하더라도 많은 게임 데이터를 포함해서 플레이를 하기는 어렵기에 어느정도 감안하고 최적화한다고 봐야할 것 같네요.

마무리

FileOpenLog라는 용어가 일반적인 용어일 줄 알았는데 실제로 사용하는 곳은 언리얼엔진 정도인 것 같습니다.
파일오픈로그(오더) 용어 그대로 파일이 열리는 순서를 최적화해서 로딩 시간을 개선하는 방법, 방법을 위한 파일 정도로 이해하면 좋을 것 같네요.

RenderDoc이란?

https://renderdoc.org/

그래픽 작업, 렌더링 최적화를 위한 프로파일링으로 사용할 수 있는 디버거 툴로 사이트에서 설명하는 내용을 가져와보면 다음과 같습니다.

RenderDoc is a free MIT licensed stand-alone graphics debugger that allows quick and easy single-frame capture and detailed introspection of any application using Vulkan, D3D11, OpenGL & OpenGL ES or D3D12 across Windows, Linux, Android, or Nintendo Switch™.
→ 요약해보면 오픈소스 그래픽 디버거로 쉬운 프레임 캡처와 상세 분석(검사)을 할 수 있는 툴입니다.

RenderDoc은 Github에서 소스를 공개하고 있으며 빌드는 홈페이지에서 다운로드 받을 수 있습니다.

Source: https://github.com/baldurk/renderdoc
Download: https://renderdoc.org/builds

RenderDoc으로 분석할 수 있는 것

언리얼 서밋 2019에서 다룬 내용을 중심으로 정리해보려합니다.

영상에서는 언리얼 엔진에서 RenderDoc 플러그인을 설정하고 보여주고 있어서 언리얼 엔진의 렌더링 파이프라인에 맞춰 정리해보겠습니다.

위 파이프라인은 추상화한 내용으로 더 자세한 내용은 참고 자료 링크로 남겨두겠습니다.
쉬운 이해를 위해 추상화를 하면서 그림을 그리는 단계와 비교해서 쉽게 설명해주셨어요.

밑그림 - 밑그림 색칠 - 다듬기 - 그리기 - 마무리
각 단계별로 어떤 내용들을 볼 수 있는지 알 수 있었습니다.

⭐ 요약 ⭐

• PrePass - BasePass - Lighting - Translucency 각 단계에서 일어나는 일을 분석할 수 있음
• Event Browser 에서 각 단계의 이벤트를 확인하고 Texture Viewer, Mesh Viewer, Pixel History 등의 기능을 통해 분석, 프로파일링할 수 있다

PrePass - 밑그림

RenderDoc에서 렌더링 파이프라인에 따라 이벤트가 발생하고 그 시점에 따라 분석할 수 있게 되어있네요. (화면 왼쪽에 Event Browser에서 확인할 수 있음)

위에서 보고 있는 event는 PrePass(PrePass DDM_AllOpaque …)입니다.

이 단계에서는 하위 이벤트에서 각 에셋들의 메쉬들을 Mesh Viewer를 통해 확인하고 과도하게 메쉬를 복잡하게 만들지 않았는지를 확인할 수 있습니다.
(폴리곤을 과도하게 사용하지는 않았는지 = 너무 디테일하게 메쉬를 만들었는지)

BasePass - 밑그림 색칠

BasePass는 PrePass와 동일하게 모델을 화면에 맞게 변형합니다. 그 후에 PrePass과 대조해서 필요한 곳에만 색칠하는 작업을 반복합니다. PrePass를 이용하여 필요한 곳만 색칠할 수 있습니다.
이 단계에서는 Texture Viewer에서 각 에셋을 텍스쳐로 색칠하는데에 필요하지 않은 텍스쳐가 사용되거나 잘못된 경우를 찾아볼 수 있습니다.

영상 예시로는 범용 머터리얼을 사용해서 발생한 이슈로 필요한 텍스쳐만 사용하는 머터리얼로 수정하고 해결하는 것을 볼 수 있었습니다.

Lighting - 다듬기

Lighting 단계에서는 에셋들이 빛의 영향을 잘 받는지 비효율적으로 빛의 범위가 크게 설정되어있지는 않은지 확인할 수 있습니다.

라이팅 각 이벤트를 눌러보고 Texture Viewer의 Outputs를 보면 어떻게 라이트가 적용되어 렌더링 씬이 바뀌어가는지 알 수 있어요.

영상에서는 불필요한 큰 라이트 범위를 조정해서 라이팅 렌더링 비용을 개선했습니다. 👍

Translucency - 그리기

이 단계는 대략 그림이 완성되었으니 마지막 마무리로 계속 이미지를 겹쳐서 그리는 단계입니다.
이 때에 추가로 그리는 범위가 커질수록, 겹쳐서 그릴수록 어려워지게됩니다. (비용이 커짐)

이 부분에 대한 프로파일링, 최적화는 언리얼 엔진 에디터에서도 쿼드 오버드로(Quad Overdraw)나 셰이더 복잡도(Shader Complexity) 뷰를 통해서 보고 개선해볼 수 있습니다.

RenderDoc에는 Pixel History 기능을 통해서 픽셀이 어떻게 변화했는지 볼 수 있는 편리한 기능이 있습니다.

1. Texture Viewer → Outputs → 이미지에서 확인하고자하는 픽셀 영역을 오른쪽 버튼을 누릅니다
2. Outputs 하단에 History를 누릅니다 → 픽셀이 변화한 히스토리를 확인합니다

영상에서는 확인한 곳의 픽셀은 안개에 의해 색이 변해야하는 곳인데 변하지 않는 것을 픽셀 히스토리를 통해서 확인 → 개선!

PostProcess - 마무리

PostProcess 단계는 포토샵의 필터 적용과 같은 단계로 볼 수 있는데요. RenderDoc에서 언리얼 엔진의 PostProcess를 보기는 쉽지 않다고 합니다.
어떤 기능에 의해 합쳐진 효과들이 적용되고 보이게되어서 RenderDoc에서는 한계가 있다고 합니다.

나중에 엔지니어나 TA 분에게 물어보고 공부해보는 것으로 해야겠군요 😃

마무리

오랜만에 최적화 부분을 이것저것 들여다보니 재미있었네요. 😎
찾다보니 RenderDoc은 오픈소스로 알려져있는 툴이고 Nvidia나 Intel에서도 분석툴이 있어서 나중에 한번 슬쩍보는 것도 재미있겠다 싶습니다.
나중에 시간나는대로 Nvidia 부터 살펴보고 포스트해보겠습니다. 👋

가이드 문서, 자료

• https://youtu.be/EF0YpKHfbAw
  • 언리얼 서밋 2019 아티스트를 위한 흥나는 프로파일링!: RenderDoc
  • 추가적인 내용은 위 영상을 참고하면 좋을 것 같습니다
• 가이드 문서-튜토리얼: https://renderdoc.org/docs/getting_started/quick_start.html
• 가이드 영상 모임: https://www.youtube.com/user/baldurkarlsson
• 언리얼 파이프라인: https://unrealcommunity.wiki/unreal-schematics-2d6859
• 언리얼 엔진 RenderDoc: https://docs.unrealengine.com/4.26/ko/TestingAndOptimization/PerformanceAndProfiling/RenderDoc/

다른 그래픽스 분석 툴

• Nvidia Nsight Graphics: https://developer.nvidia.com/nsight-graphics
• Intel Graphics Performance Analyzers: https://www.intel.com/content/www/us/en/developer/tools/graphics-performance-analyzers/overview.html