언리얼 엔진으로 카툰 렌더링 — 일곱 개의 벽 넘기

발표자가 남긴 당부

시간 관계상 커스터마이징 코드는 상당 부분 의사 코드로 생략됐습니다. 중요한 키워드는 메모해두고 나중에 엔진 코드에서 직접 검색해보라는 것이 발표자의 권장 사항이었고, 이 문서에서도 등장하는 파일·함수 이름은 가능한 한 실제 엔진의 표기 그대로 적었습니다.

UE 5.8의 Substrate Toon이 아니라 커스터마이징을 택한 이유

발표 시점 기준으로 엔진에는 이미 공식 툰 셰이딩이 들어와 있었습니다. 그럼에도 자체 커스터마이징을 계속한 이유는 두 가지였습니다.

데모 결과물

시험용 데모의 셰이딩 모델 이름은 Stylized Anime^[1], 캐릭터는 VRoid에서 제공하는 아바타 샘플 중 하나였습니다. 이 데모가 보여준 것은 “툰 룩처럼 보인다”가 아니라 툰 룩이 엔진의 라이팅 파이프라인 안에서 제대로 살아있다는 점입니다.

• 모든 종류의 직접광 효과를 받습니다.
• 자기 그림자만 그리는 게 아니라 다른 물체가 드리운 그림자도 받습니다.
• 환경광에 영향을 주고받습니다.

허들 1과 2의 관계가 이 세션 전체의 설계 철학입니다 — “직접 구현”에서 “아티스트에게 자원을 열어주기”로의 전환.

기초 다지기

BxDF가 뭐고, 왜 거기를 고쳐야 하는가

BxDF는 “빛이 L 방향에서 들어오고 카메라가 V 방향에 있을 때, 이 표면에서 빛이 얼마나 나가는가”에 답하는 함수입니다. 디퍼드 렌더러에서 베이스 패스는 직접광을 계산하지 않고 주로 GBuffer를 채웁니다(이미션이나 미리 구운 간접광 같은 일부 항은 여기서 더합니다). 직접광 라이팅은 나중에 라이트 패스가 화면을 훑으면서 GBuffer를 해석하고, 셰이딩 모델별 평가 함수를 부르는 순간에 일어납니다. 엔진 코드에는 이 호출이 그대로 있습니다 — FDirectLighting Lighting = EvaluateBxDF( GBuffer, N, V, L, NoL, Shadow );

물리 기반 엔진은 이 함수를 두 개의 표준 블록으로 조립합니다. 디퓨즈 로브(램버트 계열: 색 × N·L)와 스페큘러 로브(GGX 계열 마이크로패싯)입니다. 툰 셰이딩은 이 매끈한 두 로브를 스타일라이즈된 것으로 갈아끼우는 작업이라, 포스트 필터가 아니라 셰이딩 모델이 분기되는 바로 그 자리에 들어가야 합니다. 그래서 첫 허들이 “엔진 셰이더 코드를 고친다”가 되는 겁니다.

정공법 — 셰이딩 모델 하나를 엔진에 제대로 장착하기

셰이딩 코드를 직접 고치는 방식입니다. 다만 셰이딩 모델 하나를 온전히 붙이려면 건드려야 할 곳이 매우 많습니다.

1. 열거형 식별자 등록. EMaterialShadingModel에 값을 추가합니다 (MSM_DefaultLit, MSM_ClearCoat 등이 있는 그 열거형).
2. 셰이더 템플릿과 ShadingCommon.ush. 공통 매크로·상수·디버그 색상을 설정합니다. 여기 붙는 SHADINGMODELID_* 상수는 8비트 채널의 하위 4비트만 쓰도록 정해져 있습니다 — 상위 4비트는 출력 스킵 플래그가 이미 쓰고 있습니다.
3. ShadingModels.ush에 라이팅 정의(BxDF)를 넣습니다. 위에서 본 EvaluateBxDF가 사는 곳입니다.
4. 파라미터가 늘었다면 GBuffer 패킹/언패킹. 베이스 패스 픽셀 셰이더가 EncodeGBuffer로 쓰고 DecodeGBufferData로 다시 읽습니다.
5. 라이트 패스마다 그 값을 읽어 처리. Deferred / Clustered Deferred / Forward / Mobile이 각각 별도의 셰이더 경로입니다.

