Progress update: Stardate 90948.29

We have made a great deal of progress over the past couple of days. The most noticeable accomplishment we have achieved is the ability to control the spaceship as it flies along its track. We implemented this by using the accelerometer and gyro data to generate quaternions, which we then used to rotate the craft. To control the vertical movement of the ship on the screen, we took the pitch of the device and then used this value translate the ship up or down. The larger the difference between pitch readings, the greater the translation of the ship in the vertical direction. To control the horizontal movement of the spacecraft, we used the roll readings to generate a translation. However, since the ship is turning along a track, we were required to perform extra calculations to determine the horizontal directions to translate along. We accomplished this by taking the cross product of the ship's forward vector and the camera's up vector. This produced a vector pointing to the right of the ship. Using this vector, we were able to determine the proper directions to translate towards.

//insert flight video here

We  greatly improved the look of our application, as well. We were able to apply a texture to the ground plane. To achieve the most believable effect, we tiled a seamless texture on the texture. To reduce aliasing artifacts, we applied mip maps. This allows the texture to blur over distance, as opposed to generating the wave pattern that aliasing generates. We were also able to implement a skybox. We achieved this by creating a large cube around our scene. We then created a cube map from a texture file and applied this to the skybox. The texture we chose was a seamless texture, so as to hide the corners of the cube as much as possible. In order to allow the skybox to be seen, we needed to increase the distance to our far plane by quite a large factor.

We were also able to implement both a toon shader and environment mapping. Working with the openGL es 2.0 version of GLSL proved to have its own unique challenges. We discovered that the openGL es 2.0 pipeline was quite different from the desktop version of openGL. While standard openGL uses a fixed-function pipeline unless otherwise specified, openGL es 2.0  has no such thing as a fixed-function pipeline. Each necessary value must be explicitly passed to the shaders via attribute or uniform variables. Another challenging difference between the openGL versions was the variables automatically set by openGL that are available in the shaders. OpenGL GLSL had named variables, such as lightSource[0] and ftransform(), that allowed you to access attributes of various items in the main program. The es 2.0 version had an extremely limited set of such values. If a light position or color was needed by a shader, it was required to be saved in the main program and passed in as an attribute or uniform variable. To accomplish the environment mapping we created a cube and textured it using a cube map. We then used the values from this cube map to apply color to the object.

//insert toon/environment map video here

To provide a challenge for the player, we procedurally generate obstacles for them to fly through. We algorithmically generate tori around the path that we defined for the ship to automatically fly on. Each of these tori is then translated away from the track and scaled by a randomly generated value. This produces rings of various size and locations that the player must fly through. Our plan is to perform collision detection with the tori, so that the player can fly through the center of a torus or collide with the ring portion. This collision detection is our last main feature that has yet to be implemented.