====== Final Project ====== **Group Size:** 1-3 people\\ **Deliverables:** Working "tech demo" (shown live, but submitted as video), short presentation and a 3-4 page report\\ **Judged on:** Technical quality, originality/creativity, amount of effort, delivery of demo and presentation, clarity and completeness of report\\ ===== Registered Teams ===== ^Team^Members^Project Title^ | Team 1 | Ásgeir | Shady: Component-based architecture for flexible tool support | | Team 2 | Hjálmar, Arelíus, Viktor | Toonshading Manic Munchins | | Team 3 | Helgi | Stereoscopic viewing in Ogre 3D | | Team 4 | Marinó, Ragner | Predator vision effect | | Team 5 | Bæring, Pétur | Open map navigation in Unity 3D (part 1) | | Team 6 | Heiðar, Stefán | Open map navigation in Unity 3D (part 2) | | Team 7 | Malte, Óli, Haukur | Distance rendering for scope vision | | Team 8 | Karl | Fire particle system | | Team 9 | Sigtryggur, Þórarinn | Elemental destruction effect | | Team 10 | Guðjón, Ægir | Inverse kinematics for arms in Ogre 3D | | Team 11 | Kristján, Kristófer | Path finding in a tile based environment | ===== Presentation ====== ==== Time and Place ==== All presentations take place Tuesday April 9th (14:00-16:30) in M106. ==== Format ==== The total time you have is about 10 minutes. Aim for 4-6 minutes for slides and 4-6 minutes for demo and questions. === Slides === You should have a slide for: (1) Purpose/Motivation (what is your technology for); (2) Related/Existing Work (similar things that exist / what work did you build on); (3) Your Contribution/Exciting Technical Features/Solution. The purpose of the slides is mainly to establish that you know **why you are doing this**, and that you know **that others have tried before** and that you have **done something technologically interesting**. The final report will go into more technical discussion, so you don't have to go into too much detail unless you would like to explain something in particular in some depth. === Demo === Use your time well. **It is very important to plan/rehearse your demo**. There is nothing worse than trying to figure out during your presentation what you would like to show us. That typically means you spend valuable time messing around with the interface and/or forget to show a couple of important things. Write down on a piece of paper a demo script and time it before you arrive, so that you know that you can get through it in the allotted time slot. ===== What to Hand In ===== There are three things you need to hand in: - Your presentation slides. - Technical Report: A 2-4 page document describing the technology you presented in more detail. See the full section on report below. - Screen capture video: Use screen capture software (e.g. [[http://www.fraps.com/|Fraps]] to capture a run through your demo. Compress that capture and either submit it into MySchool along with the reportif it is small enough or submit a link to it. You do not have to provide narration. The video and the report will tell the story together. - Optional: if you can produce a runnable version of your demo, I would love to get a copy. You are not required to do this, since it may be hard to make this portable. It will not factor into your grade whether you can do this or not. ===== Judging Criteria ===== This project will be graded on: * Technical soundness (did you get the technical demo to work "as advertised"?) * Knowledge and amount of effort (did you clearly spend time on solving the technical challenge?) * Clarity of presentation (do you explain and pace your presentation well and technology demonstration and ?) * Quality of report (structure, readability, technical contents) ====== Final Project Report ====== ===== Contents ===== This is a short but informative, report about the final project that should include: - Title / Authors - Screen shot (at least one at the very top of the paper - see formatting instructions below) - Short abstract (at least one paragraph summarizing what your project is about) - Motivation (what is your technology addressing? who would want to use it?) - Related work (examples of similar things other have done. what existing work do you build on?) - Approach (explain your technical design and implementation) - Results (mention what worked and didn't work) - Future work (what would you do next if you had more time?) - References (a list of cited references in the correct format - see below, even if you only have one or two) Think of this as a poster submission to a conference. ===== Format ===== The paper should be written in a 9 or 10 point justified serif (Times or Times Roman) font in two columns per page, with a single line space. It should be 2-4 pages long. Other than that, follow the guidelines for a technical paper submission to the SIGGRAPH conference as much as you can (don't worry too much about the details, just get a feeling for the overall structure and look): * [[http://www.siggraph.org/publications/instructions/|SIGGRAPH Instructions for Authors]] * [[http://www.siggraph.org/publications/instructions/acmsiggraph.zip|SIGGRAPH Submission Template]]