[번역] RenderDoc 활용법

역자의 말: 아침부터 세벽 늦은 시간까지 이것 저것들을 하면서 보내느라 머리가 무겁습니다. 회사 관련 사업계획서도 써야지~ 투자 제안서도 써야지~ 컨설팅 고객사 일도 일정대로 마무리 해야지~ 등등. 최근에는 법인 결산 하느라 머리가 아팠습니다. 뭐 그렇고요. 사실 렌더독은 그래픽스 프로그래머 아니면 테크아티스트들이 기본적으로 사용하는거라 이런 번역글이 필요 한가? 하지만 이 다음 블로그 포스팅을 위한 전야제 느낌으로(솔직히 직접 쓰기에는 열정 낭비 같아 보였어요... 인터넷에도 많은데... ) 다가 연장선에서 포스팅을 합니다.
PS: 아... 여기 글에서 등장하는 게임은 좀 된 게임인데 중국 페이퍼컴퍼니 라는 게임사에서 출시한 니키 어쩌고 하는 게임인데요... 예전에 한복 관련 이슈 있었던 회사입니다. 그리고 뭐 개인적으로는 아트디렉터 + 그래픽 팀장 + TA 셋 모두 지인( 예전 넷이즈 ) 들이고 같은 사업부 동료들이었다는 뭐 그런 이야기... 

---

저자: 稻草人

1. 들어가며

꽤 오래전에 쓴 내용인데, 마침 같이 올려봅니다.....

2. 환경 설정

RenderDoc은 PC와 Android 모두 프레임 캡처가 가능한데, Android 캡처를 하려면 환경 설정이 필요합니다.

1. PC에 Android SDK와 JAVA JDK를 설치하고, 환경 변수를 설정해야 합니다(인터넷에 튜토리얼 많아요)
2. RenderDoc에서 Android SDK와 JAVA JDK 설치 디렉토리를 지정

Tools -> Settings 에서 설정 패널 열기

P1.설정
Android 설정 항목으로 이동 후 설치 디렉토리 지정

P2.Android 설정

1. 휴대폰에서 debuggable = true로 설정해야 합니다. 게임을 배포할 때 debuggable 속성이 있는데, 이게 true이면 프레임 캡처 디버깅이 가능합니다. 물론 모든 게임은 기본적으로 false인데, 폰 시스템에는 글로벌 debuggable 속성이 있고 이를 true로 설정하면 강제로 프레임 캡처 분석이 가능합니다. 이 속성을 활성화하는 방법은 폰 시스템마다 다르니 직접 검색해 보세요.....
2. RenderDoc에서 폰 연결하기 — 모든 설정이 완료되면 USB 케이블로 폰을 PC에 연결하면 되는데, 환경 설정이 올바르면 RenderDoc 왼쪽 하단에서 폰을 연결할 수 있어요

모든 설정이 완료되면 USB 케이블로 폰을 PC에 연결하면 됩니다. 환경 설정이 올바르면 RenderDoc 왼쪽 하단에서 폰을 연결할 수 있어요

P3.폰 연결
폰을 클릭하면 연결됩니다

P4.연결 성공
이렇게 표시되면 연결 성공이고 신나게 프레임 캡처 디버깅을 할 수 있어요. 아니라면... 처음부터 다시?

3. 게임 실행 및 프레임 캡처

모든 준비가 완료되면 게임을 실행하고 프레임 캡처를 할 수 있습니다. 실행은 물론 RenderDoc을 통해 게임을 실행하는 방식이에요(수동 실행이 아니라, 글로벌 훅을 걸고 인젝션 후 연결하는 방법도 있습니다). RenderDoc으로 실행하면 RenderDoc이 게임에 프로세스를 인젝션하고, 프레임 캡처 시 이 프로세스들이 게임이 GPU에 보내는 렌더링 정보를 가로채서 정리해 우리 앞에 보여줍니다.

