I didn't know about this little trick, so everyone please excuse me for mentioning polygons - that really was a bad idea, but IMO it was still a better idea than checking only the AABB corners - I knew that wouldn't cut it (or I eventually reached that conclusion:) ), because all of the relations between the corners were being ignored.

So, just to put it all into words (and to make sure I embed it in my mind):

If the dot product of the AABB's "positive extent" vector ( extent = abs(anycorner - center) ) and the plane's normal ( dot(extent, normal) = the length of the projection of the AABB's extent onto the plane's normal) is greater or equal than the distance from the center of the AABB to the plane, then the AABB intersects with the plane.

If that's not the case, then if the sign of the dot product is the same as the sign of the distance, then the AABB is in front of the plane; if the signs are different, the AABB is behind the plane.

Neat... wish I'd thought of that.

non-cubic AABBs

L. Spiro, how do you deal with situations where the AABB is not square?

I don't think that makes sense... all AABBs are cubic parallelograms.

RobMaddison, you don't have to use bounding speheres anymore. The method described by L. Spiro and the others is for AABBs, so if you already have the min and max values for your objects' AABBs, you can use those directly, with this method - you don't have to convert the AABB into a sphere anymore (if that's what you were doing). Sorry if I set you on the wrong path...

No, my bounding boxes are stored in the exact same way. What I meant was, if you've got an AABB which is the shape of, say a deep pizza box (perhaps it's a terrain patch with relatively small height changes), the sphere would cover the extents of the box in the x and z directions, but in the y direction the sphere would extend downward far beyond the extents of the polygons - that said, it's possible that if the camera frustum is pointing downwards toward the terrain, parts of the terrain could be drawn that are nowhere near in the frustum.Unless I've read it wrong?

As mentioned by tonemgub, these are AABB’s, not spheres. For a pizza box centered around the origin, m_vMin could be CVector3( -10.0f, -2.0f, -10.0f ), and m_vMax could be CVector3( 10.0f, 2.0f, 10.0f ). There is no restriction on the dimensions along any axis.L. Spiro

My apologies, I might not have described myself too well. I understand that these are boxes and not spheres, but you are taking a vector from the centre of the box to the maximum extent, which, for all intents and purposes, is effectively a radius and gives a sphere into which the square/rectangular box will fit.

It then looks like you multiply this radius vector by the normal of the plane. That is then used in the distance to plane check. I can't understand how this would work with an irregularly-shaped AABB, depending on which angle your frustum is at, you could be including something based on the 'radius' being used on the lowest extent.

Consider thus use case, the pizza box is standing up on its edge in line with your view vector, so basically you can just see the thin edge. Now if that pizza box goes just out of your frustum's right-hand-side plane, using this method I think you'd still be including it. If you imagine the [imaginary] sphere that results from the radius I spoke about in the previous paragraph, the radius value to check against the planes in this particular scenario is the still the centre of the box to the maximum extent, meaning part of it will be inside the frustum but none of the actual AABB will be.

Apologies if I haven't read the code properly but I've also tried it out and the results show a sizeable overdraw (or rather, draw inclusion), for irregular AABB extents.

for all intents and purposes, is effectively a radius and gives a sphere into which the square/rectangular box will fit.

The center and extent vectors do not describe a sphere, exactly. A sphere is described only by a vector center and a scalar radius, but in this case, the extent is a vector, not a scalar, so it is not a radius. You're probably just thinking of the length of the extent vector as a radius of a sphere, but when you think of it as only a sphere, you ignore the direction of the extent vector, which is also very important in this case.

It's complicated to explain how the whole method works - I'm not sure I understand it completely myself, but I assure you it does work correctly, no matter how the frustum is oriented.

for irregular AABB extents

What exactly are you reffering to as "irregular AABB extents"? You mean non-cubic extents? Those are handled correctly by the AABB-method - you just have to stop thinking about it as a sphere/plane check, and start using it. If you're getting bad results, maybe you have an error somewhere in your implementation.

Irregular

for all intents and purposes, is effectively a radius and gives a sphere into which the square/rectangular box will fit.

The center and extent vectors do not describe a sphere, exactly. A sphere is described only by a vector center and a scalar radius, but in this case, the extent is a vector, not a scalar, so it is not a radius. You're probably just thinking of the length of the extent vector as a radius of a sphere, but when you think of it as only a sphere, you ignore the direction of the extent vector, which is also very important in this case.

It's complicated to explain how the whole method works - I'm not sure I understand it completely myself, but I assure you it does work correctly, no matter how the frustum is oriented.

for irregular AABB extents

What exactly are you reffering to as "irregular AABB extents"? You mean non-cubic extents? Those are handled correctly by the AABB-method - you just have to stop thinking about it as a sphere/plane check, and start using it. If you're getting bad results, maybe you have an error somewhere in your implementation.

Yes, non-cubic extents, as L.Spiro explained. I've drawn and attached a diagram of my thoughts. Perhaps I'm missing something but if L.Spiro's fR and fS variables are calculated as per the diagram, you should be able to see where it might not work correctly.

Your fR vector is not drawn correctly. It should start at the center of the AABB and end at the left, on an imaginary plane that is parallel to the frustum plane and passes through the top left corner of the AABB (or whatever corner of the AABB is closest to the plane). I think this ensured by taking the absolute (or only positive) values of the extent vector's components - this is the part I'm not too clear on either. If this is not what you're getting from the algorithm, maybe your plane normals are not unit-length vectors, which they probably need to be in order for the dot product with them to return the length of the projection unaffected by the length of the normal. Your normals should also be pointing outwards, maybe. Also, in your drawing, the fR vector IS NOT the projection of the "max extent" vector onto the normal. The multiplication L. Spiro does there is the dot product vector-multiplication. You should really read the first paragraph from this wikipedia article: http://en.wikipedia.org/wiki/Dot_product And here's what the projection of a vector onto another vector looks like (the picture to the right): http://en.wikipedia.org/wiki/Dot_product#Scalar_projection_and_the_equivalence_of_the_definitions .

Some reading about frustum culling.

http://fgiesen.wordpress.com/2012/08/31/frustum-planes-from-the-projection-matrix/

There is simplest explanation how to create frustum from just simple matrix.

There is good read how to optimize the algorithm and why these tricks work.

http://fgiesen.wordpress.com/2010/10/17/view-frustum-culling/

AABB vs plane should be just two dots, one abs and comparision. Anything more complex is just wasterfull.

Tightest culling with AABB against frustum is achieved at object space. Creating frustum at object space is really simple and fast. And if you are only testing which side point is compared to plane you don't even need to normalize plane normals. Code at here: http://www.gamedev.net/topic/648803-frustum-culling-discrepancy/#entry5100532

Good thing with object space frustum culling is that you don't need to transform your AABB at all. Also single matrix is more compact way to store frustum than using six planes. So less data is needed.

Apologies L.Spiro, I read the fR calculation completely wrong, I can see how it works now.

Kalle_h, that's some interesting reading. Thanks for adding a different flavour to it - for experience, I'll try both ways.

Thanks again for your time guys, much appreciated

Got this working now, thanks all.

Strangely though, my algorithm only works if I add the plane distance, perhaps my frustum planes normals point inwards and yours point outwards?