## Projectile Motion in Portal 2 – part 3

And finally, let’s take a look at air resistance. Do falling objects in Portal 2 slow down due to air resistance?

Short answer: Yes! The Source engine accurately handles air resistance and terminal velocity!

Air Resistance and Terminal Velocity Background

Terminal velocity follows naturally from comparing forces acting on an object. As Newton’s first law explains, objects change the way they move only when acted upon by an outside force. For instance, a hockey puck is perfectly content sitting still on the ice so long as no forces are acting on it (as if we could speculate about the mindset of an inanimate object!). As soon as a force acts on it, perhaps in the form of a slap shot, it starts to move. The puck will maintain the same velocity until another force, let’s say the goalie’s glove, changes its velocity. To be even more precise, unbalanced forces cause changes in velocity. That is, multiple forces can act on an object without causing an acceleration so long as the forces balance each other out. In tug-of-war, for example, two teams may be enacting tremendous forces on a rope, but so long as both teams create the same force in opposite directions the rope doesn’t budge. As soon as one team pulls harder than the other, the forces become unbalanced and the rope’s velocity starts to change.

In the hockey example above, we assume the ice and air around the puck produce negligible friction on the puck, a tactic often employed by physics problems. In reality, the situation is more complicated. Any object moving through a fluid, such as air, or in contact with a surface, such as ice, feels friction. Friction is a unique force in that it always opposes motion. Without motion, friction does not exist. Unlike other forces, friction can never cause motion. As an object’s velocity increases, so does the force of friction.

In an situation analogous to tug-of-war, a falling object feels opposing forces. Gravity accelerates the object downward while air resistance accelerates the object upward in the form of friction. As the falling object gets faster, friction from air resistance increases. Eventually, the frictional force matches the gravitational force and the object no longer accelerates. At this point, the falling object has reached its maximum velocity, which we call terminal velocity.

The velocity of an object in freefall will generally follow the relationship below:
[equation 1, credit to Wikipedia] where m is the mass of the object, g is acceleration from gravity, ρ is the density of the fluid (typically air), A is the cross-sectional area of the falling object (or the surface area of the side of the object facing the direction of motion), and CD is a dimensionless constant called the drag coefficient. Notice in this equation that mass is a factor, and a more massive falling object should fall faster than a lighter counterpart.

Terminal Velocity in Portal 2

Once again, we want to collect data from Tracker and fit a curve to it with Gnuplot. This time we’ll be looking at velocity as a function of time and trying to fit it to equation 1. We’ll use Gnuplot to fit the data to a function of the form of

[equation 2]      v(t) = -B*tanh(C*t),

where B and C represent the constants before the hyperbolic tangent (tanh) and inside the hyperbolic tangent of equation 1 respectively. Holy cow. The velocity of a freefalling 55kg contraption cube almost perfectly follows what you would expect from equation 1 (note: this graph lacks uncertainty).  We can confidently say that the Source engine mimics air resistance!

We’re left with an interesting situation, though. On the one hand, we have data that clearly show that whatever algorithms are controlling motion in Source accurately represent air resistance. But now we have to wonder about the constants within equation 1. We know Source scales terminal velocity to mass. But is Source using a realistic value for air density in the game? Is it really taking the cross-sectional area and drag coefficient of the cube into account?

For now, we can check if Source is at least internally consistent, regardless of whether or not it uses accurate values for the constants in equation 1. Let’s assume that Source uses some constant to account for drag coefficient and air density. We already know mass and gravity. So let’s solve for the cross-sectional area. Gnuplot solved equation 2 with B = 318.6 and C = 0.4768. If we equate B to the constant before the hyperbolic tangent in equation 1 and solve for the cross-sectional area, we get a value of 0.121 u2. Plugging in our value for cross-sectional area to the constant inside the hyperbolic tangent, C, and using all of the same values for ρ, CD, m, and g, we get C = 0.477, which is exactly what Gnuplot produced. So, at least Source is in some way internally consistent.