3.1 게임 실행

P5.게임 실행
먼저 Launch Application 창을 열어야 합니다. 없다면 Window -> Launch Application에서 열 수 있어요. 이 창은 프로그램을 실행하는 데 쓰이며, 모든 악행의 시작점이죠.
먼저 ExecutablePath로 게임 실행 파일을 지정합니다. 오른쪽 버튼을 클릭해 선택할 수 있어요. PC라면 exe 파일을 지정하고, Android는 패키지의 실행 파일을 선택합니다. 아래에서 샤이닝니키를 예시로 들겠습니다.

P6.프로그램 선택
폰 연결 후 이런 특수 창이 뜨는데, 왼쪽에는 폰에 설치된 모든 프로그램 파일이 표시됩니다. 니키의 설치 디렉토리를 찾아보세요 — 디렉토리 이름을 모르면 폰에서 앱 정보를 확인하면 설치 디렉토리가 표시됩니다. 선택하면 오른쪽에 실행 파일들이 나오는데, 많죠... 어떤 게 맞는지는 크게 중요하지 않아요. 여러 번 시도해 보면 되니까요(보통 DefaultActivity입니다)...

P7.게임 실행
선택 후 Launch를 클릭하면 프로그램이 실행됩니다. 아래 그림은 프로그램 실행 중인 상태예요.

P8.게임 시작 중
실행에 실패했다면, 환경 문제 외에도 게임 측에서 막아 놓은 경우일 수 있어요. 예를 들어 원신은 프로세스 이름 등을 감지해서 강제 종료시키고 프레임 캡처를 방지하죠. 물론 리버스 엔지니어링 고수에게는 별 소용 없지만요...

3.2 프레임 캡처

실행에 성공하면 RenderDoc에서 프레임 캡처 창이 팝업으로 뜹니다

P9.프레임 캡처 창
Capture Frame(s) Immediately를 클릭하면 게임 프레임 캡처가 됩니다

P10.캡처 성공
캡처에 성공하면 하단에 썸네일이 표시되고, 더블클릭하면 열립니다. 우클릭으로 저장도 가능해서 나중에 이어서 분석하거나 친구에게 공유할 수 있어요. 저장 후 분석하는 걸 추천합니다...

4. 창(윈도우) 소개

RenderDoc의 모든 창은 Windows 메뉴 아래에 있습니다. 여기서는 자주 사용하는 창들만 소개할게요.

P11.창 목록

4.1 Event Browser

P12.EventBrowser
이 창은 보통 RenderDoc 왼쪽에 위치하며, 해당 프레임의 DrawCall 호출을 표시하는 데 주로 사용됩니다.

P13.드로우 내용
드로우 순서는 위에서 아래 방향이고, EID는 현재 DrawCall의 인덱스를 나타냅니다. 작은 시계 아이콘을 클릭하면 오른쪽에 각 DrawCall에 소요된 시간(단위: 마이크로초)이 표시됩니다. DrawCall 중 하나를 선택하면 오른쪽 정보 창에 해당 DrawCall의 드로우 정보가 표시됩니다.

4.2 Texture Viewer

텍스처 미리보기 창으로, 텍스처 리소스를 미리 보는 데 주로 사용됩니다

P14.TextureViewer

1. 현재 선택된 DrawCall이며, 오른쪽에는 현재 DC가 그린 내용이 표시됩니다. 이를 통해 관심 있는 부분을 찾을 수 있어요
2. 텍스처 표시 채널 전환 가능
3. 텍스처 미리보기 창(스크롤로 확대/축소, 드래그로 이동)
4. 텍스처 저장
5. 두 가지 탭 목록 있음 — Inputs는 현재 렌더링에서 사용된 텍스처, Outputs는 현재 렌더링에서 출력된 텍스처

텍스처 중 하나를 클릭하면 3번 위치에 해당 텍스처가 표시됩니다. 더블클릭하면 독립 창으로 열려요

