Portal Rendering

   { I haven't yet gotten to implementing a portal renderer so it's possible
   I make a wrong claim here by mistake, but I'll try not to :) ~drummyfish }

   Portal rendering is a method of [1]3D rendering that treats the rendered
   environment as spaces (e.g. rooms) connected by portals (doors, windows,
   ...) which allows fast and simple determination of visibility and
   therefore fast and simple rendering. It was a quite popular way of 3D
   rendering for example in the old 1990s 3D [2]games such as [3]Descent and
   [4]Duke Nukem.

   The basic general idea is to represent the 3D environment as a set of
   "rooms" (generally any [5]subdivision unit of space, not just "house
   rooms" of course) and their connections to other rooms through portals
   ("holes", shared walls through which one room connects to another); then
   when rendering we simply draw the room the camera resides in (from the
   inside) and proceed to draw the rooms that are connected by portals which
   are now visible on the screen, treating each of those portals as a kind of
   new smaller screen (i.e. a [6]clipping window). Then we go on to
   [7]recursively draw portals in those rooms again etc. until some
   terminating condition is met (e.g. all screen pixels are covered or we
   have reached maximum draw depth etc.). A limitation imposed on a room is
   often that it has to be [8]convex so that its "from the inside" rendering
   is simple; non-convex spaces are then simply split into multiple convex
   ones -- [9]EZ.

   Just as similar methods like [10]raycasting and [11]BSP rendering, portal
   rendering can be used in various ways, it is not a simple [12]algorithm
   but rather a method, approach to rendering. It may also be used just as a
   "helper" for visibility determination in another method. Notably there is
   a "full 3D" (Descent) and "2D" (Duke Nukem), sector based version of
   portal rendering. They are all based on the same principle but may have
   different limitations etc.

   Advantages of portal rendering:

     * It can work without [13]precomputation, which is a huge plus compared
       e.g. to [14]BSP rendering (though optional precomputations such as
       [15]PVS can of course be always employed). This among others saves
       time (precomputing can take a while), program complexity and space (no
       need to store extra precomputed data).
     * The environment can be [16]dynamic (change on the fly, consider e.g.
       destructible or animated environment), thanks to not needing
       precomputed data. This was made advantage of in Build engine games a
       lot, while in Doom only wall and ceiling height could change on the
       run.
     * Impossible geometry can be created -- as we may create any arbitrary
       spaces that connect to each other, it is possible to for example
       create a house that's bigger on the inside than on the outside, or a
       curved tunnel that would in reality intersect itself but doesn't. We
       can even have room above room in the 2D version (though in vanilla
       version there can't be two VISIBLE rooms above one another).
     * Effect such as mirrors are easy -- a mirror may be just a portal that
       connects to the same room in opposite way.
     * There is no [17]overdraw, a problem that plagues many 3D renderers, so
       we don't need [18]z-buffer and may probably hack the method to not
       even [19]need a [20]frame buffer. This is pretty awesome, may reduce
       memory requirements greatly and allow things such as [21]frameless
       rendering. However z-buffer and [22]double buffering are still mostly
       used so as to allow additional correct rendering of overlays to the
       environments, e.g. "2D [23]sprites".
     * For mentioned reasons the method is relatively simple, efficient and
       [24]software rendering friendly, making it a good candidate for weak
       computers.
     * ...

   TODO

2D Portal Rendering

   TODO

Links:
1. 3d_rendering.md
2. game.md
3. descent.md
4. duke3d.md
5. subdivision.md
6. clipping.md
7. recursion.md
8. convex.md
9. ez.md
10. raycasting.md
11. bsp.md
12. algorithm.md
13. precomputation.md
14. bsp.md
15. pvs.md
16. dynamic.md
17. overdraw.md
18. z_buffer.md
19. dependency.md
20. frame_buffer.md
21. frameless.md
22. double_buffering.md
23. billboard.md
24. sw_rendering.md