언리얼엔진 렌더링 파이프라인 (작성 및 공부 중)

언리얼 엔진의 렌더 파이프라인은 기본 디퍼드 렌더링(deferred rendering) 패스와 함께 사용하거나 포워드 렌더링 패스에서 실행하도록 환경설정할 수 있다.

 

이 프로세스는 왼쪽에서 오른쪽으로 진행되며, 2단계부터 5단계는 동시에 이뤄진다.

 

Deferred Rendering

1. 셰이딩이 디퍼드 패스에서 발생합니다
2. GBuffer를 기반으로 컴포지팅 작업을 수행합니다
3. 동적 라이팅 렌더링에 뛰어납니다
4. 안정적이고 예측 가능한 높은 성능을 제공합니다
5. 기능 비활성화에는 유연하지만, 표면 속성에는 덜 유연합니다
6. MSAA가 불가능하며, TAA에 의존합니다

지오메트리를 렌더링 하는 동안에는 셰이딩과 라이팅을 렌더링 하지 않음. 렌더링의 일부를 지연하는 것. 다이내믹 렌더링에 우수하고 안정적이고 예측 가능한 하이엔드 퍼포먼스에 우수하다. 기능 비활성화 면에서 더 유연하지만, 표면 어트리뷰트 면에서 안정성이 떨어짐. 라이팅을 렌더링할 때는 지오메트리를 렌더링할 때의 정보가 전혀 없음. 라이팅 렌더링을 계산할 때 사용할 정보가 더 적음.

간단한 씬이여도 렌더링 퍼포먼스가 Forward에 비하면 낮은편. 

Forward Rendering

1. 지오메트리/머티리얼과 동일한 패스에서 셰이딩을 계산합니다
2. 라이팅/머티리얼 계산 방식은 더 유연하지만, 여러 기능이 혼합될 때는 덜 유연합니다
3. 반투명 표면 렌더링에 뛰어납니다
4. 단순한 용도에서 더 빠릅니다
5. 동적 라이팅이 성능에 큰 영향을 미칩니다

정방향 (Forward)로 렌더링. 라이팅, 셰이디 지연없이 지오메트리 렌더링과 동시에 처리.

라이팅과 머티리얼 계산에 더 유연하다. 

많은 기능을 결합하는 데는 유연성이 떨어짐. 씬 내부의 계산이 급속도로 복잡해지기 때문.

단순한 상황에 더 잘 작동. 반투명 렌더링에 유리함.

포워드 렌더링 (Forward Rendering)
포워드 렌더링은 각 오브젝트를 그릴 때마다 모든 라이트의 영향을 즉시 계산하는 방식입니다.
동작 과정:

각 메시에 대해 버텍스 셰이더를 실행하여 정점을 변환합니다
프래그먼트 셰이더에서 해당 픽셀에 영향을 주는 모든 라이트를 순회하며 최종 색상을 계산합니다
이 과정을 모든 드로우콜마다 반복합니다

시간 복잡도: O(오브젝트 수 × 라이트 수)
장점:

구현이 단순하고 직관적입니다
MSAA와 같은 하드웨어 안티앨리어싱을 쉽게 적용할 수 있습니다
반투명 오브젝트 렌더링이 자연스럽습니다
메모리 사용량이 적습니다

단점:

라이트 수가 증가하면 성능이 급격히 저하됩니다
많은 라이트가 있는 씬에서는 비효율적입니다

디퍼드 렌더링 (Deferred Rendering)
디퍼드 렌더링은 지오메트리 정보와 라이팅 계산을 분리하는 방식입니다.
동작 과정:

G-Buffer Pass: 모든 지오메트리를 렌더링하여 G-Buffer(Position, Normal, Albedo, Specular 등)에 저장합니다
Lighting Pass: 스크린 스페이스에서 각 픽셀마다 G-Buffer 데이터를 읽어 라이팅을 계산합니다
최종 결과를 화면에 출력합니다

시간 복잡도: O(오브젝트 수 + 픽셀 수 × 라이트 수)
장점:

많은 라이트가 있어도 성능이 상대적으로 안정적입니다
각 픽셀은 한 번만 라이팅 계산을 수행합니다
복잡한 라이팅 효과를 효율적으로 처리할 수 있습니다

단점:

G-Buffer를 위한 메모리 대역폭과 용량이 필요합니다
하드웨어 MSAA를 사용할 수 없어 대체 AA 기법이 필요합니다
반투명 오브젝트 처리가 복잡합니다 (별도의 포워드 패스 필요)
여러 머티리얼 타입을 처리하기 어렵습니다

언리얼 엔진의 접근
언리얼 엔진은 기본적으로 디퍼드 렌더링을 사용하지만, 모바일이나 VR처럼 메모리 대역폭이 제한적인 플랫폼에서는 포워드 렌더링을 선택할 수 있습니다. UE5에서는 Lumen과 같은 글로벌 일루미네이션 시스템과의 통합을 위해 하이브리드 접근 방식을 사용합니다.
실무에서는 씬의 특성(라이트 수, 타겟 플랫폼, 메모리 제약)에 따라 적절한 렌더링 방식을 선택하는 것이 중요합니다.

