You're still here?
Today's tutorial covers Frustum Culling.
You've heard about it and maybe you are wondering what it is.
Firstly, let's define Culling in a more general sense.

The dictionary definition of the word "cull" is related to the removal of "bad" members of a group,
for example,  "When people cull animals, they kill them, especially the weaker members of a particular 
group of them, in order to reduce or limit their number."

I define Culling as the avoidance of work - something I really relate to.
Now I better qualify that definition a little.
Imagine that our virtual world contains say 100 zillion small polygons.
A few hundred of them are near the camera location, but many thousands more are hidden
behind some mountains, not to mention the ones that are BEHIND the camera.
We can clearly see that MOST of the world is not visible at once.
Why then would be try to draw ALL of them in each frame of rendering we perform?
If we only draw what is actually visible to the camera at the time, we reduce the number of
polygons that we must draw from 100 zillion to several hundred. I'm pretty sure anyone could
understand that would dramatically increase the framerate (fps=frames per second).

The best kind of work efficiency is the avoidance of work which has no redeeming value or merit,
ie, the avoidance of any work which does not contribute to our goal or goals.
In the case of culling, we benefit from doing only what is absolutely required to achieve a result.
Am I making any sense at all?

Our goal in the case of Frustum Culling is to figure out what parts of the virtual world are 
currently visible to the Camera, and render only those.

So how do we go about it? Simple - we use a View Frustum, and so it's time for me to define Frustum.
A frustum is a four-sided pyramid with the top sliced off, so that it becomes a deformed cube.
A View Frustum is an imaginary cube which contains everything the Camera can see.
This might be a little difficult at first , but please try to imagine if we projected an imaginary box
from the Camera location into the virtual world, that's what it would look like.
The smallest side of the cube is our screen that we are looking at, the largest side of the cube is
the "far" plane in the distance. Everything that is going to end up being rendered onscreen is
either partially or totally inside the View Frustum.
I used the word "plane" just now, and it too warrants a definition.
A Plane is easiest to understand if we picture a flat rectangle in the 3D virtual world.
The rectangle is flat,  and at some angle in 3D. The Plane of that rectangle can be defined by
stretching that rectangle to infinity (and beyond!). In other words, a Plane does not really exist,
its simply a way of describing an infinite flat surface at a given angle in 3D space.
Planes can be handy because they offer mathematical shortcuts.
We could define the View Frustum as eight vertices (3D points) in space.
Alternatively, we could define it as six PLANES, which we will do.
There's a pretty simple way of figuring out whether a 3D point is in front of, behind, or ON a plane.
By extension of this, it should be easy to understand that if a 3D point is within the space that is
confined by the six planes of our ViewFrustum, that it is onscreen and should be rendered.
We are going to test various stuff against the six planes of the VF.
If any stuff is either partially or totally inside the VF, we will render it.

That sounds pretty simple, until we note that the camera can A) move about and B) rotate freely.
Whenever the Camera's view changes due to either or both of those, the Frustum changes to suit.
This means we need to recalculate the Frustum to suit the current Camera view.
That sounds expensive, particularly if you are imagining the Frustum is defined by its corner vertices,
as you would be thinking about rotating all the points around to follow the camera rotation, etc.
Actually, we will be doing no such thing, as we'll take advantage of yet another math shortcut,
whereby we may "extract the planes of the VF from the current camera view".
So we can cheat and kinda "grab" the info for the Planes of the VF after we update the Camera view?
Gee, that's pretty cool !! Yep, let's do it that way :)

Later on we'll be doing more stuff with Planes, particularly involving collision detection, but for now,
it's time to look at the code for the Frustum and Camera together.

You might have noticed in the previous tutorial that the Camera "owns a Frustum object".
It just made sense to me, since the Camera and Frustum are so intimately associated, that I should
highlight this association through ownership. Each Camera we create owns its own Frustum, which is
derived from the current view of that Camera mathematically.

Some of you might have realized that Frustum Culling is a kind of glorified "boundingbox test".
That's true, it is indeed. That means understanding the process of FrustumCulling is the same as
understanding simple BoundingBox intersection testing - two birds with one stone :)

Off you go and read the code for CFrustum class. Any questions can be directed to me under the 
username EvilHomer2k at the public messageboard http://board.win32asmcommunity.net as usual.