Difference between revisions of "Project3W16"
(→Aircraft) |
|||
(47 intermediate revisions by 2 users not shown) | |||
Line 4: | Line 4: | ||
For user input the only permissible device is the Sony Move controller (the extra credit allows an additional 3D device). | For user input the only permissible device is the Sony Move controller (the extra credit allows an additional 3D device). | ||
+ | |||
+ | If you are not familiar with air races, you might find [http://www.redbullairrace.com/en_US/video/2015-season-preview this video] entertaining and informative. | ||
+ | |||
+ | Our version of the air race actually resembles the rather new category of drone races more. [https://www.youtube.com/watch?v=Ut1EJCZpvEI Here is a great video] illustrating how it works. Here is another hopefully [http://thedroneracingleague.com/videos/preseason-gates-of-hell/ inspirational video for this project]. | ||
==Sony Move Setup (10 Points)== | ==Sony Move Setup (10 Points)== | ||
Line 11: | Line 15: | ||
If you use an Apple computer with OS X [https://docs.google.com/document/d/16oB5jpbCpeRWb0o7w0b9bFbT3vEzWGqEPESWZUSCPuU/edit these instructions] will hopefully get you going with the Move. Please post any problems you run into on the Piazza page and we'll try to help. | If you use an Apple computer with OS X [https://docs.google.com/document/d/16oB5jpbCpeRWb0o7w0b9bFbT3vEzWGqEPESWZUSCPuU/edit these instructions] will hopefully get you going with the Move. Please post any problems you run into on the Piazza page and we'll try to help. | ||
− | ==Race Track== | + | ==Race Track (20 Points)== |
− | This [http://www.calit2.net/~jschulze/tmp/engineering-campus- | + | This [http://www.calit2.net/~jschulze/tmp/engineering-campus-small.zip UCSD campus model] provides the environment for the race track. The unit size is one inch. Load it into your application and turn the buildings and the ground plane into colliders that cannot be traversed. (If you implement your game in C++ and OpenGL, you only need to make the ground plane a collider.) |
The race track is a set of check points the player has to go to in a specific order in order to win. | The race track is a set of check points the player has to go to in a specific order in order to win. | ||
− | 24 hours before grading starts (which means on Thursday, February 11th | + | About 24 hours before grading starts (which means on Thursday, February 11th around 2pm), we will post the competition file along with a note on Piazza. The competition file will be an ASCII file in the XYZ file format, listing the locations of your check points. The coordinate system will be the same as that of the campus model. An XYZ file does not have a header, it only consists of a list of point locations in 3D, in the format X Y Z<return>X Y Z<return> and so on. An example for an XYZ file defining two points is this: |
<pre> | <pre> | ||
Line 25: | Line 29: | ||
The coordinates are separated by white space or a tab character, the points are separated by a line break. On each line are three floating point numbers. The first three are the x, y and z coordinates of the first point. The next three numbers are the x, y and z coordinates of the second check point, and so on. There could be hundreds of points in the file. In this project you can assume that the competition file will not have more than 100 check points. | The coordinates are separated by white space or a tab character, the points are separated by a line break. On each line are three floating point numbers. The first three are the x, y and z coordinates of the first point. The next three numbers are the x, y and z coordinates of the second check point, and so on. There could be hundreds of points in the file. In this project you can assume that the competition file will not have more than 100 check points. | ||
+ | |||
+ | '''Update:''' The file has been posted on [https://piazza.com/class/ij10xcafu7h6db?cid=54 Piazza]. | ||
Here is what you need to do: | Here is what you need to do: | ||
* Write a parser for XYZ files. It should be a simple for loop in which you read each line of the file. In C you would use the [http://www.cplusplus.com/reference/cstdio/fscanf/ fscanf] command for this. Your parser does not need to do any error handling - you can assume that you will get a proper XYZ file. You do need to recognize when there are no more points in the file (i.e., check for End of File) | * Write a parser for XYZ files. It should be a simple for loop in which you read each line of the file. In C you would use the [http://www.cplusplus.com/reference/cstdio/fscanf/ fscanf] command for this. Your parser does not need to do any error handling - you can assume that you will get a proper XYZ file. You do need to recognize when there are no more points in the file (i.e., check for End of File) | ||
− | * Draw the check points using a method of your choice. You can assume that all check points will be floating above the campus model and will not intersect with any buildings. For instance, you can draw the check points as wireframe shperes. The goal is that the visualization should allow the player to move from one check point to the next as fast as possible without missing any | + | * Draw the check points using a method of your choice. You can assume that all check points will be floating above the campus model and will not intersect with any buildings. For instance, you can draw the check points as wireframe shperes. The goal is that the visualization should allow the player to move from one check point to the next as fast as possible without missing any. A check point is reached once the aircraft's origin gets within a fixed radius of 360 inches around the check point. |
+ | |||
+ | Here is a sample [https://d1b10bmlvqabco.cloudfront.net/attach/ij10xcafu7h6db/hm3py1plxot4dc/ikgat4z2hgvq/race1.txt race track], whose points are relative to the campus model. And here is a | ||
+ | [https://d1b10bmlvqabco.cloudfront.net/attach/ij10xcafu7h6db/hm3py1plxot4dc/ikgax0ikoedx/race1.PNG screenshot] of where the checkpoints should be located. | ||
+ | |||
+ | ==Aircraft (10 Points)== | ||
+ | |||
+ | You are free to choose any 3D model for your aircraft you would like, just not an airplane. If you don't find one, feel free to use [http://www.calit2.net/~jschulze/tmp/quadcopter.dae this Collada model of a quadcopter], provided by Professor Falko Kuester's lab here at UCSD, designed by graduate student Dominique Meyer. The quadcopter's unit is inches just like the campus model. Regardless of what aircraft model you use, for collision checks with buildings and the terrain assume an aircraft size of a cube 36 inches wide, or a sphere with a diameter of 48 inches. Your aircraft does not have to be a drone, but it should be one that can plausibly fly in any direction, not only forward like an airplane. | ||
+ | |||
+ | ==Flight Controls (20 Points)== | ||
+ | |||
+ | You need to implement two different ways to control the aircraft, both need to exclusively use the Sony Move controller. The first method is described below, the second one is up to you to create. | ||
+ | |||
+ | '''Method 1: (15 points)''' This method utilizes only the 6 DOF (degrees of freedom) position and orientation data from from controller, along with a (binary) button. The idea is that when the button is pressed, the location and orientation the controller is in at that moment is stored in memory. The user will then hold down the button as long as they want to move the aircraft around. The movement is done by fetching the 6DOF data every frame, and comparing it with the 6DOF data stored initially. The difference between the two, both in position and rotation angle, should be multiplied by a fixed adjustment factor, and then applied to the aircraft. When the button is released, the aircraft should come to an immediate stop. Example: user presses the button and moves the controller towards the eye camera, without rotating it. This should make the aircraft move forward. The more the controller is moved toward the eye, the faster the aircraft will fly. One can slow down but moving the controller away from the eye. | ||
+ | |||
+ | '''Method 2: (5 points)''' Implement your own, custom method. Try to come up with a way that works better for the scenario of the air race, allowing the player to get better lap times. | ||
+ | |||
+ | ==Wayfinding (20 Points)== | ||
+ | |||
+ | The check points can be quite far from one another, and they are not along a straight line, so it will be important for the pilot to know where the next check point is. Come up with '''at least two''' visual ways of helping the player to know where to go next (10 points for each). For instance, you could have an arrow pointing to the next checkpoint along with an indicator for how far it is. Make sure your wayfinding aids give the player an idea of both '''direction''' to (in 3D) and '''distance''' from the next checkpoint. | ||
+ | |||
+ | The wayfinding aids can be displayed either in the coordinate space of the aircraft, or in world space. | ||
+ | |||
+ | '''Grading:''' | ||
+ | * 10 points for each wayfinding aid | ||
− | == | + | ==Gameplay (20 Points)== |
− | + | The player's aircraft should start at the first check point, with zero pitch or roll (level with the ground). It should be facing the second check point. | |
− | + | You should use a third person view: the camera is somewhere behind the aircraft with the aircraft in the center of the view. | |
− | + | There should be a countdown of some sort. Before the countdown ends the aircraft can't move. Once the countdown is done, a stopwatch starts running and is shown in a fixed position on the screen. The player takes control of the aircraft and tries to fly to the next checkpoint as fast as possible. Once that checkpoint is reached, there needs to be some sort of visual notification that the checkpoint has indeed been reached. Once the last checkpoint has been reached, the race is over and the time is halted and needs to remain visible. | |
− | + | Grading will include that you fly your aircraft along all the checkpoints both with our travel method as well as your own and we record both times. Who is going to have the fastest lap time in class, and what travel control method will it be achieved with? | |
− | + | You are free to add audio to the game if you desire, but there will not be extra points for it. The benefit might be that it could improve your lap times. | |
− | + | '''Notes:''' | |
+ | * Checkpoints cannot be skipped, each checkpoint has to be reached in the correct order to finish the game. | ||
+ | * If the aircraft collides with the ground or a building it should be moved back to the last successfully cleared checkpoint in the orientation it reached it, and another countdown should be initiated before the player can continue. The time between collision and the player regaining control of the aircraft should be no less than 3 seconds. | ||
− | + | '''Grading:''' | |
+ | * -5 if reaching the checkpoints in order is not enforced | ||
− | ==Extra Credit: Two Player Mode (10 Points)== | + | ==Extra Credit: Two Player Competition Mode (10 Points)== |
Create a split screen view of your application to allow another player to control their own aircraft and compete against one another. The second player needs to use the input device from the first project (Leap or Kinect). Let's find out if the player's speed depends more on skill or on the input device. Make sure your game supports the following things: | Create a split screen view of your application to allow another player to control their own aircraft and compete against one another. The second player needs to use the input device from the first project (Leap or Kinect). Let's find out if the player's speed depends more on skill or on the input device. Make sure your game supports the following things: |
Latest revision as of 15:45, 12 February 2017
Contents |
Air Race
This project is due on February 12th at 2pm and to be demonstrated, as usual, in CSE basement lab 220.
For user input the only permissible device is the Sony Move controller (the extra credit allows an additional 3D device).
If you are not familiar with air races, you might find this video entertaining and informative.
Our version of the air race actually resembles the rather new category of drone races more. Here is a great video illustrating how it works. Here is another hopefully inspirational video for this project.
Sony Move Setup (10 Points)
To use the controller, you will have to first get its driver to work. There is no official, polished driver available because the device was made for the Playstation. However, we are providing a Windows version of the driver on our MoveInVR wiki page. On the Piazza page is a special note in the pinned area under which you can post questions about the setup.
If you use an Apple computer with OS X these instructions will hopefully get you going with the Move. Please post any problems you run into on the Piazza page and we'll try to help.
Race Track (20 Points)
This UCSD campus model provides the environment for the race track. The unit size is one inch. Load it into your application and turn the buildings and the ground plane into colliders that cannot be traversed. (If you implement your game in C++ and OpenGL, you only need to make the ground plane a collider.)
The race track is a set of check points the player has to go to in a specific order in order to win.
About 24 hours before grading starts (which means on Thursday, February 11th around 2pm), we will post the competition file along with a note on Piazza. The competition file will be an ASCII file in the XYZ file format, listing the locations of your check points. The coordinate system will be the same as that of the campus model. An XYZ file does not have a header, it only consists of a list of point locations in 3D, in the format X Y Z<return>X Y Z<return> and so on. An example for an XYZ file defining two points is this:
-200.0378 100.1279 10.0475 -202.0447 103.1288 10.0905
The coordinates are separated by white space or a tab character, the points are separated by a line break. On each line are three floating point numbers. The first three are the x, y and z coordinates of the first point. The next three numbers are the x, y and z coordinates of the second check point, and so on. There could be hundreds of points in the file. In this project you can assume that the competition file will not have more than 100 check points.
Update: The file has been posted on Piazza.
Here is what you need to do:
- Write a parser for XYZ files. It should be a simple for loop in which you read each line of the file. In C you would use the fscanf command for this. Your parser does not need to do any error handling - you can assume that you will get a proper XYZ file. You do need to recognize when there are no more points in the file (i.e., check for End of File)
- Draw the check points using a method of your choice. You can assume that all check points will be floating above the campus model and will not intersect with any buildings. For instance, you can draw the check points as wireframe shperes. The goal is that the visualization should allow the player to move from one check point to the next as fast as possible without missing any. A check point is reached once the aircraft's origin gets within a fixed radius of 360 inches around the check point.
Here is a sample race track, whose points are relative to the campus model. And here is a screenshot of where the checkpoints should be located.
Aircraft (10 Points)
You are free to choose any 3D model for your aircraft you would like, just not an airplane. If you don't find one, feel free to use this Collada model of a quadcopter, provided by Professor Falko Kuester's lab here at UCSD, designed by graduate student Dominique Meyer. The quadcopter's unit is inches just like the campus model. Regardless of what aircraft model you use, for collision checks with buildings and the terrain assume an aircraft size of a cube 36 inches wide, or a sphere with a diameter of 48 inches. Your aircraft does not have to be a drone, but it should be one that can plausibly fly in any direction, not only forward like an airplane.
Flight Controls (20 Points)
You need to implement two different ways to control the aircraft, both need to exclusively use the Sony Move controller. The first method is described below, the second one is up to you to create.
Method 1: (15 points) This method utilizes only the 6 DOF (degrees of freedom) position and orientation data from from controller, along with a (binary) button. The idea is that when the button is pressed, the location and orientation the controller is in at that moment is stored in memory. The user will then hold down the button as long as they want to move the aircraft around. The movement is done by fetching the 6DOF data every frame, and comparing it with the 6DOF data stored initially. The difference between the two, both in position and rotation angle, should be multiplied by a fixed adjustment factor, and then applied to the aircraft. When the button is released, the aircraft should come to an immediate stop. Example: user presses the button and moves the controller towards the eye camera, without rotating it. This should make the aircraft move forward. The more the controller is moved toward the eye, the faster the aircraft will fly. One can slow down but moving the controller away from the eye.
Method 2: (5 points) Implement your own, custom method. Try to come up with a way that works better for the scenario of the air race, allowing the player to get better lap times.
Wayfinding (20 Points)
The check points can be quite far from one another, and they are not along a straight line, so it will be important for the pilot to know where the next check point is. Come up with at least two visual ways of helping the player to know where to go next (10 points for each). For instance, you could have an arrow pointing to the next checkpoint along with an indicator for how far it is. Make sure your wayfinding aids give the player an idea of both direction to (in 3D) and distance from the next checkpoint.
The wayfinding aids can be displayed either in the coordinate space of the aircraft, or in world space.
Grading:
- 10 points for each wayfinding aid
Gameplay (20 Points)
The player's aircraft should start at the first check point, with zero pitch or roll (level with the ground). It should be facing the second check point.
You should use a third person view: the camera is somewhere behind the aircraft with the aircraft in the center of the view.
There should be a countdown of some sort. Before the countdown ends the aircraft can't move. Once the countdown is done, a stopwatch starts running and is shown in a fixed position on the screen. The player takes control of the aircraft and tries to fly to the next checkpoint as fast as possible. Once that checkpoint is reached, there needs to be some sort of visual notification that the checkpoint has indeed been reached. Once the last checkpoint has been reached, the race is over and the time is halted and needs to remain visible.
Grading will include that you fly your aircraft along all the checkpoints both with our travel method as well as your own and we record both times. Who is going to have the fastest lap time in class, and what travel control method will it be achieved with?
You are free to add audio to the game if you desire, but there will not be extra points for it. The benefit might be that it could improve your lap times.
Notes:
- Checkpoints cannot be skipped, each checkpoint has to be reached in the correct order to finish the game.
- If the aircraft collides with the ground or a building it should be moved back to the last successfully cleared checkpoint in the orientation it reached it, and another countdown should be initiated before the player can continue. The time between collision and the player regaining control of the aircraft should be no less than 3 seconds.
Grading:
- -5 if reaching the checkpoints in order is not enforced
Extra Credit: Two Player Competition Mode (10 Points)
Create a split screen view of your application to allow another player to control their own aircraft and compete against one another. The second player needs to use the input device from the first project (Leap or Kinect). Let's find out if the player's speed depends more on skill or on the input device. Make sure your game supports the following things:
- The two players need to fly their aircrafts simultaneously.
- At the end of the race the completion times and penalties need to be displayed for each player.
- In each player's view, the other player's aircraft needs to be displayed in the location it is at that moment.
- The two aircraft should not be able to collide with each other. They are allowed to intersect with each other with no effect.