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 => arcadia.camera.Frustum.Contains(r.boundingBox) != 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

  • 1
    \$\begingroup\$ Unrelated to your actual question: Bounding frustums around rounded in any way like in the drawings. They consist of 6 planes. \$\endgroup\$
    – Nic Foster
    Apr 12, 2013 at 15:26

1 Answer 1


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. http://www.lighthouse3d.com/tutorials/view-frustum-culling/radar-approach-testing-points/

  • \$\begingroup\$ 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 ... \$\endgroup\$ Apr 9, 2013 at 11:39
  • \$\begingroup\$ 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 .. \$\endgroup\$ Apr 9, 2013 at 11:51
  • \$\begingroup\$ do you mean the whole octree or just the level/region you're testing the frustum against? \$\endgroup\$
    – concept3d
    Apr 9, 2013 at 12:06
  • \$\begingroup\$ No just the level/region ! 62'500 cube equals about ~ 12,500 octree.. thanks for your link ;-) I'll take a look after work ^ ^ \$\endgroup\$ Apr 9, 2013 at 13:46
  • \$\begingroup\$ 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. \$\endgroup\$
    – NtscCobalt
    Apr 9, 2013 at 19:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .