   Anti-portal implementation (alongside octree)
  I am having a hard time understanding (and finding resources to help me understand)how you would implement an anti-portal.I want to implement an anti-portal inside of an octree, if that is possible.I'm doing mostly outdoor terrain rendering. This includes a heightmap terrain, vehicles, foliage.I would like to know how you would go about implementing an anti-portal into the terrainFor example, I would like to be able to insert a brick wall in the middle of a detailed scene, and place an anti-portal plane inside of it. Then taking this idea I want to place a relatively complex building onto this scene, then place anti-portals inside of its walls. So when outside the inside of the building won't be rendered, and inside the building what is outside won't be rendered (except for small gaps for windows or doors).Before rendering the scene I could render the anti-portals to the Z buffer which will stop anything behind them from being drawn (reducing overdraw dramatically). However, this doesn't save any processing power from traversing through the octree behind the anti-portal, and I'm still switching texture states, shaders, making draw calls for what won't be drawn.   
  to do normal frustum culling you do an inside check on a frustum that is essentially the planes representing the eyepoint to the edges of the "screen"to do an "anti portal" aka - an occluder simply invert that logic.for an occluder, represented by a quad in 3d, build a set of planes from the eye point to the edges of the quad. The front plane IS the quad, the planes are the sides... anything that is 100% inside that set of planes is occluded.the same technique applies to convex shapes only you need to figure out the silhouette of the shape from point of view of the eyepoint before using the same algorithm as above for the inside check.   ;  So I render the anti-portal quads into the Z buffer, and if there are any then as I parse the octree I run an occlusion query with the octree node's AABB?I think it will be overkill to run an occlusion query against each object inside the octree node (in a loose octree), since an occlusion query is still realistically a render call and also requires uploading a matrix to the graphics card.So effectively, I'll insert the anti-portals into its own octree (allowing shapes other than quads so I do corners in a single render call) and render this. The problem if I have too many complex anti-portals (e.g. having a lot of buildings each with their own collection of anti-portals) - nothing is occluding the occluders! But that would be a general level design issue.One optimisation I thought of; Is it possible to tell if EVERY pixel passed the occlusion test? (excluding back faces) Because if it did then I know not to check that node's children.   ;  usually you dont render anti portals.like andy saidyou do a frustum check like you do for your view frustum, but you calculated the 4planes based on the edges of the anti portal.everything _completely_ inside the frustum (and behind the portal plane) is invisible.   ;  As Krypt0n said... use the CPU not the GPU... occlusion checks are relatively fast given a good algorithm   