To be continued with a wrap up of projectile motion…

## Projectile Motion in Portal 2 – part 2

So, is projectile motion in Portal 2 accurate?

Short answer: Yes! And in the next post, I’ll cover how Portal 2 handles terminal velocity.

Projectile Motion in Portal 2

To analyze projectile motion, we need a way to measure the position of a falling object over time. In a perfect world, this data would get exported directly from Source. You can find it in the game with console command `physics_debug_entity`. You would think that this would make getting position data easy, but as far as I know there are no tools available to directly export position data from the console to an external file, and I don’t have the time to manually record position data for a falling cube frame-by-frame. Incidentally, this post took me so long because I’ve been learning scripting for Portal 2 to export position data automatically (still a work in progress). In the meantime, I used Tracker. Tracker is a fantastic program that analyzes the motion of objects in videos. I like using Tracker because it gives me a chance to collect data in a way that better replicates the process physicists (and physics students) go through to collect data and deal with error in the real world. After all, the universe doesn’t have a `physics_debug_entity` command.

In the video below, we can see Tracker track the position of six falling contraption cubes. Notice how the graph on the right in the video replicates exactly what you’d expect for projectile motion.

However, we now need a way to convert between the units Tracker uses and panels, our favorite unit for distance in Portal 2. There is a viewpoint difference between objects at the top of the fall and objects at the bottom of the fall as a result of perspective. By using the measuring tool built in to Tracker, we measure that each panel is equivalent to 32.4 +/- 0.5 units. Tracker treats contraption cubes like point objects despite the fact that they aren’t. The point which Tracker uses to track these objects may shift, which gives us another source for uncertainty. Each contraption cube has a size of 15 units, according to Tracker, giving us a reasonable maximum bound for uncertainty of 15 units (I would argue uncertainty of 7.5 units, but that would assume each tracking point begins directly in the middle of the cube, which may not be the case).

The error from the tracker shift on a cube is significantly larger than that from perspective. I feel safe saying that the extreme maximum bound for uncertainty is 15 units.

With that in mind, let’s look at data from multiple falling objects. At a cursory glance, figure 1 shows that all objects initially follow projectile motion (the solid red line). Though smaller objects reach terminal velocity relatively early in the fall (which will be covered next), for the most part we can see that contraption cubes accelerate correctly until they reach terminal velocity. Let’s zoom in on the initial moment of a falling object and see just how closely the measured positions compare to predicted positions. Here we can see the 85 kg contraption cube’s position over the first two seconds of falling. Using Gnuplot, we can fit a curve to the data to determine exactly the rate at which the cube is acceleration. We want to fit an equation of the form

yfinal = yinitial – 0.5gt2,

which draws from equation 1. Gnuplot’s parabolic curve fit found that g = 152.1 +/- 0.8 units/s2, which is equivalent to 4.694 +/- 0.02 panels/s2. According to the game, gravity should be accelerating objects at 4.6875 panels/s2, which is within the bounds of our calculated value for g!

As far as we can tell, Portal 2 accurately depicts gravity!

To be continued with terminal velocity tomorrow…

## Projectile Motion in Portal 2 – part 1

I’ve based most of my laboratories, lessons and videos off the fact that the Source engine is frighteningly accurate in its depiction of the way objects move under the influence of gravity. In fact, my very first Portal 2 video was about projectile motion. In the video, I was able to accurately predict where I would land based on the laws of physics we know and love in the real world. That alone might be good enough reason for some people to assume the laws of physics in the game are accurate enough. Apparently, I’m not one of those people.

In today’s post, I’m giving an overview of projectile motion. Following this, I’ll present an in-depth analysis of how Portal 2 handles projectile motion and whether or not air resistance is actually a factor for falling objects.

The Physics of Projectile Motion

The vertical path of objects falling solely under the influence of gravity follows the equation

[equation 1]      Δy = vyt + (1/2)gt2 ,

