Portal Placement

Portal Placement

Overview

Portal placement is a process that can be split up into four steps:

1. Bullet ray cast - an initial step of shooting a portal and finding what surface has been hit.
2. Pre-bumping verification - checking if hit surface is viable for portal placement.
3. Bumping - attempting to fit the portal around other portals and edges.
4. Post-bumping verification - checking if bumped position is viable for portal placement.

This article will attempt to explain all of these steps, as well as mention all of the glitches and techniques related to them.

Bullet Ray Cast

At the moment of shooting a portal, a ray is being traced with following parameters:

• It's traced from the current player's eye position towards the current eye looking direction, transformed by linked portals matrix if peeking through ones. Keep in mind that in some cases the player's eye position and rotation is not always equal to the player's camera position and rotation - for instance, shaking changes camera position but not eye position.
• The length of the ray is equal to 2¹⁵ * √3, which covers the maximum distance between two points within the bounds of Source's map.
• It hits surfaces marked as solid, ignoring (as in "shooting through") following entities:

prop_physics, prop_weighted_cube, prop_monster_box, func_physbox, npc_portal_turret_floor, prop_energy_ball, npc_security_camera, simple_physics_prop, simple_physics_brush, prop_ragdoll, prop_glados_core, player, Player, projected_wall_entity, prop_paint_bomb, prop_exploding_futbol and npc_personality_core.

The tracing does go through portals, but it's stopped on the first hit prop_portal. This means that it's possible to shoot portals through world portals just fine, but shooting a prop_portal results in hitting a surface on which it's placed.

Then, if ray does hit something, presumable angles for placed portal are calculated. If hit surface is a floor or a ceiling, then the ray direction is used as an up vector, resulting in the top of the portal oriented away from the player. If it's not a floor nor a ceiling, then player's up vector is used, resulting in the portal rotated upright.

From there, the game uses the portal's origin (ray cast hit point) and its rotation for further checks.

Pre-bumping Verification

Once a surface is hit and both portal's origin and angles are calculated, a set of checks and fixes are applied to them:

1. If there's a portal belonging to player's coop partner that would overlap placed portal, partner's portal is fizzled.
2. A ray is casted 1 unit away from the origin, two units towards the surface of a portal, to see if portal would be placed on something solid. If it wouldn't, portal placement is cancelled.
3. The surface is checked if it's moving. If it does and sv_allow_mobile_portals cvar is not enabled, placement is cancelled.
4. The surface is checked if it's a pass-through or non-portallable material. If it is, placement is cancelled.

Bumping

Portal Bumping

Portal bumping occurs only when portal is placed by a player and sv_portal_placement_never_bump is not active.

The game iterates through every active portal lying on the same surface and then checks the distance between them. It's done by measuring length of a distance vector projected onto right and up directional vectors of currently placed portal, and then comparing them to width and height of the portal respectively. If both of them are smaller, the origin of a portal is moved so the length of a distance vector projected onto right directional vector would match a width of a portal, plus 1 unit. This works perfectly for portals placed on walls, because the logic works the same as just checking if portals are overlapping and moving the origin left or right so they don't overlap anymore, but when placing on floors or ceilings, portals can have different orientation, which can cause this algorithm to fail its job and bump the portal not far enough for placement to be successuful.

Edge Bumping

Edge bumping is a part where the game determines if and how portal fits on a shot surface. If it fails to fit it, the portal placement is cancelled. First, portal corners are calculated. Because of the "bump forgiveness", corner points are moved 2 units in each direction towards the middle of a portal. Thanks of that, it's possible to place a portal 2 units within a wall on each side. Then, for each corner we haven't interested with yet, corner check algorithm is executed. After that, depending on what corners have been intersected, certain checks are being made to determine the viability of the surface. TODO: this section is not finished. Explain all cases implemented in the code. Whole algorithm is repeated until surface is determined to be either portalable or non-portalable.

Corner check algorithm

For each corner of a portal, four checks are made: surface solidity, enclosing walls, bumping entities and surface portalability.

The way surface is checked if it's solid is quite interesting. A loop goes through 20 points evenly placed between the origin point (exclusive) and corner point (inclusive), moved 1 unit into the surface, and checks if they all lie within a solid object. This means that, as long as these 20 points are covered in something solid for each corner, surface can be considered viable, even though solid surface is missing everywhere else.

Enclosing wall check makes a simple ray trace from the origin to the corner, one unit away from the surface, to see if there are walls blocking the surface.

Bumping entities check makes a similar operation, but exclusively for entities meant to bump a portal, like func_portal_bumper or fizzlers.

A check for portalable surfaces is another interesting one. If portalable surface is not found on a corner point, a binary search is made to determine the point where non-portalable surface becomes portalable. However, if corner point does have a portalable surface, this check is completely skipped. This means that as long as origin point and corner points contain a portalable surface, it is possible to place a portal on them.

Post-bumping Verification

After the origin point is affected by all of the bumping and it's still viable for placement, a second set of checks and corrections are made:

1. Origin point and every corner point is checked if it's next to the solid, non-pass-through, portalable material. If any of them are not, placement is cancelled.
2. If bumped portal origin has been moved more than a maximum bumping distance away from the original origin point (sqrt((width2 + height2) / 2) units, which is equal to ~91.214 units for default portal size), placement is cancelled.
3. If a portal is closer to being vertical than horizontal (Z component of normalized portal's up vector is bigger than 0.7) and there’s a floor less than 1.5 units below the lower edge of a portal, adjusts the origin so the lower edge matches the floor position. This has been justified as helping game movement code run smoothly.
4. Placement is cancelled if portal would overlap the no-portal volume.
5. Placement is also callened if portal would still overlap any other portals.
6. If player is in a portal that is about to be replaced and the new position is close to the original one, placement is cancelled. This has been justified as a fix for a "vert hop exploit".

If everything is okay by this point, successful placement state is returned and portal is placed.

Related glitches

TBW

Portal Bump

Portal bumping mechanism attempts to move the portal origin in a way so it doesn't overlap other portals nearby. This check, however, doesn't consider edges that may be on a way or a type of a surface origin point may end up landing on. This means that, as long as all later checks are passed successfully, by bumping a portal you can place it behind walls, where you couldn't normally shoot, or on a surface that is portalable but not solid for bullets.

An example of that glitch would be an old Turret Sabotage route, where you'd bump a portal into turret scanning room in order to switch them without waiting for Wheatley to hack the door.

Portal Edge Glitch

Because portal surface is checked only on lines from origin to corners (forming an X pattern), it is possible to place a portal in a way that it's intersected by corners or models on its edges.

Portal Cut

TBW

Obscure placement scenarios

TBW