Portals and PVS's can be used together to good effect, or be used completely separately.

Let's go through the combinations:

Portals (only):

- Visibility is computed from the camera /point/, tending to improve accuracy.
- Visibility is computed on the fly, removing the need for preprocessing and additional data structures.
- Can (with difficulty) handle the dynamic object occluding static object case.

PVS (only):

- Does not in general need a portal/cell subdivision of the scene, making it useful for outdoor scenes, forests, indoor scenes with a gazillion visible portals (this kills the efficiency of portal based algorithms), etc.
- Can process offline, so it can spend minutes to hours chugging away at generating optimal (for a view cell) visibility.
- Does not in general handle dynamic occludiing static object cases (but does handle static covers static, and static covers dynamic).

PVS + Portals:

- Uses portals to compute the PVS for each room.
- It can preprocess the anti-penumbra of the portals so that only the visible PARTS of the cells are rendered (usually to expensive to do at runtime).
- The set of visible cells are predetermined, so little run-time clipping is needed.
- Portals can be combined with PVS so that the PVS is cut down to the camera POINT subset of the PVS, but still only considering the PARTS of the cell that are potentially visible from the camera view cell. The net result is higher accuracy that normal portal rendering, at the cost of preprocessing the scene.
- Using portals to generate the PVS is typically much easier/more-accurate/faster than computing the PVS for generic triangle based scenes.

Realtime portals paper


Portals+PVS papers/thesis (go to 1992)

Non-portal PVS papers/thesis

Here's a nice method with hardware occlusion queries: CHC++. I've seen it listed in some engine descriptions.

I'm using a sort of hierarchical z-buffer visibility.

Using an octree, I draw only what is inside the frustum, in a "partial" front-to-back order (because only nodes are ordered, not triangles). At the beginning, I render a number of nodes to be sure to almost entirely fill the screen-space area. Then I make a z-pyramid (where the first level is the zbuffer itself and the last the farthest visible pixel) using hardware but finally downloading it (only the last levels) into system memory. From now on for each node I check it agains this z-pyramid without using any hardware occlusion query, culling it if not visible.
I use also the z-pyramid to fast cull actor/general objects meshes that are hidden by something.

Some more great info guys, thanks.

I've been thinking though, possibly portals and an octree is enough for indoor environments with today's hardware. Like this:

1) Keep the static interior geometry very simple, i.e. just walls, any more complicated areas will be created as static objects.
2) Add the necessary portals to each node
3) At runtime, check which zone the camera is in and retrieve the list of portals that are within the camera frustum
4) Using each visible portal:
4a) Create a new frustum using the portal and draw the simple static interior geometry of the neighbouring zone it has a view into
4b) Cull the neighbouring zone's detailed static (e.g. radiators, window frames, etc) and dynamic geometry against this new frustum
4c) Retrieve a list of the portals which belong to the neighbouring zone and that are within the new frustum and repeat step 4 recursively until no more portals are found

I know this is generally how a portal engine works, but with this method, I don't really see the need to have a pre-computed PVS (as in Crowley9's "Portals (only)" description). If the static interior geometry is kept simple enough, i.e. as square as possible, the GPU should be able to easy handle any overdraw - there won't be that many wasted vertex transforms. Rooms where there are more complicated areas, like for instance, a curved wall, alcoves or broken areas, can be stored as rectangular but have these more complicated pieces stored as additional static geometry pieces that can be culled away by the frustums.

I haven't had a chance to try this out yet but does it sound okay?

few years ago i've invented a little trick that seems to nicely combine portals with hardware occlusion query, basically i subdivide scene using kd-tree that also keeps information about portals between cells faces then every frame i locate camera and render traditionally like i would classic portals, except instead of using explicit recursion i use queue that also keeps occlusion queries. that way every time i pop portal to visit from queue it usually has occlusion query completed and can be decided if i should drop it or visit destination cell, render its contents and add its portals to queue initialising queries