RED Portals and Rooms: Difference between revisions
No edit summary |
No edit summary |
||
Line 23: | Line 23: | ||
==Rooms== | ==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. | 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. | ||
[[File:Portalrooms1.png]] | |||
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 [[RED Objects#Room Effect|Room Effects]], [[RED Objects#EAX Effect|EAX Effects]], and airlocks. | |||
===Door Rooms=== | ===Door Rooms=== | ||
Revision as of 18:34, 15 November 2020
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.
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
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.
Door Rooms
Portals
Air Brush Portals
Solid Brush Portals
Portal Brushes
This page uses content from Portal rendering on Wikipedia, which is available under the GNU Free Documentation License. |