where Δy is the displacement of the fall, vy is the initial vertical velocity, g is the strength of gravity (g = – 9.8 m/s2 in the real world), and t is the time elapsed. If we assume that our object simply started falling without being launched upward or downward, we can let vy = 0, which simplifies our equation to

[equation 2]     Δy = (1/2)gt2 .

At this point, we have a simple equation to determine the vertical distance an object falls based only on how long it has been falling (though it is important to note that equation 2 is only for ideal situations because it ignores air resistance, which has significant effects in the real world). Equation 2 does not include a reference to mass, which indicates that ideally mass has no bearing on the way an object falls, as first proposed by Galileo in the 17th century. This was famously tested on the Moon during Apollo 15 when astronaut David Scott simultaneously dropped a hammer and a feather and watched them hit the ground at the same time. If you were to scour a physics textbook for opportunities to employ equation 2, you’d find problems involving marbles rolling off the edges of tables, packages dropping out of airplanes, and people dropping garbage out of second floor windows. In Portal 2, I’ve found the simplest way of replicating this type of problem is with a cube sitting atop a hard light bridge that suddenly disappears. In this situation, the object is free to fall. If the Source engine follows the laws of physics correctly, the object should accelerate at a constant rate as it falls and cover more distance per unit time.

Do not be fooled into thinking that this falling object is falling in a parabola by the parabolic shape of figure 1. The figure above only describes motion in one direction, downward. Notice that it’s simply showing a downward change in position that changes more as time goes on. In other words, the object gets faster over time. If figure 1 looks familiar, it should. It’s half of an upside down parabola that most math students create when they graph y = x2 .

[figure 2: parabola] Projectile motion is parabolic in nature. As such, projectile motion is often referred to as parabolic motion because launched objects follow graceful parabolic arcs. In the real world, objects rarely follow perfect parabolas. Friction, in some form or other, will impede or alter an object’s path. The faster an object travels, the more friction is a factor. Anything built to be fast, whether that’s an airplane, racecar or bullet train, has a sleek profile to minimize friction’s effects. Any child who has stuck her hand out of the window of a fast moving car can distinguish between a non-aerodynamic surface (where her palm is held perpendicular to the wind) and an aerodynamic surface (when her palm is held parallel to the wind).

As an object falls, it feels a constant force of gravity but an increased force of friction. Eventually the two forces equal each other and an object reaches what is called terminal velocity, or the maximum velocity attainable in free fall by an object of a particular shape and size (generally denser objects fall faster). For a human, terminal velocity is reached around 60 m/s near the surface of the Earth.

So, in studying falling objects in Portal 2, we have two metrics we can use to determine accuracy: gravity and terminal velocity.

To be continued…

Tagged , ,

## wait… what is going on here?

I’m currently hard at work analyzing the depiction of projectile motion in Portal 2. What started as a quick, one minute video has turned into a veritable research paper on the accuracy of projectile motion’s representation in the game. Keep an eye out for some hardcore physics nerdiness in the next few days.

In the meantime, here’s an interesting discussion on Reddit about the physics of a rod stuck between two moving portals. The rod should oppose the motion of the portals in this diagram until it breaks. Increasing the distance between the portals would require stretching the rod, in which case the applied force would in some way be proportional to the tensile strength of whatever material makes up the rod. This begs a few questions, of course. What about the air between two moving portals such as these? Would moving portals create suction? Would a moving portal have to also apply a force to oppose air resistance? Would vertical portal movement (in this diagram) be possible? In a vacuum with no rod present, would you still have to apply a force to change the separation between the portals?

I recently read Chad Orzel’s fun book, “How to Teach Relativity to Your Dog,” which has put me in the relativistic mindset. I can’t help but think that a situation involving moving wormholes would experience significant effects from general relativity in ways that may not be immediately apparent (or allow this kind of situation in the first place). We’re looking at a moving spacetime connection between two distance places, which hurts my brain.

Anyone have any thoughts? I’d love to hear.