P15.텍스처 미리보기
우클릭하면 해당 텍스처가 어디서 또 사용되는지 표시되고, 클릭하면 그 DC로 이동합니다. 왼쪽 하단에는 현재 텍스처의 해상도와 텍스처 포맷이 표시됩니다. 썸네일 아래에는 해당 텍스처의 이름이 표시됩니다.

4.3 Pipeline State

P16.PipelineState
이 창은 현재 DC(얼굴 렌더링)의 렌더링 과정을 표시하며, 위쪽의 여러 사각형에 각 렌더링 단계가 표시됩니다. 아래를 클릭하면 해당 단계의 정보가 표시됩니다.

4.3.1 Vertex Input

P17.VertexInput
Vertex Input은 애플리케이션 단계에서 버텍스 셰이더로 보내는 정보입니다. 빨간 박스로 표시된 부분이 사용된 메시 정보로, 위치·법선·탄젠트·UV 및 그 저장 포맷을 확인할 수 있어요

4.3.2 Vertex Shader

P18.VertexShader
이 창은 버텍스 셰이더 단계를 표시합니다

• 1 해당 버텍스 셰이더가 사용하는 셰이더. View 또는 Edit 클릭 후 셰이더를 볼 수 있어요(View는 편집 불가). 셰이더를 디컴파일할 수 있으면 디컴파일된 셰이더 코드가 표시됩니다

P19.VertexShaderCode
해당 버텍스 셰이더의 코드입니다. 이 코드를 분석하면 렌더링 로직을 더 명확히 파악할 수 있어요

• 2 해당 셰이더가 사용하는 텍스처. 목록이 비어 있으면 이 단계에서 텍스처를 사용하지 않는 것
• 3 해당 셰이더가 사용하는 텍스처 샘플러
• 4 셰이더가 사용하는 파라미터(엔진 전달 파라미터, 머티리얼 패널 파라미터 포함)가 표시됩니다. 오른쪽 화살표 버튼을 클릭하면 이 파라미터들(이름과 수치)을 더 직관적으로 볼 수 있어요

P20.해당 VertexShader가 사용하는 Buffer 데이터
해당 버텍스 셰이더가 일부 행렬, 구면 조화 함수 등의 파라미터를 사용하는 걸 볼 수 있는데, 이게 소스 코드 분석에 도움이 됩니다

4.3.3 Rasterizer

P21.Rasterizer
이 창은 래스터화 상태를 표시하며, 일반적으로 Cull Mode(컬링 모드)만 신경 씁니다

4.3.4 FS

P22.PixelShader
이 창은 프래그먼트 셰이더를 표시하며, 버텍스 셰이더와 동일하므로 여기서는 더 설명하지 않겠습니다. 일반적으로 텍스처 샘플링은 프래그먼트 셰이더에서 이루어지기 때문에 여기서 텍스처 인덱스가 많이 보이는 거예요. 위쪽에 텍스처 이름·타입·크기·포맷 등이 표시되고, 오른쪽 화살표를 클릭하면 해당 텍스처를 볼 수 있습니다

4.3.5 FB

P23.FB
이 창은 주로 셰이더의 블렌딩 모드, 뎁스 쓰기 활성화 여부, 뎁스 테스트, 스텐실 테스트 등을 표시합니다

4.4 Mesh Viewer

P24.MeshViewer
메시 표시 창으로, 현재 드로우 중인 모델을 표시합니다. 왼쪽 상단(또는 데이터에서 우클릭)을 통해 모델 데이터를 CSV 형식으로 저장할 수 있고, 스크립트를 통해 모델을 복원하여 테스트할 수 있어요.
왼쪽 프레임은 모델의 원시 데이터(버텍스 셰이더 입력 데이터), 오른쪽은 버텍스 셰이더 출력 데이터, 아래쪽은 모델 미리보기입니다

4.5 Timeline

