portals - How does a segment-based rendering engine (as in Descent) work?

As far as I know Descent was one of the first games that featured a fully 3D environment, and it used a segment based rendering engine.

Its levels are built from cubic segments (these cubes may be deformed as long as it remains convex and sides remain roughly flat). These cubes are connected by their sides. The connected sides are traversable (maybe doors or grids can be placed on these sides), while the unconnected sides are not traversable walls. So the game is played inside of this complex.

Descent was software rendered and it had to be very fast, to be playable on those 10-100MHz processors of that age. Some latter levels of the game are huge and contain thousands of segments, but these levels are still rendered reasonably fast. So I think they tried to minimize the amount of cubes rendered somehow.

How to choose which cubes to render for a given location? As far as I know they used a kind of portal rendering, but I couldn't find what was the technique used in this particular kind of engine. I think the fact that the levels are built from convex quadrilateral hexahedrons can be exploited.

Answer

descent uses a portal rendering engine this engine divides the world in convex rooms and the engine knows which room you are in

then to render you render the rooms faces and for each visible face that is a portal you adjust the frustum and render the room that the portal links to

in psuedo code:

renderRoom(room) {
    foreach face in room
    {
        if(!visible(face))continue;
        if(!isPortal(face))render(face);
        if(isPortal(face))

        {
            push frustum
            adjustFrustum(face)
            renderRoom(face.room)
            pop frustum
        }
    }
}

if a portal face is not visible then you don't need to render the room that connects through the portal

tutorial I found for creating a portal engine: http://www.flipcode.com/archives/Building_a_3D_Portal_Engine-Issue_01_Introduction.shtml