That requires you to synch up the CPU and GPU, so you'll create a large stall...

Some new console games are actually using a software renderer to rasterize a low-resolution depth buffer, and then do all the occlusion tests on the CPU to avoid the stall ;)

Hardware occlusion culling isn't used by lots of games, and it definitely shouldn't be the only method of occlusion-culling used.

There's an article on gamasutra (can't find it at the moment) and probably some here on Gamedev too, which describe "occluders" or "occlusion volumes".

Basically, you define a convex polygonal shape for large objects in your scene. You then find the edges of this shape and use them to project an occlusion frustum out into the scene. You can then test the bounding-boxes of small objects on the CPU to see if they lie inside any of these frustums -- if they do, they're hidden.

You should probably also look into sector/portal systems. Portals can be culled using the same method as above (test the portal's BB against occluders, if hidden, don't traverse into the sector linked by the portal).

before you start with occlusion culling, you shall identify what you want to achive.

occlusion culling is not to make something faster, it's rather to load-balance work. you will have more costs on one side and less on another, the goal is to save time in average by utilizing underutilized resources.

e.g.
-you have damn expensive pixelshaders, in this case your goal #1 is to cull pixels. This could be accomplished by a z-prepass.
-you are vertex limited. in this case your idea is not that bad, you could use the ID-rendertarget in a 2nd pass and identify the visible IDs. resolve them into an ID-buffer (1d texture either set to 0 or 1) and the first instruction in the vertexshader would check the ID and either reject the wohle vertex (dynamic branching) or execute the whole shader (like comple FFT for water or 8weight skinning for some 50k character).
-you are drawcall bound, in this case u need an earlier stage to cull, maybe a software rasterizer or even some artist set anti-portals (which are damn simple to implement) would help already.

sometimes some middleware could help :)

Quote:
2. you cannot classify where you are in the world without keeping track of every single sector you are in and testing whether you intersects a portal or not every time you move. (you also need to pair yourself with an initial sector) (this goes for all objects, not just the player). You *could* use a BSP tree to classify where you are (like in doom3) but anything involving a bsp is hellish work.

that depends on the rooms. if you have room geometry as well, it's fairly easy to check where you're in, and you can assume that "indoor" scene do have those "rooms". in cryengine it seems to be a simple n-gone.

Quote:
3. portal culling is done in world space, image-space methods should be used as they address the actual problem of occlusion on a raster grid rather than be specific to triangular meshes. e.g. In an image space method - dynamic particles could also be used as occluders.

imagespace doesn't strictly imply that a raster grid is used. doing portalculling in imagespace reduces the work to simple 2d-vector-math (rect-rect clipping).

I think a big advantage and at the same time disadvantage is that you need humans to set it up. so they need to be skilled in setting them in the most performant way. portals to cull empty rooms are useless, but also missing portals can be a big performance hit.

but I think the OP was anyway asking for something for dynamic scene, that makes PVS and portals kinda obsolete.