<p>Both Unity's "<a href="https://docs.unity3d.com/Manual/RenderTech-DeferredShading.html" rel="nofollow noreferrer">Deferred shading rendering path</a>" and "<a href="https://docs.unity3d.com/Manual/RenderTech-DeferredLighting.html" rel="nofollow noreferrer">Legacy Deferred Lighting Rendering Path</a>" work only for opaque surfaces. They both rely on a very similar set of passes:</p>

<ol>
<li>Render the opaque objects' lighting parameters to a number of render targets. This is referred to as the "G-Buffer pass" or "base pass".</li>
<li>Lighting is then computed in screen-space using the buffers of the first pass to compute lighting. The main benefit is that the cost of lighting is independent of scene complexity. This allows for much more complicated lighting equations with a greater number of lights.</li>
<li>Full-screen pass to resolve all these buffers to a final color.</li>
</ol>

<p>The reason this doesn't work for transparent objects is that they must be rendered back to front <em>completely shaded</em> (lighting and all). If transparent object A is in front of transparent object B, B must be completely shaded when A blends its color with B. We need that final shaded color because the lighting parameters accumulated in G-Buffers cannot be blended.</p>

<p>So, if you can use it (there are downsides), deferred shading has some very nice properties that produce very good results with good performance. That is why opaque objects will "likely" use deferred shading. Quoting from Unity doc:</p>

<blockquote>
  <p>When using deferred shading, there is no limit on the number of lights that can affect a GameObject. All lights are evaluated per-pixel, which means that they all interact correctly with normal maps, etc. Additionally, all lights can have cookies and shadows.</p>
  
  <p>Deferred shading has the advantage that the processing overhead of lighting is proportional to the number of pixels the light shines on. This is determined by the size of the light volume in the Scene regardless of how many GameObjects it illuminates. Therefore, performance can be improved by keeping lights small. Deferred shading also has highly consistent and predictable behaviour. The effect of each light is computed per-pixel, so there are no lighting computations that break down on large triangles.</p>
</blockquote>

<p>I wasn't able to find much information about Unity's clustered rendering. From what I gather it's an optimization technique for forward rendering, but it's still fundamentally the same process. Here's a very nice write-up of <a href="http://www.adriancourreges.com/blog/2016/09/09/doom-2016-graphics-study/" rel="nofollow noreferrer">how it works in Doom</a> (go to the "Clustered-Forward-Rendering of Opaque Objects" section).</p>

CC BY-SA 4.0
2019-01-23T11:34:57.720Z
Thanks for the link explaining Clustered Forward Rendering, it is very clear indeed. Then, what is the benefit of still rendering opaque objects using 2D-Tiled Shading? Would it not be easier to use 3D-Clustered Rendering for all objects, like in Doom 2016?
wip
CC BY-SA 4.0
2019-01-23T12:36:08.623Z
I added a quote. It's a performance optimization especially effective with complicated lighting equations and/or many light sources. There is no silver bullet. Each rendering method has benefits and trade-offs which make them suitable in certain contexts or not.
bernie
CC BY-SA 4.0
2019-01-23T09:52:13.957Z
2019-01-23T12:27:42.260Z
2019-01-23T12:27:42.260Z
bernie
<p>The Unity Engine manual page <a href="https://docs.unity3d.com/Manual/BestPracticeLightingPipelines.html" rel="noreferrer">Best Practice: Setting up the Lighting Pipeline</a> has a section "Render pipelines" with an illustration of Tile Rendering and Cluster Rendering:  </p>

<p><a href="https://i.sstatic.net/tpMCt.png" rel="noreferrer"><img src="https://i.sstatic.net/tpMCt.png" alt="enter image description here"></a></p>

<p>The section then mentions:  </p>

<blockquote>
  <p>Opaque objects will most likely be shaded using the tile system,
  whereas transparent ones will rely on the cluster system.</p>
</blockquote>

<p>What is the benefit of using Clustered Shading with transparent objects? Is it related to performance, or are transparent objects not supported by Tiled Shading?  </p>

<p>Why opaque objects will "not likely" be rendered with Clustered Shading?</p>

