Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm adding frustum culling into my game engine, but I have some design issues regarding the frustum and the cameras. Should the frustum be a member of the camera, or vice versa ? Should a camera be built from a frustum or should the camera build and maintain it's own frustum ?

share|improve this question
Frustum should be a member of the camera. You should expose it somehow, maybe through constructor. – XiaoChuan Yu Apr 4 '12 at 19:44
up vote 3 down vote accepted

Short Answer

Make your frustum class independent from any camera implementation - it only requires a combined view-projection matrix to be created. Then, add a frustum instance to your camera class. Think about it - it makes sense to think that a camera has a frustum but not the other way around.

Long Answer

A Camera class will typically manage a view and projection matrix. But you usually rely on helper methods from your API to create these matrices, such as CreateLookAt or CreatePerspective. While it might be possible, I don't think it would be very practical to deduce the view and projection matrices from the frustum. So I'd forget about building the camera from the frustum.

As for how to build the Frustum, I like the way that XNA handles it, which is basically by providing a constructor that takes a combined view-projection matrix and deduces everything else from there. This way there's no direct dependency between the frustum and your camera implementation. All it cares about it receiving some view-projection matrix from somewhere.

Finally, as for whether one class should contain the other, my opinion is that, if anything, your camera class could manage a frustum object and keep it in sync. I think doing it the other way around would be a bad design choice, because the frustum is a lower level concept than the camera, and the frustum shouldn't have to rely on a specific camera implementation. Or the simple argument that composition should be used to implement has-a type of relationships, and it doesn't make sense to say that a frustum has a camera.


In sum, something like this for the frustum class (just to give you an idea, it might have other members and features too):

class Frustum
    Frustum(Matrix viewProjection);
    void SetMatrix(Matrix viewProjection);

    bool Intersects(BoundingBox box);
    bool Intersects(BoundingSphere sphere);
    bool Intersects(Point point);

    Plane[6] planes;

With your camera class being something like (once again not a complete example):

class Camera
    void SetPosition();
    void SetPitch();
    void SetYaw();

    Matrix GetViewMatrix();
    Matrix GetProjectionMatrix();
    Frustum& GetFrustum(); // Or expose the Intersects methods directly

    Matrix viewMatrix;
    Matrix projectionMatrix;
    Frustum frustum;
share|improve this answer
Great answer. Also like Xna, ot might be a good idea to publ – Steve H Apr 5 '12 at 6:38
...expose a public method in the frustum class to update the frustum on a frame by frame basis. – Steve H Apr 5 '12 at 6:45
@SteveH Good point, I've added that detail to the example. – David Gouveia Apr 5 '12 at 14:15
... and I managed to misspell frustum 18 times on my answer :) – David Gouveia Apr 5 '12 at 14:42

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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