[FooHentai]

>This result could be less tight; for example, if you had a long corridor with many side rooms, and that long corridor was a single cell, then in Quake it would always try to render all the side rooms, whereas Thief would only try to render the entry cell to each of the side rooms (since those cells would always be adjacent to the corridor and visible), but Thief could cull the rooms themselves if they weren't currently visible.

Big if. You had screwed up if you left such a setup as one long vis chunk. Level designers would place vis boundaries strategically along a corridor to control this behavior. It was a bit of an art form but not exactly hidden knowledge, even the levels that shipped with quake SW had this kind of tuning built in.

Weird that at no point in this article is the engine overall referred to as what I and presumably most level/mod designers referred to it as - 'The Dark Engine'. Still, she's a classic. Tuned beautifully for the sneak/rpg gameplay of Thief and System Shock. Not at all suitable for the high speed multiplayer FPS gameplay of Quake. A comparison between the two is always interesting to see.

[causality0]

That's quite interesting. I wonder why visual culling on PC appears to have been much more primitive than culling on, say, the Nintendo 64. Some games there seem to dynamically cull every single polygon not in sight. For example, Banjo Kazooie: https://m.youtube.com/watch?v=se6y5we3p2I

[kevingadd]

That's just backface and/or frustum culling, likely being done by the N64's equivalent of the hardware transform unit or the rasterizer. Completely separate matter from visibility culling which is usually done at a very coarse level - objects, rooms, etc. Not individual triangles. It's true that game consoles typically had better culling capability of this sort built in, since without it games wouldn't have acceptable performance.

When a scene contains a truckload of triangles, culling them all one at a time like that does not win you as much performance as you might think. You always needed to do additional things on top of it.

[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.

[avereveard]

because you cut out relevant lighting from off-screen / occluded sources, it only works with prebaked lighting.

[kencausey]

I don't think Banjo Kazooie is a good comparison because the camera is entirely on a track by intention so that they could fully pre-process visibility.

[causality0]

What? You can rotate the camera freely in Banjo-Kazooie.

[CliffyA]

Ya i think OP may be mixing up crash bandicoot and banjo kazooie

[kencausey]

Sorry, that is my mistake.