#deferred shading

There is a big change when screen space ray tracing can’t hit any visible pixel on the screen buffer (especially when you look straight at the reflective surface). In my shader, no pixel will be sampled at this point. A better way is to sample from a cubemap as a ‘fallback’ reflection.

(Screen space reflection without fallback cubemap)

(Screen space reflection with fallback cubemap)

The performance has been improve after I implemented the scissor test-based optimization. However, taking a close look at the lights may cause a big impact on performance due to the large area of pixel filling. In debug mode with 500 lights, the frame rate would drop to 15 at close look of the lights comparing to 60 fps with only lights. When I reduce light radius from [200, 400] to [50, 100], it keeps running at 60 fps even when the camera is close. Also, the frustum culling on lights reduced draw calls further more. My conclusion is: avoid setting up lights with very large radius in deferred shading.

One issue with deferred shading I implemented is that each light pass will render to the entire screen buffer area, causing redundant pixel calculation. One good way to eliminate redundancy is to limit light pass to its screen rectangle area by calculating the projection of light in screen space. Then, a scissor test will be enable during light pass to minimize rendering area.

First, calculate AABB for each lighting with:

AABB.MinCorner = lightPosition - Vector3(lightRadius,  lightRadius  lightRadius);

AABB.MaxCorner = lightPosition + Vector3(lightRadius,  lightRadius  lightRadius);

(Scene lights and their AABBs)

Then, each of eight corner points will be projected to screen space, and screen rectangle can be determined.

ScreenPos = CornerPoint * Inverse(ViewProjectionMatrix);

ScreenPos /= ScreenPos.w;

Since projection matrix is an non-homogeneous transformation, don’t forget to divide by w for correct result.

ScreenPos.x = (ScreenPos.x + 1.0f) * 0.5f * ScreenWidth; ScreenPos.y = (- ScreenPos.y + 1.0f) * 0.5f * ScreenHeight;

Similar to AABB calculation, now calculate the screen rectangle area for the light and apply scissor test with ID3D11DeviceContext::RSSetScissorRects.

(Scissored light area)

Comparing to the first image, only AABB projection area is kept and performance increases.

One more thing you should pay attention to is that AABB projection may cause incorrect area due to corner points lying behind the camera. I’m dealing this case with check if camera is initially inside AABB and disable scissor test if yes.

References:

‘Calculating scissor region for deferred lighting’ from GameDev.net: http://www.gamedev.net/topic/611006-calculating-scissor-region-for-deferred-lighting/

Having forward rendering done in my own 3D engine, I planned to look into deferred shading. The major change to my code was to rendering scene objects into separated render targets called G-Buffer. Then, G-Buffers will be composed by the post processor in screen space for each light.

The three G-Buffers I used in my project were albedo, normal and world position buffers. Albedo buffer has a format of R8G8B8A8 while normal and world position buffers are R32G32B32A32_FLOAT. Both normal and world position buffers can be optimized by using a more compact format of render target. I leave the optimization to my future work. So far they work fine with my demo.

The shaders will be changed to outputting geometry information to each G-Buffer. In a pixel shader, output structure looks this:

struct OUTPUT_PIXEL { float4 Albedo : SV_Target0; float4 WorldPos : SV_Target1; float4 Normal : SV_Target2; };

Semantic SV_Target[n] represents the render target pixels will be written onto. Then, geometry information will be output to the structure, just as passing information from vertex shaders to pixel shaders:

OUTPUT_PIXEL main(OUTPUT_VERTEX Input) : SV_TARGET { OUTPUT_PIXEL Out = (OUTPUT_PIXEL)0; Out.Albedo = DiffuseTexture.Sample(Sampler, Input.UV0); Out.WorldPos = float4(Input.PosW, 1); Out.Normal = float4(Input.NormalW, 1);

return Out; }

Setting up multiple render targets is just as setting a single one.  ID3D11DeviceContext::OMSetRenderTargets takes render target numbers and an array of render targets as first and second parameter. Use all G-Buffers as render target and draw objects with deferred shader.

Following is G-Buffers from one frame of my demo:

(Albedo, from diffuse texture color)

(Position in world space)

(Normal in world space)

For light rendering, each light takes one render pass with deferred light pass shader. The light will be calculated in the same way as being done in forward shading, except getting all necessary geometry information from G-Buffers. Since lighting information is in addition to mesh surface color, an additive blending on light pass gives correct result.

In my demo, I have 100 lighting moving around the city. This basic approach may end up running very slow, but we got all the points so far.

(City with 100 dynamic lighting)

References:

‘Creating the G-Buffer’ from ‘Catalin ZZ’: http://www.catalinzima.com/xna/tutorials/deferred-rendering-in-xna/creating-the-g-buffer/

‘ID3D11DeviceContext::OMGetRenderTargets method’ from MSDN: https://msdn.microsoft.com/en-us/library/windows/desktop/ff476460(v=vs.85).aspx

Software Engineering Lab:

This is a demo showing up the lighting capabilities of the Engine that would be the heart of the game. We're using a heavy lighting model to shade all the meshes in the scene, this is done per pixel screen so it's lighting fast.

We are also gonna use simple point lights for our LPV implementation, we will have approx 230 lights in the scene at any time, 200 for the LPV (light propagation volume) and 30 "heavy" lights like this one in the video for scene lighting.