기초 다지기

계단식 음영은 램프 텍스처 한 장에서 나온다

램프는 N·L을 인덱스로 삼아 읽는 작은 1D 룩업 텍스처입니다. 내용은 아티스트가 칠한, 계단이 있는 그라데이션입니다. brightness = N·L 대신 brightness = Ramp[N·L]로 바꾸면, 한 계단 구간 안의 모든 N·L 값이 같은 밝기 하나로 뭉개집니다. 구(球) 표면을 매끄럽게 돌던 명암 경계가 뚝 떨어지는 띠로 바뀌는 게 이 때문입니다.

중요한 건 입력이 계단 경계를 넘을 때만 결과가 움직인다는 점입니다. 그래서 띠가 실제 광원 방향과 실제 그림자 마스크를 따라 움직입니다. 화면을 후처리로 양자화하는 방식과 근본적으로 다른 지점입니다. 참고로 UE 5.8 공식 툰 셰이딩도 정확히 이 설계를 택했습니다 — 릴리스 노트 표현이 “ramp-based diffuse and specular control with dithering”입니다.

한계 — 이것이 다음 허들의 동기

• 코딩이 익숙하지 않은 아티스트에게 너무 어렵습니다. 라이팅을 살짝 바꾸는 일조차 결국 엔진 코드를 건드리는 작업이 됩니다.
• 반복 주기가 너무 깁니다.

아티스트 시안 → 프로그래머 코드 수정 → 빌드 → 셰이더 컴파일 → PIE 확인 → 다시 아티스트

유니티와의 구조적 차이

언리얼에도 기존 대안은 있습니다. MPC(Material Parameter Collection)로 필요한 라이팅 정보를 만들어 넘기는 방법입니다. 하지만 매번 C++에서 라이트 정보를 수동으로 채워야 하고, 그림자 같은 항목은 훨씬 까다롭습니다. 되긴 되지만 아티스트에게 쉽지 않다는 게 문제였습니다.

왜 디렉셔널 라이트만 여는가

기초 다지기

머티리얼 그래프는 어떻게 HLSL이 되는가

에픽 공식 자료에 따르면, 생성되는 HLSL은 Engine/Shaders/Private/MaterialTemplate.ush를 바탕으로 만들어집니다. 이 파일에는 본문이 %s 자리표시자로 비어 있는 구조체와 함수들이 들어 있고, FHLSLMaterialTranslator가 그 자리를 채웁니다. 그리고 그래프의 대부분은 CalcPixelMaterialInputs 함수 안으로 들어갑니다— 계산을 그래프 여러 곳에서 재사용할 수 있게 하려는 구조입니다.

그래프에서 디렉셔널 라이트 정보를 쓴다는 건, 결국 CalcPixelMaterialInputs 안에서 엔진 함수를 호출할 수 있어야 한다는 뜻입니다. 여기서 벽에 부딪힙니다. HLSL은 위에서 아래로 컴파일되므로, 내 위치보다 아래에 선언된 함수는 호출할 수 없습니다. 발표자는 엔진의 정의 순서가 이렇게 잡혀 있는 것이 머티리얼이 엔진 내부 함수에 함부로 접근하지 못하게 막아둔 의도된 설계라고 해석했습니다.

해법 — 인클루드 대상에 태그를 달아 컴파일 순서를 제어

엔진 함수 선언이 먼저 처리되고, 그걸 쓰는 부분은 뒤로 밀려서 컴파일되도록 코드를 나눠주는 태그를 부여했습니다. 태그를 달아준 대상이 Material.ush이고, BasePassPixelShader.usf에서 이 파일을 두 번 인클루드합니다.

