Room Bounds and Portal Basics
Basic Theory[edit | edit source]
What do Room Bounds do?
A room bound will section off an area to be rendered. If the player is inside of a room bound, nothing outside of the room bound should be rendered. If the player is outside of a room bound, nothing inside of the room bound should be rendered.
What do Portals do?
Portals are visual gateways between room bounds. They should be placed between rooms at any location where the player should be able to see from one room to another. This is generally any location where doors or hallways connect one room bound to another.
To have a properly functioning Portal between two room bounds, it must be connected to both room bounds.
Basic Troubleshooting[edit | edit source]
Rendering Issues Caused by Room Bounds and Portals[edit | edit source]
Problems with room bounds and portals usually result in things not being rendered when they should be. The console command MBC will toggle the entire multibound system. If entering the MBC command fixes an issue with a disappearing object, that bug is being caused by the multibound system. The following are some common issues found when using room bounds and portals:
- When an area is using room bounds and portals, it can be difficult to navigate using the TCL command to get to a specific area. Using MBC will allow you to see all of the geometry.
- If the pivot point of an object is not inside of a room bound, it will not be rendered. This is exactly how room bounds should work, but care should be taken to ensure that all objects that should be visible in the room bound have their pivot points inside the room bounds. **Commonly, this applies to large objects that are partially in a room bound.
- Another common problem is small objects on the edge of a room bound. A room bound might not quite reach the floor, and that will cause some of the objects on the floor to not render.
- If an NPC drops an object, it is very possible that it will disappear on the ground if it is outside of the room bounds. Be sure that all room bounds contain the full visible area. Always make room bounds extend below the floor.
- A viewpoint from outside of a room bound can only see into the room bounds through a portal. This can be used to your advantage when verifying that everything is properly included in a room.
- If something is accidentally left out of a room, it will be visible if you enter the cell in-game and use TCL to fly around in the space outside of the room bounds. Anything intended to be drawn inside a room should have its pivot point inside the room bounds.
- The player can walk between Room Bound areas with or without a portal, but without a properly functioning portal, it will appear as though the player is looking out into the void. You can still walk forward, however, and once you get into the next room it will properly render.
- If everything briefly disappears as the player walks through certain areas, it is possibly caused by overlapping or separated room bounds.
- It is not good for the player to be able to move their 3rd person camera outside of the room bounds. If this happens, many objects will no longer be visible to the player.
Performance Issues Caused by Room Bounds and Portals[edit | edit source]
One negative with using portals is the player can look through many portals at the same time. This increased number of frustrum operations (FrustOps) can cause a hit to performance.
Care has to be taken to prevent the player from being able to see too many portals at once. It's OK if the portal is in an unrendered (red in TFC 3) cell. This is most commonly seen when the player is looking down a long hallway and can see many portals at once.
Use the TFC 3 command to observe portal debug info for each room. The more distant active (green) rooms will show a higher number of FrustOps. Keep the frustops number as low as possible.