RED Portals and Rooms

Portal Rendering Basics
Red Faction uses portal rendering to determine what geometry and objects will be visible at any given time and therefore avoid instances where level assets that can't be seen by the player are still being rendered. By determining which geometry and objects are not currently visible, and not rendering those assets, significant performance improvements are achieved.

As a concept, this approach involves separating levels into zones/sectors (referred to as rooms in Red Faction), which are connected to one another by small openings that the engine has been instructed to consider as portals. When the engine determines that a room behind a portal needs to be rendered (based on the player's current camera position and view direction), only the parts of that room that are visible through the portal are rendered, rather than the entire space. As a general practice, portals should be configured in any confined areas (doors, tunnels, windows, etc.) that connect two otherwise separate areas of a level. The use of portals in this way greatly simplifies the engine's task of determining visible areas and objects from any given point of view. At a technical level, portals allow the engine to use each portal as a viewing frustrum for the area behind the portal.

The diagram below illustrates how the engine determines which objects to render using portals. For this purpose, detail brushes that have alpha textures applied are considered objects.



Visualization
To better understand how portal rendering works in Red Faction, you can use several debug options in the level editor (RED) and the game client itself to visualize both rooms and portals.

Useful options for visualizing portal rendering concepts in RED's view menu:
 * Show Rooms in Different Colors
 * Show Everything See-through
 * Draw Non-see-thru Portal Faces

The same options are accessible via console commands in the RF game client (Dash Faction 1.5.0+):
 * debug room
 * debug trans
 * debug portal

Portals
Portals are used to subdivide areas within levels into rooms. Virtually every Red Faction level should contain portals, and a designer effectively using portals often makes a hugely significant impact on the performance of their level in the game. Using doors in conjunction with portals can be used to block visibility and further enhance performance (see Door Room below for more information). Portals are also necessary to effectively control the presence of liquid (see Liquid Room below for more information).

The easiest way to consider portals is to think of them as windows. If a portal is in the player's field of view, that portal is rendered. Any geometry or objects in the room beyond the portal that are visible to the player through the portal are also rendered. Only three conditions can cause a portal to not be rendered:
 * 1) The portal is off-screen (ie. behind the player)
 * 2) The portal cannot be seen by the player either directly or through another portal (ie. is fully behind a wall)
 * 3) The portal separates a Door Room from a room adjacent to it, the door is closed, and the player isn't in the Door Room

To designate a brush as a portal, tick the Is Portal box in Brush Mode operators, then click Update. Only two types of brushes should ever have this flag set - air brushes and face shape Solid brushes. Setting any other type of brush to be a portal is unsupported and will cause issues. To actually create a room, the portals must block off a section of the level that is "water-tight." You should use the visualization options listed above to confirm your portals are being created as you intend.

In theory, placing as many portals throughout your level as possible until frame rate starts going down instead of up is ideal. In practice, you should try to place as many as it takes to separate the areas of your level from each other, always considering visibility at different angles throughout your level and how portal placement will affect rendering in those areas. Try to take special care to subdivide areas that contain a large number of visible objects or complex geometry. Portals should never intersect other portals.

Below is a series of drawings illustrating the basic logic of portals and how they subdivide levels into rooms.

Air Brush Portals
Functionally, air brush portals are the same as placing solid brush portals at each intersection point between the air brush portal and other air brushes - for this reason, solid brush portals often offer more flexibility and versatility. The most common use for air brush portals are doorways and windows. When creating doorways, you should take special care to ensure the door is tightly constrained by the air brush portal and the player is never able to look through the Door Room you've created into another adjacent room while the door is closed. Simple Liquid Rooms (such as small puddles or craters filled with water) may also use air brush portals.

Solid Brush Portals
Most portals in levels should be solid brush portals. Solid brush portals are commonly used in hallways, tunnels, and any large open areas that require portals. Additionally, solid brush portals are often used to seal off Liquid Rooms. Solid brush portals will only work if the gap they're intersecting is entirely encompassed by the plane of the portal face. It is fairly common for solid brush portals to cause holes inexplicably. In these cases, you should ensure the portal is not intersecting another portal, and hit End of Time while the solid brush portal is selected. You may also want to consider grid aligning all vertices of the solid brush portal by pressing Ctrl + G while they're all selected (see Vertex Mode Hotkeys for more information). If these strategies don't resolve the issue, you may need to adjust the positioning of the solid brush portal in the world to mitigate the hole.
 * NOTE: Only face shape solid brushes can be used as solid brush portals.

Rooms
Every Red Faction level is separated into rooms - even a 4x4x4 hollow cube map will have 1 room. Adjacent rooms are joined together with portals, and nonadjacent rooms are separated by world geometry. You can see an illustration of this concept below - a portal is separating room 1 from room 2, while solid world geometry is separating room 2 from room 3.



