Difference between revisions of "Portal Placement"
From P2SR Wiki
(Created page with "{{P2 Title|Portal Placement}} ==Overview== '''Portal placement''' is a process that can be split up into four steps: # '''Bullet ray cast''' - an initial step of shooting a po...") |
|||
| Line 1: | Line 1: | ||
{{P2 Title|Portal Placement}} | {{P2 Title|Portal Placement}} | ||
| − | + | =Overview= | |
'''Portal placement''' is a process that can be split up into four steps: | '''Portal placement''' is a process that can be split up into four steps: | ||
# '''Bullet ray cast''' - an initial step of shooting a portal and finding what surface has been hit. | # '''Bullet ray cast''' - an initial step of shooting a portal and finding what surface has been hit. | ||
| Line 8: | Line 8: | ||
This article will attempt to explain all of these steps, as well as mention all of the glitches and techniques related to them. | 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: | 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. | * 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. | ||
| Line 19: | Line 19: | ||
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.<ref>Upright meaning vector directed towards positive Z. This changes only when interacting with sticky gel (seems to work differently in P2:CE)</ref> | 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.<ref>Upright meaning vector directed towards positive Z. This changes only when interacting with sticky gel (seems to work differently in P2:CE)</ref> | ||
| − | From there, the game uses the | + | 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: | ||
| + | # If there's a portal belonging to player's coop partner that would overlap placed portal, partner's portal is fizzled. | ||
| + | # 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. | ||
| + | # The surface is checked if it's moving. If it does and <code>sv_allow_mobile_portals</code> cvar is not enabled, placement is cancelled. | ||
| + | # The surface is checked if it's a pass-through or non-portallable material. If it is, placement is cancelled. | ||
| + | |||
| + | =Bumping= | ||
| + | ==Portal Bumping== | ||
TBW | TBW | ||
| − | ==Bumping== | + | ==Edge Bumping== |
TBW | TBW | ||
===Corner check algorithm=== | ===Corner check algorithm=== | ||
TBW | TBW | ||
| − | + | =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: | |
| − | + | # 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''. | |
| + | # Placement is cancelled if portal would overlap the no-portal volume. | ||
| + | # Placement is also callened if portal would still overlap any other portals. | ||
| + | # 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".<ref>No idea what it could mean, but most likely not ground reportal, as that wouldn't fix it.</ref> | ||
| + | |||
| + | If everything is okay by this point, successful placement state is returned and portal is placed. | ||
| + | |||
| + | =Related glitches= | ||
TBW | TBW | ||
| − | + | ==Portal Bumping== | |
TBW | TBW | ||
| − | + | ==Portal Edge Glitch== | |
TBW | TBW | ||
| − | + | ==Portal Cut== | |
TBW | TBW | ||
| − | + | ==Obscure placement scenarios== | |
TBW | TBW | ||
| − | + | =References= | |
<references /> | <references /> | ||
Revision as of 18:21, 19 June 2021
Portal Placement
Contents
Overview
Portal placement is a process that can be split up into four steps:
- Bullet ray cast - an initial step of shooting a portal and finding what surface has been hit.
- Pre-bumping verification - checking if hit surface is viable for portal placement.
- Bumping - attempting to fit the portal around other portals and edges.
- 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 215 * √3, which covers the maximum distance between two points within the bounds of Source's map.[1]
- 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[2], 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.[3]
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:
- If there's a portal belonging to player's coop partner that would overlap placed portal, partner's portal is fizzled.
- 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.
- The surface is checked if it's moving. If it does and
sv_allow_mobile_portalscvar is not enabled, placement is cancelled. - The surface is checked if it's a pass-through or non-portallable material. If it is, placement is cancelled.
Bumping
Portal Bumping
TBW
Edge Bumping
TBW
Corner check algorithm
TBW
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:
- 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.
- Placement is cancelled if portal would overlap the no-portal volume.
- Placement is also callened if portal would still overlap any other portals.
- 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".[4]
If everything is okay by this point, successful placement state is returned and portal is placed.
Related glitches
TBW
Portal Bumping
TBW
Portal Edge Glitch
TBW
Portal Cut
TBW
Obscure placement scenarios
TBW
References
- ↑ This info has no application, making it useless. In most cases, it's easier to assume the ray is cast infinitely forward.
- ↑ Yes, the filter has two player classes implemented with uppercase and lowercase P. No idea why.
- ↑ Upright meaning vector directed towards positive Z. This changes only when interacting with sticky gel (seems to work differently in P2:CE)
- ↑ No idea what it could mean, but most likely not ground reportal, as that wouldn't fix it.