1. 씬 준비 및 오클루전

 

언리얼 엔진은 게임(CPU), 드로, GPU라는 세 가지 기본 스레드를 갖추고 있다.

게임(CPU) 스레드는 렌더링 프로세스를 시작하기 전에 씬에 있는 모든 오브젝트의 트랜스폼을 수집합니다. 여기에는 각 오브젝트의 최종 트랜스폼 수집 전의 모든 애니메이션, 피직스 시뮬레이션 및 인공 지능(Artificial Intelligence, AI) 프로세스가 포함된다.

그런 다음 트랜스폼 정보가 CPU의 드로(Draw) 스레드에 전달됩니다. 드로 스레드는 현재 카메라 뷰에 보이는 오브젝트의 목록을 빌드하고, 카메라에 보이지 않는 나머지 오브젝트를 모두 제거하는 컬링 프로세스(culling process)를 실행합니다. 표시되지 않는 오브젝트는 드로할 필요가 없으므로 이를 렌더링하지 않으면 퍼포먼스가 향상됩니다.

이 프로세스는 다음 단계를 순서대로 수행한다.

1. 디스턴스 컬링(Distance Culling): 카메라에서 일정 거리 이상 떨어진 오브젝트를 모두 제거합니다. (디폴트 아님)
2. 프러스텀 컬링(Frustum Culling): 카메라의 프러스텀(뷰) 안에 보이지 않는 오브젝트를 제거합니다. (디폴트, 오브젝트 단위)
3. Precomputed Visibility: Precomputed Visibility 활성화 및 볼륨을 배치하여 박스 안의 모든 것을 미리 계산한 비저빌리티 셀로 채운다. 박스는 라이팅을 빌드할 때 생성됨. 카메라가 셀에 들어갈때무엇을 렌더링하고 안할지 알 수 있음. (디폴트 아님)
4. 나나이트 컬링(Nanite Culling): 나나이트 지오메트리에서 다른 컬링 방식 대신 사용된다. 나나이트는 모든 메시를 로드 가능한 작은 클러스터로 쪼개기 때문에 컬링 효율이 뛰어나다. 지오메트리를 최대한 최적화 하여 렌더링 된 표면만 포함시키며, 인스턴스르 기반으로 컬링한다.
5. 오클루전 컬링(Occlusion Culling): 씬에 있는 나머지 모든 오브젝트의 비저빌리티 상태를 정확하게 확인한다. 이 방법은 비용이 높기 때문에 눈에 보이는 나머지 오브젝트들이 다른 오브젝트에 의해 가려지지 않는지 추가로 확인되는 오클루전 프로세스의 마지막에 이뤄집니다.

최종 표시 오브젝트 목록이 GPU 스레드에 전달되고 렌더링 프로세스가 시작됩니다.

Occlusion Performance Implications (오클루전 성능 영향)

1. 거리 컬링을 설정하세요
2. 10,000~15,000개 이상의 오브젝트는 성능에 영향을 미칠 수 있습니다
3. 주로 CPU 바운드이지만, GPU에도 일부 영향이 있습니다
4. 넓은 오픈 환경은 오클루전이 잘 발생하지 않습니다
5. 파티클과 같은 요소들도 오클루전됩니다
6. 큰 모델은 거의 오클루전되지 않아 GPU 부하가 증가합니다
7. 하지만 모델을 큰 모델로 결합하면 CPU 부하가 감소합니다

2. 지오메트리 렌더링

이 단계에서 언리얼 엔진은 씬에 포함된 표시 오브젝트 목록을 처리하고 3D 버텍스 데이터를 화면에 표시되는 픽셀 데이터로 변환하는 다음 단계를 준비합니다.

https://22joon.tistory.com/101

지오메트리 렌더링

 

3. 버텍스 셰이더

버텍스 셰이더는 다음 단계를 수행한다.

로컬 버텍스 위치를 월드 위치로 변환: 오브젝트 버텍스 데이터는 로컬 스페이스에 저장됩니다. 하지만 오브젝트가 월드에 배치된 후에는 버텍스 정보가 반드시 월드 스페이스 좌표로 변환되어야 합니다.

 

언리얼 엔진에선 추가적으로 머티리얼에 World Position Offset을 추가할 수 있다.

즉 모델 자체에 오프셋을 줄 수 있음. (R, G, B가 X, Y, Z에 대응)

이는 CPU가 전혀 관여하지 않는다.

대표적으로 Cloth, Water Displacement, Foliage wind animation등에서 사용된다.

만약에 풀숲 애니메이션을 스켈레톤등으로 CPU에서 계산한다면 아주 비효율적. 버텍스 셰이더에서 처리하는 것이 매우 효율적임.

 