If the engine determines that a room is visible to the player, and that visibility is through a portal, only the geometry and objects within that room that are visible through that portal are rendered. In addition, room definition also determines the boundaries of Room Effects, EAX Effects, and airlocks.

The GeoMod engine renders each room separately, so if you have a large amount of objects or complex geometry in a single room, subdividing that room into multiple rooms may help improve performance and/or resolve rendering issues caused by limits being exceeded. Furthermore, there is a specific limit of 2048 rendered objects per room at any given time (this includes detail brushes with alpha textures). If this limit is exceeded, some objects that normally would be rendered will be skipped.

Door Rooms
Any room that contains a gold keyframe object with the Is Door flag set is considered a Door Room. Door Rooms have the status "Blocked" whenever the door mover is closed. When looking through the Door Room into an adjacent room, the adjacent room will only be rendered if the Door Room is not currently "Blocked". The theory behind this concept makes a lot of sense - adjacent rooms will not be visible when the door is closed (since the door is blocking visibility), so they don't need to be rendered. In practice, this can cause visibility issues if the boundaries of the Door Room are not tightly constrained to just the door/doorframe by the level designer. The images below illustrate this concept. In each, the camera is in Room 1.

Bad Design
In the diagram below, the door is not contained within a small room dedicated to just the door/doorframe. As a result, the entirety of Room 2 is the Door Room.




 * Bad Design - Door Open
 * Room 1 contains the camera, so is rendered.
 * Room 2 (the Door Room) is visible through a portal, so all geometry in Room 2 visible through that portal is rendered.
 * Room 3 is visible through two portals, so all geometry in Room 3 visible through those portals is rendered.
 * The door mover is opened, so the Door Room (Room 2) is not blocked. Because of this, Room 4 is visible through two portals, so all geometry in Room 4 visible through those portals is rendered.


 * Bad Design - Door Closed
 * Room 1 contains the camera, so is rendered.
 * Room 2 (the Door Room) is visible through a portal, so all geometry in Room 2 visible through that portal is rendered.
 * The door mover is closed, so the Door Room (Room 2) is blocked. Because of this, both Room 4 and Room 3 are not rendered as they are both adjacent rooms to the blocked Door Room (Room 2).

Good Design
In the diagram below, the door is contained by use of portals to a small room dedicated to just the door/doorframe. As a result, a new room (Room 5) is created, and is the Door Room.




 * Good Design - Door Open
 * Room 1 contains the camera, so is rendered.
 * Room 2 is visible through a portal, so all geometry in Room 2 visible through that portal is rendered.
 * Room 3 is visible through two portals, so all geometry in Room 3 visible through those portals is rendered.
 * Room 5 (the Door Room) is visible through two portals, so all geometry in Room 5 visible through those portals is rendered.
 * The door mover is opened, so the Door Room (Room 5) is not blocked. Because of this, Room 4 is visible through three portals, so all geometry in Room 4 visible through those portals is rendered.


 * Good Design - Door Closed
 * Room 1 contains the camera, so is rendered.
 * Room 2 is visible through a portal, so all geometry in Room 2 visible through that portal is rendered.
 * Room 3 is visible through two portals, so all geometry in Room 3 visible through those portals is rendered.
 * Room 5 (the Door Room) is visible through two portals, so all geometry in Room 5 visible through those portals is rendered.
 * The door mover is closed, so the Door Room (Room 5) is blocked. Because of this, Room 4 is not rendered as it is an adjacent room to the blocked Door Room (Room 4).

Sky Rooms
A Sky Room is the room containing a level's skybox. A level can have a maximum of 1 sky room, and sky rooms are designated via the presence of a Room Effect object with effect type Sky Room. Sky rooms can contain any number of normal or detail brushes, must be physically separated from the rest of the level, and are always rendered fullbright (without any lightmaps). Any objects in the sky room will be considered to be out of the level.

Skyboxes provide level designers with a method to create the illusion of a sky in a level. When present, a sky room is rendered as if the level is physically within the sky room, with the player camera position always located at the center of the room. Players will see the skybox projected whenever invisible textures or surfaces configured as Show Sky are used to allow the player to look outside of the level.

Basic Skyboxes Tutorial

Liquid Rooms
A Liquid Room, designated via a Room Effect object with effect type Liquid Room, contains liquid of the specified type, and at the specified depth, as configured in the Room Effect properties. The depth is calculated from the lowermost point in the Liquid Room.

Basic Liquids Tutorial

Ambient Light Rooms
An Ambient Light room has its own specific ambient light color value which takes precedence over the Level Properties ambient light value in that room. The ambient light color is the base light color applied to all normal and detail brush surfaces when lighting is calculated.

An Ambient Light Room is designated via the presence of a Room Effect object with effect type Ambient Light. The ambient light color is also configured in Room Effect properties.