Extra Credit Video (Linked on youTube):
http://www.youtube.com/watch?v=QRfySN4BIyo
Thursday, December 12, 2013
Wednesday, December 11, 2013
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.
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.
Sunday, December 8, 2013
Progress Update:
We are still making progress with the toon shader.
Since we had the gyro and accelerometer movement working for the ship, we next tried to have the camera move with the ship in front of it. We have the camera moving along a parametric path, which will allow the game to keep track of laps and allow us to scale the difficulty based on how long the player has survived.
We used a solid green plane as the ground and tried keeping the ship in front of the camera by taking the camera position and translating that position by 4 times the unit vector representing the direction the camera is pointing. This is the location where the ship would be. We then had to account for the fact that when the camera turns, the ship will need to rotate so that it is facing forward with respect to the camera. The angle of rotation needed was found by taking the inverse cosine of the dot product between the ships original facing direction and the direction the camera is facing. This was the result we got (Note: its a top down view since from the camera's perspective its hard to distinguish movement without any other items on the surface, and the path is shrunk to fit the whole movement on the screen):
Since the ship was doing a strange rotation, we knew there was something wrong. We noted that the directions the ship would face only accounted for 180 degrees of motion. This meant that the angle being returned from the inverse cosine of the dot product was never negative. To fix this, the cross product of the two vectors was taken as well. If the result had a positive y value (meaning up), then its a rotation counter-clockwise and the angle remains positive. If the result had a negative y value (meaning down), then its rotation is clock-wise and so the angle is made negative. This was the result after this change:
Success!
Side note: We are still trying to figure out what is causing the strange lighting change while it moves.
We are still making progress with the toon shader.
Since we had the gyro and accelerometer movement working for the ship, we next tried to have the camera move with the ship in front of it. We have the camera moving along a parametric path, which will allow the game to keep track of laps and allow us to scale the difficulty based on how long the player has survived.
We used a solid green plane as the ground and tried keeping the ship in front of the camera by taking the camera position and translating that position by 4 times the unit vector representing the direction the camera is pointing. This is the location where the ship would be. We then had to account for the fact that when the camera turns, the ship will need to rotate so that it is facing forward with respect to the camera. The angle of rotation needed was found by taking the inverse cosine of the dot product between the ships original facing direction and the direction the camera is facing. This was the result we got (Note: its a top down view since from the camera's perspective its hard to distinguish movement without any other items on the surface, and the path is shrunk to fit the whole movement on the screen):
Since the ship was doing a strange rotation, we knew there was something wrong. We noted that the directions the ship would face only accounted for 180 degrees of motion. This meant that the angle being returned from the inverse cosine of the dot product was never negative. To fix this, the cross product of the two vectors was taken as well. If the result had a positive y value (meaning up), then its a rotation counter-clockwise and the angle remains positive. If the result had a negative y value (meaning down), then its rotation is clock-wise and so the angle is made negative. This was the result after this change:
Success!
Side note: We are still trying to figure out what is causing the strange lighting change while it moves.
Subscribe to:
Posts (Atom)