즉 모델 자체가 움직이는 것이 아닌 렌더링 자체가 움직인 것. 피직스나 콜리전은 그대로임. 이는 CPU가 처리하기 때문.

LOD 처럼 마찬가지로 이런 월드 포지션 오프셋을 일정 거리 이상에서 비활성화 하여 버텍스 애니메이팅을 정지할 수 있음.

버텍스 셰이딩 및 컬러링 처리: 버텍스 셰이더는 버텍스 스무딩과 오브젝트 자체의 버텍스 컬러 데이터도 처리합니다.

버텍스 위치에 추가 오프셋 적용: 버텍스 셰이더는 화면에서 버텍스 위치를 오프셋하여 특정 이펙트를 달성할 수 있습니다. 이는 오브젝트의 머티리얼을 통해 이뤄지며, 월드 포지션 오프셋이라고 부른.

https://22joon.tistory.com/75

02. Vertex Shader

 

뎁스 패스

언리얼 엔진은 개별 오브젝트를 렌더링하기 전에 뎁스 패스(depth pass), 즉 초기 Z 패스를 수행하여 오브젝트의 상대적 위치를 판정합니다. 이를 통해 언리얼 엔진은 화면에서 동일한 픽셀을 여러 번 렌더링하지 않게 됩니다. 동일한 픽셀을 여러 번 렌더링하는 것을 오버드로(overdraw)라고 하며, 퍼포먼스에 막대한 영향을 미칠 수 있습니다. 언리얼 엔진은 가능한 한 오버드로를 방지하려고 시도합니다.

드로 콜

뎁스 패스 이후 GPU는 메시, 머티리얼 등 동일한 프로퍼티를 공유하는 모든 폴리곤을 동시에 드로하여 각 오브젝트를 렌더링합니다. 이를 드로 콜(drawcall)이라고 한다.

동일한 머티리얼에 할당된 모든 오브젝트의 폴리곤은 동일한 드로 콜로 취급된다. 하지만 각 고유 머티리얼에는 별도의 드로 콜이 필요합니다. 예를 들어 화면의 각 오브젝트에는 최소 1개 드로 콜이 필요하지만, 오브젝트에 할당된 머티리얼 수에 따라 더 많은 드로 콜이 이뤄질 수도 있다.

4. 래스터화 및 지오메트리 버퍼(GBuffer)

언리얼 엔진의 지오메트리 버퍼에서 찾은 이미지
래스터화 프로세스(rasterization process)는 3D 버텍스 데이터를 화면에 표시되는 2D 픽셀 데이터로 변환한다. 이 프로세스는 버텍스 셰이더가 모든 데이터를 처리한 뒤에 시작됩니다. 드로우 콜 단위로 실행 됨.

언리얼 엔진의 지오메트리 버퍼(Geometry Buffer, GBuffer)에는 씬의 지오메트리 관련 정보를 저장하는 일련의 이미지가 포함됩니다. 이 이미지에는 일반적으로 씬의 베이스 컬러, 월드 노멀, 메탈릭, 러프니스, 스페큘러를 처리하는 라이팅 정보가 포함됩니다. GBuffer의 이러한 이미지가 합성되어 화면에 표시되는 최종 이미지를 구성합니다.

이러한 합성된 이미지를 변환하는 과정은 렌더링되는 프레임마다 버텍스 데이터가 픽셀 데이터로 변환되고 적합한 이미지 부분을 GBuffer에 드로하는 드로 콜마다 발생합니다.

Overshading

한 픽셀에 표시되는 것은 단 하나의 폴리곤이다. 절대 두 개 이상에 폴리곤이 표시되지 않음. (알파 블렌딩을 고려하지 않은 가정인가?)

폴리곤이 10만개인 오브젝트라도 아주 멀리서 보면 1개의 폴리곤이 하나의 픽샐에 대응. 하지만 10만개의 폴리곤을 처리하니 퍼포먼스 차이는 없음.

쿼드는 2x2 단위로 처리된다.

보통은 픽셀의 중앙을 폴리곤이 덮는다고 가정함. (위 그림은 약간 잘못된 그림이나 설명을 위해 넘어간다)

2x2 단위로 처리하기 때문에 오버셰이딩이 여러번 반복해서 일어날 수 있다.

즉 폴리곤 밀도가 높으면 (멀리서 보거나 하는 등 픽셀당 폴리곤 밀도가 높아지기 때문에) 계산 비용이 증가한다. LOD나 컬링을 사용하여 오버셰이딩을 줄일 수 있다.

 

초기 픽셀 셰이더 패스가 복잡할수록 오버셰이딩 비용이 증가한다. 포워드 렌더링에선 초기 픽셀 셰이더 패스 비용이 늘어나, 디퍼드 셰이더 렌더링보다 오버셰이딩에 영향을 크게 받는다. 

 