① Pre-stage 태그와 함께 include  →  원래 아래에 있던 엔진 함수들이 먼저 정의됨
   (중간에 다른 인클루드들이 여럿 들어옴 — 이들도 Pre-stage 태그를 붙여 정의 순서 보장)
② Post-stage로 다시 include      →  머티리얼 본체가 정의되며 그 함수들을 실제로 사용

전용 노드 만들기 — 3파트

핵심은 UMaterialExpression을 상속받아 셰이더 코드를 만들어내는 전용 노드를 등록하는 것입니다. 에디터 모듈에서 클래스를 만들고, 노드 이름을 정하는 GetCaption과 셰이더 코드를 생성하는 Compile을 구현합니다. 둘 다 UMaterialExpression의 가상 함수로, Compile은 “새 셰이더 코드 청크를 만든다”, GetCaption은 “머티리얼 에디터에 표시할 텍스트를 반환한다”가 공식 설명입니다.

보너스 — 커스텀 노드에서 엔진 셰이더 함수 호출하기 (최종 제외됨)

컴파일 순서를 바꾸는 방법을 응용하면 커스텀 노드에서도 엔진 셰이더 함수를 호출할 수 있습니다. 원래 커스텀 노드는 HLSL 정의 순서상 강제로 앞단에 등록되어 미룰 수 없는데, 그 부분만 Post-stage로 넘기면 됩니다. 이렇게 하면 HLSL에서 for문으로 로컬 라이트를 도는 루프까지 만들 수 있습니다.

기초 다지기

왜 Lumen이 내 머티리얼 함수를 부르는가

Lumen은 메시마다 여러 각도에서 머티리얼 속성을 캡처해 서피스 캐시로 보관합니다. 이 캡처 지점을 Card라고 부릅니다. 공식 문서가 “Pixel Depth, Camera Position, Camera Vector처럼 시점에 의존하는 노드를 쓴 머티리얼은 Lumen Surface Cache 뷰 모드에서 잘못 보일 수 있다”고 경고하는 게 그 증거입니다 — 그래프가 캡처 시점에 실제로 실행되지 않으면 애초에 잘못 보일 일이 없습니다.

즉 그림자 정보를 요구하는 함수가 렌더 경로마다, 플랫폼마다 다른 시점에 불릴 수 있고, 정작 호출 시점에는 그림자가 아직 준비되지 않은 상황이 생깁니다. 그래서그림자가 준비되는 시점 자체를 손대야 했습니다.

기초 다지기

Virtual Shadow Maps가 뭘 하는 물건인가

공식 문서 기준으로 VSM은 가상 해상도 16k × 16k의 섀도우 맵입니다. 라이트 하나에 그만한 텍스처를 매 프레임 실제로 그리는 건 불가능하고, 대부분 낭비이기도 합니다 — 화면에 보이는 픽셀을 셰이딩하는 데 쓰이는 텍셀만 의미가 있으니까요.

그래서 VSM은 가상 해상도는 유지하되 물리적으로는 128 × 128 텍셀 페이지 단위로 쪼개서, 필요한 페이지만 할당해 그립니다. 문서 표현이 정확히 이렇습니다 — “Pages are allocated and rendered only as needed to shade on-screen pixels based on an analysis of the depth buffer.” 페이지 테이블이 가상 텍셀 → 물리 페이지 주소를 중개하고, 무효화되지 않은 페이지는 프레임 간에 캐시됩니다. 디렉셔널 라이트는 여기에 클립맵을 얹어 기본 6~22 레벨(카메라 기준 64cm에서 약 40km까지)을 커버합니다.

1차 시도 — 순서만 바꿔봤지만 실패

진짜 원인 — Page Marking 단계가 무엇을 보는가

페이지를 그릴지 말지 먼저 판단하는 단계가 Page Marking입니다. 공식 문서는 이 단계를 “Depth buffer analysis is used as the primary method of marking pages that are needed to render”라고 설명합니다. 즉 깊이 버퍼를 필요로 하므로, 깊이를 만드는 패스보다 앞으로 옮길 수가 없습니다.

