Basics

Motivation: current CS portals are quite complicated, to implement, but also to use with their gazillion flags - this is an attempt to streamline them somewhat.

• Portals are classified as either "light" or "heavy".
• Light portals just cause the sector behind being rendered and the visculler frustum being restricted. No other clipping takes place.
• As soon as some clipping is needed, switch to heavy portals. Those are more or less floating portals and rendered via render-to-texture.

Some implications that follow:

• Heavy portals probably always do portal plane clipping.
• Meshes that straddle a heavy portal must be rendered in both sectors.
• Using a texture for heavy portals means that they're implicitly Z filled.

Open questions would be: What functionality do we lose in comparison to the current approach? Anything significant?

• For "huge world scenarios", light portals with space warping might be desireable: space warping so sectors have different coord spaces (relevant to avoid float precision issues), but sectors could be lined up such that "heavy" clipping is not necessary.

Effects

When portals are rendered to textures:

• Allow for a way to put portals on other meshes. Irregular meshes, non-flat geometry, ... What's needed is basically a way to attach the portal contents texture and some information to compute the right texture coordinates on that texture to the mesh. Easily done with an SV context. Also, the computation of the TCs would presumably be done by the shader.
• "Automatic screen-space portals": given a bounding box (or sphere), use the screen-space area to compute the portal polygon for the view. Could enable complex "look-through" objects (e.g. "a Crystal Ball").