빠른 비교
| 방식 | 핵심 | 강점 | 약점 |
|---|---|---|---|
| Forward | 물체를 그릴 때 조명도 함께 계산 | 단순, 투명 처리 자연스러움 | 조명이 많으면 비용 증가 |
| Deferred | 먼저 G-buffer를 만들고 나중에 조명 계산 | 많은 조명에 유리 | 메모리, 투명도, MSAA 처리 어려움 |
| Forward+ | 화면을 tile/cluster로 나눠 조명 목록 제한 | forward 장점 유지 | 구현 복잡도 증가 |
구조
Forward rendering은 각 물체를 그릴 때 material과 light를 함께 계산합니다. 물체 수와 조명 수가 곱으로 늘면 비용이 커질 수 있지만, 투명 물체와 다양한 material 처리가 비교적 직관적입니다.
Deferred rendering은 먼저 G-buffer에 position/depth, normal, albedo, roughness 같은 정보를 저장합니다. 그 다음 화면 공간에서 조명을 계산합니다.
geometry pass -> G-buffer
lighting pass -> shaded image이 방식은 많은 조명이 있을 때 같은 geometry를 다시 그리지 않고 화면 공간에서 조명을 누적할 수 있습니다. 대신 G-buffer 여러 장을 저장해야 하므로 bandwidth와 메모리 비용이 큽니다.
투명도
Deferred는 불투명 표면 하나의 material 정보를 G-buffer에 저장하는 구조라, 여러 투명 레이어를 자연스럽게 담기 어렵습니다. 그래서 투명 물체는 별도 forward pass로 처리하는 경우가 많습니다.
선택 기준
| 상황 | 먼저 검토 |
|---|---|
| 조명 수가 적고 단순한 장면 | Forward |
| 투명 물체가 중요 | Forward 또는 별도 transparent pass |
| 작은 조명이 많음 | Deferred 또는 Forward+ |
| 모바일 bandwidth가 민감 | Forward 계열 검토 |
| 복잡한 material 다양성 | Forward가 단순할 수 있음 |
| screen-space lighting 중심 | Deferred |
현대 렌더러는 한 방식만 쓰지 않고 forward, deferred, compute culling, tiled lighting을 섞는 경우가 많습니다.
주의할 점
Deferred가 항상 빠른 것은 아닙니다. G-buffer를 여러 장 쓰면 메모리 대역폭이 커지고, 고해상도에서는 이 비용이 크게 나타납니다.
Forward도 조명이 많다고 무조건 느린 것은 아닙니다. tile/cluster 기반 light culling을 쓰면 조명 후보를 크게 줄일 수 있습니다.
Deferred는 G-buffer에 저장한 정보로 나중에 조명 계산을 합니다. G-buffer에 담지 않은 재질 효과나 레이어 정보는 별도 pass나 추가 버퍼 없이는 복원할 수 없습니다.
참고 링크
1 sources