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.