3DMark05’s Shadow Engine: The Way Games Do Shadowing
Futuremark first implemented dynamic shadows in 3DMark2001 using used projection shadow maps, but then it changed the approach in 3DMark03 to stencil-shadows used on Doom III. With the 3DMark05 Futuremark again changes the way it calculates the shadows to a type of depth shadow maps called perspective shadow maps (PSM), a technology that is used by today’s games, such as FarCry.
The implementation is said to be a refinement of what is commonly known as PSM, since these have problems with certain angles of light in the simplest form. The scene is rendered from the direction of the light, as in projection shadow maps, but the depth of each texel in the shadowmap is also stored. This results in a shadow map implementation that has no need for object edge vertex selection, does not add the vertex load with shadow volume polygons and does not add fill load with the invisible but usually large and numerous shadow volume polygons.
PSM in Futuremark’s implementation still offers a global lighting solution that projects shadows correctly, including self shadowing, and is suited for a wide range of different types of 3D scenes and lighting types.
Shadows from directional light sources use a 2048x2048 resolution depth map of the format R32F. If the hardware supports depth stencil textures (DST), a D24X8 depth map is used of the same size. The 2K maps are actually used twice: once for rendering the depth of objects closer to the camera and second time for the rest of the scene. Shadows from point light sources use a 512x512x6 cube map of the format R32F as depth map. These depth maps sound enormous, and one would think they take up quite a bit of fill rate. They most certainly do, and 3DMark05 is therefore less sensitive to changes of the screen resolution. Still, in some cases even two 2K maps are not enough. Game Test 3 shows one of the most difficult environments for PSM use.
The depth maps DST or R32F are both sampled using Percentage Closest Filtering (PCF). If the hardware supports DST and hardware accelerated PCF, a single bilinearly filtered sample is taken. The non-DST rendering path uses four point samples. These two implementations produce a bit different rendering, which can be seen in close inspection, by magnifying parts of frames with some shadow artifacts, and comparing these side by side. In theory, the bilinear filtering is of higher quality than point sampling, but in point sampling, the samples are taken from a larger area, and so in some cases point sampling can produce a smoother looking rendering.
One could argue that the DST and hardware accelerated PCF implementation vs. the non-DST and point sampling code paths do not produce comparable performance measurements, since the resulting rendering shows slight differences. 3DMark05 was designed with the firm belief that those two are indeed comparable, and in the fact that it is the right way to reflect future 3D game performance, the developer claims. Futuremark’s study has proved that over a dozen of the biggest game developers are using DST and hardware PCF for dynamic shadow rending in their latest or upcoming titles. So if DST and hardware PCF are supported, they should be used in depth shadow map implementations, because that is what is done also in the latest and future games. However, if the benchmark user wishes to compare exactly identical rendering performance across different architectures, DST can be disabled in the benchmark settings, and the dynamic shadows are then always rendered using R32F depth maps and four point sample PCF.