Author Archives: Cameron Pittman

physics, portal, and reddit

Check out the lively discussion on reddit about this picture:

Of course, there are a few caveats to any discussion about the physics of portals. Portals don’t actually exist and even in the game world they can’t move (except for one special example). So, not only could this scenario not happen in real life, it couldn’t even happen inside the game. That being said, it’s still a fun thought experiment.

I would tend to argue that B is the correct answer and it completely comes down to relative velocities. The cube has a velocity relative to the orange portal, which means it also has a velocity relative to the blue portal. So when the cube pops out of the blue portal, it should have that same relative velocity.

Some of the comments arguing for A use people jumping through hula hoops or door frames in their response. The space on either side of a hula hoop or door frame maintains the same relative velocity; the space around each portal has a different relative velocity in the scenario depicted above.

I like this argument but I don’t agree with it. Reddit user Falconhaxx uses the means of transmission between the two portals to argue for A. Basically, the cube can either instantaneously appear at the blue portal or move through in infinitesimal slices. Either it pops from one portal to the other or it gradually moves through. In the case that it instantaneously appears at the other portal, option A is correct. Rather than doorways, think of the portals as transporters. Whatever state an object is in when it hits the first transporter will be carried over as it instantly teleports to the other. So, if the cube has no velocity when it reaches the first teleporter, it would have no velocity at the second transporter.

On the other hand, if portals gradually move objects through (which is the stance I tend to take), then the cube would be ripped apart by changing forces. As pieces of the cube go through the portal, each feels an infinite force differential which would rip it apart. Think of dividing by 0. The forces on the cube change over no distance at all (gravity is pointing one way when the cube goes into the blue portal but gravity is pointing a different direction when it comes out), which is more than any piece of matter can handle. As a result, the cube would be sliced into infinitesimally thin slices as slice after slice of it moves from one side of the portal to the other (I bet you didn’t know you could use a variant of the word ‘slice’ four times in one sentence).

Of course, the latter argument could be used for any object going through portals. If the game played by those rules, Portal would hold the record for being the world’s first deli meat slicer simulator. Sure, the game breaks a few laws of physics (that sounds like a good topic for a post…), but it wouldn’t be fun if it didn’t.

In the end, relative velocities make much more sense. If the cube has a velocity relative to the entry portal, it should have a velocity relative to the exit portal.

Think I’m wrong? Comment and let me know!

Edit: This guy has a good point too. Does the relative momentum of the blue portal to the cube matter?

terminal velocity part 1

Portals slow you down! Go figure.

A more in depth analysis:

Portals automatically drop your velocity to about 7.8 u/s (or 1000 game units/s) as you go through them, which is why your terminal velocity drops when you go through portals more often. Every time you hit a portal, your speed drops to 7.8 u/s. If you have less distance to fall after your speed drops, your speed has less time to increase. In the longer drops, you have more time to pick up speed, meaning your terminal velocity, as measured in this experiment, will be higher.

This video is meant to describe a way to quickly and easily run experiments in a classroom. Without knowing that portals affect your velocity ahead of time, this experiment would give students a strong indication that something weird is going on and the relationship between portals and velocity is worth investigating.

Console Commands:

sv_cheats 1 (must be done first but only has to be done once)
host_timescale 0.001 (slows time to 1/1000 speed)
host_timescale 1 (brings time back to normal)

Oscillators part 2

Well, I was wrong about my simple harmonic oscillator (SHO). It’s just an oscillator. But why?

A simple harmonic oscillator experiences a restoring force proportional to distance. For instance, a mass hanging on a spring is a simple harmonic oscillator because the force the mass feels is directly proportional to its distance from some resting position. The farther down you pull the mass, the greater the force the spring will apply to the mass. In other words, the harder you yank on a spring, the harder it yanks back. The same isn’t true for the experiment I created. It doesn’t matter how high the cube is from the ground, it feels the same force of gravity. So, it’s an oscillator, just not a SHO.

But a lot of good has come out of this mistake. It actually generated a nice discussion on reddit, in which it seems we figured out that the cube is being damped in a slightly odd way.

Even if the physics in Source don’t perfectly mimic real life, running experiments gives students a chance to apply what they’ve learned to identify discrepancies. Asking, “what’s wrong with this picture?” is just as valid a lab question as any other. Answering it requires a strong working knowledge of actual physics, a good experiment, and thorough data analysis.

Gravity

Gravity shows up a lot everywhere. We can calculate it using experiments in the game engine, but we run into some difficulties because of friction. And given that we can’t ascertain the effects of friction off-hand in a virtual environment, we have to look into the game engine itself to figure out the strength of gravity.

According to Valve’s wiki, gravity is automatically set to 600 u/s2. Their units, however, are different than the ones I’ve been using. As you may recall from previous videos, I’m calling each wall panel 1 unit. In reality, each wall panel is made of 128×128 game units.

Doing a little bit of conversion, we get

600u / 128u/panel = 4.6875 panels (which easily rounds to 4.7 panels). So, gravity is automatically set to 4.7 panels/s2.

But what’s a panel to us? How does that compare to the real world? Luckily, Valve went ahead and gave us a convenient conversion chart.

According to the chart, 128 units = 2.4 m.

4.7 panels * 2.4 m/panel = 11.25 m.

Inside Portal 2 (and every other game that runs on Source), g = 11.25 m/s2

To put it in more scientific terms gSource = 1.15gEarth

It sounds weird, but it isn’t surprising. Other game engines have similar tricks, such as the Unreal Engine 2004 running time at 110% speed. Maybe it makes games seem more realistic? Not sure, but it’d be a good question for a psychologist.

Timing and Momentum Flings

In one of my lesson plans, I challenge students to build a level in which they have to use perfect timing to catch a cube that’s launched with a momentum fling. The simpler the setup, the better. Here’s an example of such a level.

Of course, the math behind a momentum fling is pretty easy. Making the catch is all about putting the moving platform in the right place at the right time.

I’ll be reusing this level for an upcoming video on the effects of friction in Portal 2.