[FooHentai]

The Quake engine BSP format precompiled visibility and lighting elements into the level file data. So at runtime you had a precomputed 'potentially visible set' (PVS) for any position a player could be within the playable area, and rendering was then performed based on that set only. Walking that tree was stunningly fast compared to runtime occlusion culling techniques. Likewise lighting info was pre-baked into the level as a layer of texture, and computed based on point-in-space light objects raycast against the PVS calculated in the previous step. All of this meant you were processing on less textures and polygons for any given position during the game, and that provided a speed edge at a time when absolute reduction in overdraw was key to performance.

This let you do stuff like (and I'm working from memory here) have a 15k triangle budget from which you could easily develop a 300k triangle environment, as long as you were VIS-ing well enough that a player never saw more than 5% of the environment from any common position. Non-visible areas were essentially completely free, because they weren't even considered at runtime. This was a significant edge over culling approaches such as the one you mentioned, at a time when that kind of edge mattered a lot.

That said, IMO this approach was tuned for extracting maximum performance from the hardware available at the time (~Mid 1996- late 98). It showed it's age heavily from Quake 3 onward and was quickly overtaken by engines adopting somewhat different approaches (e.g. Unreal) quite quickly.