This article is more than 1 year old

ATI 512MB Radeon X800 XL

More buffer, gentlemen?

High-end techniques

Before we delve into numbers, a little on how perspective shadow mapping works. Using deferred shading, where you accumulate contributions to the final frame in separate render targets, before combining them for display, you render the scene from the perspective of the viewer and then again from the perspective of any light that you want to calculate a shadow contribution from, into a high resolution, high-precision render target (2000 x 2000 or 4000 x 4000 for large view sizes such as 1600 x 1200 work best for area lights, all in 32-bit colour). That's your depth map. You then sample at the intersection of the geometry in the scene from the view with the shadow map projected by the light. The result tells you whether you're in shadow at that point. When using a cube map, you render the scene onto the faces of the cube texture instead, to create your depth map.

So I set up a simple scene in Direct3D, using the algorithm from a Microsoft sample on shadow mapping and used a 2000 x 2000 shadow map for the sun, and a smaller 512 x 512 x 6 cube map to hold the shadow maps (six of them, one per face) for three small point lights (point lights are fixed). Geometry cost is less than 20,000 vertices per frame, and there's geometry to fully occlude the point lights. So it's just a simple example.

The data costs for the shadow maps are therefore relatively fixed. The 2000 x 2000 shadow map is a 16MB texture, computed once per frame for the area light, then 1.5MB each for the cube map for the point lights. Only if the engine finds the point light fully occluded does it not render the cube map contribution to shadowing. So the shadow map cost for my example wavers between 16MB and 20.5MB per frame. Add more point lights that you might be rendering, unoccluded, and data cost equals (1.5MB x point light count) + 16MB.

While that might not sound like a lot, when you then add in the cost of material data and anything like a normal map (often very large cost if you have a lot of normal-mapped geometry on screen), gloss map, environment map (can be a full-screen sized texture) or similar on top, which need to be in card memory for highest performance, you find that using shadow mapping to render your scene starts to exert memory pressure on 256MB cards.

Obviously this is just a very simple example, which doesn't take into account scaling the shadow map for resolution, re-using the shadow map per frame, using other shadowing algorithms at the same time, the number of passes taken to render (texture re-use) or render targets being combined (which are often the largest memory cost to factor in, if they're full-screen), but hopefully it lets you see how just one popular new method for shadowing imposes a fairly large fixed-cost penalty in terms of on-card data storage needed (over ten per cent of the frame buffer size for a simple area light and one point light in my small example). And you've got to store visible textures and other art assets on top of that.

Even assuming that, thanks to normal mapping, geometry size costs aren't going to massively increase in games in the near future, texture data and the methods used to render them are going to give you, in at least some titles and circumstances, significant memory pressure on a 256MB board.

Next page: Today's titles

More about

TIP US OFF

Send us news


Other stories you might like