P25.Timeline
현재 캡처한 프레임의 타임라인입니다. 자주 사용하진 않고(보통은 슥 훑으면서 전체 흐름을 빠르게 보고 원하는 위치를 찾는 정도).

4.6 API Inspector

P26.API Inspector
현재 DC의 실제 그래픽 API 호출 정보입니다. 자주 사용하진 않아요.

4.7 Resource Inspector

P27.ResourceInspector
현재 프레임에서 사용된 모든 리소스 캐시로, 오른쪽에 리소스 목록이 있습니다. 더블클릭하면 특정 리소스 정보를 볼 수 있어요. 자주 사용하진 않습니다.

5. 디버깅 분석 시작하는 법

P28.분석 예시

5.1 전체 드로우 흐름

전체 렌더링 흐름을 보고 싶다면 왼쪽 창(EventBrowser)에서 DC 하나하나를 살펴보세요. 전체 렌더링 흐름을 이해하는 데 도움이 되며, 일반적인 흐름은 다음과 같습니다(포워드 렌더링 기준)
그림자 텍스처 렌더링(shadowMap) -> 불투명 오브젝트 렌더링(앞에서 뒤로) -> 투명 오브젝트 렌더링(뒤에서 앞으로) -> 후처리(Gamma 매핑 등 포함) -> UI 렌더링
이 기본 흐름을 파악하면 드로우 과정을 따라가는 게 훨씬 수월해집니다.

P29.전체 드로우 흐름

5.2 단일 오브젝트 렌더링 분석

분석 대상이 명확하다면 해당 오브젝트를 렌더링하는 DC를 찾아서 단독 분석을 하면 됩니다. 여기서는 니키의 얼굴 렌더링을 예시로 들겠습니다. 상하 렌더링 내용 비교와 Mesh Viewer 창을 통해 현재 오브젝트의 렌더링 위치를 파악할 수 있어요.

P30.단일 오브젝트 렌더링 분석
제 캡처에서 얼굴 렌더링의 EID는 898입니다. 분석 전에 해당 부분에 대해 어느 정도 알고 있어야 해요 — 어떤 기술이 사용됐는지, 어떤 텍스처가 쓰였는지. 이게 분석 이해에 도움이 되어서 텍스처를 봐도 멍하니 있는 상황을 방지할 수 있습니다.
오른쪽 입력 텍스처를 보면 베이스 컬러 맵, 속성 맵(경험상 러프니스·곡률·메탈릭 같은 거겠죠), 법선, 노이즈, ShadowMap, 환경 맵, Lut 텍스처가 있는 걸 볼 수 있어요. 특히 텍스처 알파 채널에 뭔가 저장돼 있는지 주의해서 보세요.
피부 렌더링에 대해 어느 정도 알고 있다면, 이것들이 모두 기본적인 텍스처라는 걸 알 수 있습니다. 다음으로 Mesh Viewer 창을 열어 모델 데이터를 확인해보세요

P31.현재 드로우 중인 메시 정보 확인
해당 모델이 사용하는 데이터를 확인하고, 테스트를 위해 저장할 수도 있어요. 버텍스 컬러에 특히 주의하세요 — 자주 별별 트릭에 사용되거든요.
일반적으로 사용된 텍스처, 모델의 형태와 데이터, 최종 표현 효과를 관찰하면 거의 다 파악할 수 있습니다. 굳이 코드를 볼 필요는 없어요(너무 귀찮으니까요. 디컴파일 후 명명이 보존돼 있으면 그나마 낫지만, 명명이 없거나 디컴파일이 안 돼서 어셈블리로 표시되면 더 끔찍합니다). 하지만 꼭 파고들고 싶다면, 필살기를 써야죠

5.3 셰이더 분석

셰이더 분석은 많은 노력이 필요하고, 충분한 지식(해당 계산 부분이 무엇을 계산하는지 파악하는 능력)도 갖춰야 합니다. 특히 인내심이 필요해요!!!
분석 시 반드시 버텍스 셰이더를 먼저 분석한 후에 프래그먼트 셰이더를 분석해야 합니다. 버텍스가 프래그먼트에 데이터를 전달하기 때문에, 어떤 데이터가 전달되는지 알아야 프래그먼트 셰이더 분석이 가능하거든요(물론 건너뛰고 프래그먼트에서 바로 출력해서 추측할 수도 있습니다)
간단하게 하기 위해 여기서는 얼굴의 버텍스 셰이더만 분석합니다. 프래그먼트 셰이더도 동일한 방식이에요(프래그먼트는 너무 길어서...)

5.4 버텍스 셰이더

P32.VertexShader 확인
먼저 PipelineState 창의 VS(버텍스 셰이더 단계)로 전환하고, 오른쪽 하단 화살표 버튼을 클릭하면 버텍스 셰이더의 입력 데이터(엔진 및 머티리얼 패널 파라미터 포함)가 표시됩니다

P33.VertexShader에서 사용되는 데이터 분석
이 파라미터들은 보통 원래 이름이 있어서, 이름으로 용도를 대략 파악할 수 있습니다. 물론 예외도 있고, 그러면 코드를 보면서 추측할 수밖에 없죠. 그 다음 Edit 버튼을 클릭하면(View 아님) 실시간 편집 디버깅이 가능합니다

P34.VertexShader 데이터 선언
앞부분은 버전 번호와 각종 변수 정의이고, 아래의 main() 함수가 버텍스 셰이더의 시작 함수입니다. 여기서부터 한 줄씩 봐야 해요

P35.공간 변환
앞 몇 줄을 먼저 보면 공간 변환을 하는 부분입니다. 행렬 연산을 이해한다면 파악할 수 있을 거예요. 모르겠다면 먼저 종이에 4x4 행렬과 4차원 벡터의 행렬 연산을 써보면 위와 같은 형태를 볼 수 있습니다.
클립 공간으로 변환 후, 뎁스 오프셋이 있는 걸 볼 수 있는데 클립 공간의 z값이 약간 오프셋됩니다. _DepthBias 값이 0인 점에 주의하세요(사실 오프셋이 없는데 이 계산 단계가 있는 것).
그 다음 클립 위치를 출력합니다(버텍스 셰이더는 반드시 클립 공간 위치를 출력해야 파이프라인이 이후의 보간, 클리핑 등 작업을 수행할 수 있습니다). gl_Position은 GLSL에서 클립 위치 출력 플래그입니다.
여기서 u_xlat0, u_xlat1 등 시스템이 자동으로 명명한 파라미터들이 보이는데, 가독성이 매우 떨어집니다. 이때 이 파라미터들을 치환해서 이후 가독성을 높일 수 있어요.

P36.필드명 치환
앞의 분석을 바탕으로 다음과 같이 치환합니다: u_xlat0 -> posWS, u_xlat1 -> posCS

P37.셰이더 재컴파일
치환 후 오른쪽 상단 Refresh를 클릭하면 재컴파일됩니다. 문법 오류가 있으면 오른쪽 하단 Errors에 오류 정보가 표시됩니다. 컴파일 성공 후 Texture Viewer에서 편집 후 효과를 확인할 수 있어요

P38.스크린 공간

P39.동차 나눗셈
앞에서 클립 공간 좌표를 구했고, 동차 나눗셈(posCS.w로 나눔)을 통해 NDC(정규화 장치 좌표)를 구합니다. OpenGL 플랫폼에서 xyz 범위는 모두 (-1~1)이며, *0.5 + 0.5를 통해 0~1 범위로 변환하여 스크린 UV로 사용합니다.
vs_TEXCOORD는 레지스터로, 버텍스 셰이더의 출력 내용입니다. 보간을 통해 프래그먼트 셰이더로 전달되는데, 이게 우리의 주요 목적입니다 — 버텍스 셰이더가 프래그먼트에 어떤 데이터를 전달하는지 파악하는 것. 메모장 같은 곳에 기록해 두는 걸 추천합니다.
현재까지 파악한 내용:

