Rendering : Forward, Deferred

Forward Rendering

forward rendering은 geometry를 그리는 시점에 각 픽셀의 조명 계산까지 함께 수행하고, 그 결과를 바로 최종 render target에 기록하는 방식이다.

geometry processing -> fragment 생성 -> material과 light를 이용한 shading -> 최종 색 출력

object 하나를 그릴 때 필요한 material, texture, light 정보가 같은 draw call 안에서 바로 결합된다.

이 구조는 화면의 각 픽셀은 자신이 속한 object를 그리는 순간 곧바로 모든 관련 광원의 영향을 계산해야 하기 때문에
광원이 많아질수록 비용이 빠르게 커진다.

---

Deferred Rendering

deferred rendering은 geometry를 그릴 때 최종 조명 결과를 바로 만들지 않고, 먼저 조명 계산에 필요한 정보를 버퍼에 저장한 뒤, 별도의 lighting pass에서 조명을 계산하는 방식이다.

geometry pass -> G-buffer 구성 -> lighting pass -> 최종 합성

여기서 geometry pass는 다음과 같은 데이터를 저장한다.

• albedo 또는 base color
• normal
• depth 또는 position
• material parameter의 일부

lighting pass에서는 이 G-buffer를 화면 기준으로 읽어 들여, 각 픽셀에 대해 필요한 광원 계산만 수행한다.
deferred rendering에서는 geometry 처리와 lighting 처리를 분리한다.

Deferred 이점

forward rendering에서는 object가 그려질 때마다 광원 계산이 반복된다.
따라서 scene에 영향을 주는 광원 수가 많아질수록 shading cost가 geometry와 강하게 결합된다.

반면 deferred rendering은 geometry 정보를 먼저 저장해 두고, 이후 lighting을 화면 공간에서 처리한다.
이 구조는 특히 다수의 광원이 존재하는 장면에서 더 효율적이다.

deferred rendering의 장점

• geometry cost와 lighting cost를 분리할 수 있다.
• 동일한 화면 픽셀에 대해 필요한 조명만 계산할 수 있다.
• 다수의 dynamic light를 다루는 장면에서 확장성이 좋다.

단점

• G-buffer를 위한 추가 메모리 대역폭이 필요하다.
• 여러 render target을 유지해야 하므로 구조가 복잡해진다.
• 투명 오브젝트 처리에는 기본적으로 불리하다.
• MSAA 같은 일부 기법과의 결합이 까다로울 수 있다.

deferred rendering은 광원이 많은 장면에서 lighting 비용을 더 잘 통제하기 위한 구조

---

deferred rendering은 다음과 같은 상황에서 특히 적합하다.

• 광원 수가 매우 많은 장면
• 화면 공간 기준 lighting 최적화가 중요한 경우
• 실시간으로 다양한 light volume을 다뤄야 하는 경우

반대로 다음과 같은 경우에는 forward rendering이 더 자연스러울 수 있다.

• 투명도 처리가 중요한 오브젝트
• 간단한 조명 모델만 필요한 장면
• 구현 복잡도를 낮추고 싶은 경우

forward rendering은

• 광원 수가 많지 않은 장면
• material과 shading 경로가 비교적 단순한 경우
• 투명 오브젝트처럼 최종 색을 즉시 알아야 하는 경우

에만 사용한다.

---

Forward + Deferred

deferred rendering은 광원이 많은 불투명 geometry 처리에 강하지만, 모든 재질을 동일한 방식으로 다루기에는 제약이 있다.
대표적으로 투명 오브젝트, alpha blending이 필요한 재질, 복잡한 per-pixel material evaluation이 필요한 경우는 deferred 경로만으로 처리하기 까다롭다.

반대로 forward rendering은 이런 재질 처리에는 자연스럽지만, scene 전체를 전부 forward로 처리하면 광원 수가 많을 때 shading cost가 급격히 커진다.

그래서 많은 렌더링 시스템은 다음과 같은 분업 구조를 택한다.

• 불투명하고 광원 수의 영향을 많이 받는 geometry는 deferred로 처리한다.
• 투명 오브젝트나 특수 재질은 forward로 처리한다.

이 구조는 성능과 표현력 사이의 균형을 맞추기 위한 선택이다.
즉 혼합 렌더링은 두 방식을 절충한 임시 해법이 아니라, 서로 다른 성질의 material과 pass를 분리하기 위한 실용적인 구조다.

---

Deferred에서 Forward연산을 처리

혼합 렌더링 대신, deferred 시스템 안에서 일부 연산을 forward에 가깝게 처리하는 방법도 존재한다.
deferred로 처리하기 어려운 부분만 국소적으로 forward 성격의 연산을 추가하는 방식.

• deferred lighting 이후에 별도의 material resolve pass를 둔다.
• G-buffer에 저장되지 않은 복잡한 shading 항목만 추가 pass에서 계산한다.
• transparent 또는 특수 재질만 별도 forward-like shading 경로로 보완한다.

예를 들어 다음과 같은 항목은 deferred만으로 다루기 불편하다.

• 반투명 재질
• 굴절
• 복잡한 specular 모델
• material별로 필요한 추가 파라미터가 많은 경우

deferred를 기본 구조로 유지하면서, 마지막 단계에서 필요한 재질만 다시 평가한다.

이 구조는

• pass 수가 늘어나 구조가 복잡해진다.
• 일부 재질은 여전히 전통적인 forward 경로가 더 단순하다.
• G-buffer 설계가 애매하면 deferred의 장점도 약해질 수 있다.

deferred 내부에서 forward처럼 연산하는 방법은 가능하지만, 결국 목적은 deferred의 기본 효율을 유지하면서 예외적인 재질만 보완하는 것이다.

---

Unreal Engine

Unreal Engine의 기본 데스크톱 렌더러는 deferred shading을 중심으로 구성된다.
공식 문서 기준으로 opaque material은 먼저 G-buffer에 material attribute를 기록하고, 이후 lighting pass가 이 정보를 읽어 조명을 계산한다.

1. depth 또는 shadow 관련 선행 pass
2. base pass에서 opaque geometry와 material attribute 기록
3. deferred lighting
4. translucency
5. post process

Unity

Unity는 사용하는 렌더 파이프라인에 따라 구성이 달라지지만, URP의 deferred path 공식 문서를 보면 패스 분리가 매우 명확함.

1. 필요 시 depth prepass 또는 depth-normal prepass
2. G-buffer pass
3. SSAO 같은 screen-space effect
4. deferred shading pass
5. forward-only pass
6. transparent
7. post process

---

정리

• forward rendering: draw 단계에서 바로 조명까지 계산한다.
• deferred rendering: geometry 정보를 먼저 저장하고, 이후 별도 pass에서 조명을 계산한다.

forward rendering은 구조가 단순하고 직관적이지만, 광원이 많아질수록 비용이 빠르게 증가.
deferred rendering은 구조가 더 복잡하고 추가 버퍼가 필요하지만, 광원이 많은 scene에서 더 안정적인 성능.

• 단순한 scene에서는 forward rendering 중심으로 간다.
• 광원이 많은 scene에서는 deferred rendering 중심으로 간다.
• 복잡한 재질과 투명 오브젝트까지 함께 다뤄야 하면 두 방식을 혼합하거나, deferred 위에 forward-like pass를 추가한다.