The Portal Paradox

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

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.

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

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

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."

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

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.

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.

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."

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 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.

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

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

"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?

The thing that makes me cross my arms and say "A" is: how does the cube change from still to moving without making contact with anything? For it to fly out the other side of the portal, something would need to give it energy. The moving platform doesn't touch it, the platform it's sitting on isn't moving, then would it be the portal? Since it perfectly conserves momentum, (aside from changing direction) it shouldn't add or subtract any energy, right? What clinches it for me is shifting my thinking about what the portal does. It's not actually moving the cube, it's shifting where the cube is. Yes, a fast-moving portal will cause a cube to appear out the other side quickly, but that doesn't mean the cube is moving quickly, just that the portal's plane of "being somewhere else" is passing over it quickly. It quickly changes from gravity pulling it in one direction to gravity pulling it in the other direction. Also, the moving platform's energy dissipates into the stationary platform.

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

Minutephysics: It depends whether you think more like a programmer or more like a physicist. Me, dual majoring physics and computer science: Visible confusion

I rule in favour of Option D. When the stationary object is consumed by the portal, the source engine crashes.

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.

r/197 going crazy