SRP(Scriptable Render Pipelines)
2018년부터 유니티에서 제공하기 시작한 Scriptable Render Pipeline(SRP)은 C# 스크립트를 통해 유니티의 렌더링을 구성하고 제어할 수 있는 기능이다.
왜 빌트인 렌더링 파이프라인말고 SRP가 필요할까?
Rendering Pipeline을 직접 구성한다는 것은 그만큼 많은 선택권을 가진다는 의미이다. 이는 개발자들이 직접 렌더링 파이프라인을 커스터마이징 할 수 있어, 게임의 렌더링 방식과 리소스 사용을 더욱 효과적으로 제어할 수 있다.
문제 발생!
이게 무조건 좋은 점만 있는 것이 아니다. 많은 선택권이 주어짐에 따라 많은 인력, 시간, 돈이 필요할 수 있다.
해결 방법
SRP 템플릿으로서 URP와 HDRP를 제공하여 이를 해결한다.
유니티는 새 프로젝트를 생성하면서 랜더링 파이프 라인을 선택 해야 한다.
01 Built-In Renderer
장점 : 다양한 셰이더와 이미지 효과가 존재하고 기존의 컨텐츠와 호환될 수 있다.
단점 : SRP를 통해서 컨트롤 할 수가 없다. 그리고 셰이더 그래프를 사용할 수 없다.
02 Lighweight(LWRP) - 현재는 보통 URP라고 부른다.
장점 : 퍼포먼스 최적화가 디어 있고 모바일 및 성능에 민감한 환경에서 높은 성능을 보여준다. 셰이더 그래프를 사용할 수 있고 최신 기능이 포함되어 있다.
단점 : SRP를 도입하기 위해서는 새로운 workflow에 대한 학습이 필요하다. 또한 일부 서드파티 툴과는 포함되지 않을 수 있다는 점을 염두해야 한다.
03 HDRP(High Definition Render Pipeline)
장점 : 고사양 PC 및 콘솔에서 고품질의 비주얼을 구현하는데 적합하다.
단점 : 성능이 낮은 플랫폼에서는 적합하지가 않으며, 새로운 툴과 프로세서의 적응하고 학습하는 시간이 필요하다.
04 Custom Render Pipline
개발자가 직접 랜더링 파이프라인을 제작을 하는 것이다. 게임이 필요한 컨텐츠에 초점을 맞춰서 컨트롤 할 수 가 있기 때문에 특정 게임에 최적화된 렌더링을 구현할 수 있다.
단점 : 초심자가 접근하기 어렵고 숙련된 전문가가 필요하다.
간단 정리
Built-in : 퍼즐은 이미 다 맞춰있고 퍼즐 꾸미기 정도만 가능하다.
SRP : 퍼즐 조각을 스스로 맞춰야 한다.
URP : 퍼즐조각을 어느정도 맞춰져 제공된다.
Render Pipeline
간단히 말하면 3D화면을 2차원으로 표현하는 과정이다. 만약 렌더링 파이프라인을 다른 종류로 전환하는 경우, 각 파이프라인이 서로 다른 셰이더와 구조를 사용하기 때문에 과정이 쉽지 않을 수 있다.
01 Render objects(오브젝트 랜더링)
씬 내의 모든 오브젝트를 초기화하고, 렌더링 큐에 추가한다.
02 Culling(컬링)
카메라 뷰에 보이지 않는 오브젝트를 제거하여 불필요한 렌더링을 방지한다. 하지만 추가 연산이 필요하기 때문에 이를 고려해야한다.
프러스텀 컬링(Frustum Culling) : 카메라 뷰 밖의 오브젝트를 제거
오클루전 컬링(Occlusion Culling) : 다른 오브젝트에 의해 가려진 오브젝트를 제거
03 Batching
유니티에서 서로 다른 오브젝트들이 각기 다른 Material을 사용하는 경우, 각 오브젝트는 별도로 렌더링이 필요하다. 그러나 같은 Material을 공유하는 Mesh들은 한 번에 그릴 수 있는데 이를 Batching이라고 한다.
Batching을 통해 한 번에 그리면 드로우콜 횟수를 줄여 성능이 향상 된다. 하지만 내부적으로 하나의 메시로 묶는 연산이 필요하기 때문에 메모리가 더 필요해진다.
드로우 콜이란?
CPU가 GPU에게 보내는 화면에 무언가를 그려달라는 명령을 의미한다. 드로우 콜은 CPU의 성능에 영향을 미치며 최적화를 위해서는 횟수 자체를 줄여야한다.
예시)
2D게임에서는 스프라이트들을 한 장의 텍스처에 눌러 담기도 한다. 그러면 하나의 Material로 처리해서 한 번에 렌더링(배치)할 수 있기 때문이다. 3D게임에서도 이렇게 텍스처를 눌러 담아서 최적화 한다.
SRP Batcher
Batch의 단위가 Material이 아닌 Shader 즉, 같은 셰이더를 사용한다면 한 번에 그릴 수 있다. 그러나 SRP Batcher를 지원해야 한다.
SRP를 지원하는지 어떻게 알아요?
Inspector창에서 확인하면 된다. 지원하는 경우 compatible이라고 나온다.
04 Post Processing(포스트 프로세싱)
렌더링이 끝난 화면에 다양한 후처리 효과를 적용하는 단꼐이다. 단순한 색보정부터 특수 효과, AA(안티 앨리어싱)까지 가능하다.
Post processing on URP
다수의 후처리 효과에서 기존대비 성능 향상을 제공한다. 특히 Bloom 효과부분 중 Boken DoF의 경우 어쩔 수 없이 무거 효과라 Gaussian DoF효과 추가하여 성능을 개선하였다.
DoF(Depth of Field) : 초점이 맞는 거리로 픽셀 연산이 많아 성능에 영향을 미칠 수 있는 무거운 효과이다.
Boken DoF : 오브젝트의 형체에 따라 블러 처리를 하므로 복잡한 연산을 한다.
Gaussain DoF : Boken DoF와 달리 단순히 블러처리를 해서 더 가볍다고 한다.
05 Upscale Sampling
성능을 가장 쉽게 최적화하는 방법은 해성도를 낮추는 것이다. 그런데 해상도를 낮추면 사용자들도 눈치 채기 쉽다! 그래서 '눈속임' 기법을 사용하면 된다.
3D씬은 저해상도로 그리고, UI는 원래 해상도로 그린다. 이는 전통적으로 콘솔 게임 에서도 애용하던 방법이며, 모바일에서도 유효한 최적화 기법이다.
특히 모바일에서 사용하면 좋은데, 모바일 같은 경우 화면이 작기 때문에 해상도를 낮춰도 많은 티가 나지 않는다. 그러므로 기법을 사용함에따라 성능을 높이고 배터리 소모를 줄이는데 유용하다.
URP에서 이를 적용시키는 방법
Universal Render Pipeline Asset에서 Quailty탭의 Render Scale을 조절하면 된다. 스크립트에서도 당연히 조절할 수 있다.
얼마나 효과가 있을까?
생각보다 효율이 좋다. 기존의 해상도의 50% 수준으로 낮추면 픽셀 수는 75%감소하고, 80%수준으로 낮추면 35%가 감소한다.
모바일에서의 URP
특히 안드로이드는 URP 사용에는 약간의 배경지식이 필요하다. 특히 안드로이드에서는 URP를 사용하는데 있어서 타겟 디바이스가 제한될 수 있다.
그래픽스 API(DirectX, OpenGL)
개발자가 각기 다른 OS와 GPU에 따라 코드를 작성하는 것은 매우 복잡하다. 그래서 그래픽스 API가 존재한다. OS와 GPU의 종류 등은 신경 쓰지 않고 렌더링 소프트웨어를 만들 수 있다.
URP와 SRP Batcher
URP의 핵심은 SRP Batcher이다. SRP Batcher는 다양한 플랫폼을 지원하지만 모바일 개발시에는, SRP Batcher가 OpenGL ES 3.1이상에서 작동한다는 점에 주목해야한다. 그러므로 Metel과 DirectX는 신경안써도 된다. 안드로이드기기마다 OpenGL ES 버젼이 다르기 때문에 이를 고려해야 한다.
안드로드에서의 URP 적용
안드로이드에서 URP를 적용하기 위해서는 타겟 디바이스가 줄어들 수 있다. OpenGL ES 3.1은 안드로이드 5.0(API Level 21)부터 지원한다. 따라서 그 이하 버전의 디바이스는 지원하지 못할 수 있다.
이에 모바일에서 URP를 사용하는데 필요한 배경지식과 제한 사항을 이해하면 안드로이드 개발시 적절한 선택을 할 수 있다.
참고
유니티 초보자도 이해하는 URP와 성능, 그리고 모바일까지🔥🔥 : https://www.youtube.com/watch?v=wNFjsi6MjAQ&t=41s
Scriptable Render Pipeline: 알아두어야 하는 사항들 : https://www.youtube.com/watch?v=eJEwnI8UGe4
[GDC 2024] Unity 6, 그 이후: Unity 엔진 및 서비스 로드맵 : https://www.youtube.com/watch?v=SExCOuTggCQ&t=1454s
댓글