Hidden surface removal and visibility determination used to be hot topics years ago. However, gradually, they seem to have faded in the background, so I wonder what people use nowadays. A mix of (old) techniques such octrees/quadtrees, BVHs, and conditional geometry? Am I missing some new killer algorithm / data structure?

Hidden surface removal and visibility determination used to be hot topics years ago. However, gradually, they seem to have faded in the background, so I wonder what people use nowadays. A mix of (old) techniques such octrees/quadtrees, BVHs, and conditional geometry? Am I missing some new killer algorithm / data structure?

I think more and more developers are moving towards occlusion culling in software. it's fast enough, you have no turn around times which is important for development speed, you also don't have setup costs (like e.g. creating portals) and you have all the flexibility you need.

regarding data structures, quite some games seem to use just an array of objects that they process in one go, this seems to be faster than suffering from cache misses by jumping to random places in hierarchical structures.

as krypton mentioned, rendering occluders in software on a small canvas is popular these days and fast too, dice did a nice paper on it.

as far as culling goes, good ol frustum culling (accelerated with caching last result) can blitz though an array of thousands of objects very very easily, and that of course could be combined with some form of bvh to reduce the number of tests down but only really necessary if you have over a few thousand individual objects at any given moment.

What about conditional/predicated geometry? Wouldn't that make software occlusion obsolete?

What about conditional/predicated geometry? Wouldn't that make software occlusion obsolete?

Not at all. Predicated rendering allows GPU to skip work efficiently, but everything involved in CPU processing is still full blown. If this involves complex CPU skinning, texture streaming or stuff like that, the CPU hit can still be significant.
Culling saves both CPU and GPU work.

Another simple system that hasn't been mentioned yet are occluder planes. I know of several "AAA" console games from this generation that only used frustum culling and occluder planes for visibility. The level is authored with large 'quads' inside any large walls/etc that occlude a lot of geometry. Each frame, the quads are frustum culled, overlapping quads are merged, and small/usless quads are rejected, which produces the list of occluders to be used that frame.
A list of bounding volume indices is processed by the frustum culling job (easily parallelizable) which produces a new list of indices (culled volumes removed). The second list is passed to another job, which tests each volume against each occluder (also easily parallelizable). If implemented correctly, tens of thousands of volumes can be culled in no time at all, with no precomputation. The final list of visible-volume indices is used to retrieve the visible objects to be rendered that frame.

Am I missing some new killer algorithm / data structure?

The killer technique these days, is simply taking old techniques and applying data-oriented and multi-core/GPGPU programming techniques to them.

[font="arial, verdana, tahoma, sans-serif"]What's the benefit of software occlusion queries, as opposed to hardware occlusion queries? [/font]
[font="arial, verdana, tahoma, sans-serif"]I mean, if done correctly hardware queries could be fast (no stall) even in DX 9.0, if fetching the results next frame.

If you implement with a one frame latency, then this is a huge draw back, not something to just brush over. There's not very many examples where I would put up with huge rendering artefacts simply because they only appeared for one frame at a time.[/font]
In order to have the one-frame latency and have no artefacts, then you need to know the positions of all objects/cameras one frame in advance, which is also possible, but instead introduces an extra frame of input latency (and a lot of system complexity), or alternatively, it requires you to always render objects that you don't have timely results for.

Second, hardware occlusion queries are expensive. For each bounding volume that you want to test, you've got to pay the CPU-side cost of issuing a draw-call (and the associated report-gathering), and on the GPU-side you've got to pay the rasterisation/fill costs. If you've got a large world with tens of thousands of objects, then this simply isn't feasible in practice.
In practice, a game-world can have millions of cullable objects in it -- a naive occlusion query system requires you to submit draw-calls for each one of them, and generally you only want to be issuing between a few-hundred to ten-thousand draw-calls per frame total (including real rendering), depending on your CPU-budgets.
To make this feasible, you've got to implement a complex system such as CHC+, which has it's own list of draw-backs.

Note, there are GPU-side alternatives to hardware occlusion queries, such as the HZB, as implemented in the "rendering with conviction" presentation. This particular technique only requires a single-draw call (instead of tens of thousands) and doesn't require rasterisation of the bounding volumes, which makes it much more scalable (and simpler) than the above techniques.

What about using instancing and occlusion culling ? For example, if a forest is rendered using instansing of a single tree, using a single draw call, how this fits with occlusion culling ?[/quote]Your culling system should not be directly tied to your renderable-object system (no dependency between them). Usually a 3rd system will use the results of the culling system when preparing renderable objects.

Two options would be to link all instances of that tree to a single cullable (either draw the whole forest or don't), or link each tree to it's own cullable, and have the instancing system adjust it's per-instance data buffers appropriately upon recieving the culling results (i.e. only include data for visible trees and adjust the instance-count), but this highly depends on your instancing system and your circumstances.

What about conditional/predicated geometry? Wouldn't that make software occlusion obsolete?

Only if you can afford to pay the CPU-side costs of rendering every item in your world every frame, and the GPU-side cost of rendering every bounding-volume every frame. In some games, this might be feasible. In any kind of game with complex visibility requirements (i.e. more than simply frustum culling), it probably isn't feasible.

What about 3rd party libraries? I don't see much talk about them.