A frustum is used to clip geometry, deciding which parts of it are visible. It seems that most cameras use a frustum shaped as a pyramid segment, i.e. a box between two rects of equal alignment on parallel planes. If the field of view is small (below 40 degree or so), this produces excellent results.

However, for larger angles, this design has a weird consequence: Objects in the center of the screen are clipped 'earlier' than those at the edges, i.e. when less far from the camera origin. This is caused by the far clipping plane being a plane, not an arc. So the Euclidian distance from camera origin to the frustum corners is larger than the distance to the far clipping plane. If the field if view is larger than about 100 degrees, the distance can in fact be twice as large or more.

As a player, one will quickly learn to look diagonally to see more. I've always found that pretty strange. Given that we mostly focus on and look at things of interest in the center of the screen, this is the exact opposite of what I would consider sensible. The view distance in the center should be at least as high as near the screen edges.

So it would seem more useful to either use an arc or quad instead of triangle to define the clipping area.

Regarding performance, I don't see a problem in making such a change at all. An arc, for instance, would replace the which-side-of-far-clipping-plane test with a squared distance check - pretty much the same. Replacing it with a quad would use the Manhattan distance instead, i.e. the player can see further in the center of the screen by factor sqrt(2).

On the other hand, only rendering stuff that is actually in the visual focus area, a lot of geometry can be excluded: at higher fov, half of it or more! There is also drastically less loading/unloading of objects when they enter and leave the visible space.

I've seen this implemented comparatively in games: The results were clearly superior, allowing larger view distances at the same performance and removing the diagonal-pop-in effect common in many games.

So I'm wondering: Why is the classic pyramid frustum still used everywhere?

  • 1
    \$\begingroup\$ What you're really talking about here is a special case for the far plane. But having all 6 planes be planes means that they can all be handled the same way, using the same calculations in the same hardware (and clipping is still a fixed-function part of the pipeline) which in turn means better parallelism and allows clipping to become totally agnostic to plane order, orientation, etc. \$\endgroup\$ Jun 30 at 7:15
  • 5
    \$\begingroup\$ I'm struggling to think of modern games where clipping/popping at the far plane is even visible. A well made game should usually disguise or eliminate this effect with LoD fall-off or cascaded cameras. I would consider any visible popping to be a bug. The player should not be able to see the limits of the far plane during gameplay — that should be an implementation detail that only the GPU has to care about. \$\endgroup\$
    – DMGregory
    Jun 30 at 11:36
  • \$\begingroup\$ Well, now that you mention it, I actually have not played very many first person games that came out in the past 10 years. My knowledge is mostly from the 2000-2010 era. At the time, it was ubiquitous even in AAA games, but the industry standard may have changed. \$\endgroup\$
    – mafu
    Jul 1 at 7:37
  • \$\begingroup\$ @DMGregory Your comment combines nicely with the accepted answer to solve my indirect/second question. If you want to put it in a post, I could updoot it. \$\endgroup\$
    – mafu
    Jul 3 at 4:18

They're planar because that's how the math works out.

Classic OpenGL and Direct3D use projection matrices to transform the scene between "world space" and "screen space". "World space" is the coordinate system you're familiar with, while "screen space" is a distorted coordinate system that's very fast for projecting the scene onto the screen.

In "screen space", the viewing frustum isn't a frustum. It's an axis-aligned cube. This turns clipping into a simple test: "is the z-coordinate between the near clipping value and the far clipping value?". As you can imagine, this is a very, very fast operation -- back when OpenGL was developed, it was easily a thousand times faster than a squared-distance check, and even today, it's probably somewhere around twenty times faster.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.