   Instead of BSP tree...?
  So I understand that BSP trees are pretty outdated and not appropriate for today's graphics hardware. But what should be used in their place? What sort of visibility structure would you use for a modern indoor FPS?Just simple quadtree-based frustum culling, or something more involved?   
  I think kd-trees and AABB-trees are pretty common. http://en.wikipedia.org/wiki/Kd-tree and just google for AABB-tree for more info.   ;  I am by no means an expert on this subject, but I think the most popular occlusion culling method for modern games is a portal system. Frustum culling alone isn't going to help in a big indoor level where you can potentially look across the entire level. You need a way to be able to basically not have to render what's on the other side of a wall, which is what a portal system can help with. The statement that BSP trees are outdated really only applies to the Quake-style usage where you use the BSP to test each individual triangle as you draw it.;  BSP trees aren't used for visibility in games like Quake -- they were primarily used to sort polygons from back to front (so they could render the world without using a ZBuffer -- a very silly idea these days).Quake (and it's derivatives) use a sector/portal system for visability, which is used by the level-compilation tools to pre-generate a PVS table (potentially visible set), which is then used for visibility calculations at runtime.PVS tables and/or sector/portal system are still perfectly fine for an indoor game.   ;  Like said before, portals usually split levels into smaller chunks. While you could use some precalculate visibility sets for static objects, nowadays there are tons of dynamic objects and they cannot be culled in an offline process, that's the main reason portals are used.Those "Chunks"are usually quite small (usually just one room or less) and you can store them in any container you want. On PSP I used just a simple array of objects. while it wasn't that fast to query culling or collision test against them, it never peaked in any profiling.if it would become a bottle-neck, I'd probably use a simple octree for every "room", because it's very easy to generate and moving objects can easily be updated within an octree.Portals are really nice, because it's soo easy to use them (frustum culling is all you need) and it works for all objects (no need to seperate static/dynamic).Portals are just problematic from the content creation side. placing them automatically isn't that great, using some exisiting tool like 3dsmax and fake portals with other objects that you convert during loading causes lot of wrong setup (at least that's my experience) and writing your own tool just because of portals is quite some overhead.An alternative would be a big octtree for the whole level and occlusion culling based on the octtree-nodes for visibility culling.   ;  Some engines today, especially those with large mixed indoor-outdoor scenes and dynamic scene object placement, use a simple software renderer to rasterize simplified conservative geometry into a small depth buffer on the CPU. This gets used to determine which objects are potentially visible. I haven't seen any detailed presentations about implementation but DICE uses this approach for their engines.   ;  You might also want to check out AB Trees, covered a bit by yann l back in the day. YOu can find information about that here, on page 2