• vs_TEXCOORD0.xy 모델 UV 저장
• vs_TEXCOORD0.zw 0 저장
• vs_TEXCOORD6.xy 스크린 공간 UV

계속 아래를 봅시다

P40.VertexShader의 일부 데이터 계산
법선 맵을 사용했다면 이 벡터들(탄젠트, 바이탄젠트, 법선)을 계산해서 탄젠트에서 월드로의 변환 행렬을 구성해야 합니다.
in_TANGENT0.w * unity_WorldTransformParams.w는 바이탄젠트의 방향 반전 여부를 계산하는 데 사용됩니다.
이후 탄젠트를 모델 공간에서 월드 공간으로 변환하는 건 말할 것도 없고(벡터 변환이라 3x3 행렬만 있으면 됩니다). 그 뒤에 정규화 연산이 있는데, 벡터(x,y,z)를 정규화하려면 벡터를 그 길이로 나누면 됩니다. 법선 변환 시에는 비균일 스케일의 오류를 제거하기 위해 역전치 행렬을 사용해야 하므로 법선의 공간 변환은 약간 다릅니다.
바이탄젠트의 외적 계산은 외적 공식을 검색하면 유도할 수 있어요. 변수명을 치환합니다: u_xlat6 -> tangentWS, u_xlat2 -> normalWS, u_xlat16_3 -> bitangentWS

P41.레지스터에 저장된 데이터
그 다음 이 3개 벡터와 월드 공간 위치를 레지스터에 저장합니다

• vs_TEXCOORD2(tangentWS.x, bitangentWS.x, normalWS.x, posWS.x)
• vs_TEXCOORD3(tangentWS.y, bitangentWS.y, normalWS.y, posWS.y)
• vs_TEXCOORD4(tangentWS.z, bitangentWS.z, normalWS.z, posWS.z)

P42.전역 조명 계산
앞부분은 전역 조명 계산입니다. Unity에서 동적 오브젝트는 주변 라이트 프로브의 데이터를 샘플링하여 전역 조명을 구합니다. Unity에서 SampleSH(half3 normalWS) 함수를 검색하면 구현을 볼 수 있어요. 그 뒤는 Unity에서 선형 공간을 Gamma 공간으로 변환하는 함수로, https://blog.csdn.net/weixin_45979158/article/details/103495824 를 참고하세요
그 다음 구한 전역 조명(GI)에 환경색을 곱해서 레지스터에 저장합니다: vs_TEXCOORD5.xyz GI(라이트 프로브 샘플링, 버텍스 셰이더에서)

P43.그림자에 사용되는 파라미터 계산
다음은 그림자 파라미터 계산입니다. shadowmap을 사용하면 라이트 위치에서 카메라로 뎁스 텍스처 하나를 그린 뒤, 모델 좌표를 라이트 카메라의 뷰 공간으로 변환하여 z값(뎁스)을 가져와 이전 뎁스 텍스처와 비교해서 그림자 생성 여부를 판단합니다.
이렇게 버텍스 셰이더의 모든 출력 데이터를 파악했습니다

• vs_TEXCOORD0.xy 모델 UV, zw에 0 저장
• vs_TEXCOORD2 (tangentWS.x, bitangentWS.x, normalWS.x, posWS.x)
• vs_TEXCOORD3 (tangentWS.y, bitangentWS.y, normalWS.y, posWS.y)
• vs_TEXCOORD4 (tangentWS.z, bitangentWS.z, normalWS.z, posWS.z)
• vs_TEXCOORD5.xyz GI(라이트 프로브 샘플링, 버텍스 셰이더에서)
• vs_TEXCOORD6.xy 스크린 공간 UV
• vs_TEXCOORD7.z (라이트 공간에서) 그림자 뎁스, 뷰 공간 기준
• vs_TEXCOORD7.xyw (라이트 공간에서) 클립 좌표 xyw

