Hidden surface removal (HSR) is the process of deciding which parts of a 3D scene are visible from a chosen viewpoint, so surfaces blocked by nearer geometry are not drawn as if they were in front. It is also called visible surface determination. In a typical real-time renderer, a depth buffer can make that decision separately for each pixel.
What problem does hidden surface removal solve?
When a 3D scene is projected onto a 2D image, different surfaces can land on the same pixel. Only the surface nearest the camera should contribute to the visible result at that location; farther surfaces are occluded. HSR determines which surface wins for each viewing direction or image sample. It addresses visibility, not the whole rendering process: lighting, shading, color, and other effects are separate concerns.
The closely related phrase visible surface determination describes the same problem from the opposite perspective: rather than asking what is hidden, it asks what can be seen. In line rendering, the corresponding task is often called hidden-line removal. Cornell’s computer graphics lecture and a WebGL teaching chapter discuss visibility and depth testing in this context.
How does a depth buffer determine what is visible?
A z-buffer, or depth buffer, stores a depth value for each image sample. As geometry is rasterized, the renderer compares each new fragment’s depth with the value already stored at that location. If the fragment is nearer under the renderer’s depth convention, its depth and color replace the stored values; if it is farther, it does not replace the visible sample. The process is local to each pixel, so overlapping geometry does not need to be placed in one globally correct draw order.
- Initialize depth storage: Set each sample to the far value used by the selected depth convention.
- Rasterize scene geometry: Generate fragments at the image samples covered by each projected primitive.
- Compare depths: Test each fragment against the depth currently stored at that sample.
- Keep the nearer result: When the fragment passes, write its color and depth; otherwise retain the existing visible sample.
Apple’s Metal documentation on primitive visibility and depth testing describes attaching a depth texture to a render pass. It notes that a depth test may occur before fragment shading, which can avoid shading some hidden fragments in implementations that use that ordering; it is not a guarantee for every pipeline or scene.
How does the z-buffer compare with painter’s algorithm?
The painter’s algorithm draws primitives in an order, usually from farthest to nearest, so later, nearer surfaces cover earlier ones. This is intuitive, but a simple global order can fail when surfaces intersect or overlap cyclically: there may be no single ordering that correctly handles every region. Subdividing primitives or using other handling can address such cases.
A depth buffer resolves visibility at image samples instead of relying on that global ordering. Apple summarizes the distinction: “To determine visibility independently from the submission order, you need to add hidden-surface removal.” The practical trade-off is that a z-buffer requires depth storage for its samples, while sorting approaches rely on ordering and may need extra work for difficult overlaps. Which approach is appropriate depends on the rendering goal and scene; the sources do not establish a universal winner.
What other hidden-surface-removal methods are there?
HSR names a problem, not one particular algorithm. Methods can be grouped by where and how they decide visibility:
Recommended Free Tools
Rank #3
| Method family | Where visibility is resolved | Key characteristic |
|---|---|---|
| Image-space methods, including z-buffering | At pixels or image samples | Compare depth where projected geometry overlaps; a z-buffer handles fragments independently of global submission order. |
| Object-space methods | Between objects or geometric regions | Use scene geometry to determine visibility apart from deciding every final pixel. |
| Depth sorting (painter’s algorithm) | By ordering primitives | Draw far to near; complex intersections or cyclic overlap can defeat a simple global order. |
| Ray casting | Along viewing rays | Find which geometry is encountered as visible along each ray; discussed as a visibility approach in the computer graphics textbook chapter. |
| Subdivision approaches | By splitting geometry or regions | Can help handle cases where one global ordering is insufficient. |
| Hierarchical methods and spatial structures | Across grouped or organized scene regions | Examples in the textbook overview include hierarchical z-buffers, BSP trees, portals, and potentially-visible sets. |
These categories make different computation and data-structure choices. The right comparison is not simply which method is “best”: it depends on scene structure, the desired output, and the balance between visibility correctness and computational efficiency.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What does a theoretical complexity result tell us?
A 1992 paper by Micha Sharir and Mark H. Overmars reports an O(n √k log n) running-time bound for a particular algorithm on n triangles with a known partial depth order and an output visibility map of combinatorial complexity k. This is a theoretical result for that algorithm and input model, not a general benchmark for HSR or a prediction of real-time rendering performance.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
