Rendering 13, Deferred Shading, a Unity Tutorial
Total Page:16
File Type:pdf, Size:1020Kb
Catlike Coding Unity C# Tutorials Rendering 13 Deferred Shading Explore deferred shading. Fill Geometry Bufers. Support both HDR and LDR. Work with Deferred Reflections. This is part 13 of a tutorial series about rendering. The previous installment covered semitransparent shadows. Now we'll look at deferred shading. This tutorial was made with Unity 5.5.0f3. The anatomy of geometry. 1 Another Rendering Path Up to this point we've always used Unity's forward rendering path. But that's not the only rendering method that Unity supports. There's also the deferred path. And there are also the legacy vertex lit and the legacy deferred paths, but we won't cover those. So there is a deferred rendering path, but why would we bother with it? After all, we can render everything we want using the forward path. To answer that question, let's investigate their diferences. 1.1 Switching Paths Which rendering path is used is defined by the project-wide graphics settings. You can get there via Edit / Project Settings / Graphics. The rendering path and a few other settings are configured in three tiers. These tiers correspond to diferent categories of GPUs. The better the GPU, the higher a tier Unity uses. You can select which tier the editor uses via the Editor / Graphics Emulation submenu. Graphics settings, per tier. To change the rendering path, disable Use Defaults for the desired tier, then select either Forward or Deferred as the Rendering Path. 1.2 Comparing Draw Calls I'll use the Shadows Scene from the Rendering 7, Shadows tutorial to compare both approaches. This scene has its Ambient Intensity set to zero, to make the shadows more visible. Because our own shader doesn't support deferred yet, change the used material so it relies on the standard shader. The scene has quite a few objects and two directional lights. Let's look at it both without and with shadows enabled for both lights. Shadows scene, without and with shadows. While using the forward rendering path, use the frame debugger to examine how the scene gets rendered. There are 66 geometry objects in the scene, all visible. If dynamic batching was possible, these could've been drawn with less than 66 batches. However, that only works with a single directional light. As there is an additional light, dynamic batching is not used. And because there are two directional lights, all geometry gets drawn twice. So that's 132 draw calls, 133 with the skybox. Forward rendering, without shadows. When shadows are enabled, we need more draw calls to generate the cascading shadow maps. Recall how directional shadow maps are created. First, the depth bufer is filled, which requires only 48 draw calls, thanks to some dynamic batching. Then, the cascading shadow maps are created. The first light's shadow map ends up requiring 111 draw calls, while the second one needs 121. These shadow maps are rendered to screen-space bufers, which perform filtering. Then the geometry is drawn, once per light. Doing all this requires 418 draw calls. Forward rendering, with shadows. Now disable the shadows again and switch to the deferred rendering path. The scene still looks the same, except that MSAA has been turned of. How does it get drawn this time? Why doesn't MSAA work in deferred mode? Deferred shading relies on data being stored per fragment, which is done via textures. This is not compatible with MSAA, because that anti-aliasing technique relies on sub- pixel data. While the triangle edges could still benefit from MSAA, the deferred data remains aliased. You'll have to rely one a post-processing filter for anti-aliasing. Deferred rendering, without shadows. Apparently, a GBufer gets rendered, which requires 45 draw calls. That's one per object, with some dynamic batching. Then the depth texture gets copied, followed by thee draw calls that do something with reflections. After that, we get to lighting, which requires two draw calls, one per light. Then there's a final pass and the skybox, for a total of 55 draw calls. 55 is quite a bit less than 133. It looks like deferred only draws each object once in total, not once per light. Besides that and some other work, each light gets its own draw call. What about when shadows are enabled? Deferred rendering, with shadows. We see that both shadow maps get rendered and then filtered in screen space, right before their lights are drawn. Just like in forward mode, this adds 236 draw calls, for a total of 291. As deferred already created a depth texture, we got that for free. Again, 291 is quite a bit less than 418. 1.3 Splitting the Work Deferred shading appears to be more efcient when rendering more than one light, compared to forward shading. While forward requires one additional additive pass per object per light, deferred doesn't need this. Of course both still have to render the shadow maps, but deferred doesn't have to pay extra for the depth texture that directional shadows need. How does the deferred path get away with this? To render something, the shader has to grab the mesh data, convert it to the correct space, interpolate it, retrieve and derive surface properties, and calculate lighting. Forward shaders have to repeat all of this for every pixel light that illuminates an object. Additive passes are cheaper than the base pass, because the depth bufer has already been primed, and they don't bother with indirect light. But they still have to repeat most of the work that the base pass has already done. Duplicate work. As the geometry's properties are the same every time, why don't we cache them? Have the base pass store them in a bufer. Then additive passes can reuse that data, eliminating duplicate work. We have to store this data per fragment, so we need a bufer that fits the display, just like the depth and the frame bufer. Caching surface properties. Now we have all the geometry data that we require for lighting available in a bufer. The only thing that's missing is the light itself. But that means we no longer need to render the geometry at all. We can sufce with rendering the light. Furthermore, the base pass only has to fill the bufer. All direct lighting calculations can be deferred until the lights are rendered individually. Hence, deferred shading. Deferred shading. 1.4 Many Lights If you're only using a single light, then deferred by itself doesn't provide any benefit. But when using many lights, it shines. Each additional light only adds a little extra work, as long as they don't cast shadows. Also, when geometry and lights are rendered separately, there is no limit to how many lights can afect an object. All lights are pixel lights and illuminate everything in their range. The Pixel Light Count quality setting does not apply. Ten spotlights, deferred succeeds while forward fails. 1.5 Rendering Lights So how are lights themselves rendered? As directional lights afect everything, they are rendered with a single quad that covers the entire view. Directional lights use a quad. This quad is rendered with the Internal-DeferredShading shader. Its fragment program fetches the geometry data from the bufer and relies on the UnityDeferredLibrary include file to configure the light. Then it computes the lighting, just like a forward shader does. Spotlights work the same way, except that they don't have to cover the entire view. Instead, a pyramid is rendered that fits the volume that the spotlight illuminates. So only the visible potion of this volume will be rendered. If it ends up completely hidden behind other geometry, no shading is performed for this light. Spotlights use a pyramid. If a fragment of this pyramid is rendered, it will perform lighting calculations. But this only makes sense if there actually is geometry inside the light's volume. Geometry behind the volume need not be rendered, because the light doesn't reach there. To prevent rendering these unnecessary fragments, the pyramid is first rendered with the Internal-StencilWrite shader. This pass writes to the stencil bufer, which can be used to mask which fragments get rendered later. The only case when this technique can't be used is when the light volume intersects the camera's near plane. Point lights use the same approach, except with an icosphere instead of a pyramid. Point lights use an icosphere. 1.6 Light Range If you've been stepping through the frame debugger, you might have noticed that the colors look weird during the deferred lighting phase. It's as if they're inverted, like a photo negative. The final deferred pass converts this intermediate state to the final correct colors. Inverted colors. Unity does this when the scene is rendered with low dynamic range – LDR – colors, which is the default. In this case, the colors are written to an ARGB32 texture. Unity logarithmically encodes the colors to achieve a greater dynamic range than usual for this format. The final deferred pass converts to normal colors. When the scene is rendered in high dynamic range – HDR – Unity uses the ARGBHalf format. In this case, the special encoding is not needed and there is no final deferred pass. Whether HDR is enabled is a property of the camera. Switch it on, so we see normal colors when using the frame debugger. HDR enabled. 1.7 Geometry Bufers The downside of caching data is that it has to be stored somewhere.