Dev Blog #3

Tuesday April 22, 2014

Here we are, last day before our Alpha build is due and our presentation. The project has come a long way since the beginning. I would estimate that we are about 50-60% done, with most of the important features implemented but in need of bug fixing/more tweaks. I will talk about my physics tweaks that I did last night in a little bit. Everyone, save for a couple, did their work and contributed to the project. I applaud my team members for their hard work and dedication. Now, on to the good stuff.

So, yesterday August informed me that his text drawing for our HUD (that displays time, velocity and height) was crashing because the jumper would accelerate so fast that his speed became NaN almost instantaneously. I pounded my head against the code for awhile, then decided to comment out all of the physics I had put in and just simply make the jumper fall under the force of gravity. This allowed August to make sure his text was working fine, which it did. After that was done, I was not happy with having to scrap all of that nice physics code. So, I went back and looked over everything. I took out the gravity changes I made and put back in the original physics. I went through it line by line, and even did the calculations by hand for a couple of height values to make sure my calculations were correct. Turns out they weren't. Oops. Sign issues everywhere. I guess that's what happens when you are tired and coding at 2 AM, but I digress as there is no excuse for sign errors in the simple physics I used. I went back through it again, line by line, doing calculations by hand. I finally got all of my pre-calculated values correct (those not directly affected by height that needed to only be calculated once, and not on a per update basis. Saved us so many clock cycles and memory.) Then it was time to re-test my physics equations. Again, sign issues everywhere. I even had an arithmetic mistake (put something in the Java function Math.pow() that needed to be outside that function). Hehe, oops again. After re-writing that equation and doing hours of research to make sure that I was doing the physics correctly, I tested it one last time and HUZZAH it worked. But, with one major bug. The jumper accelerates just fine now and his terminal velocity (the real max velocity Felix hit, ~372 m/s or ~834 mph) but never slows back down. Don't know why or how. It will take a little while longer and some testing with our delta time value to see if it is a delta time issue (I think it is). But, for the alpha, it is fine as it shows that the physics model works.

Here is what the code looks like for our physics: (Keep in mind, its still a work in progress. Also, excuse formatting. Blogger doesn't have <code> tags...)

public void update(float dt)
{

//deltaT += dt;

//update the jumper's height based on the y component of position (since we are falling in the y direction)
height = position.y;

//updating our falling physics data
temperatureAtHeight = seaLevelTemp - (tempLapseRate * height);
pressureAtHeight = 1000.0f * (seaLevelPressure * (float)(Math.pow((1.0f - (height * preCalcPressureFraction)), preCalcPressureExponent)));
//pressure has to be in Pa, not kPa. so we multiply by 1000

densityAtHeight = (pressureAtHeight * molarMassOfAir) / (gasConstant * temperatureAtHeight);

//calculate air resistance
airResistance = new Vector3D(0.0f, 0.5f * densityAtHeight * (float)Math.pow(-velocity.y, 2.0f) * 0.579f , 0.0f);

//calculate net force
airResistance.add(new Vector3D(0.0f, -gravity, 0.0f));
//Vector3D netForce = new Vector3D(0.0f, airResistance.y, 0.0f);

Vector3D weight = new Vector3D(0.0f, mass * gravity, 0.0f);

acceleration = weight.subtract(airResistance).scale(1.0f / mass);
//from the formula a = (W-D)/m where W is weight, D in our case is the netForce and m is mass

//v = v0 + at
velocity = velocity.add(acceleration.scale(dt));

//check to see if we are at terminal velocity or not
if(-velocity.y > maxSpeed)
{
//if we are, we have to use -maxSpeed because we are falling in the downward direction, not up
//changing the sign below will cause the height to go back up after you hit maxSpeed
velocity.y = -maxSpeed;
}

//position = p0 + vt + (at^2)/2
position = position.add(velocity.scale(dt)).add(acceleration.scale((float) Math.pow(dt, 2)).scale(0.5f));
}

I was also able to complete the spacepod model and get it into the game. It looks really nice, especially after Matt L fixed some tessellation issues with the models themselves. I was also able to complete the cinematic for Phase 1 which I detailed and documented in my last blog post.

Until next session, thanks for reading.

Dev Blog #2

Thursday April 17, 2014

For the second blog that is required for my class, I am going to talk about how I made the cinematic for Phase 1 of our game. The cinematic consists simply of the spacepod moving upwards, to signify that it is starting its ascent to the jump altitude. This is a very, very simple animation as it just consists of a vertical translation of the spacepod over 100 frames. I chose to make the animation take 100 frames as it would slow down the speed of the animation. So, on with the details.

I first imported our spacepod model and its door into 3DS Max. In the same scene, I made a sphere object and converted it to an editable poly. I then scaled the sphere up uniformly to the size I thought would look good in the cinematic. I moved the sphere above the spacepod and focused my attention on the bottom set of faces. I highlighted those faces and extruded them down towards the spacepod. After I made the balloon and the spacepod "touch", I went ahead and attached the balloon to the spacepod using Max's Attach feature. This turns all of the different components into one model allowing you to do things to the model as a whole and not having to select each individual component. You would only do this after you were done working on each individual component and only if you wanted the model to be one component and not many components.

After I attached the balloon to the spacepod, it was time to start the animation process. I selected my model, changed to the Motion tab in the right hand side of 3DS Max and selected the Auto Key option. The Auto Key option allows you to just move the frame slider and adjust your model. It will mark the key frame automatically. So, the first frame is simply the spacepod on the ground. I moved the frame slider to the last key frame (100 in this case) and moved the spacepod up into the air. This caused the second key to be placed. Once this process was done, I went to the Render Setup menu to render out the animation. The easiest way to do this, if you want a video file of your animation, is to open the Render Setup menu, select the radio button that allows you to select a range of frames (0-100 in my case), scroll down until you see the Render Output section, click the Files button, change the output file type to a movie file (in my case, I used .avi), give your file a name and hit save. This will pop open a new window that will allow you to select a compressor for your file. I used the MJPEG compression, which cut my frames down to around 80 (this is ok, as it did not affect the speed of the animation. Just its file size). Hit the OK button and then click the Render button on the Render Setup window. Wait a few seconds/minutes depending on the complexity and frame count of your animation(s) and... Voila! You now have a rendered movie of your animation. You can then use the .avi file if your engine/framework supports it or convert it to some other file type. I converted mine to a .mp4 and a .3gp in order to test out the Android Media Player with different file types.

I followed a tutorial on this process at this link. Everything I described above can be seen in that video.