The Portal Paradox

Aperture Science wants to remind you, that you can't put Portals on moving walls. Thanks. Edit: "Could you guys stop commenting the same stuff on my two year old comment."

1: Put two portals on ceiling 2: Put a cube half way through 3: Gravity pulls on both sides equally therefore the cube doesn't fall 4: Profit

my physics teacher (slightly suggested by me since we were both gamers and I was the one who provided him a copy of the game to play) used Portals related lessons several times to explain concept like inertia or the meaning of accumulated and static momentum He used this problem in one of his lessons, and was the funniest one imho, since the class was very interested in this problem and came up with a lot of solutions for both option A and B

Years ago, I was trying to program a small 2-D platformer game that had a mechanic where a user exiting one side of the screen would reappear on the opposite side (same with top to bottom). I tried adding an extra mechanic where the user could resize the game frame to solve puzzles and I ran into this same question. I realized that I had accidentally backed into creating a Portal style game in 2D with moving portals. In terms of physics, the proper answer is that the object leavers the exit portal with the speed and acceleration it had RELATIVE to the entrance portal. And that speed and acceleration is relative to the exit portal (not the environment). While it makes for an interesting thought experiment, it creates a lot of problems for a programmer. For example, if the user is shrinking the game frame, the portals are moving toward each other. An object entering a portal gets a speed boost from both the entrance AND the exit portals (because they are moving toward each other). If a user allows the player to go through the portal several times while shrinking the screen, the user will accelerate each time, until the player is going so fast that the frame rate of the program can't keep up. This creates weird problems with the collision engine (player is moving so fast they pass straight through solid objects) and the rendering engine (player is moving so fast that it creates an optical illusion where it looks like they are moving backward). After breaking my brain on this for a while, I realized why portals really aren't allowed to move - it creates physical possibilities that are impossible to replicate with a computer. I ended up abandoning the project because the physics was not something that could be simulated with a computer. I'm guessing that the developers of Portal had these same issues, which is why the portals can't be placed on moving surfaces.

There's only one way to address this issue: Portal 3. Which in itself will cause a paradox because Valve don't count to three.

"Speedy thing goes in, speedy thing comes out."

if a portal in this game's rules, as I have understood, is in a surface and it starts moving, the portal disappear instantly

Consider what you would see looking into the exit portal. You would essentially see the ground pushing the cube out of it. When you think about it like that, it seems like it would have to be relative to the object and the entry portal.

"The portals never move" Cough cough neurotoxin generator cough cough

To quote GLaDOS from Test chamber 10, "Momentum, a function of mass and velocity, is conserved between portals. In layman's terms: speedy thing goes in, speedy thing comes out."

Assuming that portals are only windows as seen in the games, the only force applied on the cube to move him is the gravity force at any speed of the orange portal

i have watched this video a dozen times in the past 3 years and my answer changes every single time

"speedy thing goes in, speedy thing comes out" but what if speedy thing was never speedy? [queue vsauce music] what if, instead, stationary thing goes in speedy hole: does it come out the other fast or slow?

I think this paradox is the entire reason that Valve implemented a "no portal on moving platforms" policy except for one exception where it would be impossible to put an object through it

I think we could measure speed relative to the environment and still have B happen in a game if the teleportation takes both the object and portal's speed relative to each other into account. For instance, if cube and orange are both moving towards each other at a speed of 1, then cube exits blue at a speed of 2, but if both are moving in the same direction, then if orange is faster than cube, then cube would exit blue at the speed of orange - cube. The same thing would then apply to the speed of blue relative to cube. If blue is moving forward, then cube exits at its new velocity plus that of blue.

The portal, in my opinion, would behave as if the bottom platform was pushing it into the portal, since the platform moving towards the portal, and the portal moving towards the platform are essentially the same thing in this context.

My science teacher used portal as an example to explain this and he played it for us as well which is super surprising

The portals aren't teleportation. It's just making a continuous space where there normally isn't one, it's no more teleportation than you walking into your kitchen.

another option is that if an entry portal moves then the exist portal has to move at the same speed. So the speed should be relative from the portal to the object itself, I think of portals like tubes or rings which are the same, the only difference is what is bigger the length or the diameter.

I always thought of the portals as gates or doors. Normally stationary you walk through one side come out the other. If a door frame is throw thrown at you yourself won't gain any momentum from that. Also my problem with B is, you don't have any momentum to start with even if a portal is moving at you fast and slams down on top of you you should still be standing on the same ground so what force will pull you up.