Selective Bloom RendererFeature 자체 구현
ChosenPros
- 레이어 격리 가능, RT/픽셀 비용 직접 통제
Cons
- 유지보수 책임 본인, URP 버전 업그레이드 대응 필요
⏱ 1 min read
Selective Bloom RendererFeature
URP Bloom을 레이어 단위로 격리 처리 — RT 메모리 90% 절감 + 픽셀 처리량 35~40% 절감
- −90%VFX FPS RT 메모리 (~5–10 MB → ~0.5 MB)
- −35~40% 픽셀 처리량 (1080p 기준)
- 레이어 격리 UI·캐릭터·배경에 Bloom 미영향
Problem
Approach
URP 기본 Bloom 튜닝
Pros
- 검증된 구현, 유지보수 부담 없음
Cons
- 레이어 격리 불가, 메모리·픽셀 비용 그대로
Why Selective Bloom RendererFeature 자체 구현: 이펙트만 Bloom 처리한다는 요구가 명확하므로, 화면 전체를 처리하는 mip chain 구조 자체가 과잉. LayerMask로 BloomFX 레이어만 별도 RT에 렌더 → 2-pass 블러 → Additive 합성하는 최소 파이프라인이 적합.
Architecture
Implementation
- 01
Step 1 — RendererFeature: 레이어 격리 렌더링
LayerMask 필터로 BloomFX 레이어 외 오브젝트는 컬링. 다운샘플 단계(
downsampleSteps)는 인스펙터에서 0~3 조정 가능. - 02
Step 2 — Separable 2-pass Blur
3-tap × V/H 분리 블러. iteration으로 반경 확장. RT 2개를 ping-pong해서 메모리 최소화.
오프셋 벡터(
_BlurOffset)는 vertex shader에서 한 번 계산해 V2F로 전달 → fragment 비용 절감. - 03
Step 3 — Additive 합성 + HDR 톤매핑 컨트롤
- BT.709 휘도 기반 Threshold로 색상 비율 보존
_HighlightIntensity로 피크 강도 조절 (제곱 곡선)_WhiteOut으로 매우 밝은 영역만 흰색으로 타오르게 (white-hot)
Validation
1080p 기준 비교
| 항목 | URP 기본 Bloom | Selective Bloom |
|---|---|---|
| 픽셀 처리량 | ~4.0M | ~2.6M (−35%) |
| Blur 샘플 수 | 9-tap dual filter | 3-tap × 2-pass = 6-tap |
| RT 수 | 6+ (mip chain) | 2 (ping-pong) |
| RT 메모리 | ~5–10 MB | ~0.5 MB (−90%) |
| 합성 영향 범위 | full screen | BloomFX 레이어 한정 |
| 다운샘플 단계 | 5+ 고정 | 0~3 인스펙터 조정 |
| 머티리얼 파라미터 | Threshold·Intensity 등 일부 | Threshold·Highlight·WhiteOut·Blur 가중치 등 직접 노출 |
Tradeoffs & Future Work
Tradeoffs
- 레이어 분리 강제: BloomFX 적용 대상은 별도 레이어로 분류 필요. 기존 프로젝트 마이그레이션 시 레이어 정리 비용 발생.
- DrawRenderers 추가: BloomFX 레이어 오브젝트 수가 많으면 별도 드로우콜이 증가할 수 있음. 화면당 수십 개 수준의 이펙트에서는 무시 가능.
- mip chain 부재: 매우 큰 반경의 블룸이 필요하면 blurIterations 증가가 필요해 비용이 선형 증가. 광역 글로 효과보다 점광원·이펙트 발광에 최적.
- URP 버전 업그레이드 대응 책임: Blitter.BlitCameraTexture, ScriptableRenderPass API 변경 시 자체 유지보수 필요.
Conclusion
URP 기본 Bloom은 cinematic·콘솔 환경의 화면 전체 발광 표현에 최적화되어 있다. 모바일에서 이펙트 발광만 표현하면 되는 시나리오라면 이 파이프라인 자체가 과잉이며, 레이어 격리 + 최소 패스 구조의 자체 RendererFeature가 더 적합하다.