스크립터블 렌더 파이프라인
1. 개요
1. 개요
스크립터블 렌더 파이프라인은 유니티 테크놀로지스가 개발한 유니티 엔진의 고수준 스크립팅 가능 렌더링 프레임워크이다. 이 기술은 2018년에 출시된 유니티 2018.1 버전에서 최초로 등장하였다. 기존의 고정된 렌더 파이프라인을 대체하여, 개발자가 C# 스크립트를 통해 렌더링 과정의 거의 모든 측면을 세밀하게 제어하고 프로그래밍할 수 있도록 설계되었다.
이 프레임워크의 주요 목적은 고품질 렌더링을 구현하고, 실시간 렌더링 파이프라인을 직접 제어하며, 다양한 플랫폼에 맞게 렌더링을 최적화하는 데 있다. 이를 통해 게임 개발 및 인터랙티브 콘텐츠 제작 분야에서 그래픽스 품질과 성능을 균형 있게 조절할 수 있는 유연성을 제공한다. 스크립터블 렌더 파이프라인은 컴퓨터 그래픽스와 게임 엔진 아키텍처의 핵심 구성 요소로 자리 잡았다.
스크립터블 렌더 파이프라인은 렌더링 로직을 에셋 형태로 관리하는 모듈식 구조를 채택한다. 핵심 구성 요소로는 렌더링 설정을 정의하는 렌더 파이프라인 에셋과 실제 렌더링 작업을 수행하는 렌더러 에셋이 있다. 또한, 렌더링 단계를 구성하는 렌더 패스와 그래픽스 API에 명령을 전달하는 커맨드 버퍼를 활용하여 복잡한 렌더링 효과를 구현한다.
2. 기본 개념
2. 기본 개념
2.1. 렌더 파이프라인 에셋과 렌더러 에셋
2.1. 렌더 파이프라인 에셋과 렌더러 에셋
스크립터블 렌더 파이프라인의 구성과 동작은 렌더 파이프라인 에셋과 렌더러 에셋이라는 두 가지 핵심 에셋 타입을 통해 정의된다. 이들은 프로젝트의 렌더링 방식을 결정하는 설정 파일 역할을 한다.
렌더 파이프라인 에셋은 렌더링의 전체적인 구조와 질감, 그림자 품질, 광원 처리 방식과 같은 고급 설정을 담당한다. 이 에셋은 유니티 에디터의 그래픽스 설정에서 지정되며, 프로젝트가 사용할 렌더링 백엔드와 전반적인 렌더링 품질을 제어한다. 반면, 렌더러 에셋은 렌더 파이프라인 에셋 내부에서 참조되며, 실제로 카메라가 장면을 그리는 구체적인 단계와 순서, 즉 렌더 패스의 스택을 정의한다.
이러한 분리된 구조는 높은 유연성을 제공한다. 하나의 렌더 파이프라인 에셋에 여러 개의 서로 다른 렌더러 에셋을 연결할 수 있어, 예를 들어 메인 카메라에는 고품질의 포워드 렌더러를, UI나 특수 효과를 위한 카메라에는 단순화된 렌더러를 사용하는 식으로 상황에 맞게 렌더링 방식을 세분화할 수 있다. 이는 성능 최적화와 특수한 렌더링 요구사항을 동시에 충족시키는 데 핵심적이다.
따라서 스크립터블 렌더 파이프라인을 구성할 때는 먼저 렌더 파이프라인 에셋을 생성하여 전역 설정을 하고, 이후 필요에 따라 하나 이상의 렌더러 에셋을 만들어 각 카메라에 할당하는 워크플로를 따른다. 이 두 에셋이 함께 작동하여 실시간 렌더링의 모든 측면을 프로그래머블하게 제어할 수 있는 기반을 마련한다.
2.2. 렌더 패스
2.2. 렌더 패스
렌더 패스는 스크립터블 렌더 파이프라인에서 하나의 완전한 렌더링 작업 단위를 정의한다. 렌더링 과정을 카메라별, 효과별로 세분화된 단계로 나누어 구성하며, 각 패스는 특정 목표(예: 깊이 정보 생성, 그림자 맵 렌더링, 불투명 오브젝트 그리기, 후처리 효과 적용 등)를 수행하기 위한 커맨드 버퍼 명령어 집합을 담고 있다. 개발자는 이러한 패스들을 유연하게 조합하고 순서를 제어함으로써 전통적인 고정 렌더 파이프라인에서는 불가능했던 세밀한 렌더링 제어를 실현할 수 있다.
렌더 패스는 크게 스크립터블 렌더 패스와 블릿 패스 등으로 구분된다. 스크립터블 렌더 패스는 C 샤프 스크립트를 통해 완전히 사용자 정의가 가능한 패스로, 커스텀 렌더 타겟 설정, 셰이더 패스 실행, 커맨드 버퍼 기록 등의 모든 작업을 프로그래머가 직접 설계한다. 반면, 블릿 패스나 렌더 오브젝트 패스와 같은 내장 유틸리티 패스들은 유니티 엔진이 제공하는 공통 작업을 빠르게 수행할 수 있도록 미리 정의된 템플릿 역할을 한다.
렌더 패스 설계의 핵심은 렌더링 자원의 효율적 관리와 재사용에 있다. 여러 패스에서 동일한 렌더 텍스처나 버퍼를 참조할 수 있으며, 패스 간의 의존성을 명시적으로 정의함으로써 불필요한 연산을 제거하고 GPU 작업 부하를 최적화한다. 예를 들어, 그림자 맵을 생성하는 패스를 먼저 실행한 후, 해당 맵을 사용하는 메인 오브젝트 렌더링 패스를 실행하는 식으로 파이프라인을 구성한다. 이는 모바일 게임부터 고사양 PC 및 콘솔 게임에 이르기까지 다양한 플랫폼에 맞는 렌더링 전략을 구축하는 데 필수적인 기반이 된다.
2.3. 커맨드 버퍼
2.3. 커맨드 버퍼
커맨드 버퍼는 스크립터블 렌더 파이프라인의 핵심 구성 요소 중 하나로, GPU에 제출할 그래픽 명령어 목록을 담는 객체이다. 렌더 패스 내에서 이 버퍼를 생성하고, 드로우 콜, 클리어 작업, 렌더 타것 변경 등 다양한 렌더링 명령을 기록한다. 이렇게 기록된 명령어들은 나중에 커맨드 큐를 통해 GPU에 제출되어 실행된다. 커맨드 버퍼를 사용하면 스크립트를 통해 렌더링 과정을 세밀하게 제어할 수 있으며, 기존의 즉시 실행 모드 렌더링과 달리 명령을 미리 모아서 효율적으로 처리할 수 있다.
커맨드 버퍼의 주요 기능은 드로우 메시, 렌더 텍스처 복사, 커스텀 쉐이더 패스 실행, 포스트 프로세싱 효과 구현 등이 있다. 예를 들어, 특정 카메라의 뷰를 미리 렌더링하거나, 셰도우 맵을 생성하는 과정, 스크린 스페이스 리플렉션과 같은 복잡한 효과를 추가할 때 커맨드 버퍼가 활용된다. 이를 통해 개발자는 유니티 엔진의 기본 렌더링 흐름을 벗어나 자유롭게 확장된 렌더링 로직을 설계할 수 있다.
커맨드 버퍼는 렌더러 에셋에 정의된 렌더 패스에서 생성되고 관리된다. 각 패스는 자신의 렌더링 목적에 맞게 하나 이상의 커맨드 버퍼를 사용하며, 커맨드 버퍼 풀을 통해 성능 최적화를 도모할 수 있다. 사용이 완료된 버퍼는 적절히 해제하여 메모리 누수를 방지해야 한다. 이와 같은 저수준 제어 기능 덕분에 스크립터블 렌더 파이프라인은 모바일 게임의 효율적인 렌더링부터 AAA 게임의 고품질 시각 효과 구현까지 광범위한 요구사항을 충족시킬 수 있다.
3. SRP의 장점
3. SRP의 장점
스크립터블 렌더 파이프라인은 기존의 고정된 빌트인 렌더 파이프라인을 대체하며, 개발자가 렌더링 과정을 세밀하게 제어할 수 있도록 해준다. 이는 게임 엔진의 렌더링 아키텍처를 완전히 재정의하여, 다양한 플랫폼과 프로젝트 요구사항에 맞는 고도로 최적화된 렌더링 솔루션을 구축할 수 있는 기반을 제공한다.
가장 큰 장점은 렌더링 로직의 완전한 제어권을 개발자에게 부여한다는 점이다. 개발자는 C# 스크립트를 통해 카메라별 렌더링 순서, 라이트 처리 방식, 포스트 프로세싱 효과 적용 시점 등 렌더링의 모든 단계를 직접 설계하고 최적화할 수 있다. 이를 통해 특정 하드웨어의 성능을 극대화하거나, 독특한 비주얼 스타일을 구현하는 것이 가능해진다.
또한, 모듈화와 재사용성이 크게 향상된다. 렌더링 작업을 독립적인 렌더 패스 단위로 구성할 수 있어, 특정 기능(예: 그림자 생성, 반사 계산)을 모듈처럼 조합하거나 교체하기가 용이하다. 이는 프로젝트 간 코드 재사용을 촉진하고, 복잡한 렌더링 효과를 체계적으로 관리할 수 있게 한다.
마지막으로, 유니티가 공식적으로 제공하는 유니버설 렌더 파이프라인과 하이 데피니션 렌더 파이프라인은 모두 이 프레임워크 위에 구축된 구현체이다. 이는 개발자가 하나의 통합된 API와 개념을 학습함으로써, 모바일부터 고사양 PC에 이르기까지 광범위한 그래픽스 요구사항을 처리할 수 있는 역량을 갖추게 함을 의미한다.
4. SRP 구현체
4. SRP 구현체
4.1. 유니버설 렌더 파이프라인 (URP)
4.1. 유니버설 렌더 파이프라인 (URP)
유니버설 렌더 파이프라인은 유니티 테크놀로지스가 개발한 스크립터블 렌더 파이프라인의 주요 구현체 중 하나이다. 이 렌더 파이프라인은 유니티 2018.1 버전에서 처음 소개되었으며, 모바일 게임부터 PC 게임 및 콘솔 게임에 이르기까지 광범위한 플랫폼에서 고품질의 실시간 렌더링을 제공하는 것을 목표로 설계되었다. URP는 개발자가 그래픽스 설정을 세밀하게 제어할 수 있는 스크립팅 가능한 프레임워크를 제공하여, 다양한 하드웨어 성능에 맞춰 렌더링 품질과 성능을 최적화할 수 있게 한다.
URP의 핵심 설계 철학은 성능과 접근성에 있다. 이는 빌트인 렌더 파이프라인의 단순함과 HDRP의 고급 기능 사이에서 균형을 잡는다. 이를 통해 인디 게임 개발자부터 대형 스튜디오에 이르기까지 다양한 규모의 프로젝트에서 활용할 수 있다. URP는 사전 구성된 렌더링 기능 세트를 제공하지만, 커스텀 렌더 패스와 커맨드 버퍼를 통해 파이프라인의 거의 모든 단계를 프로그래밍 방식으로 수정하거나 확장할 수 있는 유연성을 유지한다.
주요 기능으로는 향상된 2D 조명 시스템, VFX 그래프와의 통합, 그리고 유니버셜 셰이더를 통한 단순화된 머티리얼 워크플로우가 있다. 또한, VR 및 AR 애플리케이션 개발을 위한 최적화된 렌더링 경로를 포함하고 있어, 차세대 플랫폼 개발에도 적합하다. URP는 지속적인 업데이트를 통해 새로운 렌더링 기술을 도입하며, 실시간 글로벌 일루미네이션 솔루션과 같은 기능도 점진적으로 지원하고 있다.
특징 | 설명 |
|---|---|
주요 목표 | 광범위한 플랫폼 지원과 성능 효율성 |
주요 대상 | 모바일, PC, 콘솔을 아우르는 게임 및 애플리케이션 |
핵심 장점 | 높은 접근성, 사전 구성된 최적화, 커스터마이징 가능성 |
주요 기술 | 유니버셜 셰이더, 스크립터블 렌더 패스, 2D 조명 시스템 |
4.2. 하이브리드 렌더 파이프라인 (HRP)
4.2. 하이브리드 렌더 파이프라인 (HRP)
하이브리드 렌더 파이프라인은 유니티 엔진의 스크립터블 렌더 파이프라인 생태계 내에서 제공되는 주요 구현체 중 하나이다. 이 렌더 파이프라인은 이름에서 알 수 있듯이, 기존의 레거시 렌더러와 새로운 SRP 기반 렌더러를 혼합하여 사용하는 접근 방식을 취한다. 이는 프로젝트를 완전히 새로운 URP나 HDRP로 마이그레이션하는 데 따르는 복잡성과 시간을 줄이면서도, 특정 렌더 패스나 효과에 대해서만 SRP의 고급 제어 기능을 활용하고자 할 때 유용한 선택지가 된다.
주요 작동 방식은 커맨드 버퍼를 통해 특정 렌더링 단계에 사용자 정의 명령을 삽입하는 것이다. 예를 들어, 기본적인 불투명 오브젝트와 투명 오브젝트 렌더링은 기존의 빌트인 렌더러가 처리하도록 한 상태에서, 특수한 포스트 프로세싱 효과나 커스텀 그림자 생성, 특정 레이어의 오브젝트에 대한 별도의 렌더링 패스는 SRP API를 통해 프로그래밍적으로 제어할 수 있다. 이렇게 하이브리드 방식으로 구성하면, 프로젝트의 대부분은 검증된 기존 워크플로우를 유지하면서도, 필요한 부분에만 SRP의 유연성과 성능 이점을 도입할 수 있다.
하이브리드 렌더 파이프라인은 특히 대규모 기존 프로젝트를 점진적으로 현대화하거나, 특정 플랫폼에 맞춘 매우 세밀한 렌더링 최적화가 필요할 때 그 강점을 발휘한다. 또한, URP나 HDRP가 제공하지 않는 독자적인 렌더링 테크닉을 구현해야 하는 경우, 하이브리드 접근법을 통해 핵심 로직만을 SRP로 개발하고 나머지는 기존 인프라를 활용하는 전략을 세울 수 있다. 이는 게임 개발뿐만 아니라 시뮬레이션, 가상 현실 등 다양한 실시간 렌더링 응용 분야에서 유용하게 적용될 수 있는 중간 단계의 솔루션이다.
4.3. 하이 데피니션 렌더 파이프라인 (HDRP)
4.3. 하이 데피니션 렌더 파이프라인 (HDRP)
하이 데피니션 렌더 파이프라인은 유니티 엔진의 스크립터블 렌더 파이프라인 프레임워크를 기반으로 한 고품질 렌더링 솔루션이다. 이 렌더 파이프라인은 고사양 PC, 플레이스테이션 5, 엑스박스 시리즈 X/S와 같은 고성능 플랫폼을 대상으로 하며, 시네마틱 수준의 시각적 충실도를 실시간으로 구현하는 것을 목표로 한다. HDRP는 물리 기반 렌더링, 정교한 조명 시스템, 고급 후처리 효과를 광범위하게 지원하여 AAA급 게임이나 고품질 아키텍처 시각화, 자동차 렌더링 등에 적합하다.
HDRP는 스크립터블 렌더 파이프라인의 핵심 구조인 렌더 패스와 커맨드 버퍼를 활용하여 렌더링 과정을 세밀하게 제어한다. 이를 통해 개발자는 복잡한 다중 패스 렌더링, 사용자 정의 포스트 프로세싱, 특정 하드웨어 아키텍처에 맞춘 최적화를 구현할 수 있다. HDRP는 볼류메트릭 라이팅, 스크린 스페이스 리플렉션, 레이 트레이싱과 같은 현대적인 렌더링 기법을 통합하여 사실적인 조명과 반사, 그림자 효과를 제공한다.
이 렌더 파이프라인을 사용하기 위해서는 HDRP 에셋과 HDRP 렌더러 에셋을 프로젝트에 설정해야 한다. 또한, HDRP 전용 쉐이더 그래프나 HLSL로 작성된 쉐이더를 사용해야 하며, 기존의 빌트인 렌더 파이프라인용 쉐이더와는 호환되지 않는다. HDRP는 높은 하드웨어 요구사항과 복잡한 설정 과정이라는 진입 장벽이 있지만, 그 대가로 다른 유니티 렌더링 솔루션보다 월등한 시각적 결과를 얻을 수 있다.
5. 작동 방식
5. 작동 방식
5.1. 초기화 및 설정
5.1. 초기화 및 설정
스크립터블 렌더 파이프라인을 프로젝트에서 사용하기 위해서는 먼저 렌더 파이프라인 에셋을 생성하고 프로젝트 설정에 지정해야 한다. 이 과정은 유니티 에디터의 메뉴나 C# 스크립트를 통해 수행할 수 있다. 생성된 렌더 파이프라인 에셋은 그래픽스 설정 창에서 활성화되며, 이를 통해 카메라가 사용할 렌더러 에셋과 같은 구체적인 렌더링 방식을 결정한다.
초기화 단계에서는 렌더 파이프라인 클래스를 상속받은 사용자 정의 클래스의 인스턴스가 생성된다. 이 인스턴스는 RenderPipeline.Render 메서드를 오버라이드하여 전체 렌더 루프를 정의하는 핵심이 된다. 설정 과정에서는 커맨드 버퍼를 활용하여 렌더 패스를 구성하고, 쉐이더와 머티리얼이 새로운 파이프라인과 호환되도록 쉐이더 변형을 관리하는 작업이 포함된다.
스크립터블 렌더 파이프라인의 설정은 프로젝트 전반에 걸쳐 일관된 렌더링 품질과 스타일을 보장하는 동시에, 특정 카메라나 씬에 대해 개별적인 렌더러를 할당하는 유연성을 제공한다. 이는 유니버설 렌더 파이프라인과 하이 데피니션 렌더 파이프라인과 같은 공식 구현체를 선택하거나, 완전히 새로운 사용자 정의 파이프라인을 구축하는 토대가 된다.
5.2. 렌더 루프
5.2. 렌더 루프
스크립터블 렌더 파이프라인의 핵심 작동 원리는 렌더 루프에 있다. 렌더 루프는 매 프레임마다 카메라가 장면을 렌더링하기 위해 실행되는 일련의 단계적 절차를 의미한다. 이 과정은 렌더 패스라는 단위로 구성되며, 개발자는 커맨드 버퍼를 통해 이러한 패스들의 실행 순서와 내용을 직접 프로그래밍하여 제어할 수 있다. 이는 기존의 고정된 렌더 파이프라인과 달리, 특정 게임이나 애플리케이션의 요구사항에 맞춰 렌더링 방식을 유연하게 구성할 수 있게 해준다.
일반적인 렌더 루프는 초기화, 컬링, 렌더링, 후처리 단계로 나눌 수 있다. 먼저, 필요한 렌더 텍스처를 할당하고 라이트 데이터를 설정하는 등의 초기 작업이 이루어진다. 이후 카메라의 시야 내에 보이는 객체들만을 선별하는 컬링 과정을 거친다. 그다음으로는 객체들을 쉐이더와 머티리얼에 따라 그리는 주요 렌더링 패스(예: 불투명 객체 렌더링, 투명 객체 렌더링)가 실행된다. 마지막으로 블룸이나 컬러 그레이딩과 같은 이미지 효과를 적용하는 후처리 패스가 수행되어 최종 화면이 완성된다.
이러한 렌더 루프의 설계는 성능과 화질에 직접적인 영향을 미친다. 예를 들어, 모바일 플랫폼에서는 렌더 패스의 수를 최소화하고, 고사양 PC에서는 고품질의 글로벌 일루미네이션이나 복잡한 셰이딩을 위한 여러 패스를 추가할 수 있다. 스크립터블 렌더 파이프라인은 개발자로 하여금 이러한 최적화와 확장을 엔진의 코어 수준에서 구현할 수 있는 능력을 제공한다.
5.3. 쉐이더 작성
5.3. 쉐이더 작성
스크립터블 렌더 파이프라인에서 쉐이더를 작성하는 방식은 기존의 빌트인 렌더 파이프라인과 차별화된다. SRP는 HLSL을 기본 쉐이더 언어로 사용하며, 쉐이더 라이브러리 파일을 통해 핵심 라이팅 및 그림자 기능을 제공한다. 개발자는 이러한 라이브러리를 포함하는 쉐이더 코드를 작성하여 렌더 패스 내에서 커맨드 버퍼를 통해 실행한다. 이 접근 방식은 렌더링 로직의 통제권을 개발자에게 부여하며, 다중 플랫폼 지원을 위한 쉐이더 변형 관리도 용이하게 한다.
SRP용 쉐이더는 일반적으로 HLSLPROGRAM 블록 내에 작성되며, 유니티의 SRP 쉐이더 라이브러리에서 제공하는 함수와 구조체를 활용한다. 예를 들어, 라이팅 계산을 위해 Lighting.hlsl 파일을 포함하고, 표면 정보를 전달하기 위해 Attributes 구조체와 Varyings 구조체를 정의한다. 버텍스 쉐이더와 프래그먼트 쉐이더의 진입점 함수명은 URP와 HDRP와 같은 SRP 구현체에 따라 약간의 차이가 있을 수 있다.
SRP 쉐이더 작성의 핵심은 렌더러와의 통합이다. 쉐이더는 특정 렌더 패스에서 요구하는 렌더 타겟 형식과 호환되어야 하며, 렌더 상태(예: 컬링 모드, 블렌딩, 깊이 테스트)는 종종 쉐이더 패스 태그나 커맨드 버퍼를 통해 제어된다. 또한, SRP 배처와 효율적으로 협력하기 위해 쉐이더에 적절한 라이팅 모드 태그와 렌더 큐를 지정하는 것이 중요하다. 이를 통해 드로우 콜을 최소화하고 렌더링 성능을 향상시킬 수 있다.
6. 사용 사례
6. 사용 사례
스크립터블 렌더 파이프라인은 개발자가 특정 프로젝트의 요구사항에 맞춰 렌더링 방식을 세밀하게 제어할 수 있게 해주며, 이는 다양한 사용 사례에서 두드러진 장점으로 작용한다. 고품질의 시네마틱 컷신이나 AAA급 그래픽을 요구하는 콘솔 및 PC 게임 제작에는 하이 데피니션 렌더 파이프라인이 적합하다. HDRP는 물리 기반 렌더링, 고급 라이팅 효과, 정교한 포스트 프로세싱을 지원하여 사실적인 시각적 품질을 구현하는 데 사용된다.
반면, 모바일 게임이나 VR/AR 콘텐츠와 같이 광범위한 플랫폼과 높은 성능이 요구되는 프로젝트에서는 유니버설 렌더 파이프라인이 주로 활용된다. URP는 가볍고 효율적인 구조를 통해 스마트폰, 태블릿, VR 헤드셋 등 다양한 하드웨어에서 안정적인 프레임률을 유지하면서도 풍부한 시각 효과를 제공할 수 있다. 이는 크로스 플랫폼 개발을 용이하게 한다.
또한, 스크립터블 렌더 파이프라인의 확장성은 특수한 렌더링 기법이나 비게임 분야의 응용 프로그램 개발에 유용하다. 예를 들어, 건축 시각화, 의료 시뮬레이션, 혹은 특정 스타일라이즈드 렌더링 기법이 필요한 프로젝트에서 개발자는 커스텀 렌더 패스를 설계하여 기존 파이프라인으로는 구현하기 어려운 독특한 시각적 스타일이나 데이터 시각화 방식을 창출할 수 있다.
7. 주요 API
7. 주요 API
스크립터블 렌더 파이프라인의 핵심 기능은 C# 스크립트를 통해 렌더링 과정을 제어하는 데 있으며, 이를 위해 제공되는 주요 API들이 있다. 이 API들은 개발자가 렌더 파이프라인 에셋을 구성하고, 커맨드 버퍼에 명령을 기록하며, 카메라별 렌더링을 관리하는 데 사용된다.
가장 중심이 되는 클래스는 ScriptableRenderContext이다. 이 클래스는 렌더링 명령의 실행 컨텍스트를 제공하며, CommandBuffer에 담긴 일련의 그래픽스 명령을 제출하고 실제 GPU에서 실행되도록 스케줄링하는 역할을 한다. 개발자는 ScriptableRenderContext.Submit() 메서드를 호출하여 기록된 명령을 실행한다. 또한 ScriptableRenderPipeline 클래스는 모든 SRP 구현체의 추상 베이스 클래스로, Render() 메서드를 오버라이드하여 프레임별 렌더링 로직을 정의한다.
렌더링 명령을 구성하기 위해서는 CommandBuffer 클래스가 광범위하게 활용된다. 이 클래스를 통해 드로우 콜 발행, 렌더 타겟 전환, 컴퓨트 셰이더 디스패치, 일시적 렌더 텍스처 할당 및 해제 등의 저수준 작업을 지시할 수 있다. RenderingCommandBuffer의 명령들은 ScriptableRenderContext.ExecuteCommandBuffer()를 통해 컨텍스트에 주입된다. 한편, ScriptableRenderPass와 ScriptableRenderer 클래스는 렌더링 작업을 모듈화하고 재사용 가능한 단위로 구성하는 프레임워크를 제공하여, URP와 HDRP 같은 구체적인 구현체의 기반이 된다.
렌더링 관련 데이터에 접근하기 위한 유틸리티 API도 중요하다. RenderPipelineManager는 SRP의 글로벌 라이프사이클 이벤트를 감지할 수 있게 해주며, UniversalRenderPipeline이나 HDRenderPipeline과 같은 구체적인 파이프라인 구현체 클래스는 각각의 설정과 글로벌 프로퍼티를 제어하는 정적 메서드와 프로퍼티를 제공한다. 또한 Shader 클래스와 MaterialPropertyBlock 클래스를 결합하여 런타임에 셰이더 프로퍼티를 효율적으로 관리하고 설정하는 것이 일반적이다.