5.5 프래그먼트 셰이더

버텍스 셰이더와 동일하므로 생략....

6. 보충

6.1 색 공간 문제

분석 중에 화면이 이렇게 보이는 경우가 자주 있어요

P44.실제 관찰 효과
전체적으로 어둡고 칙칙한데, 최종 렌더링 결과는 이렇습니다

P45.원하는 관찰 효과
이렇게 큰 차이가 나는 건 Linear와 Gamma 공간 문제 때문입니다. 먼저 전체 렌더링 과정에서 이 둘이 어떻게 전환되는지 명확히 해야 해요

P46.색 공간 변환
올바른 조명 계산을 위해 모든 데이터는 선형 공간에서 계산되고, 모든 오브젝트 렌더링이 끝난 후 Gamma 매핑을 거쳐 Gamma 공간으로 변환되어 디스플레이에 전달됩니다. 디스플레이는 받은 이미지를 선형 공간으로 변환하여 출력합니다.
프레임 캡처 분석을 하면 Gamma 매핑 단계를 건너뛰게 되어(빨간 선 경로로 가는 것) 최종 표시 색상이 어둡고 칙칙하게 됩니다.
디버깅 중에 올바른 색상을 보고 싶다면, 프래그먼트 셰이더에서 최종 출력 색상에 수동으로 Gamma 매핑을 한 번 적용하면 됩니다.

P47.수동 보정
마지막 DC에서 Gamma 매핑 코드를 찾아 복사해서 사용했습니다.

P48.보정 결과 비교
전후 비교를 볼 수 있습니다

6.2 디컴파일 도구

니키처럼 친절한 게임은 이제 드물고, 대부분의 게임에서는 어셈블리 셰이더를 얻게 됩니다. 어셈블리를 바로 보면 도전은 의미가 없어요. 그래서 역어셈블 도구가 필요한데, 정상적인 셰이더 형태로 번역해 줍니다(그래도 읽기 힘들긴 하지만요). 다음 링크가 도움이 될 수 있어요
GitHub - luxuia/dxbc_reader
GitHub - HugoPeters/DXBC2GLSL-Standalone
GitHub - crossous/DXIL2HLSL
처음 이걸 접했을 때는 역어셈블이 가능하다는 것도, 관련 도구가 있다는 것도 몰랐어요. 그래서 직접 수동으로 역어셈블(천여 줄)+이해 정리를 했습니다... 기록으로 남겨두겠습니다(덕분에 레벨이 몇 단계 올랐지만요...)

P49.흑역사

6.3 메시 추출 도구

보통 복원 작업도 해야 하는데, 모델 테스트를 위해 정점 데이터를 CSV 형식으로 저장한 후 도구를 통해 FBX로 변환할 수 있어요
https://github.com/Alunice/TaTa/tree/master/CSV2Mesh
github.com/Alunice/TaTa/tree/master/CSV2Mesh
https://github.com/FXTD-ODYSSEY/RenderDoc2fbx
github.com/FXTD-ODYSSEY/RenderDoc2fbx

7. 마무리

RenderDoc으로 남의 것을 디버깅하고 디컴파일하는 작업은 그 자체로 많은 경험과 인내심이 필요한 일입니다. 하지만 경험이 충분히 쌓이면 굳이 디버깅할 필요도 없어지죠 — 결국 세상 모든 건 다 비슷비슷하게 돌아가는 법이라, 텍스처만 봐도 어떤 효과인지 알 수 있고, 파라미터만 봐도 어떻게 계산하는지 알 수 있게 되니까요. 이후의 디버깅은 사실상 자신의 추측을 검증하는 작업이 될 뿐입니다.....