What Deferred Shading Stores Before It Lights
A renderer still needs to know what each visible surface is made of before it can decide how light should affect it. In deferred shading, an early pass writes that information into a set of screen-sized buffers called a G-buffer. For each pixel, the buffers may record the surface’s color, orientation, depth, and material properties such as roughness.
A later pass reads those records and combines them with the scene’s lights. A surface facing toward a lamp can receive more of its light; one facing away may receive little. Because the lighting pass works from the completed screen image, it does not need to repeat the full geometry and material work for every light.
Why the Order Helps—and What It Costs
The advantage becomes important in scenes with many dynamic lights. With a forward renderer, lighting calculations are commonly tied to drawing objects, so a light may be considered repeatedly as different objects are drawn. Deferred shading separates the tasks: first determine the visible surfaces, then apply lighting to those screen pixels. Depth testing, which keeps nearer surfaces in front of farther ones, helps prevent hidden geometry from contributing to the final image.
The tradeoff is that the G-buffer itself takes memory and bandwidth: the graphics processor must write several images, then read them back. Deferred shading also handles transparency less naturally. A pixel may contain several overlapping translucent surfaces, while a basic G-buffer keeps only one surface record per pixel. Engines therefore often render opaque objects with deferred shading and handle transparent effects in a separate pass.
The key shift is architectural: lighting becomes a screen-space operation, making many lights more practical without requiring the renderer to redraw the scene for each one.
