We are entering Week 4 now of our Senior Project, and this is my first post. Whoops. Really should have started this sooner, but I did not have anything to talk about. Over the past few weeks, my team and I have been breaking the project up into teams and tasks, and we finally got everyone put into something. My job, as it stands right now, is to write the Physics system and make a model of the Earth for our game. Since modeling is really self-explanatory, let's talk about the physics.
The Stratos Jump, as it is formally called, was a remarkable feat of human engineering and endurance. From 120,000 feet, Felix Baumgartner jumped, broke the speed of sound, and landed safely on the ground. The physics involved with this jump are fairly straightforward, but it will take some explaining and extra research to get the formulas correct to model the behavior correctly.
So, what do we know about the physics of this jump? First of all, the atmosphere at the height of the jump has a much lower density than the atmosphere does at ground level (or sea level, for that matter). This density also changes with the temperature, and we all know that it gets colder the higher you go. There is a great post by Rhett Allain over at scienceblogs.com (link here) that explains the physics behind this jump. I will try and explain it in my own words here, but if something does not make sense, I would suggest going and reading that article and looking at the formulas.
LATER THAT SAME DAY...
Well, it appears this is going to be harder than I expected. Our client wants this to be as realistic as possible, which means my physics simulation will have to be as realistic as possible. After looking over a ton of reports and articles written about the subject, I have come to the conclusion that I will probably use the model put together by Allain in his initial article and a followup he wrote after data was released from one of Felix's test jumps (link here). Sure it isnt the actual data from the real jump, but I can modify the model to include the real data. I am merely going to use the formulas he used to calculate his model. Here is how I see it as of right now:
Physics update loop:
1) Calculate temperature as a function of height using this formula:
Where T is temperature, T0 is the standard sea-level temperature in Kelvin, L is the temperature lapse rate in Kelvin/meter and h is height in meters.
2) Calculate air pressure as a function of height using this formula:
Where p is pressure, p0 is standard air pressure at sea level in kPa, L is the temperature lapse rate, h is height, T0 is standard sea-level temperature, g is the gravitational constant (can probably get away with 9.8 m/s^2 here), M is the molar mass of dry air and R is the universal gas constant.
3) Calculate air density as a function of pressure using this formula:
The variables are all explained in the above steps. There is one caveat, though. The p on the right side of the equation has to be in Pa, not kPa as above.
4) Calculate force of air resistance using this formula:
Where p is air density, A is the cross sectional area of the thing falling (our skydiver in this case), C is the drag coefficient, and v is the velocity of the diver. Allain was nice enough to have already calculated an average AC value that should work for our purposes in his most recent article that I linked above. The AC value I will use is .579m^2.
5) Calculate net force on skydiver, which will be air resistance plus gravity.
6) Calculate the new velocity and update it
7) Calculate the new position and update it
This seems really inefficient. I might have to find some way of pre-computing some of these values. Maybe do it upon initialization of the physics object that the skydiver object will have inside it to access its physics properties. I could probably get away with pre-computing all of the values that don't deal directly with the height, which will be passed into the update function every update tick. That way I am only computing a few values that change every tick and not every value. Might save some clock cycles, we are on mobile after all. And if we are targeting Android 2.3.3, which is the most common Android install on the market currently, then there are going to be some very, very slow devices that will try and run this. That could get ugly. I think the pre-computing idea is the best way to handle this.
