Here is what Im speaking of, fairly straight-forward coding....

http://www.chadvernon.com/blog/resources/directx9/frustum-culling/

YogurtEmperor is right on the money except for one thing, that is if the center of the object is outside of the view frustum. Add in the bounding sphere of the object to compensate for objects for stuff outside of the view area that are partially visible. Don't know how to show you the code compared to his since I did it by plane equations (ABCD) but it does work...

I only said a point is inside the k-DOP if it is in front of every plane to give him an idea of the concept of a k-DOP.
The code I provided in my tutorial uses AABB’s for checking objects, and adds them if fully or partially inside the frustum.


L. Spiro

Makes sense if you explained it, I was just giving an example since our code is a bit different. Best to read his code for this thread...

I have a few gripes with that tutorial, but before I gripe on anything I want to also make something clear.

I do certainly agree that his tutorial is better for those just beginning. My gripes are entirely about optimizations, so my gripes are not warranted if your only goal is to understand the concept.
And that is perfectly fine. I would not be offended if someone uses his tutorial instead of mine, which is why I posted a few gotcha’s in case you do. By using his tutorial you are assuming that the plane equation is stored normally. That is, the distance part is not negated.

I would have liked him to have mentioned that, because in my tutorial I explained clearly that the distance part of the plane is negated, and I explained why. But if people blindly follow his examples, they won’t necessarily realize which method they are using to store their planes, because he never specifically says it is the non-negated form. So they would not be able to easily grow from his tutorial up to mine.


Which way you store your planes is up to you, but I wish every tutorial would explain which way it is being done. My tutorials will always be more for the advance group of programmers, and because of that I will be presenting structures that may be modified to suit optimized algorithms. In this case I negated my plane distance to become that much more optimized, but at least I explained that in each case where it was significant.

This is what I wish more tutorials would do.


L. Spiro

There is only one part where that matters.
For OpenGL, you just need to pass the transposed matrix to the function that builds the frustum.
Of course ideally you would change the function to work with a column-major matrix, but for simplicity you can just use the function as-is and transpose the matrix.


This table shows the relationship between a Direct3D matrix and an OpenGL array of floats:

_11 _12 _13 _14 -> [ 0] [ 4] [ 8] [12]
_21 _22 _23 _24 -> [ 1] [ 5] [ 9] [13]
_31 _32 _33 _34 -> [ 2] [ 6] [10] [14]
_41 _42 _43 _44 -> [ 3] [ 7] [11] [15]
This table is designed to perform the transpose operation for you, so if you simply do a Find & Replace for each of the DirectX members into the respective OpenGL array values you will effectively be modifying the function to work with OpenGL matrices natively (no need to transpose the matrix).



L. Spiro