보통의 경우는 퍼포먼스에 큰 영향을 주지는 않지만, 포워드 렌더링을 사용하고 퍼포먼스를 최대한 끌어올려야 하는 경우 이 부분도 함께 고려해야한다.

GBuffer

GBuffer의 구조와 역할
GBuffer는 여러 개의 렌더 타겟으로 구성되며, 각 픽셀의 기하학적 정보와 재질 속성을 저장합니다. 언리얼 엔진 5 기준으로 주요 GBuffer는 다음과 같습니다:
GBufferA: SceneColor - 월드 스페이스 노멀 벡터
GBufferB: Metallic, Specular, Roughness - 재질의 물리 기반 속성
GBufferC: Base Color  - 기본 색상 정보
GBufferD: Additional (조사 필요)

GBufferE: Additional (조사 필요)

 

디퍼드 렌더링은 두 단계로 나누어 사용한다:

Geometry Pass: 모든 오브젝트를 렌더링하면서 GBuffer에 정보 기록
Lighting Pass: GBuffer의 정보를 읽어 조명 계산 수행

이 방식의 장점은 조명 계산이 실제로 보이는 픽셀에 대해서만 수행된다는 점이다.

포워드 렌더링에서는 가려진 오브젝트에도 조명을 계산하지만, 디퍼드는 최종적으로 보이는 픽셀만 처리하므로 다수의 동적 라이트 환경에서 효율적입니다.

성능과 메모리 트레이드오프
GBuffer는 해상도에 비례하여 메모리를 소비합니다. 4K 해상도에서는 상당한 VRAM을 차지하므로, 모바일이나 저사양 플랫폼에서는 포워드 렌더링을 선택하는 경우도 있다.
또한 투명 오브젝트는 GBuffer에 기록할 수 없어 별도의 포워드 패스로 처리되며, MSAA(Multi-Sample Anti-Aliasing)와 호환되지 않아 TAA나 다른 안티앨리어싱 기법을 사용해야 한다.

 

커스텀 뎁스

커스텀 뎁스 활성화시 그 모델은 별도의 렌더 타깃, 별도의 GBuffer에 포함된다

렌더링 텍스처와 텍스처 스트리밍

 

먼저 텍스처를 임포트할때 압축하는 이유는 셰이더에는 텍스처 샘플러 개수 제한이 있고, 메모리 제약과 대역폭 한계가 있기 때문이다.

텍스처 해상도는 렌더링 퍼포먼스에는 거의 영향을 주지 않지만 메모리와 대역폭에 영향을 준다.

언리얼 엔진은 텍스처 스트리밍을 사용하여 텍스처를 렌더링함으로써 씬의 텍스처 로딩을 최적화한다. 텍스처 스트리밍 시스템은 텍스처 밉맵(mipmap)을 사용한다. 이는 동일한 텍스처 이미지 시퀀스를 다른 해상도로 사전 계산한 것이다.

밉맵

언리얼 엔진은 카메라와의 거리에 따라 게임플레이 동안 텍스처의 밉맵을 스트리밍한다. (DDS 텍스처 파일안에 저장된다) 이는 대역폭 및 메모리 소비를 최적화하고 카메라에서 멀어질수록 노이즈를 줄이기 위해 자동으로 수행된다.

 

밉맵을 사용하기 위해선 텍스처 크기가 2의 제곱이어야 한다. 일반적인 텍스처 크기는 3840 x 2160 픽셀(4K) 및 1920 x 1080 픽셀(HD)입니다. 텍스처가 특정 비율일 필요는 없으며, 1920 x 480 픽셀 텍스처도 밉맵을 수신합니다.

(2의 제곱이 아닌 경우 밉맵과 스트리밍을 이용할 수 없다)

 

메시가 아닌 텍스처용 레벨 오브 디테일(LOD)이라고 할 수 있다. 언리얼 엔진은 각 이미지가 이전 단계의 절반 해상도인 밉맵을 자동으로 생성한다.

 

결론적으론 카메라와 텍스쳐의 위치 관계에 따라 적절한 텍스처를 로드하고(이는 텍스처 스트리밍을 통해 처리), 밉맵을 생성할 지 안할지 결정하는 것이 중요하다.

 

5. 픽셀 셰이더 및 머티리얼

레이어링을 보여주는 서브스트레이트 머티리얼

오브젝트가 GBuffer에서 완전히 렌더링되면 언리얼 엔진은 각 오브젝트의 머티리얼 프로퍼티를 사용하여 픽셀 셰이더로 화면에서 각 오브젝트의 셰이딩을 시작한다.

픽셀 셰이더(pixel shader)는 화면에서 픽셀의 컬러를 수정하는 일련의 계산을 수행한다. 픽셀 셰이더는 GPU에서 실행되며, 매우 뛰어난 효율성을 제공한다.

픽셀 셰이더는 언리얼 엔진의 머티리얼 시스템을 제어하며 라이팅, 포그, 리플렉션, 포스트 프로세스 이펙트를 계산하는 데 사용됩니다.

