I have a third person camera that contains two matrices: view and projection, and two Vector3's: camPosition and camTarget. I've read up on frustum culling and it makes it seem easy enough for a first person camera, but how would I implement this for a third person camera? I need to take into effect the objects I can see behind me too. How would I implement this into my camera class so it runs at the same time as my update method?

    public void CameraUpdate(Matrix objectToFollow)
        camPosition = objectToFollow.Translation + (objectToFollow.Backward *backward) + (objectToFollow.Up * up);
        camTarget = objectToFollow.Translation;

        view = Matrix.CreateLookAt(camPosition, camTarget, Vector3.Up);

Can I just create another method within the class which creates a bounding sphere with a value from my camera and then uses the culling based on that? And if so, which value am I using to create the bounding sphere from?

After this is implemented, I'm planning on using occlusion culling for the faces of my objects adjacent to other objects. Will using just one or the other make a difference? Or will both of them be better? I'm trying to keep my framerate as high as possible


1 Answer 1


First of all, let's talk about culling as a performance optimisation. All the usual rules of performance optimisation apply: you should measure it! Are you below your performance target? And what's hurting your performance?

Basically: no point in including performance optimisations all willy-nilly.

That being said - maybe you've already measured it and you do have a performance problem. Object culling can help you stay within your batch limit. Occlusion culling individual faces is more likely to hurt performance than to help. For the class of performance problems that this optimisation feels like it should solve, early Z or occlusion queries are, perhaps, the correct optimisations to persue.

Now I've got all that out of the way, I have good news: frustum culling for a third-person camera is exactly the same as for a first-person camera. It's the same for basically any kind of camera.

You take your camera's matrix, which is view * project, and create a BoundingFrustum (MSDN), which you can then use to perform intersection tests for culling.

You're basically creating a cut-off pyramid extending from the camera - this shape:


And anything that intersects that shape is what will be visible within your camera volume. That shape is the same between both camera types.

The reason this works is because a camera matrix takes vertices in world space, moves them "in front" of the camera with view matrix, and then projects them (with your project matrix) into a region from (-1,-1,0) to (1,1,1) within which the GPU's rasterizer actually performs its rendering.

BoundingFrustum simply reverses that process - taking the corners of the raster space and unprojecting them back out into world space.

  • \$\begingroup\$ Well the reason my fps is so low is because I'm trying to draw 10,000 cubes, but all with their own vertex buffer. The reason for this is because I don't know how to store them in a chunk and just draw the chunk. I also don't know how to edit an individual cube within a chunk. So I'm trying out occlusion and frustum culling first to see if it has any difference on a huge size map \$\endgroup\$ Commented Jun 27, 2013 at 5:29
  • \$\begingroup\$ Ah I now realize that I can use the frustum in my camera class for picking too. I also need to create bounding boxes for each one of my cubes that are being drawn. So if I have a cube class and a camera class, where am I putting the code that checks for the intersection and removes the unseen cubes? \$\endgroup\$ Commented Jun 27, 2013 at 5:41
  • \$\begingroup\$ @ChristianFrantz I think this answer you got before still applies. I'd strongly suggest investing the time in figuring out that approach. One vertex buffer per chunk, only include exposed faces in that buffer. (And then you might frustum-cull entire chunks). Rendering individual cubes is very much the wrong approach. \$\endgroup\$ Commented Jun 27, 2013 at 5:45
  • \$\begingroup\$ @ChristianFrantz (In answer to your newer comment) You'd use BoundingBox - have one for each cube - and do the intersection check right before you draw the cube. (Again - not the right approach - but that's how you'd do it.) \$\endgroup\$ Commented Jun 27, 2013 at 5:47
  • \$\begingroup\$ Ok so I'm pretty much wasting time trying to use the frustum. Can you give me an example of how to make a chunk of cubes? I would guess to loop through the vertices and change the offset of each one slighty so they have different positions, but that would still create a lot of vertices \$\endgroup\$ Commented Jun 27, 2013 at 5:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .