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
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…
[…] 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 […]
[…] Here’s the data I used to analyze projectile motion, in case anyone ever wants to do their own data analysis: Portal 2 Position Time Data, […]
[…] finally, let’s take a look at air resistance. Do falling objects in Portal 2 slow down due to air […]