렌더 파이프라인 이란?
- 씬의 콘텐츠를 가져와 화면에 표시하는 작업을 말합니다.
- 수행하는 작업으로는 컬링, 렌더링, 포스트 프로세싱이 있습니다.
- 파이프라인은 저마다 기능/성능 특성을 가지고 있으며, 다양한 게임, 앱 및 플랫폼에 적합합니다.
렌더 파이프라인 종류
- 빌트인 렌더 파이프 라인 : 유니티의 기본 렌더 파이프 라인으로 커스터마이즈 옵션이 제한적
- 유니버셜 렌더 파이프라인(URP) : 쉽고 빠르게 커스터마이즈 가능한 스크립터블 렌더 파이프라인으로, 광범위한 플랫폼에 최적화된 그래픽스 구현 지원
- 고해상도 렌더 파이프라인(HDRP) : 스크립터블 렌더 파이프라인으로, 고사양 플랫폼을 위한 최신 고해상도 그래픽스 구현 지원
- Unity의 스크립터블 렌더 파이프라인 API로 커스텀 렌더 파이프라인을 생성 할 수도 있음
빌트인 렌더 파이프라인의 약점
- C++로 작성되어 수정이 불가능하여 파악이 어려움
- 렌더링 알고리즘이 하드 코딩
- 제약 없는 커스터마이징으로 모든 플랫폼에 우수한 성능 달성이 어려워짐
- 렌더링 코드에 콜백이 노출되어 파이프라인에서 동기화 포인트가 트리거 되는데 이러한 콜백은 멀티스레드 렌더링 최적화를 방해하며, C# 호출을 통해 프레임의 어떤 지점에서든 동적으로 상태 인젝션의 변경이 가능하게 됨
- 렌더 플로와 렌더 패스가 사전 구조화 되어 있음
Q. 동기화 포인트가 트리거 되는데, 이러한 콜백이 멀티 스레드 렌더링 최적화를 방해하는 이유?
- 비유로 설명하면 "멀티 스레드"는 여러 요리사가 동시에 요리를 하는 것이고 "동기화 포인트"는 모든 요리사가 잠깐 멈춰 기다려야하는 순간이라 생각해보자, 열심히 멀티 스레드인 여러 요리사들이 작업중이다가 "프레임의 어떤 지점에서든 동적으로 상태 인젝션의 변경" 즉, 어떤 순간이든 상관없이 갑자기 모든 요리사가 잠깐 멈춰야하는 "콜백으로 인한 동기화 포인트"가 발생하게 되는 경우를 말합니다. 예측 불가능한 이러한 동작으로 인해 성능이 저하된다고 얘기하는 것입니다.
- 쉽게 얘기하면, 멀티스레드로 렌더중(Audio, Physics, GPU) -> 갑자기 콜백 발생 -> 모든 스레드 일시정지/렌더링 상태 변경(상태 인젝션) -> 다시 모든 스레드 재시작으로 인한 성능 저하 + 예측 불가능한 동작
Q. 렌더 플로와 렌더 패스가 사전에 구조화가 왜 문제인가?
- 사전 구조화가 되어 있다는 것은 렌더링 순서가 고정되어 있어 원하는 데로 커스터마이징이 안된다는 얘기, 예를들면 모바일과 PC에서 다른 최적화가 필요해도 변경이 어려운 문제를 직면할 수 있음
해결책? -> 스크립터블 렌더 파이프라인(SRP)
- 고사양에서 저 사양 기기에 이르기까지 최대한 많은 하드웨어 플랫폼에 맞게 지능적이고 안정적으로 지원
- C#을 사용하여 렌더링 프로세스를 커스터마이즈 가능
- 아키텍처의 변화를 지원할 수 있는 유연성 제공
- 많은 플랫폼에서 적합한 성능의 선명한 그래픽스를 만들 수 있도록 유연성 제공
- C#을 이용해 렌더패스와 렌더링 컨트롤 가능
- Shader Graph와 같은 아티스트 친화적 툴 사용하여 만들 수 있는 HLSL 셰이더 제어 및 커스터마이즈 가능
- 셰이더를 통해 하위 수준 API와 엔전 레이어 추상화 엑세스 가능
URP를 선택해야하는 이유?
- 다양한 사용자 엑세스 지원: 아티스트, 테크니컬 아티스트가 모두 설정할 수 있고 정식 게임 제작을 위한 렌더링 기술 개선 및 프로토 타이핑에서 더 높은 유연성을 제공
- 확장 및 커스터마이징: 기존 기능 수정 및 새 파이프라인 확장이 가능하며, 에셋스토어/타사 패키지 크리에이터/숙련된 스튜디오/고급 팀 등 믿을 수 있는 옵션 선택 가능하며, 개발자가 렌더 파이프라인 도중 호출되도록 간단한 C#으로 작성하여 성능 저하 없이 고수준 커스터마이징 실현 가능
- 다양한 렌더링 옵션: 포워드,포워드+, 디퍼드 렌더링 경로를 지원하는 유니버셜 렌더러와 2D 렌더러 제공하며, 이러한 렌더러는 추가 기능 및 스크립터블 렌더 패스를 사용하여 확장도 가능
오브젝트 렌더링 기능은 렌더링 파이프라인의 다양한 이벤트에서 특정 레이어 마스크로부터 오브젝트를 렌더링하는데 사용이 되며, 머터리얼 및 기타 렌더 상태를 오버라이드 할 수 있어, 코드를 작성하지 않고도 렌더링 커스터마이즈가 가능함, 또한 특정 요구 사항에 맞춰 커스텀 렌더러를 통해 URP 확장도 가능
- 성능 향상:
-> 실시간 조명을 더 효율적으로 계산, 포워드 렌더링은 싱글 패스에서 모든 조명을 계산하며, 포워드+는 오브젝트 단위 대신 공간을 분류해 광원 컬링하여 표준 포워드 렌더링보다 더 나은 품질을 보임, 이러한 방식은 프레임을 렌더링할 때 더 많은 광원을 활용할 수 있습니다. 디퍼드 렌더링에선 Native RenderPass API를 지원하여 G버퍼와 조명 패스가 싱글 렌더 패스로 결합될 수 있도록 함
-> 메시를 드로우할 때 CPU, GPU 성능 개선되었음, 뎁스 처리방식에서 더 적은 드로우 콜과 개선을 지원하는 SRP Bacher 덕분임
-> URP를 사용하면 모바일 기기에서 타일 메모리를 더 효율적으로 사용 가능하며, 전력 소비량이 줄고 배터리 수명도 길어짐
-> 통합 소프트 프로세싱 스택을 포함하여 빌트인 렌더러 파이프라인에 비해 높은 성능을 제공, 볼륨 프레임워크를 사용하면 코드를 작성하지 않고도 카메라 위치 기반의 포스트 프로세싱 효과를 만들 수 있음
- 최신 툴과 호환성: Shader Graph, VFX Graph, 렌더링 디버거 등 아티스트 친화적인 최신 툴 지원
Q. 포워드 렌더링이란?
- 각 픽셀에 대해 모든 광원의 영향을 한 번에 계산하는 방식
- 빌트인의 경우 멀티패스 포워드 렌더링 방식으로 광원 수에 따라 드로우 콜이 증가함
- URP는 위에서 설명한 것 처럼 싱글패스 포워드 렌더링으로 모든 조명을 한번에 처리하여 최적화함
* 멀티패스와 싱글패스 차이점
- 멀티 패스는 오브젝트 1개 랜더링 할때마다 광원이 4개면 4번의 드로우콜이 발생하지만 싱글패스는 총 4개의 광원을 한번에 계산하여 1개의 드로우콜만 발생함
Q. 포워드+ 렌더링이란?
- 화면을 타일로 나누어 각 타일별로 영향을 미치는 광원만 계산하여 효율성을 높인 방식
- 빌트인은 아예 지원을 안함
- URP는 타일 기반 광원 컬링을 통해 대용량 광원 처리에 최적화 되어 있음
Q. 디퍼드 렌더링이란?
- 지오메트리 정보를 G-Buffer에 저장한 후, 별도 패스에서 조명 계산을 수행하는 방식
- 빌트인은 "G-Buffer작성 -> 메모리 저장 -> 조명 패스에서 다시 읽기"가 되어 분리된 패스로 인해 메모리 대역폭 오버헤드가 발생하여 모바일에 특히나 비효율적임
- URP는 "G-Buffer -> GPU캐시 -> 조명 계산"으로 진행되며 Native RenderPass API를 지원하여 G-Buffer와 조명 패스가 단일 렌더 패스로 결합되어 특히 모바일에서 뛰어난 성능을 보여줌
*G-Buffer: 픽셀의 위치, 법선, 색상, 재질 정보 등을 저장하는 여러개의 텍스처 버퍼
*지오메트리 정보: 3D 모델의 형태, 위치, 방향 등의 기본적인 형상 데이터
*Native RenderPass API: 모바일 GPU의 타일 기반 렌더링 특성을 활용해 여러 렌더링 단계를 하나로 결합하는 기술
최종 결론
- URP는 빌트 인 렌더링에 비해 성능이 매우 뛰어나며 커스터마이징이 가능하다는 강점을 가지고 있다.
- 빌트 인은 렌더 플로와 렌더 패스가 사전 구조화가 되어 있어 플랫폼 별 최적화, 특수 효과 등 만들기 어려움
- 빌트 인은 동기화 콜백이 트리거 되어 멀티 스레드 렌더링에 최적화를 방해하지만, URP는 미리 사용할 설정들을 준비해놓고 갑작스러운 상태변경이 없어 성능이 뛰어남
TODO: 추후 PDF파일에 있는 실습도 해보면 좋을 것 같음
참고 자료 : 바로가기
Unity 고급 사용자를 위한 유니버설 렌더 파이프라인 소개(Unity 2022 LTS) | Unity
유니버설 렌더 파이프라인을 기반으로 새 프로젝트를 시작하거나 빌트인 렌더 파이프라인에서 기존 프로젝트를 마이그레이션하는 방법을 소개하는 전자책입니다.
unity.com
빌트인 렌더 파이프라인의 렌더링 경로 - Unity 매뉴얼
Unity의 빌트인 렌더 파이프라인은 다양한 렌더링 경로를 지원합니다. 렌더링 경로는 조명 및 셰이딩과 관련된 일련의 작업입니다. 렌더링 경로는 저마다 다른 기능 및 성능 특성을 지니고 있습
docs.unity3d.com
'유니티 > 유니티 이론' 카테고리의 다른 글
| [이론] ECS (2) | 2025.06.26 |
|---|---|
| [이론] 에셋 번들 (2) | 2025.06.18 |
| [이론] Addressable (0) | 2025.06.15 |
| [이론] UniTask (3) | 2025.06.12 |
| [이론] async/await (0) | 2025.06.11 |