언리얼 엔진에서는 머티리얼 에디터가 추가된다.

머티리얼 시스템은 하이 레벨 셰이더 언어(High-Level Shader Language, HLSL) 셰이더 템플릿을 머티리얼 에디터와 함께 사용하여 새로운 셰이더를 만든다. 그 후 셰이더에도 정의되지 않은 파라미터와 변수가 많은데, 이것들을 머티리얼 인스턴스에서 정의한다. 이과정을 통해 오브젝트에 적용되는 최종 머티리얼을 생성합니다. 

 

다만, 셰이더는 머티리얼이 사용되는 곳 하나 당 셰이더 하나가 만들어 진다. (거대하고 복잡한 셰이더 하나로 여러 곳에서 사용하도록  만드는 것 보다 효율적이라고 한다.)

 

이러한 머티리얼은 텍스처처럼 파라미터를 사용하여 각 오브젝트의 외형을 정의할 수 있다.

 

머티리얼

머티리얼 파이프라인은 대부분 PBR (Physical Based Rendering)을 기반으로 한다. 여기 사용하는 입력은 스페큘러, 메탈릭, 러프니스가 있다.

왜 PBR을 사용한 이유는 PBR은 통합 셰이딩이기 때문이다. 

PBR은 통합 셰이딩 방식입니다 – 몇몇 예외를 제외하면 거의 모든 곳에 사용됩니다.

최대 효율을 얻기 위해 우리는 오로지 PBR에만 집중합니다.

PBR은 예측 가능하기 때문에 아트 파이프라인(작업 흐름)을 개선합니다.

우리는 GBuffer 및 합성 기반 워크플로우로 인해 고유한 제한에 직면합니다.

성능 영향

하나의 머티리얼/셰이더가 참조할 수 있는 텍스처 샘플러의 최대 개수가 정해져 있습니다. 일반적으로 16개이며, 그 중 13개만 사용할 수 있습니다. DX11에서는 최대 128개의 공유 샘플러를 사용할 수 있습니다.

텍스처 크기는 보통 프레임레이트 손실이 아닌 랙(멈춤)과 프리징(정지)을 유발합니다.

픽셀 셰이더는 많은 작업을 하기 때문에 성능에 큰 영향을 끼칩니다.

해상도가 높아질수록 복잡한 머티리얼이 더 큰 영향을 끼치게 됩니다.

6. Reflections

루멘 리플렉션
언리얼 엔진은 씬에 포함된 모든 오브젝트를 셰이딩한 다음 오브젝트의 머티리얼 프로퍼티를 기반으로 오브젝트의 리플렉션 렌더링을 시작합니다.

언리얼 엔진은 네 가지 시스템을 사용하여 리플렉션을 씬에 렌더링합니다. 이러한 시스템은 다음 순서로 실행됩니다.

1. 리플렉션 캡처(Reflection Captures): 사전 계산(레벨 로드, 또는 프로젝트 쿠킹시)되며, 특정 위치의 스태틱 큐브맵에 저장됩니다. 매우 빠른 대신 부정확하고 이펙트가 국지적(Local effect near the capture location)이다.  (블렌드 되기전 단일 리플렉션 캡처를 이용하면 카메라 위치만 달라져도 반사 위치가 부정확해짐. 따라서 다른 리플렉션들과 블렌딩 되어 사용되는 것)    캡처가 겹치는 부분이 많으면 픽셀 셰이더 연산이 증가하여 느려진다.
2. 플레이너 리플렉션(Planar Reflections): 평면에서 발생하거나 평면에 비친 다이나믹 리플렉션을 캡처한다. 세팅에 따라 무거울 수 잇고, 정확한 리플렉션 표면이 필요하다면 사용 가능하다. (방 안의 거울 등). 그리고 보통 평평한 평면에서 사용된다.
3. 스크린 스페이스 리플렉션(Screen Space Reflection, SSR): 화면에 보이는 정보를 사용하여 실시간으로 정확한 오브젝트 리플렉션을 그린다. 노이즈가 있고 매우 무겁다. 또한 반사될 물체가 일부 가려지거나 안보이면, 리플렉션도 계산되지 않아 끊기게 된다.
4. 루멘 리플렉션(Lumen Reflections): 씬에서 전체 러프니스 값 범위의 리플렉션을 처리합니다. 이 리플렉션에는 스카이라이트, 클리어 코트 머티리얼 및 반투명, 단일 레이어 워터 머티리얼에 대한 지원이 포함된다.

언리얼 엔진은 이 세 가지 방법을 조합하여 활용한다. 스크린 스페이스 리플렉션을 우선시하며, 그다음 플레이너 리플렉션으로 전환되고, 마지막으로 리플렉션 캡처로 전환됩니다. 최종 리플렉션 결과는 GBuffer에서 러프니스, 스페큘러 및 메탈릭 이미지와 결합됩니다.

 

루멘 글로벌 일루미네이션 (Lumen Global Illumination)