발표에서는 이 판단이 GBuffer까지 검사한다고 설명했습니다 — 이 픽셀이 정말 그림자가 필요한 셰이딩 모델인지, 노멀이 라이트를 향하고 있는지를 확인해 불필요한 페이지를 걸러내는 꼼꼼한 컬링이라는 것입니다.^[4] 깊이만 본다면 깊이 프리패스 뒤로는 앞당길 여지가 있지만, GBuffer까지 검사하면 마킹이 베이스 패스의 산출물에 의존하므로 순서를 뒤집을 수 없습니다.

해법 — GBuffer 검사를 건너뛰는 플래그

커스텀 불리언 플래그(SkipGBufferTest)를 하나 추가해, 우리 경로에서는 GBuffer 검사를 건너뛰고 바로 페이지를 마킹하도록 했습니다.

그림자가 그려지는 원리 (복습)

사진 · 자료

캐스케이드 섀도우 맵 — 카메라 거리에 따라 섀도우 맵을 나눈다

절충안 — 4개 그룹

구현 ① 언리얼의 기존 그림자 등록 구조

예시 상황은 디렉셔널 라이트 1개, 카메라 거리에 따른 캐스케이드 3개, 레벨에 프리미티브 3개입니다.

• 그림자를 그리는 주체는 FProjectedShadowInfo이며, 디렉셔널 라이트마다 캐스케이드 수만큼 생성됩니다(여기서는 3개).
• 실제로 그림자를 드리우는 프리미티브들은 Subject Primitive로서 AddSubjectPrimitive를 통해 각 ShadowInfo에 등록됩니다.
• 즉 같은 캐스케이드의 ShadowInfo에 여러 프리미티브가 모이는 구조입니다.

구현 ② 그룹 개념 삽입 — 세 곳

코드에서 “Layer”가 곧 “그룹”이라고 보면 됩니다.

구현 ③ Nanite는 별개다 — 비트 플래그 패킹

구현 ④ 실제 섀도우 맵 그리기

구현 ⑤ 샘플링 규칙

경로별로는 CSM이면 구워진 마스크 텍스처를, VSM이면 전용 함수로 가상 페이지 맵을 직접 읽도록 코드에서 분기합니다.^[6]

나머지 일반 머티리얼은?

Deferred에서 Stylized Anime 외의 머티리얼은 그림자를 라이트 패스에서 그리고, 모든 그룹의 그림자를 다 받아야 합니다.

그래서 허들 1의 BxDF 수정 방식을 다시 가져오되, 그대로가 아니라 커브 에셋을 얹어 아티스트 친화적인 방향으로 접근합니다.

라이트 커브 — 가로축은 원래 라이팅, 세로축은 결과

커브를 셰이더로 넘기기

1D 커브 구조를 그대로 GPU로 옮길 수도 있지만 구조가 복잡하고 계산 효율도 좋지 않습니다. 채택한 방식은 이렇습니다.

1. 커브를 여러 지점에서 미리 샘플링해 StructuredBuffer로 업로드합니다.
2. 셰이더는 런타임 입력 값으로 인덱스와 프랙션을 구해 주변 두 샘플을 읽고 선형 보간 한 번으로 값을 얻습니다.
3. 이 샘플링은 쿡 타임이 아니라 플레이 시점에 이뤄집니다.

로컬 라이트 적용 — 딱 두 군데 수정

Default Lit 라이팅 함수를 복제한 다음 두 곳만 고쳤습니다.

1. 계산 전에 N·L을 로컬 라이트용 커브로 변환합니다.
2. 계산이 끝난 Diffuse와 Specular 값에 스타일라이징 팩터를 곱합니다.

이 팩터는 라이트별이 아니라 디렉셔널을 뺀 모든 라이트를 한꺼번에 통제하는 전용 가중치이며, 디퓨즈용과 스페큘러용 두 개가 있습니다.

인다이렉트 라이트 — 무엇을 변환할 것인가

문제는 인다이렉트 연산에 N·L, 즉 라이트 방향과 노멀 사이의 각도항이 없다는 것입니다. 로컬 라이트처럼 N·L 커브에 넣을 수가 없습니다. 그래서 라이팅 결과로 나온 색의 밝기를 변환하는 쪽으로 방향을 틀었습니다 — 색조(Hue)와 채도(Saturation)는 보존하고 명도(Value)만 카툰풍으로 조절하는 방침입니다.

간접광 RGB  →  HSV로 변환 (V = 밝기 정보 취득)
            →  V를 커브로 리맵
            →  다시 RGB로 복원
결과: 색조·채도는 그대로, 밝기만 조절

적용 위치는 간접광 관련 엔진 셰이더입니다. 베이스 패스의 간접광 반사항이나 Diffuse Indirect Composite 같은 패스에서, 컴포짓된 간접광 색에 이 변환 함수를 한 번씩 호출하는 방식입니다. 그 결과 로컬 라이트와 인다이렉트에도 제한적이지만 아티스트에게 자유도를 줄 수 있었습니다.

이 허들의 구현량이 가장 적습니다. 엔진이 이미 오버라이드 플래그 + 섹션 등록이라는 확장 지점을 갖고 있기 때문입니다.

활용 예시 — 같은 레벨, 같은 캐릭터, 완전히 다른 표현

기초 다지기

GBuffer에 “남는 채널”이 없다는 게 무슨 뜻인가

GBuffer는 디퍼드 베이스 패스가 픽셀별 머티리얼 정보를 적어두는 풀스크린 렌더 타겟 묶음입니다. 라이팅은 나중에 머티리얼 그래프를 다시 돌리는 대신 이 버퍼를 읽습니다. PC 디퍼드 기본 레이아웃은 대략 이렇습니다.

• GBufferA — RGB 월드 노멀, A 오브젝트 단위 플래그
• GBufferB — R Metallic, G Specular, B Roughness, A ShadingModelID + 출력 스킵 마스크를 8비트 한 채널에 비트 패킹(하위 4비트가 모델 ID)
• GBufferC — RGB BaseColor, A AO (스태틱 라이팅에서는 로그 인코딩된 간접광 조도)
• GBufferD — CustomData. Subsurface·ClearCoat·Hair·Cloth·Eye 등 추가 입력이 필요한 모든 셰이딩 모델이 공유합니다
• GBufferE — 프리컴퓨티드 섀도우 팩터 · GBufferF — 월드 탄젠트 + Anisotropy · Velocity는 별도 타겟

모든 채널에 주인이 있고, 일부는 비트 단위로 쪼개 쓰며, 스킵 플래그조차 4비트로 배급됩니다. 그래서 새 모델의 추가 입력은 기존 채널의 의미를 빼앗거나 GBufferD를 셰이딩 모델별로 나눠 쓰는 수밖에 없습니다. 디코딩 시점에 HasCustomGBufferData(ShadingModelID)가 “이 모델이 CustomData의 주인인가”를 판정하는 구조가 정확히 그 결과입니다.

쓰는 쪽 열기 — 머티리얼 에디터

• 머티리얼 에디터의 Custom Data 핀을 사용합니다.
• 원래 이 핀은 Clear Coat나 Eye 같은 일부 셰이딩 모델에서만 열립니다. 셰이더 쪽에서도 HasCustomGBufferData가 그 모델들만 허용하고 있습니다. IsPropertyActive에 우리 셰이딩 모델을 추가해서 같이 열어뒀습니다.
• 머티리얼 제작 과정에서 림 영역이나 머리카락 영역 값을 새로 열린 핀에 꽂을 수 있습니다. 각각 16비트를 할당해 충분한 표현력을 확보했습니다.

읽는 쪽 열기 — 포스트 프로세스

• 포스트 프로세스에서 쓰는 SceneTexture 노드에 항목 2개를 추가했습니다. 정의는 MaterialTemplate.ush에 있습니다.
• 여기서 ID를 정의하고, 스위치 케이스 분기에서 전달받은 커스텀 데이터 값을 다시 읽어 반환하도록 했습니다.
• 결과적으로 포스트 프로세스에서 SceneTexture 노드에 ID를 설정하면 머티리얼이 써둔 커스텀 데이터 값을 그대로 쓸 수 있습니다.

