Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I wonder if it is possible to optimize the performance of "BoundingFrustum" requesting return of the visible elements that are found only on the part of the ground before the player .. Checker and not all over the field unnecessarily?

This picture shows a Region 250X250 or 62,500 cubic! I thought it would be optimized to calculate the "Frustum" in half of the region! 31'250 cubic or less

Here my incomplete function:

foreach (Octree.Node node in regions.Where( /* ? only before the player... */).Where(r => != ContainmentType.Disjoint))


Here's a better picture of what I want. enter image description here

Here is a complete example of the world loaded in my games! Where each region has 62,500 cubic. My problem is that if the player looks towards another region, I have to calculate my "Frustum" in four parts! Or 4 * 62'50 = 250,000 cubic cubes. And every call my function 'update ()' enter image description here

share|improve this question
Unrelated to your actual question: Bounding frustums around rounded in any way like in the drawings. They consist of 6 planes. – Nic Foster Apr 12 '13 at 15:26

I wonder why are you thinking to optimize this.. you are already using octrees which is supposed to eliminate most of the scene with a couple of tests, so the remaining frustum/bounding testing for even hundreds of objects probably wont event affect your performance unless you are wokring on a very performance critical game, so I think using octree is good enough.

Edit based on comment:

one way is to use a faster (maybe your own) method Frustum.contain(). One approach comes to mind is to use radar based frustum culling (assuming Frustum.Contain checks with every plane in the frustum (which I suppose why Frustum.contain() is not so fast in the first place.

share|improve this answer
Yes the octree help already very well. But I thought I could still improve performance with the calculation of "Frustum"! Because the call "Where (m => camera.Frustum.Contain (m.BoundingBox) ..." is not very fast ... – Mehdi Bugnard Apr 9 '13 at 11:39
You should know that each region has 62,500 cubic! I added an explanation in my description. I thought more efficient to calculate my "Frustum" in half of my area. 32'250 cubic or less .. – Mehdi Bugnard Apr 9 '13 at 11:51
do you mean the whole octree or just the level/region you're testing the frustum against? – concept3d Apr 9 '13 at 12:06
No just the level/region ! 62'500 cube equals about ~ 12,500 octree.. thanks for your link ;-) I'll take a look after work ^ ^ – Mehdi Bugnard Apr 9 '13 at 13:46
If you are actually CPU bound on the frustrum checks, can you simply use the oct tree or at least reduce the calls? The GPU may be better at trimming these extra objects out than calling Frustrum.contains() for each object especially if they are very small. – NtscCobalt Apr 9 '13 at 19:55

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.