fps is non-linear. Use ms/frame. Says you’re going from 111 ms/frame (no culling) to 50 ms/frame.
The problem is my that my timer is crap. It gives different results every time. I’d need to run some kind of average. Do you know of a good timing source for Linux? Anyway, the fps’s I give here are just inverted timing values, i.e. 1/(time_between_the_frames_in_seconds), so I don’t see a problem with them.
That’s one. And by frustum I assume you mean culling against 6 planes that define the frustum, right?
So what are some other permutations?
- frustum - tile-sphere, and then if it passes do frustum - tile-AABB
- frustum-bphere - tile-bsphere
- frustum-bsphere - tile-bsphere, and then if it passes do one or more of the other more expensive tests (frustum - tile-bsphere, frustum-bsphere - tile-AABB, frustum - tile-AABB).
Yes, by frustum I mean testing against all the 6 planes. As far as other permutations are concerned; I first calculate the set of tiles that fit inside a frustum AABB, and then check them all against the exact frustum, just to be sure they really are within and not just within the frustum AABB. So the frustum AABB already provides a good starting point. I suppose I need to test every possibility and arrive at a decision based on the tests.
It depends on the expense of the operation you’re trying to protect and the expense of protecting it. That depends on more than just your CPU and GPU perf.
On newer cards I get more fps, if I don’t do any exact frustum-tile AABB overlap tests at all, the cards are so fast, they don’t mind clipping. But on older cards this is not the case. It would be interesting to find out, if the old card just isn’t capable of gulping down all the geometry coming in at that resolution, despite the cull.
On a new card, I could do instancing, alas.
For simple symmetric frusta, I think you can usually get an exact answer by taking the midpoint of a frustum diagonal, and then just expand the bsphere by each frustum corner just to make sure.
This reminds me of the Ritter sphere algorithm. I kind of doubt it this gives the minimum sphere, as the sphere center is limited to the diagonal and there are more than 1 frustum diagonals, but only one minimum sphere is possible.
But for the general problem of computing a bounding sphere for a set of points cheaply, google “Welzl’s minimum bounding sphere”.
Some other links to explore:
- View Frustum Culling Tutorial (Lighthouse3D)
- Frustum Culling (Flipcode)
- Welzls Minimum Sphere Algorithm Demystified
One might argue, that Welzl’s algorithm is not about calculating the minimum sphere, but to find out which points define it. There are up to 4 of them and if one knew in advance which 1 to 4 of the 8 were “right”, then one would not need to run the Welzl’s algorithm, but could directly calculate the minimum sphere.
Maybe I could make 1 experimental run of Welzl’s algorithms, see what points it picks and then designate those points as always “right”.
I’ll just have to do some benching, I suppose.
PS: frustum - tile bsphere test also involves 6 planes and is not much cheaper than frustum - tile AABB test, I think.