루멘 글로벌 일루미네이션을 사용하는 경우, 루멘 리플렉션이 자동으로 사용됩니다. 하지만 루멘 GI 없이도 루멘 리플렉션을 사용할 수 있습니다. 이 경우, 언리얼 엔진은 베이킹된 라이팅을 루멘 리플렉션과 함께 사용합니다.

7. 스태틱 라이팅 및 섀도 (Pre-rendered)

 

프리컴퓨티드 라이팅이 있는 씬
언리얼 엔진은 리플렉션이 렌더링된 이후 씬에 있는 모든 오브젝트에 대해 스태틱 라이팅 및 섀도를 렌더링합니다.

 

언리얼 엔진은 라이트매스 글로벌 일루미네이션(Lightmass Global Illumination) 시스템을 사용하여 씬의 라이팅 정보를 사전 계산합니다. 라이팅 및 섀도 정보는 라이트맵 UV 텍스처에 저장되며, 이 텍스처는 씬에서 오브젝트를 렌더링할 때 오브젝트의 베이스 컬러와 블렌딩됩니다. (다만 모델이 아주 크면 라이트 맵의 픽셀이 부족해 라이팅 해상도 퀄리티가 떨어질 수 있음.)

 

장점: 빠르다. 리얼타임 라이팅의 퀄리티보다 자세하고 정확하다. (라이트 맵 해상도와 UV 레이아웃 퀄리티에 따라 실제 퀄리티가 결정된다.)

단점: 메모리가 비용이 증가한다. Pre-compute할 시간이 필요하다. 모든 모델의 라이트맵 UV를 준비해야 한다. 무언가 바뀌면 다시 렌더링해야한다.

라디오시티와 글로벌 일루미네이션?

라이트매스 글로벌 일루미네이션 시스템은 모바일 및 저사양 디바이스를 대상으로 하는 프로젝트에 적합합니다.

 

라이트 맵

텍스처에 라이팅과 섀도를 구워 넣은 것. 그 후 텍스처의 베이스 컬러를 곱한 것. 

이를 위해 모델의 UV 라이트 맵이 필요하다. 라이트 맵의 크기는 균일하게 유지하는 것이 중요. 또한 카메라에 너무 멀리 있는 물체의 라이트 맵 해상도가 높을 필요는 없다. 

 

간접광 캐시

다이내믹 모델이 월드에서 움직일 때, 간접광들을 그리드 형태로 캐시한다. 가장 가까운 점에 밝기 값을 쿼리하여 본래 값과 혼합한다.

Static Lighting 성능 영향

정적 조명은 항상 동일한 속도로 렌더링됩니다.

한 개든 5만 개든, 베이킹 후에는 똑같이 동작합니다.

라이트맵 해상도는 메모리와 파일 크기에 영향을 끼치나, 프레임률에는 영향이 없습니다.

베이크 타임은 다음에 따라 증가합니다.
a. 라이트맵 해상도
b. 모델 및 조명 개수
c. 높은 품질 설정
d. 감쇠 반경이나 광원 반경이 큰 조명

 

8. 다이내믹 라이팅 및 섀도 (Real-time)

언리얼 엔진은 스태틱 라이팅이 렌더링된 다음 다이내믹 글로벌 일루미네이션 시스템인 루멘을 사용하여 다이내믹(리얼타임) 라이팅 및 섀도를 렌더링합니다.

루멘은 차세대 콘솔 및 고사양 PC를 위해 디자인된 완전한 다이내믹 글로벌 일루미네이션 및 리플렉션 시스템입니다. 이 시스템은 글로벌 일루미네이션 및 리플렉션을 대규모로 처리하기 위해 다양한 레이 트레이싱 메서드를 사용합니다.

루멘은 무제한의 디퓨즈 바운스를 제공하며 나나이트 가상화 지오메트리와 원활하게 작동합니다. 또한 이 시스템은 버추얼 섀도 맵과 연계되어 고해상도 리얼타임 소프트 섀도를 생성합니다.

루멘은 씬에서 전체 러프니스 값 범위의 리플렉션을 처리하는 루멘 리플렉션을 제공합니다. 이 리플렉션에는 스카이라이트, 클리어 코트 머티리얼 및 반투명, 단일 레이어 워터 머티리얼에 대한 지원이 포함됩니다.

루멘을 씬에서 사용하는 경우 스크린 스페이스 리플렉션을 대체합니다.

 

GBUffer를 이용한다.

장점: Dynamic, Real-time 방식이다.

단점: 퍼포먼스가 무겁다. 특히 그림자에서 매우 무겁다. 적절한 작업과 조합을 찾아 개선하는 것이 반드시 필요하다.

보통 그림자에서 렌더 퀄리티를 낮추거나, 다른 곳의 퀄리티를 낮춘다. 라디오시티나 글로벌 일루미네이션을 적용할 수 없다. (언리얼 엔진 4 기준으로 보인다. 조사 필요) 

 

