[Unity] Renderer

■ Renderer (Unity 6 + URP)

렌더러	작동 방식	장점	단점
Forward	· 씬 안에 있는 각 오브젝트를 개별적으로 렌더링하고 각각의 픽셀을 개별적으로 계산한다. · 즉, 화면의 모든 픽셀마다 Unity가 해당 픽셀의 최족 생상에 영향을 주는 씬의 각 오브젝트의 조명과 셰이딩을 계산함. · 9개 정도의 제한적인 광원의 수. 초과하면 다 무시하거나 Bake로 대체.	· 직관적으로 이해할 수 있음 · 광원 수가 적으며 머테리얼이 단순한 씬에선 효과적임.	· 광원 수가 많고 머테리얼이 복잡한 씬에서는 비효율적임. · 각 광원이 씬의 여러 패스를 거쳐야 하므로 렌더링 오버헤드가 늘어나기 때문
Forward+	· Forward Rendering의 한계를 일부 개선한 기법   · 많은 수의 광원을 더 효과적으로 처리함 · 광원을 클러스터(Cluster)로 그룹화하고 조명을 계산할 때는, 각 클러스터 내 오브젝트만 고려함. 한 클러스터 내 처리가능한 광원의 수는 일반적으로, Unity URP 기준, 32개임 · 씬 전체에 광원의 개수 제한은 없음. 다만 카메라 세팅에 따라 현재 화면(View) 내에 처리 가능한 광원의 수가 제한적일 수 있음. ▼ 예시를 생각해봄  예를 들어 1080p 해상도 기준 32(8 x 4) 타일로 나뉜다고 가정하면, 이론적으로는 한 프레임에 최대 1024개(32 Clusters x 32 Lights)까지 처리가 가능하다.  하지만 일반적으로는 한 화면에 보이는 광원의 수가 대략 ~ 256개까지만 퍼포먼스 문제없이 무난하게 처리 가능하다.	· 광원의 수가 많은 씬에서 특히 성능이 뛰어남. · 각 광원에서 고려해야 하는 오브젝트의 수를 줄여 하드웨어 리소스를 더 효율적으로 활용할 수 있음.	· 광원 수가 매우 많거나 상당히 복잡한 씬에선 여전히 제한적 · Forward Rendering에 비해 더 많은 작업과 최적화가 필요할 수 있음
Deferred	· 지오메트리 렌더링 프로세스에서 조명 및 셰이딩 계산을 분리함   · 각 픽셀의 위치, 노멀, 머테리얼 프로퍼티 정보를 내포한 G-Buffer 세트로 지오메트리를 렌더링 함.   · 버퍼에 저장된 정보를 바탕으로 픽셀 단위로 조명을 계산함. · 1000+@ 개의 광원까지 커버 가능 · T(n) = O(n)	· 오브젝트 단위가 아니라 픽셀 단위 조명 계산이므로 광원 수가 많거나 머테리얼이 복잡한 씬에서 매우 효율적임 · 성능 저하를 최소화하면서 많은 수의 광원을 렌더링할 수 있음	· 추가 버퍼를 저장하기 위한 메모리 사용량 증가. · 투명 오브젝트 관련 제한, 볼류메트릭 조명 같은 특정 유형의 조명 효과 처리에 어려움이 있음

 

■ Renderer 지원 기능

기능	Forward	Forward+	Deferred
오브젝트당 사용 가능한 최대 실시간 광원 수	9	무제한, 카메라별 제한 적용	무제한
픽셀당 노멀 인코딩	인코딩 없음 (정확한 노멀 값)	인코딩 없음 (정확한 노멀 값)	두 가지 옵션 존재 1. G-Buffer 노멀 양자화 : 정확도 손실, 성능 향상 2. 팔면체 인코딩 : 정확한 노멀, 모바일 GPU에는 상당한 성능 영향을 미침
MSAA	O	O	X
GPU 상주 드로어	X	O	X
버텍스 조명	O	X	X
카메라 스태킹	O	O	X (G-Buffer기반임. Overlay카메라가 따로 G-Buffer에 쓸 수가 없음)

 

▼ 설정 가능 위치 (URP Asset을 생성하면 같이 추가 되는 Renderer Data에서 확인 가능)

 

■ 참고

https://unity.com/kr/resources/introduction-to-urp-advanced-creators-unity-6?utm_source=youtube-dc&utm_medium=social&utm_campaign=kr_unity_live_Feb_edit_unity6_URP_ebook

Unity 고급 사용자를 위한 유니버설 렌더 파이프라인 소개(Unity 6 에디션) | Unity