CC BY-SA 4.0
2019-01-23T03:49:47.220Z
The reason is that when drawing transparent faces, draw order matters. It is simpler to have rough draw order guarantees when you split space into chunks and draw them far to near. Or that is what i think. I might be wrong, which is why I didn't post this as an answer.
Sebastián Mestre
<real-time><transparency><unity><tile-based-rendering>
Benefits of Clustered Shading vs Tiled Shading?
wip
# Benefits of Clustered Shading vs Tiled Shading?

(Asked by: username_0 on 2019-01-23)

The Unity Engine manual page [Best Practice: Setting up the Lighting Pipeline](https://docs.unity3d.com/Manual/BestPracticeLightingPipelines.html) has a section "Render pipelines" with an illustration of Tile Rendering and Cluster Rendering:

[![enter image description here](https://i.sstatic.net/tpMCt.png)](https://i.sstatic.net/tpMCt.png)

The section then mentions:

> Opaque objects will most likely be shaded using the tile system,
> whereas transparent ones will rely on the cluster system.

What is the benefit of using Clustered Shading with transparent objects? Is it related to performance, or are transparent objects not supported by Tiled Shading?

Why opaque objects will "not likely" be rendered with Clustered Shading?

**Tags:** real-time, transparency, unity, tile-based-rendering

> **Comments:**
> **username_1**: The reason is that when drawing transparent faces, draw order matters. It is simpler to have rough draw order guarantees when you split space into chunks and draw them far to near. Or that is what i think. I might be wrong, which is why I didn't post this as an answer.  

---

## 1 answers

### Answer by username_2 on 2019-01-23. Score: 3 | Accepted answer

Both Unity's "[Deferred shading rendering path](https://docs.unity3d.com/Manual/RenderTech-DeferredShading.html)" and "[Legacy Deferred Lighting Rendering Path](https://docs.unity3d.com/Manual/RenderTech-DeferredLighting.html)" work only for opaque surfaces. They both rely on a very similar set of passes:

1. Render the opaque objects' lighting parameters to a number of render targets. This is referred to as the "G-Buffer pass" or "base pass".
2. Lighting is then computed in screen-space using the buffers of the first pass to compute lighting. The main benefit is that the cost of lighting is independent of scene complexity. This allows for much more complicated lighting equations with a greater number of lights.
3. Full-screen pass to resolve all these buffers to a final color.

The reason this doesn't work for transparent objects is that they must be rendered back to front *completely shaded* (lighting and all). If transparent object A is in front of transparent object B, B must be completely shaded when A blends its color with B. We need that final shaded color because the lighting parameters accumulated in G-Buffers cannot be blended.

So, if you can use it (there are downsides), deferred shading has some very nice properties that produce very good results with good performance. That is why opaque objects will "likely" use deferred shading. Quoting from Unity doc:

> When using deferred shading, there is no limit on the number of lights that can affect a GameObject. All lights are evaluated per-pixel, which means that they all interact correctly with normal maps, etc. Additionally, all lights can have cookies and shadows.
>
> Deferred shading has the advantage that the processing overhead of lighting is proportional to the number of pixels the light shines on. This is determined by the size of the light volume in the Scene regardless of how many GameObjects it illuminates. Therefore, performance can be improved by keeping lights small. Deferred shading also has highly consistent and predictable behaviour. The effect of each light is computed per-pixel, so there are no lighting computations that break down on large triangles.

I wasn't able to find much information about Unity's clustered rendering. From what I gather it's an optimization technique for forward rendering, but it's still fundamentally the same process. Here's a very nice write-up of [how it works in Doom](http://www.adriancourreges.com/blog/2016/09/09/doom-2016-graphics-study/) (go to the "Clustered-Forward-Rendering of Opaque Objects" section).

> **Comments:**
> **username_0**: Thanks for the link explaining Clustered Forward Rendering, it is very clear indeed. Then, what is the benefit of still rendering opaque objects using 2D-Tiled Shading? Would it not be easier to use 3D-Clustered Rendering for all objects, like in Doom 2016?  
> **username_2**: I added a quote. It's a performance optimization especially effective with complicated lighting equations and/or many light sources. There is no silver bullet. Each rendering method has benefits and trade-offs which make them suitable in certain contexts or not.  

---