Shadows (그림자)

Regular Dynamic Shadows: 라이트가 만드는 섀도우, 라이트의 모빌리티가 Movable, 다이나믹 섀도우 드리우기 옵션이 켜져있어야함. 문제는 섀도가 매우 선명하고 뚜렷해서 메시의 적은 폴리곤 수가 그대로 표현된다. 반사광 표현도 없다. 라이트 맵과 블렌딩되어 결과가 약간 부드러워진다.

Per Object Shadows (Stationary light shadow): Mobility가 Stationary일 때, 라이트 맵도 생성하고, 그 위에 다이내믹 라이팅도 렌더링 한다. Regular Dynamic Shadows보단 약간 부드러워 보인다.

Cascaded Shadow Maps (CSM): 대규모 야외 환경에서 다이나믹 라이팅을 사용할 수 없다. 디렉셔널 라이트에서 여러 섀도 맵을 계단식으로 배치 (다수의 동적 섀도 세트를 연쇄적으로 배치) 한다. 

 

 

Distance Field Shadows: CSM만으로 개방된 대규모 야외 환경의 섀도를 렌더링하는 것은 어렵고 무겁다. 먼거리의 섀도를 낮은 정밀도로 표현하는 것이 필요하다. 지오메트리 대신 디스턴스 필드 정보를 사용하여 섀도를 드리을 부분을 알아낸다. 섀도를 드리우려면 두 점의 거리를 알아야 한다. 빛이 어디서 오는지, 빛이 지오메트리를 얼마나 가까이 지나는지, 그 지오메트리와 빛이 닿는 다음 지점은 얼마나 떨어져있는지, 섀도는 얼마나 늘어지는 지 등 모든 거리를 계산하려면 너무 무겁고 느리다. 이때 모델 사이의 거리를 저장할 수 있으면 그 모든 데이터를 실시간으로 계산하기 쉬울 것이다.

텍스처를 합쳐 3d로 표현한 것.

 

그외

Inset Shadows: 오브젝트별 그림자와 동일합니다. 일부 동적 모델에서 더 높은 해상도의 그림자를 사용할 수 있게 해줍니다.

Contact Shadows: 미세 접촉 그림자로, 작은 디테일에 유용합니다.

Capsule Shadows: 매우 저렴하고 단순화된 그림자로, 모델의 아래쪽에 생성됩니다.

퍼포먼스 팁

Dynamic Lighting 성능 영향

동적 조명은 디퍼드 렌더러에서는 비교적 비용이 저렴하지만, 포워드 렌더러에서는 매우 비쌉니다.

비용은 픽셀 셰이더 연산에 따라 결정되므로, 더 많은 픽셀이 영향을 받을수록 더 느려집니다.

빛이 카메라에 가까울수록 더 많은 픽셀이 영향을 받고 동작이 느려집니다.

반경(radius)은 가능한 한 작게 설정해야 합니다.

과도한 겹침(overlap)을 방지해야 합니다.

필요하지 않으면 그림자 생성을 꺼두세요.

지오메트리의 폴리곤 수가 그림자의 성능에 영향을 미칩니다. 동적 그림자가 많은 환경에서는 낮은 폴리곤 모델이 더 필요합니다.

이 영향(성능 저하)을 줄이기 위해 Distance Field(거리장)를 사용하는 것을 고려하세요.

Distance Field는 직선의 딱딱한 에지(모서리)를 가진 단단한 모델에서 가장 잘 작동합니다.

멀리 있을 때 그림자를 페이드시키거나 꺼두세요.

두 라이트는 시각적으로 같아보이지만, 라이트 범위로 인해 왼쪽이 연산이 더 많이 필요하다. 

다이나믹 섀도가 많으면 폴리곤수에 주의해야한다.

또한 라이트가 실제로 보일때만 키는 것도 적절한 방법. (문 열기전 방 안에 있는 다이나믹 라이트를 전부 끄고, 문을 열면 킨다.)

기본 규칙 두 가지

가장 높은 성능이 필요할 때만 정적 라이팅을 사용하세요.

언제든지 자유롭게 조명 변경이 필요할 때만 동적 라이팅을 사용하세요.

Dynamic Lighting, Static Lighting 믹싱

Mixing

정적(static)과 동적(dynamic) 라이팅을 혼합하는 것이 (항상은 아니지만) 대부분 최선의 선택입니다.

약하고 먼 조명에는 정적 라이팅 사용

카메라 근처의 간접 조명 렌더링에는 정적 라이팅 사용

정적 라이팅 위에 동적 라이팅을 추가하여 셰이딩과 그림자를 더 강조하고, 정적 결과 위에 상호작용 레이어를 만들기

9.포그 및 투명(Transparency)

언리얼 엔진은 픽셀 셰이더에서 다이내믹 라이팅 및 섀도를 렌더링한 다음 포그 및 투명 이펙트를 렌더링합니다.

