Ändringar mellan två versioner
Här visas ändringar i "Project Instructions" mellan 2015-03-23 16:38 av Christopher Peters och 2015-03-23 16:40 av Christopher Peters.
Visa < föregående | nästa > ändring.
Project Instructions (DGI15)
Deliverable Your project deliverable should be comprised of:
o A comprehensive project report. This is a textual and graphical description of how you designed the program, how it works and the theoretical aspects relating to the techniques used. This explanation should be written by you and relate to your own code (i.e. be more than simple general definitions from the lecture notes). See the “Marking Guide” below.
o A link to a blog describing the progress of the project. If elements of the blog are relevant to the report, then they may be used to comprise parts of the report (although other aspects, such as individual contributions to the project may be less suitable to the blog).
o The commented source code, project files and executable for the application in a sensible directory structure.
o Some screenshots (or even better, a small movie demonstration), where appropriate, of the output of the program - something else that is nice to integrate into a blog. If using Unity, you may like to include a web player version of your project on your blog: it's very easy to create.
Details
• You may work individually or in groups up to size three. You are recommended toshould clearly identify respective contributions of group members to the final project i.e. Tthe report should contain an explicit section outlining the individual contributions of each member of the group to the project.
• Your project - including all source (code, models, textures), executables and accompanying documentation – should be archived in .zip or .rar format and uploaded to Bilda. Do not forget to include the names and student IDs and official KTH email addresses of all members on the documentation.
• You may use any completed DGI15 lab-work, and the supplied code from the labs, as a basis for completing a project (see marking guide for details of incremental lab work). But make sure to reference all work used from sources and all collaborations, and do so clearly by identifying what sections of work you have completed.
• Make sure to keep a local copy of the source code, executable and other materials related to your project.
Project Reporting • Identification details on report. Names and student IDs and official KTH email addresses of all members.
• One page project specification.
• Clear, logical structure with headings and subheadings; well presented. Critical reflective evaluation of what you did, why you did it, what you learned. Anything interesting/surprising along the way? How did you solve challenging problems?
• Screenshots providing evidence of functionality where appropriate. A small, narrated movie demonstrating your program and its creation would be a great addition. Blogs describing progress and tutorials are also beneficial. Relevant blog entries may be taken to form report sections.
• A half page description of how the project could be improved by, informed by or related to perceptual user studies, with details from a user study that you attended.
• References to resources used and collaborations. Be explicit about exactly what work is yours and what belongs to other group members and external sources.
• References and description of state-of-the-art international work in the topic of the project and how your project relates to it.
• Presentation all of the above in a clear and concise way.
Project Grading Every project is different and will be marked based on its individual merits. However, there are some generic requirements. You should check with the course team for feedback on your project idea if you have doubts or questions. Generally, the more specific your specification/idea is, the better the feedback that you will receive.
Indicative requirements Scale Fully functioning, coherent implementation and demonstration, utilizing a good mix of graphics technologies (which should include a significant graphics programming aspect, but could also relate to modelling, interaction, perception and so on); comprehensive report. Demonstrated excellence in communication of concepts - through an illustrated blog, for example. A – C, depending on level of challenge, sophistication of results, presentation and level of achievement Small functional graphics program. Examples:
1) Extending one of the labs in order to add minor additional features;
2) A limited 3D graphics modelling project imported into Unity;
3) Another small project of your choice (check with course team).
All should include a comprehensive report.
D – E, depending on level of challenge, sophistication of results, presentation and level of achievement Additional Notes and Miscellany:
• Projects do not have to be programmed in C++, although it is desirable. One recommendation for higher grades is to re-implement a graphics and animation technique from a research paper as a C++ DLL and integrate it into the Unity engine.
• You may do projects related to plug-ins and scripts for 3D modelling software such as Blender, Maya, Max, but you should ensure that there is a programming aspect to the project (e.g. scripts to generate automated content). You can also use any engines, SDKs and libraries as required o support the project.