Your final team project will give you a chance to show off what you have learned (and will be learning over the rest of the semester) by applying it to a domain of your choice. Your four-person team will design and develop an application, for which you will need to decide who your users are, what they will be able to accomplish, and how they will accomplish it. At the core of what you are doing there should be a 3D UI that supports selection, manipulation, travel, and wayfinding within some domain. You have a lot of freedom in making those decisions, but we will expect that what you design will emphasize what has been covered in this course. You can build a game, or a visualization system, or an AR browser, or.... Basically anything. Whatever you do, your work will be graded based on how well it shows off what you have learned in 4172. (Please read that last sentence again.)
Your project should be built using Unity and Vuforia on an Android or iOS device. You are also welcome to optionally support communication between that device and external processing or data resources, or use multiple networked devices running your Unity app using a desktop machine running Unity as a server. Thus, your project could involve collaboration between multiple users. (If you want to support networking, please talk to us.) If you want to use any other devices or libraries, please talk to us.
Your final project proposal should be presented through some form of presentation software (e.g., Powerpoint or Acrobat), and should last four minutes, not including time for answering questions from your fellow class members and us. Your presentation should make clear the high-level goals of your application; how you currently expect the work to be divided among your team members; the interaction techniques that you expect to use for selection, manipulation, travel, and wayfinding; how users will interact with your application (see below); and any questions that you are trying to resolve. To minimize the time it takes between teams, you will need to provide us with your presentation material by noon the day of the class at which it is due, uploading your presentation to CourseWorks, as described below.
As you craft your final project proposal, we would like to make sure that you are thinking carefully about your application in terms of the users for whom you are designing it and what they will be doing as they use it. To phrase this more formally, we would like you to create two personas and two use scenarios for your application. A persona is a fictitious person that you will make up to represent a particular class of users that you expect to support. Defining personas, each of whom will have a name, age, and brief life story, will enable you to think and talk more concretely about a specific user. A use scenario is a narrative description of how your application is used to perform a coherent set of tasks by one (or more, for collaborative applications) persona. Each of your personas should be involved in at least one of your scenarios. Please see this explanation of use scenarios and personas.
For each persona, a one-slide description in your presentation should be enough. For each scenario, you will probably want to use a series of slides in which you present a storyboard that shows how the scenario unfolds. We don't expect you to have written any code at this point, so simple hand drawings and text are all you will need. Videos of paper prototypes are also fine. And, if you prefer, a live performance is fine, too (though please shoot some pictures in advance to include in your slides).
Please name your presentation file [YourTeamName]_proposal.ext, where "ext" is the extension for that filetype. If you have a video, please name it [YourTeamName]_proposalVideo.ext. Here's how to submit your presentation through CourseWorks:
For each in-class progress report, please provide an update, of up to four minutes in length, on what your team has done since the week before. It's fine to begin with a one- or two-sentence recap of what your project is, but please don't make this a revised version of your project proposal. You should describe what you've done over the past week (including any revisions of your goals), what you expect to accomplish over the coming week, and how this positions your team relative to finishing.
As you did for the project proposal, please use some kind of presentation software. As you move past report 1, we'll look forward to seeing videos or live demos of preliminary parts of your project.
To minimize the time it takes between teams, you will need to provide us with your presentation material by noon the day of the class at which it is due, uploading your presentation to CourseWorks, as described below. The one exception will be for live demos, which you can run on your own device(s) without having to provide them to us in advance. However, if you intend do a live demo, it's essential that you make sure to practice it to fit within the time available, and know how to make it display on the projector. Electronic classrooms such as 233 SW Mudd are usually unlocked at all times, so you can stop by at off hours to test.
For each progress report, please name your presentation file [YourTeamName]_progressPresentation[N].ext, where "N" is the progress report number (1–3) and "ext" is the extension for that filetype. If you have a video, please name it [YourTeamName]_progressVideo[N].ext. Then, submit your progress report on CourseWorks, following the same steps you followed for submitting your proposal.
To help your users understand how your UI works, you should submit two kinds of documentation: a written description and a video demonstration. Please also include a screen shot and one-paragraph description. Here's more detail:
Written description. Write a document that describes how to use your system and why you designed it the way that you did. The grade you receive will depend in part on the rationale behind your choice of techniques, justified in terms of the material covered in class, in the assigned readings, and in any additional material that you have consulted. You should include screen shots in your description, integrated into the document. There is no minimum length; however, your document should fully explain your user interface and design choices. Your description should be submitted as a PDF file, although Word files will also be accepted.
Video demonstration. Create a narrated video demonstration (at most four minutes in length) that shows your system in action. (Please see the guidelines from your last assignment.)
Screen shot, paragraph, and permission. Please provide a representative, full-resolution, screen shot of your project (png or jpg) and a brief, one-paragraph overview to include on our course project overview page. If you would like to have your names listed next to your screenshot on the overview page and on the course video that we will create, please also give me your permission to do that in the form of the sentence: "[YOUR NAMES] are willing to have their names appear next to their presentation of their work on the project web page and video for COMS W4172."
In addition to the material that you hand in, your team will be preparing a live presentation of your work that will take place on TBA, starting at TBA in TBA. Your presentation should provide an overview of your design concepts, followed by or integrated with a live demo of your system. Refreshments will be provided, and we'd like each of you to be there for all the presentations. We will have at most 14 minutes per team, during which your team should be prepared to present a total of 9 minutes of material and then field questions and comments from the course staff and your fellow students. Please practice in advance to make sure that your presentation runs smoothly and on time! And, make sure that
Please bring a copy of your video [not just a link to its URL] to the presentation on your laptop. This will provide you with a fallback if you encounter problems with your live demo. We will also give you a USB stick to which we would like you to copy your video, so that (a) we do not have to download it and (b) we get an original high-quality copy.
Your submission should include your complete Unity project (but, no executables or Xcode project directories), your written description, your video demonstration, and your screen shot, one-paragraph overview, and permission to use your media and names for our projects web page. We would also appreciate your including any additional files you will use during your presentation (e.g., PowerPoint files). It is your responsibility to make sure that any file you submit is virus-free. Note, again, that any screen captures should be integrated into your written description, and not included as separate images. Each file should include your name and UNI at the beginning.
Your submission should include:
Your written description.
Your video demonstration. We strongly recommend you upload your video to a video-hosting site, a file-hosting site, or as a separate upload to your CourseWorks Dropbox for 4172.
Please compress all files in your submission (with the exception of the video) into a second parent archive file named [YourTeamName]_finalProject.[zip|tar|gz|rar]. Please remember to include all the items listed above. Remove any large extraneous files (e.g., raw video footage or screen captures) that will bloat your submission.
Please verify that you can run your executable code by first extracting a copy of this archive to a location on your computer outside the directory tree where you did your development. Then, Build from within Unity and attempt to deploy to your mobile device. Similarly, if you're uploading your video, then extract and play it, or if you're hosting your video on a video site, make sure it's playable through the URL you provide.
Submission will be done through CourseWorks. Here are the steps:
Please try to submit before the deadline since CourseWorks can sometimes become busy and slow. You may not use any late days for the final project.
Your grade for this project will be determined in part by the quality of the user interface that you implement, evaluated using the heuristics you applied in Assignment 2: http://www.useit.com/papers/heuristic/heuristic_list.html.
Enabling Extended Tracking can make it possible to work in a much larger volume.
Depending upon the size of the Image Targets you are using in this assignment, the angle with which they are viewed, and the lighting, camera position and orientation computed by the tracking software can change noticeably from one frame to another, resulting in "jitter." Consequently, the greater the distance between a vertex of an instance "attached" to an Image Target and the Image Target itself, the greater will be the variation in that vertex's position from one frame to another. For example, if you are implementing pointing with a visible "ray" emanating from an Image Target, this will be more evident in the jittering of the distant tip of the ray than in the base of the ray. In general, your scene will be more stable if (a) there are more completely unobscured, clearly viewed features that are seen simultaneously by your camera, (b) the vertices in your scene are closer to the Image Targets that define their positions, (c) the Image Targets are closer to the camera, and the (d) the Image Targets are not viewed from an extreme glancing angle.
Whatever you do, let the tracking software determine the position and orientation of the ground target and any other targets. That is, you should not require the physical camera to be at a hardwired position and orientation relative to any target.
Tracking with optical targets is sensitive to lighting and the quality and rigidity of the printed target. A dirty, crumpled, folded, or curled target will significantly decrease the quality with which you can track.
Avoid camera poses that view targets from oblique glancing angles that can cause the ink in the targets to appear shiny. Ensure that your Image Targets are perfectly flat. (You will get the best results if you glue them to cardboard or other firm material.) Please see the Image Targets guide on the Vuforia Resources site to learn how to create high quality targets.
You'll get the best results working in a brightly lit environment.
If you're having trouble implementing your desired interactions with targets, consider temporarily implementing "backup" debug interactions that use the touchscreen or 2D GUI control panels to verify the non-optical-tracking aspects of your code (e.g., your scene graph or transformations). This will help isolate problems with general program logic, scene graph design, and 3D transformations that you might erroneously attribute to optical tracking.
When using Unity Play Mode, if Vuforia doesn't have a profile for the camera you're using, you should select the shortest possible exposure time. A longer exposure time will result in blurry images during motion, which in turn will cause poor tracking. With plenty of light and a short exposure time, you should be able to get results using Vuforia as stable as these, which were run using the ALVAR tracking package on what is now a seven-year-old laptop with NVIDIA GeForce Go 7400 graphics, a 2.0 GHz Intel Core 2 Duo CPU, and 2GB RAM—hardly a heroic machine by today's standards. If your laptop camera has an adjustable focus, then set it so that the general area where you are performing your interactions is as clearly focused as possible. You will probably find it useful to disable any "automatic" brightness, contrast, or exposure options. (When using a built-in laptop camera, you may want to set ARCamera→QCARBehaviour→"Mirror Video Background".)