언리얼 엔진은 포그 이펙트를 렌더링할 때 익스포넨셜 하이트 포그 시스템을 사용하여 카메라로부터의 높이와 거리를 기반으로 포그 밀도를 렌더링합니다. 또한 이 시스템은 볼류메트릭 포그를 생성할 수 있다. (픽셀 셰이더 안에서 단순 블렌딩 렌더링)

 

투명 오브젝트는 반투명 머티리얼을 사용하며, 프로세스의 이 단계에서 렌더링됩니다. 

디퍼드 렌더링 패스를 사용하는 경우 언리얼 엔진은 GBuffer에서 사용 가능한 정보를 통해 투명을 렌더링합니다. 

또는 포워드 렌더링 패스를 사용하도록 머티리얼을 환경설정하여 보다 정확한 투명 이펙트를 생성할 수 있습니다.

 

단, Deferred 렌더링에서 Transparency를 다룰때 어려움이 있음.

GBuffer로만 렌더링을 해야하는데, GBuffer에 저장된 데이터로는 반투명을 제대로 렌더링하기에 부족하기 때문.

머티리얼의 Translucency 항목에서 다양한 세팅이 있는데, Deferred 렌더링의 한계를 극복하기 위함이다.

반투명의 경우 특히 Translucent대신 Masked로 설정하면 더 빠르게 처리 가능하다. 반투명이 정말 필요하면 Default Lit대신 Unlit으로 하거나, 여러 꼼수를 쓰는 것을 추천한다. (어떻게든 꾸며낼 수 있으면 꾸며내는 것을 추천한다.)

 

보통 렌더링의 나중의 stage로 미룸. 포워드 렌더러는 반투명 렌더링에 훨씬 좋음.

그래서 더 좋은 결과를 위해 이 부분만 포워드 렌더링 하는 병합 방식을 사용하기도 함. 

 

첫 번째 이미지

투명 렌더링은 최고 품질로 렌더링할 때 픽셀 셰이더 개수가 많아져서 비용이 매우 큽니다.

동일한 픽셀을 여러 레이어가 덮거나, 매우 많은 픽셀이 덮이면 투명 렌더링은 비용이 커집니다.

픽셀 셰이더의 비용 외에도, 렌더 순서를 정렬하는 문제도 있는데, 이것 역시 느리고 오류 발생에 민감합니다.

두 번째 이미지
투명 머티리얼이 덮을 픽셀이 많을수록 머티리얼은 최대한 단순하게 설계하는 것이 좋습니다.

빛을 고려하는 투명 머티리얼은 언릿(Unlit, 비조명) 트랜슬루언트 머티리얼보다 훨씬 더 비쌉니다. 진짜 필요한 경우에만 빛을 적용하세요. 최대한 라이트를 페이크(가짜)로 처리하세요.

세 번째 이미지
포함되지 않은 항목들

서브서피스 렌더링

굴절(Refraction)

디스플레이스먼트 매핑

화면 공간 앰비언트 오클루전(SSAO)

인터페이스 및 UI 렌더링

데칼(Decal)

 

10. 포스트 프로세스 이펙트

최종 이미지에 뎁스 오브 필드가 적용된 씬
언리얼 엔진은 포그 및 투명이 렌더링된 후 이미지에 추가 이펙트를 적용합니다. 이러한 이펙트는 최종 이미지가 처리된 이후에 적용되므로 포스트 프로세스 이펙트라고 합니다. 이 이펙트는 픽셀 셰이더에 의존하며, GBuffer에서 사용 가능한 정보를 활용합니다.

일반적인 포스트 프로세스 이펙트로는 라이트 블룸, 뎁스 오브 필드, 라이트 섀프트, 톤매핑, 모션 블러 등이 있습니다.

언리얼 엔진은 포스트 프로세스 단계의 일부로 템포럴 슈퍼 해상도(Temporal Super Resolution, TSR)를 적용할 수 있습니다. TSR은 플랫폼에 구애받지 않는 템포럴 업스케일러로, 언리얼 엔진이 고해상도의 4K 이미지를 렌더링할 때 사용합니다. 비용이 많이 드는 렌더링 계산의 일부를 여러 프레임에 걸쳐 분할하여 적은 비용으로 이미지를 얻습니다.

렌더링 체인에서 템포럴 슈퍼 해상도는 뎁스 오브 필드 이후에 발생하며, 그 이후에 산출되는 모션 블러, 블룸 등은 모두 업스케일됩니다.

이러한 이펙트가 GBuffer에 적용되면 언리얼 엔진은 최종 이미지를 화면에 렌더링합니다.
위에 설명된 단계는 화면에 단일 프레임을 생성합니다. 이 단계는 게임의 타깃 프레임레이트에 따라 종종 초당 30~60회 반복됩니다.

 

참고 사이트 및 문서

https://dev.epicgames.com/documentation/ko-kr/unreal-engine/introduction-to-rendering-in-unreal-engine-for-unity-developers#draw-calls