# Introduction to sectors and portals.

Let's say your level consists of a city full of building objects and an interior of a tavern and there are 1000 objects altogether in your level. The engine has to dig through 1000 objects to decide what to render. But if you are inside the tavern, probably 950 of those objects representing the exterior will NEVER be visible. This is where sectors are a big win.
Sectors are a way of hinting to the engine what is potentially visible and not. You can visualize the sector as a container of objects. In the example above let's say we create two sectors, one for the interior of the tavern and another for the rest of the city.
Thus if you are indoors in the tavern 'sector', the engine is only rendering 50 objects and not 1000. But if you are outside, it is rendering 950 instead of 1000, which is not that much of a help. This is why CS (and most other 3d engines) can render indoor scenes much faster than outdoor scenes. Indoor scenes can be heavily sectorized. You can imagine if the tavern in our example is 2 stories tall, we could make indoor rendering even faster by splitting apart the "tavern" sector into "tavern floor 1" and "tavern floort 2" sectors, with perhaps 20 objects and 30 objects respectively. This would make rendering in those areas even faster.
But what if you are inside the tavern and look out a window, or look out an open door? If the engine is only considering the "tavern floor 1" sector, you won't be able to see the outdoors through the window.
This is where "portals" come in. A portal is a polygon in a sector that triggers the engine to render another sector besides just the one you are in. So when you model the window of the tavern, you will create also another invisible object that fits the window, and you flag it as a "portal to outdoor sector". When the renderer renders the 20 objects in "tavern floor 1" sometimes that window will be visible, depending on which direction you are looking, and if the renderer sees that it is rendering a portal polygon, it adds the sector the portal points to ("outdoor" in this example) to the queue of sectors to render. This means in our case it will render the 20 objects, then render the 950 objects. Thus, if you are indoors and you cannot see the window/portal, it will render much faster than if you turn just a little bit and can see even a fraction of the window. When the window shows and activates the portal even a little bit, the 950 outdoor objects must be considered and not just the 20 "tavern floor 1" objects. CS handles this fairly efficiently, but it is still significant overhead. The solution to this is to split the city outside in more sectors, so that the portals to other sectors are not visible and the engine has to consider less objects.
In our example, you would also need a portal the other direction too, if you want people to be able to stand outside the tavern and look in through the window. Portals are not bi-directional. This mean you have to create another portal object of the same shape of the first one that from the outside looks into the tavern. Looking in a tavern window isn't going to slow down your render very much though, because it only changes your total rendered object count from 950 to 970.
Where handling portals gets complex is that portals can be recursive. Imagine standing outside the tavern, looking in the window, and seeing all the way through the tavern to a window on the opposite wall, which shows the outdoors of the city again. This takes your render count from 950 to 970 to 1920, because now the outdoor sector is being considered twice. Smart level design can and should keep these to a minimum.
Actually this isn't as inefficient as it sounds, because when a sector is added to the queue of sectors to render, it is visibility clipped to the shape of the portal before true visibility culling is done. The "cone" of what you can see through a window is obviously much smaller than the entire city, and clipping off objects outside the window view is a pretty fast calculation. This is why small portals like windows are faster than big portals like doors or walls.
Hopefully this helps explain why it is good to divide up things into sectors, but only in certain cases.

Notes to add :
- everytime you have a bunch of geometry behind one portal and that portal is not in the camera view, you save a lot of calculations
- the flarge level made by CS people is 1 sector per room :)
- that's an extreme, but it works well.
- those must be in the exact same position
- just facing opposite directions.
- they should face the player.

A simple rule: the IDEAL (most efficient) portal is a portal that:
a) arrives in the sector at the BOUNDARY of all mesh objects in that sector.
b) leaves in the sector at the boundary too.
a) is more important than b).
I manually added <clip/> and <zfill/> to ALL portals I found in the two sector version
and this helps remove a lot (not all) of the render errors. However, it slows down the
level too. Especially <clip/> can be expensive so it would be nice to try to set
<clip/> only when REALLY needed.

When is <clip/> needed? <clip/> is needed when you have a portal that
ARRIVES in the middle of a sector. i.e. if you have a portal that arrives in the sector
and there is NO geometry at all behind the portal plane then <clip/> is
not needed and shouldn't be set for performance reasons.

<zfill/> is needed when you have a portal that STARTS in the middle of a
sector.
Performance of <zfill/> is not that bad.

Back to Portals and sectors