핵심 — 어디에 실어 보낼 것인가 (플랫폼별)

비용 회피 장치 — 셰이딩 모델 분리

아래는 세션에서 다룬 내용이 아닙니다. 발표가 “Substrate Toon이 있는데도 왜 커스터마이징인가”로 시작하기 때문에, 그 공식 기능이 실제로 무엇인지 확인해 덧붙였습니다.

중요한 점은 발표자의 포크 기반인 UE 5.6에는 이 기능이 없다는 것입니다. 이 세션의 “직접 다 만들었다”가 왜 필요했는지를 설명해주는 사실이고, 동시에 지금 새로 시작하는 프로젝트라면 공식 경로를 먼저 검토해야 하는 이유이기도 합니다. 반대로 이 세션이 강조한 “머티리얼 그래프에서 아티스트가 직접 만지는 자유도”는 프로파일 기반 공식 기능과 여전히 결이 다릅니다.

공개 방식은 아직 내부 논의 중입니다. 발표자는 가감 없는 피드백과 의견이 큰 힘이 된다고 전했습니다.

각주

1. 셰이딩 모델 명칭 — 이 문서는 데모의 셰이딩 모델을 Stylized Anime으로 표기했습니다. 정확한 명칭은 자료 공개 시 대조가 필요합니다. UE 5.8의 공식 기능명은 Substrate Toon Shading이며, 이 세션의 커스텀 모델과는 별개입니다. ↩
2. Main Light 노드의 출력 핀 구성 — Direction / Color / Shadow 3개로 정리했으나, 실제 핀 이름은 자료 공개 시 확인이 필요합니다. ↩
3. Deferred + CSM 경로의 “섀도우 맵 얼리 모드” — 섀도우 뎁스를 베이스 패스 앞으로 옮기는 공식 콘솔 변수는 확인되지 않았습니다. 포크의 커스텀 플래그로 보입니다. 참고로 UE4 시절 디퍼드 렌더러에서는 실제로 섀도우 뎁스가 베이스 패스보다 먼저 그려졌으므로, “원래 되던 것”에 대한 기억일 가능성도 있습니다. ↩
4. Page Marking의 GBuffer 검사 — 공식 문서는 VSM 페이지 마킹을 깊이 버퍼 분석으로만 설명합니다. 셰이딩 모델·노멀 방향을 함께 보는 컬링은 이 포크에서 추가된 것일 수 있습니다. 깊이만 본다면 프리패스 뒤로 옮길 여지가 있고, “베이스 패스 산출물에 의존한다”는 결론은 GBuffer까지 검사할 때 성립합니다. ↩
5. GPU Scene의 여유 비트 활용 — GPU Scene 인스턴스 데이터에 플래그 비트필드가 존재하는 것은 맞지만, 남은 비트를 커스텀 용도로 쓰는 것은 공식 확장 지점이 아닙니다. 엔진 업데이트 시 깨질 수 있는 설계입니다. ↩
6. VSM 페이지 맵 직접 샘플링 함수 — 발표에서 언급된 전용 샘플링 함수 이름은 공개된 엔진 문서·코드에서 확인되지 않았습니다. 포크의 헬퍼 함수로 보이며, 공식 VSM 샘플링 패스의 이름은 VirtualShadowMapProjection입니다. ↩
7. 렌더 패스 순서 — “VSM 결과가 베이스 패스 이후에 만들어진다”는 의존 관계는 공식 문서로 확인됩니다(페이지 마킹이 깊이 버퍼를 필요로 하므로). 다만 Lumen 씬 업데이트와의 정확한 상대 순서는 공식 문서에 명시되어 있지 않아, 위 도해는 발표 내용을 그대로 옮긴 것입니다. ↩

발표 중 직접 언급된 참고 자료

Stylized Rendering Insights from Japan

Nanite: A Deep Dive (SIGGRAPH 2021)

이 문서의 사실 확인에 사용한 공식 자료